SDE, BWAPI owner, hacker.
What is "Jump section protection"?
Set section size to negative -> jump back.
I think that this haven't been used at any protectors yet. Though this can be broke quite easily.
Many mpq based compression has already been done in mpqrw library.
..though I still can't catch up TM2's chk compression...
That's a very interesting suggestion actually. It might be possible to embed chk sections in other sections this way. For example, you could theoretically put FORC and OWNR INSIDE the VCOD or other unused part of the chk. This might improve compression slightly by eliminating voids of unused data (0's). Using your own dummy section to jump to different parts of the chk could come in handy. It may even be possible to overlap similar data which might have a significant impact on compression.
Again, in theory, this is a really good idea and definitely worth exploring if you're really interested in improving current chk compression techniques. Make sure you've mapped out the used and unused bits, then check to see if overlapping can occur.
Just to lay it out:
UNIT<size>
<unitdata>
OWNR<size>
<ownrdata>
JUMP<afterLastJumpLocation>
<unitdata>
JUMP<ownrLocation>
You could also put it into an infinite loop, however I don't think that would be much use since there is no break condition.
A possible use case?
Suppose you are not using any upgrade settings, then your UPGx section will have a lot of voids (what you would normally change to 0). You can embed the TECx section right inside of it. Since the value of the voids don't matter (doesn't have to be 0) you can possibly save space this way.
As I'm writing this, I found a use case for the "loop" idea. Suppose you want 30 stacked minerals. Well, by looking at the data structure, we see that the last 8 bytes of the UNIT structure for MOST units are unused. What can fit in 8 bytes? A section header! We can have ANOTHER UNIT section embedded within the current one! Ok ok, let's not get too excited, let me lay this out slowly.
We have to use 4 ideas to make this work.
- We can have duplicate, stackable, UNIT sections
- We can jump to any position in the chk. (the idea that was brought up)
- Knowing the fact that the last 8 bytes of a UNIT structure are unused in most cases.
- Knowing that Start Locations aren't added to the game as units (this is used to jump out of the "loop" and to maintain a fixed count prior)
We can get 30 with 8+8+8+6
The structure of units can be layed out as follows:
UNIT<size>
<some units>,UNIT<9 units> v--make8_1
dummyStartLoc,UNIT<9 units> v--make8_2
minerals
minerals,UNIT<8 units> v--make6
minerals
minerals
minerals
minerals
minerals
minerals
JUMP<make8_2>dummyStartLoc
JUMP<make6>dummyStartLoc
JUMP<leave>dummyStartLoc
JUMP<make8_1>
OWNR... <-- leave
dummyStartLoc could be any start location for any player, I believe the last start location placed is used for the player, so you can place the actual start location between make6 and leave.
EDIT: To compare, the above uses 12 unit slots as opposed to the original 32.
The same can be used (more easily) for triggers and briefings, especially if you have more than two of the same trigger!
EDIT: Don't forget that section header names (might) be able to be 0 as well, so 'JUMP' would be 0, ensuring that the only non-zero bytes would be the location of the jump.
EDIT2: Credit to trgk
EDIT3: Stackable sections: UNIT, THG2, TRIG, MBRF. However, THG2 probably won't work too well.
Post has been edited 2 time(s), last time on Mar 1 2013, 10:51 pm by Heinermann.