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)
Post has been edited 1 time(s), last time on Apr 2 2011, 6:07 pm by PIESOFTHENORTH.
None.
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
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.
Post has been edited 1 time(s), last time on Apr 2 2011, 3:30 pm by PIESOFTHENORTH.
None.
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:
All PlayersNeutral commands at least 1 any unitGive 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.
None.
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
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.
None.
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).
None.
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.
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!
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).
None.
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.
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!
SDE, BWAPI owner, hacker.
This is a programmer's worst nightmare. Good luck.
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.
None.
Running a fresh instance of the program and loading & saving a map with no further interaction = the same input.
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!
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.
None.
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?
None.
It will give all to player 1.
And this still doesn't make sense. O.o
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!
Yeah it's weird.
It will give all to player 1.
well darn how do I make it give to any available players in force 1?
None.
SDE, BWAPI owner, hacker.
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.
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.
None.