Actually, two bytecounts have been changed (automatically by RevEngEd 2).
Also bytes @38542 have been changed, from 12362 to 30168.
Actors.bin has a recursive structure.
You have a block, which is "ID [2 bytes] - length [4 bytes] - *data [length-6 bytes] ".
*data could be two things
- a list blocks (recursive, nodes of a tree)
- some final values (leafs)
The "-6" is because "length" is for the entire block, id and lenght-bytes themselves included.
An example will make it clear. Look again at this log:
actors.bin.txt
0x534C [68708] (19539) .BIN file > this is the outer block
- 0x534 is the ID (2 bytes), i.e. "SL" (bytes 0-1)
- [68708] is the int value for bytes 2-5 and is the length of this block. In this case, the block is the file, so this is also the file length
- (19539) is just the int value for 0x534C, don't mind it
The main block contains (in this case) two blocks: Specifications block (line 2 of log) and Definitions block (line 2543 of log).
Specification block has:
- ID: 0x0040 (bytes 6-7)
- Length: 38534 (bytes 8-11)
38534 is the length of the specifications block, and the next 38534 - 6 bytes will contain all specifications (-6 because of 6 bytes are used to store ID and length)
So go at byte 38534 (specs length) + 6 (ID and length of the outer block): @38540 the definitions block starts.
It is:
- ID: 0x20AE (bytes 38540-38541)
- length: 30168 (bytes 38542-38545)
The next 30168 - 6 bytes are the definitions. If you add manually a definition using a hex editor, you should also change the entire file byte count and the definitions block byte count.
Now, if you look at every definition (I imagine you can tell where they start and end, because you handled them),
you'll notice that they have the same structure (ID, length, data).
So, the first definition is the one for "m_B2_zebr_", which has
ID: 0x21AE @38546
Len: 57 bytes
Data.
At 38546 + 57 will start the second definition.
Also, the "m_B2_zebr_" has recursively the same structure, divided into 3 blocks
Block1 @38552 > ID: 0x23AE, length 17, then 17-6 charactes as the LABEL (with 0x00 as string end)
Block2 @38569 > ID: 0x22AE, length 10, then 10-6 bytes which are the int value representing the type for this definition (in this case is 8, i.e. a LADDER)
Block3 @38579 > ID: 0x24AE, length 24, then 24-6 bytes which are the very definition for ladder "m_B2_zebr_"
I hope this is clear enough.
Scene2.bin works the very same way, but it's more complex.
Here an example log:
scene2.bin.txt
I don't know why you can't delete object in this scene2.bin with DC|ED. DC|ED can't handle correctly the bytecounts, so a manual (hex editor) work should be done (at least until RevEngEd 2 is released
)