Going to take a while - I leave for a conference followed by vacation on saturday.

Thank you!

Enjoy the vacation!


I tried it. I am looking for a GUI, not a text based editor. How did you make this editor? Is there a tutorial for plug-ins somewhere?

Siege tank turrets and goliath turrets are showing up colored blue regardless of the owning player's colors.

Thanks, I'll upload a fix later tonight

E: I just made it a full official release - it should trigger the auto updater.

Post has been edited 1 time(s), last time on Oct 26 2017, 9:17 pm by Suicidal Insanity.

Can confirm!

I also noticed that the Zerg Lurker box is to small. It should be the same size as the Ultralisk.

E: Also, is there anyway to makes strings use their own? Having things like Capture1 happen or changing a unit name and having it change a comment is pretty frustrating.

Attachments:

Post has been edited 1 time(s), last time on Oct 27 2017, 3:53 am by Pauper.

Did you edit the unit name in the string table or in the unit settings? The unit settings should un-recycle the string when it is changed.

String table. So if I have this problem, I need to modify the unit string once then return it to normal?

Ya every dialog auto recycles strings and also auto unrecycles them as they are changed. The string table is raw access to the data - it can't know which reference you want to change if a string is re-used multiple times.

Congratulations on fixing the turret color bug, SI!

Would ot be possible to append a value on the end of each strings (invisible to the user and game) so this doesn't happen? I had a few more location names change again. I don't understand why this happens in SCM Draft but not StarEdit.

Is there an easy way to make file associations with SCMDraft? It's still trying to open maps with my old copy (the one not in program files).

It shouldn't if you are not using the string editor. Let me know if you can get it consistenly reproduced. (If you are renaming switched, make sure you are using the very newest version)


If you run the installer it should have that as an option.

I have been using the string editor for all of my work.

So, should I just not use the string editor for anything to avoid these kind of bugs?

Its not a bug. If you edit a string that is used in 3 places in the string editor, you update all three places because you are avoiding the logic that recycles / unrecycles string text.

From a developer standpoint, it isn't a bug. But to any normal person.. it is a bug.

Now that I am aware of the issue I will work around it.

But sometimes you just have to think like a normal person and not a developer (used to work with a ton of developers and had to couch them to think like a normal person sometimes).

Again, thank you for your hard work.

Honestly, we're not normal persons there SCMD is made for people who make maps and mods. Nothing is normal in SC since you dig deeper into it's workings. Then SCMD simply provides interfaces for some SC internal structures that people won't need to HEX-edit raw maps manually as they did when there was no SCMD in the early era of Staredit-based X-tra editors and alike.

Moreover sometimes changing *all occurrences* of the string in one place is exactly what people want. In this case they go to the string editor. In all other cases they specifically change the name of the object they want to change.

O.o I understand why you say that, telling him to think "like a normal person" is not fair though. Even from an endpoint user view it should be clear that it *must* work that way - given that you know how string recycling works. I'll briefly explain it in the following. Feel free to ask if you have more in-depth questions.

Look at the problem this way: You want to edit a string of a certain trigger. You go to the string editor, look for that string and find it. Now you as the map maker should know that you used that exact same string multiple times. Since ScmDraft is smart enough to recognize it, it doesn't create a new string with the same content, but references all triggers to the same string.
So how is ScmDraft supposed to know in which trigger you want to edit the string? Right, it can't. Hope you see the problem.

The "problem" is a feature called string recycling. And it's definitely not a bug. String recycling is a god-sent for any string heavy map (e.g. RPGs) as the string limits fill quicker than you would believe. So it's really about knowing how all the features work, and I'll be the first to admit that ScmDraft has so many hidden features that it would be nice to have them documentated somewhere. But I guess time for developing comes first, and SI does a good job of announcing most of what he does, so we all have to keep ourselves up to speed through this topic.

Since we're talking about string recycling I want to remind everyone about an optimization opportunity that probably raised several times along these years.

Some maps have text-based inventory/menu systems that display items in a list like this (preview map here):

