You could write a batch script that copies the mpqs and launches scmdraft with a specified profile to cover the first two steps.

Do we have a command line arguments? Like directly open a map or such.

When there are unnamed locations text trigedit assigns them names like "Unnamed Location (N)". If there happens to be a named location with the same name "Unnamed Location (N)" then the truly unnamed location is being compiled into this faked location. Faked location overrides special name. I found a way to enhance this to exclude the very possibility of corrupting behavior that can be used by various map obfuscators and the like to spoil our lives.

Make behavior opposite, i.e. make any location with id N accessible via that special name "Unnamed Location (N)" no matter what. This special meaning shouldn't be covered with the fake location name "Unnamed Location (N)" even if that location exists. If faked location with name "Unnamed Location (N)" has ID K then it is still available through it's own special name "Unnamed Location (K)".

Finally, before generating text triggers check map for unnamed locations. If there are unnamed locations then use special names for all locations in generated text, if there isn't it's safe to use locations natural names as it is now.

Optionally: rename this special name for unnamed locations to "Int:N" to better match what we have for units. In classic trigedit unnamed locations might display as "LocID:N" for consistency as well.

There is the same issue with forces that is being approached in the way opposite to locations current behavior. When there are unnamed forces their names in text triggers have special meaning, i.e. those names are not covered with faked names of the same kind. Let's say force 2 has name "Force 1", then "Force 1" in text triggers still references force 1.

Escape from this situation is the same: detect at least 1 unnamed force, and use text "Int:N" in place of all forces names in this case, otherwise natural forces names are safe and good to use. In classic trigedit display "PlayerID:N".

There is the other unpleasant situation when two entities (forces or locations) have same names. Detect that situation as well and fall back to special names of kind "Int:N" in this case too.

Summarize
My proposal is as follows:
1. Accept special names of kind "Int:N" in text trigedit as players and locations parameters at any time.
2. Those special names are never overriden by the same names of the corresponding entities, i.e. always work in a predictable way.
3. When there is a slick situation (presence of unnamed entities or entities with equal names) fall back to usage of these special names for all entities of this kind.
4. When there is an entity with user-provided name "Int:N" we have to fall back to special names for those entities too.
5. Accept special names of kind "LocID:N" in classic trigedit for consistency with what we have for players and units.
6. If there is a location with (malformed) name "LocID:N" then choose this malformed location in classic trigedit like you already do for units in deaths with malformed names "UnitID:N".

Comment on the last point, I agree that for classic trigedit this is a good behavior for people who aren't aware about this feature. In that case people at least get what they expect.

As a useful side effect, this will allow trigger generators to prepare SCMD text triggers that reference forces and locations without knowing or caring about their proper names in the map.

Post has been edited 23 time(s), last time on Aug 10 2019, 10:40 pm by Wormer.

I took a different approach...
User Assigned Name > Default Name > Plain Number

But that was because I had to retain reverse compatibility.

But we could make a separate compile mode, e.g. classic, version X, version Y and make whatever we want from there.

How plain numbers interfere with that? It would be best of the two worlds to accept plain numbers in those fields as well and keep everything as it is for backward compatibility. But I don't know how hard is it to implement different type of argument when "Int:N" functionality is already there for units.

Post has been edited 2 time(s), last time on Aug 11 2019, 12:55 am by Wormer.

accepting plain numbers as the priority over the dynamic strings is where reverse compatibility is lost vs the old which was only the dynamic string if it existed

Does it mean that your restriction was: ill-formed texts have to be ill-formed in the new version? Then yes... to me 'backwards compatible' means all well-formed texts are well-formed in the new version with the same semantics. Some texts ill-formed before can become well-formed in the new version though, that usually not a problem. I think I'm misunderstanding something

Anyway, in case SI is not very far from implementing integers as alternative arguments to players, locations, units, my modified proposal with those looks like this:
1. Accept integer numbers in text trigedit as arguments to players, locations, or units at any time.
2. When there are unnamed entities or entities with same names use integers for those entries only when generating text for trigedit.
3. Keep everything else as is for backward compatibility.
+ 5. and 6. from above unchanged for classic trigedit

