I was using it to compress a map earlier. Worked fine, eventually changed the map (the uncompressed file) and then compress the updated map. But now TinyMap just crashes, only for this map.

The editor I use is SCMDraft2 Beta 0.8

Not sure what could cause this, so I'll just run it here.

Found the problem but don't know how to fix it. (see below)

You should probably narrow it down until you DO know what causes this, because Farty is lazy and won't find the bug for you.

I guess so, but I don't ever recall changing anything major.

I thought maybe there would be some commonly known reason for it to crash that I happened to have unknowingly caused.

I've figured out the problem:

If I add a trigger to give left players units to the other players, TinyMap doesn't like that. The Trigger goes like this:

Description:	players who leave give their units to allies
Players:	All Players
Conditions:	Neutral commands at least 1 any unit
Actions:	Give all any unit owned by Neutral at Anywhere to Force 1

Any way to get TinyMap to accept that? Does this trigger look like it will even work? It looked ok to me.

The trigger should work unless commands doesn't work for neutral, but afaik it does, so I've got no idea why tinymap wouldn't like it.
Dunno if it helps, but here's some variations you could try:
- replacing commands with brings
- giving it to a single computer player
- split up any unit in buildings and men
- use a different location. Either you have a static 'playing field' location you can use or you can cycle a location from unit to unit and give them 1 by 1

I tried modifying each parameter, even using a specific unit type and a specific location I had, no matter what I put, TinyMap won't let me use that action.

I have similar triggers in my map which TinyMap will eventually compress without problems. Can't say they're exactly the same (can't remember), but I do have triggers involving neutral player giving units back and forth.

Are you on Windows Vista or Windows 7? If so, you're more likely suffering from issues around that, and not specifically from this trigger. Unless, of course, this specific trigger caused a problem on WinV/7 systems but not on XP (seems unlikely).

The map you posted worked for me, and the trigger worked too?

What operating system are you on? Windows 7 for some reason (based on reports form people) seems to act very erratically with TinyMap2... I don't have it (nor do I know anyone who does) so I can't really debug it, though.

yeah i'm on win7 64x

It's almost certainly that you're using Win7 then, and not specific triggers in your map. Note that I can run TinyMap 10 times and have it fail, then run it once and it works. Or run it 50 times and have it fail in a row. Or run it and have it work 15 times in a row without failure.

I've posted several times about the flakiness and my final process that seems to temporarily 'fix' whatever is wrong and increase the likelihood that it'll work for you, which is (after it fails on your map), open up random Blizzard melee maps and compress them. Normally just compressing one will be fine, but sometimes that didn't 'fix' the issue, so I'd have to compress multiple different ones. Quitting and restarting TinyMap may or may not help. Then, after you've compressed some melee maps, try your map again and see if it works. A successful compress will automatically pop out the details pane and show the expected stats, a failed operation will either crash, or not pop the tab out, or create a file that is way too small (0 byes, occasionally I had one that was bigger, but not as big as the map should've been when compressed).

I can't think of anything that would cause it to do this either ... It breaks every law and rule for everything to have something to work one time and not another with the same input.

This is a programmer's worst nightmare. Good luck.

Quote from O)FaRTy1billion

I can't think of anything that would cause it to do this either ... It breaks every law and rule for everything to have something to work one time and not another with the same input.

Clearly the input is not the same every time. There's some additional input aside from the map that's screwing it up (or possibly an API call in Win7 sometimes returns differently from WinXP?), the problem is it's just not clear what that additional influence would be. I can't imagine there's any sort of file that Windows is writing to disk though, so maybe an API call being different is the best explanation?

Note that I have observed on many of the occasions when it produces a 0-sized output that it turns into a huge memory hog, eg I can watch the memory increase from a couple of megs up to 2.1gigs, at which point Windows stops giving it any extra memory, and it just sits there and does nothing, never advances any further and the file never grows from 0 byes, so I guess it's stuck in some sort of loop that allocates memory? That might be a hint. I think the times where it crashes may actually just be memory-allocation type crashes where Windows has denied it the extra memory, wheraes other times Windows gives it everything it wants but it never actually crashes from it.

The fact that running standard melee maps (I just use Blizzard ones 'cause they convenient) appears to influence following map compression is another clue. I only say 'appears' because I haven't done enough tests on it, but for example I had times where it would fail 10-20 times in a row (restarting tinymap between each attempt), then I'd compress a melee map followed by the map that previously failed and it worked fine. Then it might work for a while longer, before eventually failing again.

Running a fresh instance of the program and loading & saving a map with no further interaction = the same input.

Yes and no. It can get stuck in cycles where loading the program, and loading a file to compress it doesn't work. You can do it over and over and it'll fail each time. Then load the program, compress a *different* Blizzard melee map, which succeeds, then close the program. Start it up again and select your originally failing map and this time it'll compress it without issues.

So clearly there is some additional input *somewhere*, probably something lurking in Windows, that is screwing it up. Although I think a likely explanation would be some API returning an unexpected value.

So I just remembered that my map already had "give units" actions. 5 of them. It was only if I added that 6th one that it wouldn't compress. So I deleted the original 5 of those actions (they weren't really being used for anything) and tried adding that trigger again. TinyMap actually accepted it! So maybe for some reason there's a limit of how many of those actions it will allow?

Anyway I tested the trigger on bnet, had one player leave, nobody got his units.

But apparently making ze trigger give to a specific player instead of Force 1 made it work.

So I did

Give all any unit owned by Neutral to Player 1
Give all any unit owned by Neutral to Player 2
Give all any unit owned by Neutral to Player 3
Give all any unit owned by Neutral to Player 4
Give all any unit owned by Neutral to Player 5

Will that cycle through all the players until it finds a player who is in the game and then give the neutral units to that player?

It will give all to player 1.

And this still doesn't make sense. O.o

Yeah it's weird.

Quote

It will give all to player 1.

well darn how do I make it give to any available players in force 1?

Quote from Lanthanide

Yes and no. It can get stuck in cycles where loading the program, and loading a file to compress it doesn't work. You can do it over and over and it'll fail each time. Then load the program, compress a *different* Blizzard melee map, which succeeds, then close the program. Start it up again and select your originally failing map and this time it'll compress it without issues.

So clearly there is some additional input *somewhere*, probably something lurking in Windows, that is screwing it up. Although I think a likely explanation would be some API returning an unexpected value.

The only thing that would do this is temporary files if anything. There's no need to store data from the last compression and load it in a new instance. A new instance runs a fresh environment unless the programmer specifically makes it load something that was saved by the previous instance and intentionally or unintentionally remained to be loaded by the next. If the new instance does not load any data and there are no conflicts with the previous data (provided no coding error) then it would be a user(Operating System) problem and not an issue for the application.

Quote

then it would be a user(Operating System) problem and not an issue for the application.

We already know that, because it only happens on Vista and Win7 apparently. XP is fine.

Clearly we can't make Microsoft fix the bug (?) in their operating system, but Farty can potentially the issue in his program.