This is done by issuing a separate display text message for each line. For each item there are 2 strings stored: "> Item 1" and "Item 1", where the first one is used to display the current selection. The second such string is always a suffix of the first one. There is no need to store any data for the second string.

The simplified STR section for such a map could look something like:

Numbers are given in brackets, characters given without parentheses, each number and character is 16bit unsigned integer. The first number N (in the example N = 6) is total number of stored strings, then there are N numbers that specify string offset (zero-based) from the start of the section counted in double bytes (words as programmers call them). We see that strings 1 and 2, 3 and 4, 5 and 6 reuse common data chunks.

I really believe such menu systems use a really big portion of available string memory. Getting this optimization to work would almost halve that requirement. Assure you, this is enough to make at least RPG makers happy - they can add twice more content for their inventories!

Even more. For instance, creative mind can display quantities of specific inventory items with the number of characters '>' specified before the item text which is tabulation-padded. The current selection is color-encoded, the color comes as the first character:

Some major savings there since all is needed to store a single string data chunk per item: "[color code]>>>> Item 1". Making the use of grey color is another opportunity (which is unfortunately broken as of the most recent patch, but I hope this is going to be fixed).


The following discusses the simplest implementation:

Nothing fancy is required to make this work. From my perspective 3 updates are needed:

• When a new string for an entity is getting added the recycling mechanism should account not only for it's equality to the other string, but also for the case when it is the other string's suffix.
  
• When a string reference is getting deleted. If the deleted string was pointing to the start of a data chunk and there is no other string pointing there then truncate the data chunk from the beginning to the longest reused suffix or delete data chunk if it was the only usage at all. Otherwise if the deleted string was just a suffix of a reused string data chunk then do nothing except reduce chunk usage count.
  
• When a string is edited from the string editor and the resulting string becomes so short that it's suffix-substring would point to the string data chunk that comes next. This one is something we can't ignore. Probably the sanest solution is to unrecycle those suffix-substrings that "got out of the data chunk" with their previous contents.
  

The following is the example of the common workflow:

Let's consider my example above. For instance I decide to change some default unit name to "m 1". The new string is there but no new data chunk is added. The existing suffix is reused for unit's name. STR section will look as follows:


Then I am changing the first string chunk in a string editor to "> Itexm 1". This isn't resulting in any unrecycling. Text in my triggers is changed to "> Itexm 1" and "Itexm 1" respectively, unit's name string still points to the 6'th character of the string chunk and looks like "xm 1" now. STR after this operation:


Let's say I'll do something weird to the first string chunk in a string editor. Like change it to something totally different: "hello world". As long as the resulting string is at least 6 characters we don't care. Text in my triggers now uses strings "hello world" and "llo world", unit's name is " world" (with leading space). STR after this operation:


The only case we do care for is such a change in the string editor that makes the first string chunk shorter than 6 characters. Let's say we change it to just "hell". It's clear that the unit's name string can't point to the 6'th character in the string now because the string is just 4 characters long. We just then unrecycle the string for the unit name with it's previous contents to a new string chunk:


After the last operation we had 2 strings in our triggers text: "hell" and "ll". If I change the first one in text trigger editor to "enough" it is just getting unrecycled to the new string data chunk. Since there is no string pointing to the start of the first string chunk that one is getting truncated to the longest suffix under use which is "ll":


EDIT:
The proposed solution isn't user-friendly, but SI-friendly instead - it's the least changes required for this thing to work. Usually it means to the user: don't mess up with suffix-reused strings in a string editor. Adding a single color code or character closer to the start of such a string chunk in a string editor will shift all the following substrings data.

We could try to be more smart and detect the text insertion point or the deleted text to fix substring pointers accordingly, but sometimes it's hard to tell if several text blocks were inserted somewhere and several were deleted or the string was completely rewritten. Accounting for such a logic isn't an easy thing to do at all.

Post has been edited 5 time(s), last time on Nov 4 2017, 6:06 pm by Wormer.

"like a normal person" was not intended to call SI anything negative. If it came off that way I apologize. There are a lot of people who get into map making just to make maps and have some fun. They aren't going to understand how that feature works if there isn't any explanation of it. Maybe "think like a noob" would of been a better statement. I don't know.