My main concern is to avoid (let artificial, but still) cases when just a recompilation on text trigedit generates different result. Also provide a better interface for text trigger generators is of importance.

Post has been edited 4 time(s), last time on Aug 11 2019, 1:14 am by Wormer.

Imagine all location names are nulled and text triggers are exported. It cannot be imported back, therefore preserving compatibility is pointless.



Same effect goes for units, imagine someone renaming units to "UnitID:N" in the triggers. Exported data would be useless as well. My approach was to separate user define strings and IDs by parser ("Unit name" vs ID:0, qouteless).

Since exported triggers with ambiguous names could not be imported back correctly, it would make sense to add (or replace original with) some additional distinguishable parser token to each such ambiguity (replace quoted location names with unquoted location IDs, same with unit names and switches)

Okay, I forgot switches, switches in the basket too!

SCMD is tricky at places. This problem doesn't exist for units, because they are always referred with original names in exported text, i.e. marine is always 'Terran Marine' no matter the custom name you give.

But you got the point, basically how much different ID:# from just #? This is a cleaner solution to accept integers as arguments. If this is too much work, ambiguous names still can be exported when there is an unambigous naming scheme (like original names for units) to fall back in case of trouble.

It is possible to accept custom units names too. Fall back to original naming scheme in case when 1) someone gives zergling a name 'Terran Marine', 2) blanks out it's custom name to null string, 3) gives a name 'Brothers Twins' for both zergling and marine. Custom units names reference scheme is just less useful, because usually custom units names contain color codes and change more frequently, who wants to bother with color codes in triggers?

Post has been edited 1 time(s), last time on Aug 11 2019, 11:25 am by Wormer.

What I meant was to differ on token type (in any way, either integer or keyworded integer, doesn't really matter), not the value. "Terran Marine" == 0, etc.

Aren't you worrying about a problem that the user is only causing himself? I mean what is the real world use case for the user naming his locations or switches to default names for other indices?

Users are stupid if they do that. The only real (valid) use case would be defense mechanism against map editing. Copying/pasting data from/to trigedit would corrupt them.

There are two reasons besides unifying behavior and polishing stuff:
1. It's a backdoor for various obfuscation techniques.
2. Better interface for text trigger generators.

Shouldn't the now official SC editor be error-prone to corruption scenarios?

Post has been edited 1 time(s), last time on Aug 11 2019, 10:55 pm by Wormer.

I'd honestly rather try to work on 4K support and ome other future features than some niche potential obfuscation technique, which in practice is unlikely as map protectos would strip out the location name and switch name strings anyhow. The new text engine already is a large step forward as before all invalid locations were just called "invalid location" etc.


E: Or possibly CurrentPlayer support. Or my 9.2TB backlog of photos.

Alright, I thought to catch on those in hot pursuit. Important things and personal priorities (like kittens ) go first of course! Thank you for keeping the development, and CP-trick is probably more needed indeed.

There been a question about command line arguments, I forgot if it's documented anywhere as well?

I thought I had em documented, but I couldn't find the list.

-map=[filename]

-profile=[xyz]


And will be removed in the next release:
-charEncoding=[codepage]


Also some legacy ones from the days when scmdraft generated the images for the staredit map DB, I do not know if those three still work.
-image and -minimapimage and -imageonly

Oh my lord, 9.2 TB! *bows* My entire archive is 750 GB.

If I ever managed to get rid of the redundant and bad shots it would probably be less than half that size.

A few years back I spent 2,5 years re-sorting, re-culling and re-attributing all of my archive. Though I was only doing this as time allowed, mostly during the evenings after work. It's a biatch of a job.

OTT, why are you removing the codepage command line parameter?

Because it is in the settings UI now. (Although the official release is failing to store/load that setting, so its good that the command line still exists)