Staredit Network > Forums > SC1 UMS Theory and Ideas > Topic: Facts about the SCR EUD emulator
Facts about the SCR EUD emulator
Dec 20 2017, 10:45 pm
By: 0xeb  

Mar 8 2018, 2:37 am 0xeb Post #21



Quote from Lanthanide
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

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:

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

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

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

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

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

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

Quote
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

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

Please let me know.




Mar 8 2018, 2:39 am 0xeb Post #22



Quote from Lanthanide
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
Quote from Lanthanide
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.


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!




Mar 8 2018, 3:19 am O)FaRTy1billion[MM] Post #23

👻 👾 👽 💪

Quote from 0xeb
Quote from Lanthanide
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

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:

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

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

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

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

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

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

Quote
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

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

Please let me know.
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



TinyMap2 - Latest in map compression! ( 7/09/14 - New build! )
EUD Action Enabler - Lightweight EUD/EPD support! (ChaosLauncher/MPQDraft support!)
EUDDB - topic - Help out by adding your EUDs! Or Submit reference files in the References tab!
MapSketch - New image->map generator!
EUDTrig - topic - Quickly and easily convert offsets to EUDs! (extended players supported)
SC2 Map Texture Mask Importer/Exporter - Edit texture placement in an image editor!
\:farty\: This page has been viewed [img]http://farty1billion.dyndns.org/Clicky.php?img.gif[/img] times!

Mar 8 2018, 8:28 am Lanthanide Post #24



Quote from 0xeb
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!
Ok, I've made a demo map of some of the things I talked about. I haven't done any iscript edits because there aren't any tools or guides for this, so I'll have to break out my debugger and do it from scratch this weekend.

It turns out changing the graphics in the way that I wanted to doesn't even work in 1.16.1 either, but I think it should be possible to do so, given that it's just updating the GRP pointer from the scout to point at the existing grp of the wraith, rather than trying to load new images.

I've also thrown in a few extra issues into the map to look at, and I've commented the triggers so hopefully you can follow all the pieces (you may have received some of this info via Heinermann in the last few days):
  • Victory triggers in SCR when the map has any EUDs in it are broken - the button will say Victory but the score screen will display as Defeat. This works as expected in 1.16.1
  • The map revealer unit graphic hasn't been updated for SCR so its still low-res
  • The overmind coccoon icon graphic hasn't been updated for SCR so its still low-rest (check scout's command card buttons - top left that replaced Move)
  • The Kills leaderboard in 1.16.1 allowed overflow to display Deaths of units, eg Kills of unit 444 is actually Deaths of khaydarin crystal. This was very useful in 1.16.1 because we can set Deaths via standard trigger actions, but not Kills. This was used in my very popular Desert Strike Night Fixed 2.63 map, and hence that map is slightly broken in SCR since this no longer works.

Download here: http://www.staredit.net/sc1db/file/4034/

Also for the extended EUD triggers you mentioned, do you have any plans to support control flow of trigger execution? Even a very rudimentary Goto instruction for use in triggers would be immensely helpful. It could be as simple as "goto trigger 8 earlier than this trigger" and also "goto trigger 2 later than this trgger" (presumably by updating the 'next trigger' execution pointer). That would allow for branching and loops, which would be super useful when trying to apply changes to an unknown number of units at a time, eg:
1. P1 bring at least 1 Marine to location 1 -> move location Rem onto Marine, remove marine at Rem, set custom score +1 for player 1
2. P1 bring exactly 0 marine to location 1 -> goto trigger 4
3. Always -> Goto trigger 1
4. ...

Right now because we don't know how many marines are at location 1 we have to do binary countoffs, or require multiple trigger cycles to execute the trigger to remove all of the marines and credit the player points for them. This is an extremely rudimentary example of what mappers often want to do; with there being 1700 units in the unit list, editing unit data via CUnit EUDs is fairly cumbersome at present, but some looping capability would make such operations far more tractable.

I guess you'd have to deal with infinite loops in some manner.

Post has been edited 2 time(s), last time on Mar 8 2018, 8:39 am by Lanthanide.



None.

Mar 8 2018, 6:43 pm 0xeb Post #25



Quote
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

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).

Quote
00000730: DA 68

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.




Mar 8 2018, 8:32 pm Lanthanide Post #26



That would explain why I got some weird hotkey inconsistencies, I had some strings that were like y\0Hotkey Y and in-game the string would just become "y". I replaced it with y\06Hotkey Y and that fixed it.

Post has been edited 1 time(s), last time on Mar 9 2018, 5:28 am by Lanthanide.



None.

Mar 9 2018, 9:42 am O)FaRTy1billion[MM] Post #27

👻 👾 👽 💪

Quote from 0xeb
Quote
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

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).

Quote
00000730: DA 68

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.
Cool, thanks for the info.

The generated stat_txt strings try to just fill unused space, either within strings (specifically the StarEdit sorting strings) or the space of unused strings, which sort of breaks #3. For some things it would be difficult to make a properly formatted stat_txt without rewriting the whole file with just triggers. Although, as long as everything else works fine it should be very easy to break references to overwritten memory to fix the specific problem Lanth was having.

Post has been edited 1 time(s), last time on Mar 9 2018, 9:54 am by FaRTy1billion.



TinyMap2 - Latest in map compression! ( 7/09/14 - New build! )
EUD Action Enabler - Lightweight EUD/EPD support! (ChaosLauncher/MPQDraft support!)
EUDDB - topic - Help out by adding your EUDs! Or Submit reference files in the References tab!
MapSketch - New image->map generator!
EUDTrig - topic - Quickly and easily convert offsets to EUDs! (extended players supported)
SC2 Map Texture Mask Importer/Exporter - Edit texture placement in an image editor!
\:farty\: This page has been viewed [img]http://farty1billion.dyndns.org/Clicky.php?img.gif[/img] times!

Mar 9 2018, 7:35 pm 0xeb Post #28



Ok guys. I fixed the emulator's logic so it behaves like 1.16.1 in regards to null terminators. I had two maps to test with. Hopefully, I did not break the other maps I did not try with.

You don't have to do anything special. The labels.scx map works as is now. Expect the fix in the next version of SC:R.




Apr 17 2018, 9:39 am Lanthanide Post #29



Hey 0xeb, here's a map demonstrating iscript changes that work in 1.16.1 that would be good to support in SCR, as well as a graphical change that doesn't work in 1.16.1 or SCR, but it should theoretically work. iscript changes would be HUGELY useful to let us do a lot more with mapping, and the graphical changes would allow us to clone images and give them different graphical effects, and this is especially useful if we can also do iscript changes.

The map is here: http://www.staredit.net/sc1db/file/4034/ I've had this kicking around for quite a few weeks now, just didn't get around to posting.

There are comment in the triggers indicating what does work in 1.16.1 but doesn't work in SCR, but would be great to support.

A brief description of the map contents here:
  • Fly a unit over the red beacon to end the game in Victory. In SCR, the button says Victory but when you click it, you get Defeat. 1.16.1 does Victory properly. This is a general bug for all EUD-enabled maps in SCR.
  • The triggers create a Tom Kazansky wraith just beneath the red beacon, with the iscript changed to produce a white engine graphic. Note that if you fly this wraith around, the engine is white, but all of the other wraith engines are orange - having white and orange engines in the map at the same time is only possible through these iscript changes. For some reason the iscript change sometimes crashes, and the engine only seems to work the first time you move the unit and then disappears and won't come back; probably the iscript is slightly wrong somehow (Farty did this change for me).
  • There are some overlords flying around, if you attack them with scouts, their missiles are coloured orange instead of blue - would be great to support this in SCR.
  • If you fly a unit over the blue beacon, then all of the normal wraith engines are turned to white. This is just to demonstrate that without specific iscript changes, changing the colour of the underlying wraith engine graphics effects all units that use that image. Hence why image cloning is also really desirable - it will be possible to clone images and give them different draw settings, so we can have different coloured engines of the same type on different units.

There are a few other bits and pieces in the map which you can see by inspecting the triggers & reading the comments.



None.

Options
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[08:59 pm]
Lanthanide -- D2 sound design not nearly as good, but it's a far faster game
[08:58 pm]
Lanthanide -- most of the monsters were very distinct just from their sounds (vipers were a bit meh, in particular), and given the slow methodical nature of D1, listening for monster sounds played a big part in how you progressed
[08:57 pm]
Lanthanide -- Diablo 1 had amazing sound design, skeletons sounded so great to kill
[08:57 pm]
Lanthanide -- if you listen to SC2 sound effects, particularly spells via an mpqeditor, they're all just generic womps and wisp sounds
[08:56 pm]
Lanthanide -- the sounds in SC1 are a bit cartoony, like d.matrix and irradiate sound effects, but they clearly stand-out from anything else in the game
[07:17 pm]
Pr0nogo -- yeah, hard to do worse than FK
[07:12 pm]
Voyager7456 -- so this'll be a step up then
[07:09 pm]
Pr0nogo -- @voy i can't believe you'd request that i stream that map when i've been playing fucking flame knives for 3-4 hours twice a week smh
[07:07 pm]
Pr0nogo -- so when a bunch of explosions are the same (sc2) you're not going to be able to read things as easily
[07:07 pm]
Pr0nogo -- sound is a big part of readability too, especially in 3d games where readability tanks due to incompetent graphics artists (and all blizz games have pretty ass particles, see war3 etc)
Please log in to shout.


Members Online: Roy, Voyager7456, ivasej, MTiger156, Lanthanide