using jump sections for compression seems bad, if what i've googled is right
implode : lz77 + shannon coding?
jump section are somewhat random. (deff ffff in middle of positive number)
if what i've googled is right, then blocks of 0 (000000000000...0000) should be encoded by less than 8 bytes in lz77. (from wiki - lz77 and lz78.)
Instead of nulling things, it may be better to fill them with prior character. This may compress 1~2kb more?)
ex) a0000000 -> aaaaaaaa, a0000b000cd0 -> aaaaabbbbcdd
Even SMC seems to not handle jump section properly
Post has been edited 1 time(s), last time on Mar 3 2013, 9:18 am by trgk.
EUD
SDE, BWAPI owner, hacker.
Well the jump section would probably work in the duplicate triggers/unit cases. I don't think you're right about repeated bytes, since this increased the size of my test map. The MPQ compression library being used might be a little at fault. Perhaps we should be looking there?
So bad MPQ doesn't know it's compressing triggers for example. If only it was taking into account the real structure of data being compressed... *sigh* Anyways, I was thinking for a moment about duplicate triggers and couldn't come up with many useful examples. They might be used here and there, but from my experience the majority of triggers are binary countoffs. If only it was possible to compress series of triggers with minimal changes (that actually follow a pattern) then it was a *real* breakthough.
P.S. By the way, is it possible to include jumps into conditions or actions? That could probably be more useful than compressing entire triggers.
Some.
P.S. By the way, is it possible to include jumps into conditions or actions? That could probably be more useful than compressing entire triggers.
No fields are available for doing so, it's sometimes possible to "jump" actions with waits; very tricky to make even small systems work off this though.
Edit: Perhaps it's possible to engineer a escape from a trigger by causing some kind of exception to be thrown given certain map conditions?
Post has been edited 1 time(s), last time on Mar 4 2013, 8:05 pm by jjf28.
TheNitesWhoSay - Clan Aura -
githubReached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.
Well the jump section would probably work in the duplicate triggers/unit cases. I don't think you're right about repeated bytes, since this increased the size of my test map. The MPQ compression library being used might be a little at fault. Perhaps we should be looking there?
Yeah I was wrong.
Tested with python with some test protection applied. (Including Jump section intersection)
- (4)Python1.3.scx : original
- (4)Python1.4.scx : jump section compressed + Test melee compression of scxcomp.
- (4)Python1.5.scx : TM2ed. (Just.)
- Anyway, why does TM2 set human slots to computers?
Should finalize this soon...
Attachments:
EUD
- Anyway, why does TM2 set human slots to computers?
It sets humans to computers only for melee maps. It makes it so that they don't give errors if you try and load in Use Map Settings (UMS sections do not exist in melee maps), and because it makes more values the same and removes some VCOD values.
TinyMap2 - Latest in map compression! ( 7/09/14 - New build! )
EUD Action Enabler - Lightweight EUD/EPD support! (ChaosLauncher/MPQDraft support!)
EUDDB -
topic - Help out by adding your EUDs! Or Submit reference files in the References tab!
MapSketch - New image->map generator!
EUDTrig -
topic - Quickly and easily convert offsets to EUDs! (extended players supported)
SC2 Map Texture Mask Importer/Exporter - Edit texture placement in an image editor!
This page has been viewed [img]http://farty1billion.dyndns.org/Clicky.php?img.gif[/img] times!
Test build. I don't know if this works well. (It may eat up your trigger)
Jump section 'Compression' enabled.
- Edit + file
Attachments:
Post has been edited 1 time(s), last time on Mar 11 2013, 12:21 pm by trgk.
EUD
+ GUI
+ Indivisual wav's size won't enlarge anymore. If scxcomp failed compressing it, then it will leave it as-is.
(Compressible wav file will have the same compression as before)
Post has been edited 3 time(s), last time on Mar 13 2013, 12:02 pm by trgk.
EUD
SDE, BWAPI owner, hacker.
Are you also using the source for the MPQ compression (so that it could be modified)?
Are you also using the source for the MPQ compression (so that it could be modified)?
Yes. But I don't know if I can modify them properly.
EUD
SDE, BWAPI owner, hacker.
If you share your current source code, I could take a look at it if I have some time.
If you share your current source code, I could take a look at it if I have some time.
It's spaghetti code... (VERY Seriously.) Maybe I should use some time to make this more readable...
Collapsable Box
mpqrw\ : function for mpq reading/writing. This had been extended to decrypt mpq protection by SMC. (This project is intended to not unprotect many unprotectors.)
mpqfcnt.f/cpp : Some function set for easy read-write of mpq thing.
recover.cpp : Reads chunks.
chunk.cpp, chunk.h : Some chunk-related functions.
repair.cpp : (Source code name is in this way, because this project is derived from src of An Unprotector...) Applies some protection. Very messy;
mkpsolver.cpp - Trial & Error.
offset_table_solver.h/cpp : Code to utilize jsp(Jump Section Protecton) for compression.
and many others...
Attachments:
EUD
SDE, BWAPI owner, hacker.
There's a comment in imp.c
//
// The following part checks if there isn't a longer repetition at
// a latter offset, that would lead to better compression.
//
// Example of data that can trigger this optimization:
//
// "EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEQQQQQQQQQQQQ"
// "XYZ"
// "EEEEEEEEEEEEEEEEQQQQQQQQQQQQ";
//
// Description of data in this buffer
// [0x00] Single byte "E"
// [0x01] Single byte "E"
// [0x02] Repeat 0x1E bytes from [0x00]
// [0x20] Single byte "X"
// [0x21] Single byte "Y"
// [0x22] Single byte "Z"
// [0x23] 17 possible previous repetitions of length at least 0x10 bytes:
// - Repetition of 0x10 bytes from [0x00] "EEEEEEEEEEEEEEEE"
// - Repetition of 0x10 bytes from [0x01] "EEEEEEEEEEEEEEEE"
// - Repetition of 0x10 bytes from [0x02] "EEEEEEEEEEEEEEEE"
// ...
// - Repetition of 0x10 bytes from [0x0F] "EEEEEEEEEEEEEEEE"
// - Repetition of 0x1C bytes from [0x10] "EEEEEEEEEEEEEEEEQQQQQQQQQQQQ"
// The last repetition is the best one.
//
I would have to sit down and take a look if I wanted to really understand the algorithm used.
