SC2 BETA Editor findings

[Ricky_Honejasi]

26) Alright, the trigger editor in SC2 now allow something much more dramatic compared to WC3 : the fetching AND modification of the data editor's values IN-GAME of pretty much anything AND for ANY player wanted. That's a big step forward for potential maps.

In my example I did the modified the following for player 1 only via TRIGGERS :
-> The command center's button's tooltip to some other string.
-> The SCV Unit's name to "Local Player's SCV"
-> The SCV Unit's Max Life to 150

Note that my example doesn't modify the data for any player other than player 1. You can see the screenshots below to see the results and how to reproduce it.

This big step means the following in SC2 and more :

-> In a RPG map, each hero can be renamed to a written name of the player's choosing instead of preset names by the author.

-> You don't need multiple (altered or not) copies of a same unit-type to allow a lot of customization in-game (by the player) and/or to avoid specific conflicts that would occur otherwise.

-> If you care about languages issues (ex : making your map's units, tooltips, etc. in English AND French AND Spanish.), you can actually have a language menu for a player to pick its language and truly modify every thing into the language of their choosing. All that without having any real drawback on other players (other than the extra map size for those triggers).

The only real limits in such case would be if a Spanish player selected a custom unit of a French player and see the French name of its unit. Another case would be if the Spanish player controls the French's units, I presume he would see everything in French.

-> Opens up the possibility to backdoor potential cases of the data editor or to do changes that might be much simpler to do via triggers.

Note : I am still not sure of what happens if player's unit gets converted by another player yet. However, in all likelyhood, I presume it would change into the converting player's data values.

Overall, I am very happy about it since it's something that I would need in my personal plans.

[Xenon]

Thanks for the info, Ricky. I tried to change the catalog value of a projectile mover speed but couldn't get it to work (probably because I included the CMover_ in the path string).

Damage effects have a "kill" flag (which of course instakills the target) and a "live" flag, which prevents it from ever killing the target (reduces hp to 1). Useful for making things like SC1 plague, or triggered damage systems where you don't want units being killed before you can calculate how much damage you actually want.

Even though projectiles are units, moving them with triggers doesn't appear to work. The game prints their X/Y coordinates as messages as having been moved. Weird.

[Alevice]

"-> If you care about languages issues (ex : making your map's units, tooltips, etc. in English AND French AND Spanish.), you can actually have a language menu for a player to pick its language and truly modify every thing into the language of their choosing. All that without having any real drawback on other players (other than the extra map size for those triggers).
"

Take into account that, much like the game itself, the actual data is taken from the local region directory. If you open up a map with an MPQ viewer, you will notice that there is a folder like enUS (or enGB, or esMX, etc) where there is a file called Gamestrings.txt. This one stores practially all localized data for the given language-region, including all data editor strings, trigger/variable names and values within. No need for langauge menus and such. There is a downside, in that if you failed to specify a localization, the player with such localization will read almost everything like unit/name/stuff and so on, rather than bothering to load it from the default localization.

So yeah, playing with people from other regions will both rule and suck depnding on the map.

[RazorclawX]

Eh, you know there's a Text editor? It shows all the text strings you wrote in the map in one location.

[Alevice]

Of course, but it only shows it for your current localization. You need to chnage it and edit every string accordingly.

[RazorclawX]

Which is still better than how it was in War3.

[Xenon]

There are a lot of buttons for stuff that is no longer in the game (or is/was in the campaign, such as 2 Zeratul abilities and a bunch of upgrades). They also included this classic icon from SC:

[Ricky_Honejasi]

Now a critical issue that can happen in trigger editor just jumped on me today.

If your variables (as in all map-wide, not just individual variables) takes just too many global array space. You will either have editor errors that it takes too much memory OR worse, SC2 will flat out ignore your triggers altogether.

For example, I tried a single 3D integer array of 80*80*80 (512000 global array size) in the  editor shows me this message :

Code: Select all

Script failed to compile: Could not allocate Global Memory (try reducing the size) (See Trigger Editor for more details)

Funny test, a 3D integer array of 78*78*78 (474552) and it shows up that (I don't have ANYTHING else other than said variable + a trigger show up text) :

Code: Select all

Script failed to compile: Script too large (See Trigger Editor for more details)

Next test, a 3D integer array of 75*75*75 (438976), editor don't complain but inside SC2, it flat out ignore any trigger I have.

I had to drop down to 65*65*65 (274625) so that SC2 don't ignore my triggers.

While I can understand that Blizzard will not allow ridiculously high global array sizes, my main peeve is that SC2 ignore triggers if variables takes too much space. To me, it's a big problem since I am poking massively on various dialogs for my future map and I do need to keep references on a lot of data.

Admittedly, I could manage better but it's still very annoying that you continue to trigger and suddenly *poof* no trigger doesn't want to work at all on your next test and you poke around until you figure that it is what's happening.

My next main peeve about it is the max size ... let's stick with the 65*65*65 case. I checked the integer length and its range is −2,147,483,648 to +2,147,483,647 thus requiring 32 bits (or 4 bytes)

274625 integers would imply an use of 274625 * 4 = 1098500 bytes ... in other words more or less a 1 MB of RAM data cap for variables. That's ridiculously low considering that most non-crappy computers have 2+ GB (or 2000+ MB) of RAM and that SC2 easily use between 500 and 1000 MB of data for various stuff.

While technically it's still better than the 8182 1D limit per wc2 array variable as a whole, it's still annoying especially in advanced triggering cases that might require a lot of variables (ex : references to a lots of dialogs + all a large stash of their items of each dialog).

So I decided to make memory tests to see if it pushes RAM memory with more or less variables and to have an idea if variables takes a lot more memory than expected. All tests were made on a 64x64 empty map with the bare minimum, using terran race to avoid the RAM usage changes due to interface changes and such. Between each test, I closed down SC2 to avoid a test impact the memory of the next one.

Tests :
Without variables : 279304k
With variables      : 279796k
With variables + a manual initialisation loop for every array space : 280136k

So ultimately, the only thing this tells us that SC2 seems to preallocate the maximum memory possible for variables (and possibly script since I heard there was a limit of 1 MB ... coincidence?). No way to deduce if they screwed up memory management or not for variables.

Side things I noticed :
->  SC2 can abort your trigger execution (at least map initialization) if it takes too long.
->  SC2's integers "roll back" like in general programming if it goes beyond the max (ex : 2,147,483,647 + 1 would rollback into −2,147,483,648)

[RazorclawX]

It's either a performance cap or a safeguard for deliberate overflow. War3 had no shortage of such things and I suspect the SC2 methods only have to be discovered.

[Xenon]

gex, the guy who made Castle Fight noticed this (or something like it) [link]

[Ricky_Honejasi]

Damn, it's annoying but anyway, I do have a plan to make my work otherwise thanks to one of the dialogs' features (can have pretty much the same dialog but hide/show items + have different text on the same items but shown to different players).

Now I tried to copy-paste some array variables to another folder of my Trigger Editor mostly to avoid renaming yet just cut down the required array spaces. However, the compiler managed to misinterpret it (it somehow had an additional loop incrementor that caused a syntax error), I was forced to kill those variables and recreate the same ones in the same folder and renamed the same way so that it becomes fine again.

In other words, you might prefer to just plain recreate the wanted variables from scratch instead of copy/pasting to slightly modify them.

[Lavarinth]

In regards to the 2MB max limit for script:

Personally, I believe this isn't a huge issue for campaigns specifically. This issue may arise for complex maps such as Castle Fight, but when we're talking about campaigns, which is mostly our specialty, you have to consider your vast array of new options. No longer do we require loading screens as maps can preload in the background of a map via triggers. And on top of that, you can even skip the loading screen as well, making a near seamless "map" out of any amount of maps you want, each one holding their own script or triggers. Got a minigame you want the player to play but think it'll eat up too much of the global main map for this chapter or episode? Send it off into another map without interference in gameplay to the player. Have the map store the information much like in WC3, and load the newly acquired data of success or failure, etc into the main global map you've designed and presto.

[Ricky_Honejasi]

While it's not a confirmed finding (can't concretely test) but it's something that should be considered trigger-wise.

In triggers, it is now possible to detect a player's slot even as a referee or observer. This could imply that while referees/observers cannot normally interfere with the game, it can be very possible that they can if you let them trigger-wise.

The repercussions could be that if you set a "All players" trigger detection, it would also includes the observers/referees for the best AND worse.

A positive example would to create a dialog that normally all players can see only data and that observers/referees can also see them like if they were players.

A negative example, let's say you add up a dialog that every player can push the a button to create units, it might be possible that it also affect the observer/referee to create an unit for himself/herself inside the game. Note that could extend to chat commands and basically anything that an observer/referee can technically still do as observer/referee.

As a side thing, I do remember seeing at some point enough triggers to emulate a player into a observer/referee (even in terms of being able to chat or not) and vice-versa but I can't seem to find it again. I wonder if Patch 10 or 11 removed it or if it was just my imagination.

[Xelxiuz]

Casual question for you guys: Is it possible to access the collector's edition Thor mesh without collectors edition ie: use it in a custom map, allow others who don't have collectors to use it when playing your custom map, etc?

[tipereth]

I imagine it would just make your Thors look different in melee games but that's really just speculation on my part.