Hmm... What is the version if you right click on the EXE and go to properties? I've been updating it every time I release it.

Post has been edited 1 time(s), last time on Mar 13 2010, 12:40 am by FaRTy1billion.

it said it was last modified on February 28th 2:55:45pm

Wait no. 2.0 XD

2.0.?.? ... ;o 2.0.3.5 is the latest. Also, you have an old version. Redownload.

You shouldn't bother. If people don't want a section compressed, then they shouldn't compress anything at all. If there's a bug in a section, then report it. If there was an option to disable sections, then it's less likely that bugs will be reported. The "all or nothing" package is the way to go.

Hey, what is "changes sprite players" fixed? I asked because, I found another bug, apparently for computer players, (well at least for player 7 computer that I'm 100% sure) gets converted to zerg race, my player 7 computer was protoss but it got converted to zerg, this is really important because the computer in my map is protoss-based, and he will refuse to upgrade his attack/armor if he is changed to zerg.

Tested, approved! Tinymap2 changes Player5-8 race to zerg, either it's an AI or human. Player1-4 stay untouched. I wonder why.
[attach=6031]
[attach=6032]

Attachments:

Guess it's best if TinyMap2 not touch race settings if the player owner is Open or Computer.

Woops, mah bad, forgot to update the one in the DLDB.

I also wonder why. ;o

...
Found the problem!
I accidentally had it load only 4 bytes of the player race section instead of all 12. ;o

Any more bugs right now or should I just make a new build?

Attachments:

Actually only 8 should matter.

It clears 9-12 anyway, but I like to load the entire section anyway.

Uploaded new version.

Hi Farty!
You're putting zeros everywhere where it won't spoil the map to have a better compression ratio, right? It's because series of consequently equal bits are compressed to one bit plus the number of it's repetitions, right? (Well, in the simplest case it is like that at least.) Anyways are you sure putting zeros everywhere is the best thing to do? If you exactly know the compression method you may select such values which will make the best compression. (Well, at least ideally, because this might be something like NP-hard problem or whatever.) Have you taken this possibility into consideration?

Except a lot of things I am setting to 0 wont work if you set them to anything other than 0. 0s compress really well because there are a lot of them already. I wouldn't know what to make them since I don't know the compression algorithm anyway.

i found another bug, units that are given anything above the normal energy reserve 64ish?, are reset to 64 (i had a defiler that starts with 250 energy and it starts with 64ish). Also wen i activate a trigger that changes the mineral value in a mineral field, it goes to 0

Aw, poor CUWP slots.

Could you restate this a little better or post a map with the bug isolated?

I found the problem (unnecessary break; in switch statement).

What do you mean?

Post has been edited 1 time(s), last time on Mar 30 2010, 7:49 pm by FaRTy1billion.

i mean i have a hero defiler whos starting mana is 250\250 but after i use tinymap2 it starts with 64\250

My guess is that tinymap2 clears the unit properties data for energy.

Well is 64 really the starting energy? I never thought energy would have a different outcome than HP and Shields.

BTW 64 / 250 = .256, which probably makes it 0x100 / 1000.

Through my searches for an Uberation 2 download last night I found the Koreans have made a 'counter' to TinyMap2 caleld SCMREC, it reconstructs every single section of a map. I have yet to test it.