Punkline
Dr. Frankenstack
- Joined
- May 15, 2015
- Messages
- 423
Achilles1515 made an illuminating note earlier about how the game keeps track of where these converted offsets are in the relocation table of a Plxx.dat file.14000000 0000XXXX and 1C000000 0000XXXX are "black sheep" and f**kin' weird.
These commands still remain likes ghost even though you delete these commands.
For example,
this commands
14000000 000035F8 ...........
change to
08000005 2C00000A ..........
In this case, game will freeze when hitbox hit a character because damage is 504%(0x1F8%).
So, we should be careful not to move these commands.
Edit: he also made another post that goes into more detail with an example.
I’ll try to explain with some pictures Ampers @tatatat0 @Itaru
Special events like 14 and 1C point to specific offsets in the .dat file. When loaded in the game, they are copied into memory and need to have their offsets recalculated as RAM pointers:
After being loaded into the game, both 14 events in DK’s taunt get converted into something like this:
14000000 00003944 -- file offset
->
14000000 812778A4 -- dynamic pointer
So when you try to edit these 14 and 1C events, the relocation table still tries to convert what it thinks are offsets--even though the data has been changed.
---
It seems to be possible to prevent this from happening.
Take note of the location of the offset in your problematic 14 or 1C event modification and find the start of the relocation table from the value in 0x4 of the .dat header. Then scroll down until you find the location of your offset:
You just need to get the relocation table to stop referencing the locations you want to edit.
Edit: This part is where I don't really know what to do... It seems like editing the table too severely would mess up a few things.
I thought a benign way to go about it might involve replacing the the problem offsets with the next valid table offset, like this:
I figured this would get the job done without anything too heavy being done to the table; but it seems to mess up the offset calculation for the repeated entry.
Does anyone know of a simple way to eliminate these entries without like, changing the file size? It DOES seem to fix the conversion ghosts:
After being loaded into the game, both 14 events in DK’s taunt get converted into something like this:
14000000 00003944 -- file offset
->
14000000 812778A4 -- dynamic pointer
So when you try to edit these 14 and 1C events, the relocation table still tries to convert what it thinks are offsets--even though the data has been changed.
---
It seems to be possible to prevent this from happening.
Take note of the location of the offset in your problematic 14 or 1C event modification and find the start of the relocation table from the value in 0x4 of the .dat header. Then scroll down until you find the location of your offset:
You just need to get the relocation table to stop referencing the locations you want to edit.
Edit: This part is where I don't really know what to do... It seems like editing the table too severely would mess up a few things.
I thought a benign way to go about it might involve replacing the the problem offsets with the next valid table offset, like this:
I figured this would get the job done without anything too heavy being done to the table; but it seems to mess up the offset calculation for the repeated entry.
Does anyone know of a simple way to eliminate these entries without like, changing the file size? It DOES seem to fix the conversion ghosts:
Last edited: