I am having the same signed integer problem with Deaths conditions that I was having with Deaths actions:
1. If I enter 2147483648 it is capped to be 2147483647
2. If I enter -2147483648, upon next load it displays as 2147483648, which upon saving is capped back to 2147483647
3. If I enter -1, upon next load it displays as 4294967295, which upon saving is capped back to 2147483647

Classic or text trigedit?

Text trigedit.

Classic editor has other problems, like not letting you enter negative signs but also not letting you enter anything larger than 2^31.

I'm not on the latest version, basically since you started making the trigger changes, since it seems unstable at the moment.

It turns out that the condition parsing code for memory offsets in text trigedit doesn't use the default number parsing code. -> fixed.

I can enable negative signs if that is useful, just is flipping a parameter. Why do you want to enter values greater than 2^31? 2^29 already covers the entire address space since it is indexing a DWORD table.


Its somewhat unstable, but if nobody is willing to use it and report bugs, it will take ages to stabilize, since I don't make maps anymore.


E: Next build will have the changed CUWP management code, and also verifies the ref count each time a trigger is saved to quickly detect mismatches.


E2: Uploaded.

Post has been edited 2 time(s), last time on Feb 22 2018, 1:02 am by Suicidal Insanity.

Yeah, but I'm doing Serious Mapping right now, don't want to risk it breaking data in my map, making me spend hours chasing bugs. I've got my own self-imposed bugs to worry about at the moment.

Binary count-offs. I've implemented a one-way hash algorithm that abuses uint32 overflow to achieve MOD(x, 2^32) operation, and as part of that I have a lot of binary countoffs that are multiplying very large numbers.

Because of the shortcomings in scmdraft with uint32 handling I had to use chkdraft to implement it.

Negative signs isn't actually desirable, just need to be able to enter numbers larger than 2^31.

Can you post an example of your triggers? You say you are abusing overflows, but why do you want to abuse overflows in the editor instead of using whatever mod 2^32? I limit uint32 to -2^31 .... 2^32-1, which covers 1.5 times the entire range.

Post has been edited 1 time(s), last time on Feb 22 2018, 9:05 am by Suicidal Insanity.

I'm seeing this in other maps too. Sometimes all I have to do is open the TrigEdit++ window and then close it, don't even need to click compile. Other times it only happens if I click compile.

Anyway, easiest reproduction is just to open the 4-18.scm map that I sent you. Open TrigEdit++ and close it - for me, that doesn't produce the error on this map. But if I open and click Compile (without making any changes) and then close it, I get 11 of the string corruption messages in a row.

It would be nice if string editor window gave you some indication as to which string index you had selected.

In one map (not this one), it said the string corruption was on a particular string that was in used in 439 triggers, and when I checked the count in the string editor, it still showed the same number of triggers referencing it.

Do you think this is likely to be a genuine error, or just some spurious? If I saved the map and ignored the error, would I eventually have data corruption?

I can't say - I would assume if the ref counts are reported as mismatched that they really are mismatched though. Guess I will need to find time to remove as many triggers as possible from a map that has that problem to trigger it with something I can match on paper, but that will take a few days, more important bugs to fix for now.


E: From what I can work out, trigeditplus does not include a string in it's Transmission action, and loses references to those strings.


E2: New version out, the 'Always Display' flag wasn't being updated for tranmissions.

Post has been edited 4 time(s), last time on Feb 27 2018, 12:53 am by Suicidal Insanity.

Could hex values eventually be accepted in text-TrigEdit, similar to how it is in classic TrigEdit's SetDeaths action?

Maybe it would look like this? (Doesn't actually work atm)

Once text trigedit is updated to use the ScmDraft number parsing code instead of its own, it will work.

You used to be able to move triggers up and down the trigger list by selecting them and press U or O for Up or Down (D was delete, which is silly - that's what the delete key is for).

This no longer works, which makes it difficult to quickly move a trigger to the top or bottom of the list.

Bug: in classic trigger editor if I copy an existing Player Deaths condition, and change just one of the parameters (eg, change the unit from Terran Ghost to Terran Medic), then when I click Ok, the other 3 fields will be set to 0 values, eg if it was originally Current Player, Exactly, 11, Terran Ghost and I change only the unit to Terran Medic, upon clicking OK the condition will read Player 1, At Least, 0, Terran Medic. Very annoying (and initially quite confusing).

These are the sorts of bugs that can easily chew up hours of debugging if you don't notice the condition is wrong initially, and then your triggers behave in unexpected ways.

That was temporarily disabled while I was trying to track down the root cause of Korean language input problems.



I'll take a look. I wonder if that happens because it tries to switch it to EUD.

E: Thanks for reporting that, it only happened in release mode, not debug mode, which explains why I didn't notice it. The condition type was 8bits and was aliasing a 32bit value.

E2: Uploaded

Post has been edited 3 time(s), last time on Feb 28 2018, 11:51 pm by Suicidal Insanity.

There's a small issue with unit collision boxes (all men, buildings, etc. everything). The bottom and right sides are 1 pixel smaller than normal, allowing illegal unit placements despite Allow Stack and Place Units/Buildings Anywhere settings disabled, and giving unit placement errors in-game.

Easily avoided by being careful when placing units, but would be nice to have that fixed; it wasn't the case in previous versions (0.8.0 and such).

Ok, I'll verify the offsets and if its off by one I'll fix em. Thanks for the report.

E: Fixed, and same off by one error existed for the bottom / right side of the map, where I also fixed it. I guess SC treats the collision box as inclusive.

Also uploaded a new build, hopefully no more bugs turn up in it.

Post has been edited 2 time(s), last time on Mar 2 2018, 11:38 pm by Suicidal Insanity.

So today I downloaded the most latest one: Scmdraft 2 - 2018.03.09 ...And I keep getting this error on my map. Yet it will open others. No clue. Back to 0.9.0.

Is it an ice world map by any chance? I had added error checking to tileset load, and it appears that the ice tileset does not have a color shift palette, which likely is unused by the game.

Post has been edited 2 time(s), last time on Mar 11 2018, 12:11 pm by Suicidal Insanity.

Sadly yes.

Edit: How is the ice world unused by the game if the game plays it in SC and SC:R???

SI is saying that he added a check into scmdraft to look for things it considers wrong. It assumes all maps should include a colourshift palette file in the map, except that ice world is an oddity and some ice world maps don't include such a palette file because SC doesn't use it - probably the map was created by an older version of scmdraft, or Staredit, or some other editor, which didn't include the palette file. So scmdraft incorrectly assumes that since all maps have to have palette files to be valid, this mapis invalid and won't let it load.

I presume that a new ice world map in scmdraft will include the palette file in the map save, even if SC ignores it. So scmdraft won't have a problem with new ice world maps of its own making.

So if you're familiar with MPQ editors, you could try making a new ice world map in scmdraft, saving it, looking for what file must be the palette one, extracting it and inserting it into your own map file (which is actually an MPQ archive under the hood). That should then let scmdraft open your map.

Its fixed in the newest official download - just use that ( http://www.stormcoast-fortress.net/downloads/scmdraft2ZIP/ ).


The game data files do not have a blue.pcx file for iceworld for some reason. Some of the game data is a bit inconsistent - another example is the vespene geyser sprite using tileset dependent frames, but the shadow does not include tileset dependent frames for broodwar tilesets. I have been adding a bunch of consistency checks to the game data loading, and in this case I didn't check every last tileset if it passes and missed that.