quote:Yes, this is something that I've noticed/encountered a while back (maybe a year or so ago) but haven't documented it. I've figured how to work with it but don't know exactly the rule. I'll write what I know and how I work with it.
i've got some trouble to find some hex near Noumea in Coral Sea... it seems that the hexes down here have a different coordinate system... is it possible ?
For exemple, Noumea is 143,194 and so should be 73410. But in the file, the hex is noted 7874. So the coordinate "line" seems to be in fact "15" instead of "143".
What do you think ?
Encoded coordinates logged by the game in the USR(8) field do not exceed 2^16, or 65536. So for example, if the coordinate you're working with is, [x=164,y=50] = 84018, USR(8) will be equal to 84018 - 65536 or 18482. However, the field before this value (i.e., USR(7)) will not be 0. I haven't figure out specifically what different non-zero values mean except that a non-zero field will distinguish this coordinate from [x=36,y=50] which also is equal to 18482.
And for your case, x=143, y=194; USR(8)=(512 x 143 + 194) - 65536 = 73410 - 65536 = 7874. However, USR(7) is (must be) non-zero in order to distinguish it from the x=15 & y =194. This coordinate, which also is 7874 will have USR(7) = 0).
On the upside, you can edit a game file and put a coordinate in greater than 65536 in USR(8) provided the preceding field (i.e., USR(7) is zero). You can then load that game file and (re) save it and MWiF will take care of the wrap around (i.e., subtracting 65536) and populating USR(7) with a non-zero value. If you're editing a coordinate that is already larger than 65537, in which case USR(7) ~= 0, you can use the formula USR(8) = 512x + y - 65536 to change the coordinate provided the new (unwrap) coordinate is also greater than 65536. That is, USR(8) can NEVER be less than 0.
< Message edited by rkr1958 -- 2/2/2018 10:59:11 PM >