The string size limit is due to the way the string section is structured/read by StarCraft and cannot simply be extended in an editor - see http://www.staredit.net/wiki/index.php/Scenario.chk#.22STR_.22_-_String_Data for the technical details. If our goal is a flat increase to the amount of string data we can have in-game then this suggestion needs to be given to Blizzard.

An editor can however make it so that strings that are not used in game (such as trigger comments) do not take up space within StarCrafts string table and I suggest SI take this up at some point if blizzard does not extend strings themselves, please use the same format I have or document whatever format you end up using if you add support for extended strings. http://www.staredit.net/topic/16101/.

Ok, I will report this string issue to blizzard.

Ty!

Ya, not really much we can do about it





New version, still no health bars so it's not publicly linked. It avoids warning spam on map close due to non-existent animations, re-positions the two expand / collapse buttons on the panels now to keep em in the corner, and I started some logic changes in the terrain code to split the actual map data from the undo / redo / edit logic.


Prongo, I started fixing the 'map is marked as saved on load' thing, and then decided to fix the underlying cause instead of just clearing the changed state which had to do with doodad tile generation, so that isn't included - I want to double check some changes before commiting.

Now with health bars, and a few graphical glitches I found fixed. This also lets you open more than 8 windows per map, yay .... !


If any graphics are still glitched, let me know, I hope I caught everything.


Hopefully I can do one final pass on the changes this weekend, and then go on to the next subproject.

SI, please reduce the center of location marker size to several pixels (4-5 would probably be enough). The star looks very disruptive too, a small X would suffice.

I'll think about it.


Fixed a graphic glitch with doodads, and added a bunch of changes to terrain handling internals. Shouldn't cause any visual differences, but reverses a design decision from 2k5 or so I haven't been happy with the last few years =) Also, I will soon support custom color cycles.

SI, I've found a significant bug with Trigger Editor that is making working with EUDs pretty much impossible. Should be very easy to fix.

Reproduction:

• Create a brand new map, open trigger editor and edit the first trigger as so:
  Quote

  Trigger("All players"){
  Conditions:
  Always();
  
  Actions:
  Set Resources("Current Player", Set To, 50, ore);
  Set Deaths("Int: -120747", "Terran Marine", Set To, 4278648963);
  Set Deaths("Int: -120746", "Terran Marine", Set To, -200);
  }
• Click to compile the triggers, there will be no error. Close the trigger editor
  
• Re-open the trigger editor, and observe the values of the actions have been changed:
  
  Quote

  Trigger("All players"){
  Conditions:
  Always();
  
  Actions:
  Set Resources("Current Player", Set To, 50, ore);
  Set Deaths("Int:-120747", "Terran Marine", Set To, 2147483647); <----- HERE
  Set Deaths("Int:-120746", "Terran Marine", Set To, 4294967096); <----- HERE
  }
• Compile the triggers, there will be no error. Close the trigger editor
  
• Re-open the trigger editor, and observe the value of the 2nd action has been changed:
  
  Quote

  Trigger("All players"){
  Conditions:
  Always();
  
  Actions:
  Set Resources("Current Player", Set To, 50, ore);
  Set Deaths("Int:-120747", "Terran Marine", Set To, 2147483647);
  Set Deaths("Int:-120746", "Terran Marine", Set To, 2147483647); <----- HERE
  }

Basically it doesn't handle signed / unsigned integers in any sane way. The best fix would be to allow it to store unsigned integers without altering them.

I found this because I was working on a set of complex EUDs, and I'd get part of it working and test to confirm, then do some more work, and suddenly the things I previously tested as working were half-broken.

I'll try and track that down tonight.

E: Should be fixed

Post has been edited 1 time(s), last time on Jan 10 2018, 12:37 am by Suicidal Insanity.

Here you go. Exe is there to test out. Play in badlands and it should cycle between all indexes.

Attachments:

Would it be possible to add the list ID to the dropdown boxes in SCM Draft? For example, the "Unused" units are Unit ID 91. It would make it much easier when working with EUD to know what the Unit ID is in the list since each editor seems to have its own way of showing the drop-down list. ID is the same across all platforms. Thank you.

I have an idea how this could work nicely, will try it this weekend. No promises, my idea may be completely unworkable


Corbo: Fixed a bug in my implementation, I missed a detail in the format, and now it works.


E: Build is online. Also mostly done with splitting out terrain logic from the map class.

Lanthanide: Did it solve the overflows for you?

Post has been edited 2 time(s), last time on Jan 11 2018, 1:05 am by Suicidal Insanity.

Thank you SI.

The overflow issue is resolved. I had that same problem and it works without issue now!

THANK YOU!

Color cyling code also affects SCMDraft interface stuff, like black grids, isom placement square, location areas, names, etc. It's cool. It's hilarious, but is it desired?

Admittedly I find no real use for color cycling black color or any other UI color in the future so this will not happen and probably no one will notice unless we cycle all color ids like in my test.

Terrain code cleanup is done (for now)... hopefully nothing broke. Now my starcraft map class doesn't touch the undo class at all, its all handled on the editor level =)

I'm a bit tempted to add X / Y offset to map resizing and trying to make that undo / redo able, but that is a very niche feature, so I may start cleaning up the trigger code and expanding EUD support instead.

As always, I'm also open to other suggestions.

Would be nice to get support for expanding maps in any direction instead of just down and right. That's the top of my feature request list atm.

Hopefully an easy update: can you label the list of `Unlabeled / Unused` upgrades and techs? Just their IDs is sufficient.

Hi SI,

It looks like the overflow fix was reverted recently.

https://kek.gg/i/X8_jY.png

The image above shows the error in action. Anything over 2147483647 will revert to that number and cause a bunch of corruption in the EUD action.

If you could please look into this ASAP that would be great!

Also, would it be possible for TrigEdit to automatically convert input like this "SetMemory(0x6635D0, SetTo, 16842753);" into "Set Deaths("Int: 222363", "Terran Marine", Set To, 16842753);"? It would save a TON of time.

Thank you,
Bitz

First of all, make sure you didn't switch to an older build. As far as I can tell, the last three alphas all include the exact same build of text trigedit. Otherwise, as a workaround, copy the trigedit.sdp file from the build that has it fixed into the current build.

The second thing would need to be an option, since it has always been converting set deaths into set memory if the unit is terran marine.

Thank you SI, I will give that a shot now.

An option would be great, I am sure everyone working with EUD's would love it!

EDIT: It works, for those of you having the same issue download the version from 1/10/18 and replace the latest version TrigEdit with the this version.

Post has been edited 1 time(s), last time on Jan 19 2018, 8:05 pm by Pauper.

The same uint32 bug with the text trigger editor applies to the Memory condition as well.

In classic trigger editor, the memory deaths offset -119293 becomes 4294848003 when you open the text trigger editor, which is then capped to signed 32 bit after compiling.