I found a minor display bug in the emulator / SCR.

The following map works correctly in 1.16.1, but displays a bug in SCR. http://www.staredit.net/sc1db/file/4030/

If you select the Dark Archon and hover your mouse over Mind Control, you'll see in SCR that it has a spurious "tack Move" in green at the end of the string, that does not appear in 1.16.1. The problem seems to be when the stat_tbl editing ends on a 4-byte boundary, that the terminating <0> is ignored. See imgur for example of SCR buggy display vs 1.16.1 working display. It's not related to the Korean characters, that's just what I happen to have in this string. I've had it occur with fully english strings too.

https://imgur.com/a/PEwWY

000068C0: BE EE 00 ^^77-03 42 75 79-20 03 57 01-65 61 70 6F ╛ε w♥Buy ♥W☺eapo

000068C0: BE EE 00 77-03 42 75 79-^^20 03 57 01-65 61 70 6F ╛ε w♥Buy ♥W☺eapo

000068C0: 63 6B 20 55-6E 69 74 00-^41 74 74 61-63 6B 20 54 ck Unit Attack T

00000720: 78 68 85 68-91 68 98 68-A4 68 B7 ^68-C8 68 D4 68 xhàhæhÿhñh╖h╚h╘h

I found a minor display bug in the emulator / SCR.

The following map works correctly in 1.16.1, but displays a bug in SCR. http://www.staredit.net/sc1db/file/4030/

If you select the Dark Archon and hover your mouse over Mind Control, you'll see in SCR that it has a spurious "tack Move" in green at the end of the string, that does not appear in 1.16.1. The problem seems to be when the stat_tbl editing ends on a 4-byte boundary, that the terminating <0> is ignored. See imgur for example of SCR buggy display vs 1.16.1 working display. It's not related to the Korean characters, that's just what I happen to have in this string. I've had it occur with fully english strings too.

https://imgur.com/a/PEwWY

Great, I look forwards to extended EUD triggers!

iscript changes that would be awesome:

• Ability to add 'do weapon damage' to animations that don't have them, or remove them from animations that do. Or remove/add to an animation multiple times (eg leave zealot animation the same, but have it only deal 1x damage. I think this is also what makes a valkyrie shoot 4 times per attack animation)
  
• Ability to change sound effects
  
• Ability to reference different graphics, eg for wraith iscript, display dropship shadow instead of wraith shadow, or for weapon projectile iscript change the on-hit graphic to a different one.
  

Similarly for graphics, it would be great if we could re-use the same grp in multiple image slots, right now this is ignored.

One thing I would really love to be able to do, is have 2 wraiths in the game: one calls the regular wraith engine graphics in its movement iscript, and the 2nd wraith calls duplicate engine graphics from its modified iscript in a different image slot, and those secondary wraith engine graphics are rendered as Hallucinated (blue) or Warp Flash (white). Right now that isn't possible at all, and although I understand there will always be restrictions around what can be done with graphics, in this case all I'm wanting to do is have 2 images that look like wraith engines, one coloured blue, and have two iscripts, one of which points at the blue engine effect. Right now because we can't duplicate images, and we can't alter iscripts, all units that look like wraiths (wraith, tom kazansky hero) will have orange OR blue engines, you can't have some with blue and some with orange (or even cooler, blue, white and orange engines, which could represent different upgrade levels of a wraith unit, or in my use-case visually signal the types of weapons each wraith is equipped with).

Just to be clear with the wraith example, the existing wraith unit is composed of images 243, 244 for the shadow and 245 for the engines. What I'd like to be able to do, is take another image that I don't need in the map, eg 589, and change it's grp pointer to be thingy\tphGlow.grp (#250) and change it's drawing function to 16 (hallucination), and then have a way to duplicate the wraith's iscript - either as a brand new iscript in new memory, or by overwriting an iscript I don't care about - and change the new copy so that it references images 243, 244 and 589 for the engine graphics. That way I'll be able to have a regular wraith, and a blue-engine wraith, in the game at the same time.

Similarly right now we're rather limited in the amount of things we can do with weapons, because all instances of a particular weapon will take any changes you make, eg the seeker spore (spore colony attack) has puffs of green smoke behind it, you can get a neat effect if you change that green puff sprite to point at a building fire image, but because we can't duplicate a weapon in its entirety, it means if you gave such an attack to vultures (eg, as a hellion flame attack) then all spore colonies would also have the fire added to their attacks too.

Ok, I debugged the problem. It has nothing to do with alignment. The string table for the stat_txt that your EUD map is patching is buggy. While SC1.16.1 is happy with it, SC:R validates all the string offsets.

There's one offset at 0x68C3:


The next string in the string table is at 0x68C8:


The offset 0x68C8 is a remnant from the old stat txt that was originally pointing to:


To fix your map, update that offset (at 0x72C). Cutting a string with \0 is not enough for SC:R in certain situations.


To decommision a string, have it point to offset 0xb000 then it should become empty but valid string.

Please let me know.

Can you please give me a simple map containing the modified iscript and desired changes that work on SC 1.16.1? Like this I can compare results as I add this feature.

Thank you!

He was using a tool that I wrote to generate the triggers. Does that mean SC:R doesn't read the strings the same as 1.16.1? Do I need to do the 0xb000 thing for unused strings whose memory is overwritten? I don't expect it to be 100% the same in SC:R, but I just figured it would re-interpret it the same as 1.16.1, meaning \0 is all that is needed. XD

00000730: DA 68

Okay, I did not explain the situation correctly. It is not about \0 exactly.

We have changed color code and hotkey code meaning in SC:R. In SC 1.16.1, when a start had something like: char\0Text, then the char is the hotkey for the text.
In SC:R, we changed the \0 to \x07 instead. For the emulator to work like SC 1.16.1 in regards to changing hotkeys for stattxt, the emulator does the following:

1. When stattxt changes are detected, the emulator buffers all the writes until the end of the trigger
2. After all triggers, the emulator stattxt adapter goes over the new StatTxt table and tries to 'convert' to SC:R format. In particular, it tries to change char\0text to char\7\text.
3. The adapter computes a string's length by subtracting TStrTbl.wStr[I+1] and TStrTbl.wStr[I]. Basically, a properly generated stattxt will emit content with no gaps where the offset difference and the actual string length (with zero terminator) are equal.

Now the problem in that map is that the TStrTbl has some offset values (in an unintended manner) that fulfill the condition: char\0\text <- however the EUD map maker did not intended that. He simply intended to cut off the previous string.

This is exactly the case in the problematic map mentioned here. Forget about the 0xB000. The proper way is to have all string offsets point to valid entries. Why? Because the adapter really rebuilds the hotkeys table internally (which is in another data structure).


This offset takes us to:

000068DA: D4 00 74 61-63 6B 20 4D-6F 76 65 00-41 74 6B 20 ╘ tack Move Atk

Which the adapter thinks it needs correction because 0xD4 is followed by \0 followed by the text. So it replaces the \0 with \7 and that's where the previous string includes contents of the next one as a side effect.

To fix this shortcoming, just have the offset at 0x730 point to somewhere else than 0x68DA. Anything that has \0\0\0 should work.