make sure u have the latest version i had a similiar problem but it was fixed with the last update, farty one other problem i noticed was for Player 1 the fog of war was reset, like everything was blacked (Layer --> Fog Of War) even tho i had everything lit up, it reset it

Quote from O)FaRTy1billion

Could you tell me the values of Global Start Level, Global Max Level, the Default checkbox of the applicable player, and the player Start/Max levels?

{0;20;0;20}

it does the same when replicating the conditions.
testmap.scx (52.06 kb) -- 3 hits testmap1.scx (6.64 kb) -- 1 hits

Hmm ...
The steps I used in the upgrades is:
- If the upgrade is unused or if the player is unused, then null the player settings (use default, player start level, player max level.) This should not be the case as the player is not unused.
- If UseDefault or if player settings == default settings, then clear player settings and set UseDefault. This should also not do anything since UseDefault is being set ...

;o

Apparenltly the Default Max is being cleared.

EDIT:
Aha! I found it!
In my code to clear Upgrade 60's Max Level (as you cannot upgrade it) I forgot to add the index, so it's clearing Terran Infantry Armor.

EDIT2:
Ok, I did something to the Fog of War layer for those who are having that problem.
Post 1 updated with new version.

I don't know if this is possible with your current implementation, but could you make compressing sections/chunks optional? For example: have a checklist with all the known sections, and add a check to the sections you want to compress by editing the data.

If you can just turn off the buggy sections (MASK for example was messing up, those people could simply disable tinymap from editing that section and the fog of war would work). It seems like you already have this compartmentalized already, but I don't know how hard it would be to code something like that.

Most compression comes from simply compacting the mpq archive anyway.

Where would I put such a checklist? ;o

Quote from rockz

Most compression comes from simply compacting the mpq archive anyway.

What I do to each section makes that section more compressible in the MPQ, that's how TinyMap2 makes maps so much smaller. ;o

hopefully in the "options" section.

I was assuming there were better ways to compact the archive without changing any data in scenario.chk, much like a "best compression" method utilized by rar and LZMA.

I remember opening a map in uberation, compressing it, extracting the scenario.chk, then reinserting it with winmpq, and the filesize jumped back up to normal.

Super thanks Farty! /bighug

Blargh it didn't work for me. It opens OK, then I choose a map and press save and it freezes. About the third attempt, it just crashed after I selected a map (a random version of temple siege).
I tried it on windoze XP with SP3. I'll try it on vista later.

Also, apparently OSMap 2 can unprotect it. I thought it was supposed to be compressed so much that it beat all the unprotectors?

Does it not work for any map?

Have you opened OSMap 2's output in an editor and tried doing anything with it?

In any case, protection was not my goal.

Quote from O)FaRTy1billion

Does it not work for any map?

OK it works for some maps. It didn't open any temple siege's, or hungry hungry hydras. Most maps opened when I tried, just a few random ones like that. Other ones won't save, like attack of the homeless (I was just trying random maps in my folders.) Some DO save though, for example coon city.

Quote

Have you opened OSMap 2's output in an editor and tried doing anything with it?

In any case, protection was not my goal.

Yep tried that, it let me open and do stuff and save. I realise it wasn't your goal but it'd have been nice

Quote from O)FaRTy1billion

Where would I put such a checklist? ;o

Because it would be a lot of work for very marginal benefit to include this in the GUI - if everything is working properly and bugfree people won't need to select particular areas - you could make a .ini file with text flags for the different areas:
upgrades=true
unit_stats=true
fog_of_war=true
triggers=false

You could potentially have several levels of compression for various areas. This would be more work to implement, but would let you track down bugs in the more complex compression areas, eg you could have trigger compression at low, medium and high levels, and you might find a bug that occurs in 'high' but not in 'medium', which will help you track down where the problem is much faster. You could potentially use old TinyMap1 compression as the "medium" level (you could even have true/false/tinymap1 for simpler areas like unit stats or whatever), although obviously I have no idea how compatible that old compression system is with your new code. This would also help with diagnosing why particular maps won't compress - drop the areas 1 by 1 until you find a configuration where it does compress, and you've found your culprit.

Of course it's possible that having different combinations of compressibility itself could introduce new bugs, so the disclaimer would be that it is intended to run at full compression always, and lowered levels of compression is merely for bug-fixing purposes only and should not be used unless full compression causes an issue.

Doing all that seems like a lot of work for no real use...

I could easily disable sections in the INI based on how it handles sections ...
TinyMap1 didn't handle sections at all, it was a massive wall of "LOAD THIS INTO MEMORY, EDIT IT ALL AS A BIG PILE OF GARBAGE, PUT IT BACK." ;o TinyMap2 goes section-by-section loading the sections into memory after loading the map. When you compress the map, there are individual functions for each section... Basically to debug something I just go to that section's function and figure it out ... Each one is really small so it isn't very difficult.

Also, in MSN we found that certain maps wouldn't compress because they were protected. I have a very weak support for opening protected maps, and unless there is a lot of demand for it I have no intentions on supporting it further.

Quote from O)FaRTy1billion

Also, in MSN we found that certain maps wouldn't compress because they were protected. I have a very weak support for opening protected maps, and unless there is a lot of demand for it I have no intentions on supporting it further.

I can help you there

There's no reason to compress a protected map. Unprotection is already a ridiculously simple process.

Quote

There's no reason to compress a protected map. Unprotection is already a ridiculously simple process.

If that's true, then how does TinyMap2 have such epic protection?

Quote from fat_flying_pigs

Quote

There's no reason to compress a protected map. Unprotection is already a ridiculously simple process.

If that's true, then how does TinyMap2 have such epic protection?

Because I apparently do something that (most) unprotectors don't recognize. ;o

Quote from fat_flying_pigs

Quote

There's no reason to compress a protected map. Unprotection is already a ridiculously simple process.

If that's true, then how does TinyMap2 have such epic protection?

OSMap 2 opens it

Quote from fat_flying_pigs

Quote

There's no reason to compress a protected map. Unprotection is already a ridiculously simple process.

If that's true, then how does TinyMap2 have such epic protection?

it corrupts the vcod section. You can still open the map in starforge a lot of the time. Most of the other sections remain the same, so you can just rebuild the map.

Quote from rockz

Quote from fat_flying_pigs

Quote

There's no reason to compress a protected map. Unprotection is already a ridiculously simple process.

If that's true, then how does TinyMap2 have such epic protection?

it corrupts the vcod section. You can still open the map in starforge a lot of the time. Most of the other sections remain the same, so you can just rebuild the map.

A lot of protections corrupt the VCOD section, and most unprotectors support that...

Could I be having an outdated version? because the terran infantry armor still resets and this is a big problem in my map XD