D
DLPB_
Guest
ujunon1 example
The unknown bytes in walkmesh > misc.
At least some of these are to do with the starting offsets X and Y for field.
I am currently adding field centring to Aali's driver and I had to look at the asm. When I traced back what values were involved in the main screen offset X Y for field, this data is used. For example, Y offset (or one of the ones involved) is at MainFieldOffset + 0x24
006443F9 - 0FBF 48 24 - movsx ecx,word ptr [eax+24]
ujunon1
Code: [Select]
You can see here the A0 (Movement orientation) and 40 (Camera focus) - but the 0x24 byte is offsetY of the screen.
In fact a lot of those values marked 00 in misc are set in the function involved with the address above. I have successfully changed global Y offset without interfering with this data. I was going to force the change by bypassing this, but some fields are relying on this data.
From the 3rd byte on of misc data (zeroed part), it seems to conform to MainFieldOffset + 0x22 onwards. I am unsure what the preceding 2 bytes do at this time but they don't match 0x20 and 0x21.
For example, in bwhlin2 misc unknown data is
00 f7 80 f6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Yet we see in asm
62 77 68 6C 69 6E 32 00 00 80 00 00 60 FF 88 FF A0 00 78 00 00 00 01 00 00 04 00 04 00 04 00 04 88 FA 80 F6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Above in red, the main Y offset of screen. Chances are that changing this word to 10 (or perhaps 8) will centre the field (or at least move it down)- but will need some testing.
The unknown bytes in walkmesh > misc.
At least some of these are to do with the starting offsets X and Y for field.
I am currently adding field centring to Aali's driver and I had to look at the asm. When I traced back what values were involved in the main screen offset X Y for field, this data is used. For example, Y offset (or one of the ones involved) is at MainFieldOffset + 0x24
006443F9 - 0FBF 48 24 - movsx ecx,word ptr [eax+24]
ujunon1
Code: [Select]
Code:
75 6A 75 6E 6F 6E 31 00 00 A0 40 00 00 FF 00 FF 00 01 00 01 00 00 00 00 00 04 00 04 00 04 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 63 02 78 00 00 00 4A 02
In fact a lot of those values marked 00 in misc are set in the function involved with the address above. I have successfully changed global Y offset without interfering with this data. I was going to force the change by bypassing this, but some fields are relying on this data.
From the 3rd byte on of misc data (zeroed part), it seems to conform to MainFieldOffset + 0x22 onwards. I am unsure what the preceding 2 bytes do at this time but they don't match 0x20 and 0x21.
For example, in bwhlin2 misc unknown data is
00 f7 80 f6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Yet we see in asm
62 77 68 6C 69 6E 32 00 00 80 00 00 60 FF 88 FF A0 00 78 00 00 00 01 00 00 04 00 04 00 04 00 04 88 FA 80 F6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Above in red, the main Y offset of screen. Chances are that changing this word to 10 (or perhaps 8) will centre the field (or at least move it down)- but will need some testing.
Last edited: