Hello everyone,

I worked on SCR's emulator and I am glad the community liked it so far. It was a long task but we finally achieved a high level of success.

The EUD emulator also works on Mac OS now. It does lots of house keeping because it is not possible to do a simple pass-thru or forwarding emulation.

* A note about partial values

The EUD triggers do not provide primitives such as: "A = B" and hence the epScript compiler generates a bunch of triggers to do a binary search on the desired value and construct its value in parts.

When the emulator detects such access to pointer fields, it will start buffering the changes (because pointers are incomplete) until the changed pointer value (in the emulator's view) correspond to an actual in-game pointer of the same type.

This approach works most of the times and is used a lot in the CUnit emulation.

* CUnit

The following are the supported fields

* Unit selection array

It is possible to read/write to the unit selection array. The only allowed values that will take effect in the real game are proper CUnit pointer values.
Any incomplete values remain visible to the emulator alone and not the game.


* AI scripts

Both AIScripts and AIScripts2 (BW) are supported.

You cannot change the AI pointer script but you can overwrite whatever it points to. The original AI script was around 40kb. I noticed some EUD maps write more than the original allocate size, therefore the emulator now allocates extra 0x6000 bytes for custom AI scripts.

* CSprite

It is possible to change offsets 0, 4 and 8 only. Writing anything else will result in an EUD error.

The values that can be written should be valid pointers in to the sgUnitsMem array.

* CImage array

Regarding the CImage array, at the time being, it is a no-operation dummy buffer. The CImage array is present so that the games work. No graphical changes can take place.

* MPQ frozen maps
Regarding MPQ frozen maps: the emulator supports the MPQ freeze feature by trgk. It exposes just enough Storm data structures to let the EUD map retrieve the dynamic triggers decryption keys.

* Strings chunk / table

It is not possible to change the real pointer value of the strings chunk. Map makers write to it and what not but it does not have effect in the game.
The strings in that table are also initialized once and any changes to the strings values are not reflected.

What is important to note though that anything after the end of the string table (but still within the strings chunk) is readable and writable. Only EUD maps are aware of the data in the strings chunk (beyond the string table).

The strings chunk emulation is what allow the compiled maps (epScript) to work.

* Cards and buttons

Cards and buttons are re-written when the emulator detect changes from the EUD map. The button changes are reflected after all the triggers have executed.

By re-writing the cards/buttons, we allow the map makers to create more buttons than originally was possible. The map makers can change the pBtn pointer in the card structure to point to any memory address that is EUD accessible

* Palettes and bitmaps

Most GFX elements are also a NOP. The static buffers are initialized to zero. The dynamic buffers are allocated in the emulator and have the original sizes as 1.16.1 but read/write do nothing.

* Dialogs and Controls

There are lots of TCtrl static pointers in SC 1.16.1. From the emulator's perspective, most of those pointers are initialized with NULL.

Map makers should test for NULL and not blindly derefence those controls pointers.

Changing controls is not allowed in the emulator.

* Wireframes

Wireframes are partially supported. There are 3 wireframes supported: trans wire, mulsel wire and stat wire.

The emulator provides the same original data as SC 1.16.1 and lets the EUD map change the GROUP and FRAME information as they please, however:

- If the wires are dirty, after all the triggers execute, the emulator will proceed and rebuild the wire data
- Providing new wire FRAME data is not supported
- Shuffling FRAME data is supported -> An EUD map can duplicate wire frames for 10 units for instance. As long as the FRAME checksum is one of the checksums of the old SC 1.16.1 frames, then the emulator will allow duplication or reshuffling of the frames.

These limitations exist because SCR does not have the same FRAME format no longer.


* Stat Text

Stat text is emulated as well. You can only change the buffer pointed to by the static pointer. Changing the pointer itself is not supported.

When changes to stat text are detected, the custom hotkeys profile will be disabled and the hotkeys specified in the stat text strings will be effective.

* Other addresses

There are lots of data structures in SC 1.16.1 that no longer exist or make sense in SCR. For convenience, the emulator provides such data structures as empty NOP buffers (think /dev/null).

There are some maps that for some reason (checking SC's version by code byte checks?) read the code section of SC. For such maps to work, I have a bunch of supported code locations that are allowed to be read from the emulator.
The emulator will serve the same exact bytes as SC 1.16.1. Writing to code locations is a NOP.

* Storm

Storm also contains lots of data structures. Unfortunately, Storm has changed alot in SCR and no longer mirrors the old game. There's very limited support in the emulator when it comes to doing Storm changes.
For instance, some maps try to access the MPQ archive list in memory and what not. That is supported just enough for MPQ freeze to work and nothing else.

* Final notes

The EUD emulator has be re-written twice so far and the second re-write is much elegant than the first internal version.
Please keep in mind that supporting all EUD aspects of 1.16.1 is a big task and that's why it is limited for now.

Next year's SCR patch will feature all of the stuff I described above. The current patch is still limited.

If you have specific questions, please ask them in this thread.
If you find a problem, please provide exact details on how to reproduce the issue (screenshots, GIF files with illustration/steps, test maps, etc).

Welcome. =)

Here are some references for the provided offsets above:

• CUnit reference
  
• CSprite reference
  

Possibly an anti-hack?

Welcome to SEN 0xeb!

Borderline EUD question: would you consider re-enabling setting regular deaths for players 9 through 12? As I understand it the editable range of the set deaths action was strictly limited to players 1-8 when EUD actions were initially patched out but players 9-12 were an allocated part of the death table and wouldn't actually be an overflow. This would be a big help for maps/mapping tools that use death counters as variables/to do math.

Hi jjf28 and thank you.

No, that death counter array won't change because it breaks save games. EUD map makers use the ExtRegion in the game save structure as a scratch / variables space. Additionally, there are lots of useless strings (like RRTI info) that have been used by map makers as variable space.

Not an EUD question at all, but is it likely that we'll get first-class trigger support for some fairly general parts of data that are only editable by EUDs at the moment?

For example the ability to manipulate unit upgrades via trigger, instead of having to use EUDs? Or triggers that allow unit kills to be set (in addition to deaths)?

There are no plans to introduce new triggers. The only way so far is to use EUD to access all the supported EUD features. Meanwhile, map editor makers (SCMDraft for instance) can abstract EUD access into nice high level functions or GUI.

*chuckles a little*

???

I've got a memory overflow that worked perfectly in 1.16.1 but is now broken in SC:R. I used it in my popular Desert Strike Night Fixed map.

It uses memory overflow on the Show Leaderboard Kills action to display deaths of a unit, instead of kills of a unit. Since DCs are fully controllable via triggers, it allows us to have 228 arbitrary leaderboards (in addition to the 'custom score' leaderboard).

I've made a test map showing what works and what doesn't - it's possible to display deaths of Terran Marine, but it doesn't work for any other unit. Move the SCV onto the beacon to change the display to deaths of Young Crysalis (which I use in my Desert Strike map) and observe that it reads a value of 0 instead of 444 as expected.

Leaderboard deaths test map

Post has been edited 1 time(s), last time on Jan 6 2018, 8:41 pm by Lanthanide.

yoyo, thanks for you work. Could you add support for writing to CUnit? Currently can only read from it, can't write. I'm trying to use binary countoffs to transfer a unit's order coordinates to deathcounter, which requires that I subtract from the address considering the nature of binary countoffs.

EDIT: IGNORE THIS, MY STUFF WAS INCORRECT. Writing to CUnit works

Post has been edited 1 time(s), last time on Jan 27 2018, 5:18 am by Butch.

"006D1200 334759 iscript.bin pointer" says it is backed by code now, but can't seem to be read? If we can't read it to copy, what can we do with it?

iScript is not currently supported in SC:R.

You can set any value to 006D1200, but it is ignored.
It's value is fixed to 00000000

Ah. I was just hoping we could do *something* since it was recently changed to "backed by code", which would imply it has some functionality.

I read through the presentation you uploaded on your site http://0xeb.net/ very impressive! I had no idea that creating the emulator would have required deciphering so many 'unknowns' on your part, ie the amount of effort required to simply work out what was being changed, and why.

On page 72, you noted that the method of copying values between addresses is very inefficient and uses lots of triggers, and destroys the initial value in the first place, requiring it to be copied back (with yet more triggers).

The number of triggers involved makes it quite annoying to use such systems when writing triggers manually or with tool assitance (as most mappers here at SEN do not use trgk's EUD compiler), and trgk has also said he's not found a more efficient technique for performing value copies between addresses.

I have a suggestion for a simple extension you could make to the emulator, to support easier copying of values. And that is to modify the behaviour of the following two actions:
* Modify memory at death table X, Subtract 0
* Modify memory at death table X, Add 0

The first action of "subtract 0" could be made to copy the value at the address into a buffer (provided by the emulator), and the second action of "add 0" could be made to copy the value from the buffer into the referenced address. Basically a copy and paste with a special-purpose variable inside the emulator to store the value. Thus it would take 2 trigger actions to copy values between two addresses, instead of the dozens of entire triggers it currently takes. It should also be possible to copy and paste values between triggers, if the map-maker had a use for such an operation. I don't think anything more sophisticated than a single uint32 would be necessary; while multiple buffers to copy to/from might be nice, just being able to do any copy operation at all will be a big improvement over the current situation.

I think it's unlikely that there would be (m)any published maps using these actions, since subtracting or adding 0 should effectively be a NOP in SC 1.16.1. I guess it's possible that trgk's compiler could somehow do something with these, although I'm not sure what.

To avoid breaking any existing maps, I think there's two approaches that could be taken:
1. Scan through the ~17,000 known EUD maps and see if any of them use these actions in their triggers. If not, it should be safe to add this new behaviour to the emulator.
2. Alternatively, or if a map is found to use these actions, create a new memory address outside of the normal 1.16.1 address range that we can write a value of 1 to. The default being 0. Writing 1 enables the functionality in the emulator for the current map.


I hope that you'll consider adding this feature to the emulator, as it'll make certain mapping tasks considerably easier, and I don't believe it would take much effort - certainly not as much as many of the existing behaviours you've had to add special handling to support!

Post has been edited 5 time(s), last time on Feb 7 2018, 3:36 am by Lanthanide.

I think we need other actions for that. eudplib maps may add or subtract 0 frequently. However I like the idea.

I've just been made aware of another resource at our disposal by jjf28, which could be enhanced to provide far superior functionality to the Cut & Paste I suggested above and I think it would probably be less work to implement in the emulator as well, so a win-win.

The trigger structure uses a full byte ("Type2") for the modifiers, eg "set to", "add", "subtract", "toggle" and only 12 of the bits in this byte are used in 1.16.1, leaving 4 bits that can be given new definitions. According to trgk, these upper-order bits are not used by any of the existing EUD compilers.

http://www.staredit.net/wiki/index.php/Scenario.chk#Complete_Modifier_List
https://puu.sh/ziBcU/e1ada8ea73.png

So we could define bits 12 and 13 as "Add value at address to address" and "Subtract value at address from address" eg:
* Modify memory at death table X, Add value at address Y
* Modify memory at death table X, Subtract value at address Y

This would allow for the easy copy of pointers or other values between memory spaces:
* Modify memory at death table X, Subtract value at address X // Set value at memory location X to 0
* Modify memory at death table X, Add value at address Y // Copy value Y to memory location X

We could have as arbitrary many 'buffers' for doing calculations as we wanted with this scheme, rather than being restricted to only 1 buffer as in my previous suggestion. It also lets us add and subtract memory values directly, without having to do binary countoffs.

Since there are another 2 unused bits, these could be defined for other purposes too. I haven't put much thought into this at all so I'm not sure what the best use of these remaining 2 bits would be, but probably using them for conditions is the right direction to head in. So something like "Is memory address X value less than value at memory address Y" and similarly "Is memory address X value greater than value at memory address Y".

That would let us easily compare memory addresses against each other, although it wouldn't let us perform an "exactly" operation, unless we made them "greater than or equal" and "less than or equal" (aka "at least" and "at most") and then you put both conditions together into a trigger to synthesize an "exactly" condition. It might be that in practice "exactly" is far more useful than just "greater" and "lesser" comparators, and therefore we should use 1 bit for that, and have 1 bit left for definition of some other operator.

Or, an approach that would require significantly more work, would be to generalise the definitions of the bits, since right now bits 0-3 + 10 are only useful for trigger conditions. If the code were extended so that each bit had a separate definition when used in conditions vs actions, we could get a 16 different operators for conditions and actions which I think would allow a pretty-much complete set of foundational arithmetical / logical operations for both conditions and actions.

---

Edit:
After some further thought, I think the 4 new operators that would be most useful are: add, subtract, set, and exactly equal.

* Modify memory at death table X, Add value at address Y
* Modify memory at death table X, Subtract value at address Y
* Modify memory at death table X, Set to value at address Y
* Is memory at death table X exactly equal to value at address Y

The justification for "set" is that having a single action to copy values around is better than having to do a subtract + add. Set is something we will likely want to use a lot, and so having a bit entirely for that is worthwhile.

That leaves us with 1 bit, which is useful as being the "exactly equal" operator to give us direct comparisons between memory addresses.

Greater and Less Than comparisons can be achieved by copying Y into buffer Z, and then subtracting X from Z, then we can check whether the value of Z is 0 or not using existing conditions. It might be a little tricky for doing subtractions that result in negative numbers though, since I think the u32 will wrap around but the existing "at least" modifier will detect that as being a large positive number instead. So then you might have to do the operation both ways, or add 2^31 into buffer Z to start with and do a comparison as to whether the value of Z is < 2^31 or > 2^31.

Anyway, that's my thinking from someone who does manual EUD triggers. Of course trgk may have other operations that would be much more beneficial for his purposes.

Post has been edited 12 time(s), last time on Feb 8 2018, 4:41 am by 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

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

Handled by code is not very specific. In that case, it is handled by the eud_partial_buffer_adapter_t with mapped size = 0. Meaning all the iscript's buffer is a NOP essentially.

OTOH, the aiscript.bin support was added.

While changing sprites and other graphical aspects is not supported, would you be interested in iscript.bin changes to affect the animation sequences and only that?


Yes, there are plans to add extended EUD triggers. Same concept as IOCTL. They will leverage unused fields in the condition/trigger structures to express new operations including faster *mem1=*mem2 primitives.

And thanks for the report, I will look at it.

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.

Post has been edited 6 time(s), last time on Mar 7 2018, 6:53 am by Lanthanide.

Being able to change anything in iscript would be very useful, whether it be as simple as rearranging the called scripts in the headers (e.g. being able to copy the ground attack animation to the air attack animation for a normally ground-only unit) or actually being able to overwrite the script data itself.

Post has been edited 3 time(s), last time on Mar 7 2018, 6:06 am by FaRTy1billion.