Skyrim Mod talk:Mod File Format/REFR

XMBO

This three floats are duplicated in all instances I observed as the first three floats of the XPRM field. They are displayed in the CK under Primitive/Bounds (value multiplied by 2 there). Changing values there seems to change them for the XPRM field only, XMBO is unchanged. Are there two sets of bounding data? --Alfwyn (talk) 17:58, 16 November 2012 (GMT)

Interesting question. Unfortunately, I got sidetracked into doing other things last night and had to put this project down. I'll be doing more investigation later today, I hope, so I'll post back here if I develop any insights. – Robin Hood↝talk 18:11, 16 November 2012 (GMT)

Well, I've got a hint of an answer. Have a look in Skyrim.esm at 0x00102D52. In that record, the XMBO and XPRM values are different. When you open it in the CK (under Interiors/MarkarthVlindrelHall), you get the error message "FORMS: Primitive reference 'RoomMarker' (00102D52) has half-extents that differ from its multibound data." and the object is marked as changed. That suggests that XMBO is short for "multibound (object?)", though I don't actually see anything under the "multibound" tab. It also answers a very minor question on my end, which was why it was divided by two; the name "half-extent" pretty much tells us that. My 3D graphics processing knowledge is next to nil, but browsing around, I was at least able to confirm that half-extents are common for box objects, so nothing unusual here as far as that goes.

Also, for the float and the int at the end of the XPRM field: my float values are yours divide by 10 (i.e., 0.15 and 0.2). For the int, a few objects in Hearthfire (0x01000B7E - 0x01000B9E) have a 3, as well as a bunch in Skyrim (haven't looked at others), which tentatively hints that it might be a flag field of some kind, though with only 1s and 3s to go on, that's a total guess. – Robin Hood↝talk 06:48, 17 November 2012 (GMT)

Ok, that error message is interesting. On the other hand I can't confirm that they are different for that HF record, the fact it shows as changed for you, suggests it is in fact changed in your version. The half-value things is just convenient. Given the middle of the box as position, you can just add/substract the values to get the position of the outer bounds. I'll have a look at the last two values, but I didn't change those, it's probably older speculation, a lot of those are inaccurate. --Alfwyn (talk) 19:07, 17 November 2012 (GMT)

It's only changed in the Skyrim version; in the HF version, it's corrected. Given that the CK marked the record as changed when I opened only Skyrim.esm and made no changes at all, I suspect they built in some kind of automatic checking/fixing at some point, so it got included in HF automatically. – Robin Hood↝talk 20:30, 17 November 2012 (GMT)

Oops, missed that, thanks. --Alfwyn (talk) 21:22, 17 November 2012 (GMT)

XTEL

The description here suggests that the positioning data is 'relative', maybe relative to the selected door object. But according to my test results its the absolute positioning in the cell for the exit. For example a positioning of x = 0, y = 0, z = 0 will teleport characters to the centre of Skyrim and not to the centre of the exit door reference. — Unsigned comment by 182.189.231.83 (talk) at 17:56 on 6 December 2014

I just checked one at random, but it looks like you're right. I've made the change to the page. – Robin Hood  ^(talk) 19:44, 6 December 2014 (GMT)

DATA

It says here that you can divide x,y by 4096 to get the cell coordinates but the point x=0,y=0 is the bottom left of the cell 0,0 hence it will work for +ve cell coordinates but not negative ones. I think doing (if (x < 0) -> cell_x = (x/4096)-1 and same for y might do.) — Unsigned comment by 39.34.177.205 (talk) on 26 December 2014‎

Good catch! Your formula would work, or if the language you're using has a Floor() function, that should work too. I've altered the page accordingly. – Robin Hood  ^(talk) 07:22, 27 December 2014 (GMT)