Quote from Lanthanide

Looks like someone's beat me.

It's setting the goliath & hero damage to 0/0, and same for the tank & tank hero. Kinda ruining the beta test of my map on public (since I want it protected)

fyi if that's the only problem, you should be able to fix it yourself. I suppose you'll lose most of the compression though.

how can u fix it urself wen it only does that after protection, it changes the atk to 0, and resets base armor to 0? and losing compression kinda negates the point of usin tinymap2, for now anyways

because you don't have to open the map in any editor, you just have to edit the UNIx section. I think it will decompact the archive, however, and I don't know how one recompacts it any more than simply putting it in winmpq.

I've identified some of the reported problems...
Clears unit armor - It is supposed to clear the armor if the unit is always invincible (like minerals, beacons, etc.), except I accidentally made it clear if the unit ISN'T invincible. ;o
Resets subunit (tank/gol) damage - It resets weapon damage, but because the turrets have the weapon, the tanks don't. Most people don't edit the damage via the turret, so it thinks it is unused.
Changes sprite players - ;o Another error on my part ... I blindly just clear the player for sprites. As a quick-fix I'll make it so it just nulls doodad sprites.

Can those who had these problems confirm they are now in working order?

I shall try this later tonight when I get home, I'll let you know how it goes.

I didn't realise the tanks had separate turrets that controlled damage. Does this mean we can set the tank and turrets to do different damage values, and get strange results in-game, or will one value always override the other?

One will always override the other... In the map they are stored in the same place, so it can't have two values.

Sweet, i dont see any of those problems that were there b4, 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

Tanks and goliaths don't have an attack. Their weapon is 130 (none).

Just something that popped into my head, but any condition stating "at least 0" (accumulate, bring, command, countdown timer, deaths, elapsed time, kill, memory, opponents, score) is the same as stating "always" and isn't needed. I'm not sure if you already remove this, but it could save a byte or two.

Edit: EUDs can use negative values, and although I doubt you would use "at least 0" in an instance of one, it's a possibility.

Quote from Roy

Just something that popped into my head, but any condition stating "at least 0" (accumulate, bring, command, countdown timer, deaths, elapsed time, kill, memory, opponents, score) is the same as stating "always" and isn't needed. I'm not sure if you already remove this, but it could save a byte or two.

I don't think I do, but it's listed in the things to do.

-1 is at least 0 when starcraft reads it. Also, ANY number can use negatives, so long as it's 4 bytes.

Farty did u manage to fix that fog of war problem for P1 or at least find the cause?

I'm just wondering because I'm too lazy to test. But do you delete "Always" conditions?

A trigger without condition runs like "Always" and "Always" really doesnt do anything.

I'm pretty sure he did, I suggested the same. We also encountered a trigger behaviour that nobody has ever heard of before: Conditions and actions are read until a NULL condition/action byte is found. Conditions/actions after the NULL one are ignored. There's currently no tool that follows this behaviour properly.

The behaviour was encountered when we tried sandwiching conditions/actions together (conditions moved to the end of the array and actions remain at the beginning, or vise-versa), to increase the size of the NULL-space between each trigger.

Quote from Heinermann

I'm pretty sure he did, I suggested the same. We also encountered a trigger behaviour that nobody has ever heard of before: Conditions and actions are read until a NULL condition/action byte is found. Conditions/actions after the NULL one are ignored. There's currently no tool that follows this behaviour properly.

The behaviour was encountered when we tried sandwiching conditions/actions together (conditions moved to the end of the array and actions remain at the beginning, or vise-versa), to increase the size of the NULL-space between each trigger.

Yeah I found this out when I deleted conditions or actions inbetween other actions (sometimes I have comments in the middle of a trigger). This would lead to half the actions being skipped. I think for compression, OSMAP2 nulls all action "slots" after the last non-null actionbyte.

Quote from LegacyWeapon

Yeah I found this out when I deleted conditions or actions inbetween other actions (sometimes I have comments in the middle of a trigger). This would lead to half the actions being skipped. I think for compression, OSMAP2 nulls all action "slots" after the last non-null actionbyte.

TinyMap2 nulls a lot of things I wouldn't have even thought of if DK hadn't been helping.

Any idea why tinymap2 disables terran infantry armor upgrades?

it disables things not being used.

Well terran infantry armor is being used, has cap of 20 and all forts of values in my map.

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?