Yeah. Here's what I gots.

Attachments:

Ok, the map is using the extended string table, so make sure you are using one of the two newest daily builds.

And why does it? Last I checked the usual string limit was nowhere near filled (even now the editor reports it at 57.7%).

Besides, I had issues with some triggers refusing to run despite there having been no space for error in the conditions (it was a simple bring at location condition which didn't seem to fire for some reason, stalling the whole map where it used to run smoothly. Can it be connected?)

I think it does it by default for SCR maps.

No idea whats up with the triggers. I doubt that it connected.

I'm confused. What's the difference between the SCR maps?
Dunno what I'd have to do with the triggers, though. Can a map become corrupted so that some of the triggers stop running altogether?

Not sure what you mean. SCR map format -> allows new doodads, uses extended strings. Non-SCR map format: no new doodads, no extended strings.

I haven't heard of map's being corrupted in such a way. Either they load or they do not load in game.

I see. Doesn't explain why other maps with SCR doodads were able to be opened with the same build, but oh well. I wasn't aware that the extended strings are turned on automatically, even before the regular 64KB limit is reached.

I'll look into the trigger problems separately.

Only the latest two dailies support the extended strings. Possibly that is why.

Downloaded version 2020.02.12(W) yesterday and a fair amount of trigger properties now show as "invalid". For example Invalid order, Invalid ally type, Invalid scoretype. This is only a cosmetic issue in the main Classic Trigedit screen, not specific to any map, profile, or starcraft installation.

Ok, good to know. I was trying to unify text resources for classic and text trigedit and something may have gone wrong.

Is that correct?

No. If you use SC:R doodads or more than 65kbyte string data then it will require SC:R, otherwise it will store it in 1.00 / 1.04 compatible formats depending on what features you used.

how does it work with other extended limits like units and sprites?

That doesn't depend on the map format, that depends on the options you choose when hosting the map. So I can't influence that.

Think I found a bug (with custom brushes)

Any brush saved with old version of SCM Draft (I used 0.8) will function normally in 0.9.10 and 0.9.11 brush palette (explanation of what "normally" is is to follow)

Any brush saved with newer version of SCM Draft, will be shaded over in brush palette as if there was fog of war over it (this is what I mean by not normal), and in addition, the Layer selection will change from Terrain to Cut/Copy/Paste (using a brush created with 0.8.0 SCM Draft will not change the Layer selection at all).

Brushes of different versions may be mixed in the same brush file. Saving the brush using either copy/cut/paste OR terrain brush in 0.8.0 does not alter the outcome - they both are the same.

Edit: brush file with both fogged and un-fogged brushes uploaded

Attachments:

Post has been edited 2 time(s), last time on Mar 2 2020, 11:30 am by Tassaar930. Reason: forgot to attach

The newer brushes include fog of war. When pasting it you can disable it be clicked the corresponding checkbox.

That's the checkbox you're talking about right? Even when I have it off, the brush in the palette window is still shaded over

Edit: I'm being dumb - nvm

Edit Edit: Could you make ticking/unticking the checkbox apply the changes to the Brush Palette window as well?

Post has been edited 1 time(s), last time on Mar 3 2020, 9:10 am by Tassaar930.

What is this all about?

Some debug code slipped in - I was trying to track down why opening the map properties window was extremely slow on the latest win10 build while it was instant on win7/8.