Campaign Creations

From the natives.galaxy comments:

//--------------------------------------------------------------------------------------------------
// About Types
//--------------------------------------------------------------------------------------------------
//
// -- Complex types and automatic deletion --
//
// Many native types represent "complex" objects (i.e. larger than 4 bytes).  The script language
// automatically keeps track of these objects and deletes them from memory when they are no longer
// used (that is, when nothing in the script references them any longer).  The types which benefit
// from automatic deletion are:
//
//      abilcmd, bank, camerainfo, marker, order, playergroup, point,
//      region, soundlink, string, text, timer, transmissionsource, unitfilter, unitgroup, unitref,
//      waveinfo, wavetarget
//
// Other object types must be explicitly destroyed with the appropriate native function when you
// are done using them.

Ah, excellent.  Thank you, sir!

Sc2's garbage collection should render most memory leak problems a memory now.

While I am still not 100% sure, I do believe that all local variables in a trigger are created EACH time a trigger is started by an event (regardless on the trigger's successful conditions or not) as opposed that after initial successful conditions.

If this allows to use local variables into your trigger's conditions, the downside is it might cause additional mostly unnecessary net latency (since at this point, it's rare that you would use local variables in initial conditions). Ultimately, I guess the only way to minimize it might be via a function call (that does have the local variables) immediately with the needed parameters (ex : Triggering Unit, etc.) .

By extra latency, I imply such scenario :

Event - A unit takes damage
Condition - Damaged Unit-Type of Unit is Marine
Local Variables - Blah1 - Integer
                        Blah2 - Integer
                        Blah3 - Integer
Actions : (Random various ones)

In this case, if my theory is right, it would create (and destroy at near-end instant trigger end due failing conditions) all those 3 integer variables EACH time that a unit takes damage (regardless if said unit is a marine or not).

Ricky_Honejasi wrote: While I am still not 100% sure, I do believe that all local variables in a trigger are created EACH time a trigger is started by an event (regardless on the trigger's successful conditions or not) as opposed that after initial successful conditions.

You are correct, since local variables must always be declared at the beginning of the function, the trigger action function first initializes the variables, then evaluates the Condition, then evaluates a expression concerning the action (I don't know why it does this), then calls the functions from the Actions. If the local variables are initialized to with a function that creates an object (like say a unit or point), the object is created each time the event response fires. Fortunately, points are automatically cleaned; this is not the case for units.

Master Jademus Sreg wrote:

Ricky_Honejasi wrote: While I am still not 100% sure, I do believe that all local variables in a trigger are created EACH time a trigger is started by an event (regardless on the trigger's successful conditions or not) as opposed that after initial successful conditions.

You are correct, since local variables must always be declared at the beginning of the function, the trigger action function first initializes the variables, then evaluates the Condition, then evaluates a expression concerning the action (I don't know why it does this), then calls the functions from the Actions. If the local variables are initialized to with a function that creates an object (like say a unit or point), the object is created each time the event response fires. Fortunately, points are automatically cleaned; this is not the case for units.

Ugh, so how to clean up local unit variables? I do have quite a lot of calls using them and considering the triggering memory limit, I would hate my map to manage to hit the limit in mid-game and essentially mass breaking my triggers.

The local variable still gets cleaned, regardless; there's no leak there. But if the unit object is created in the same line as the variable initialization, instead of in the trigger action, then the unit will be created every time the event response fires.

Master Jademus Sreg wrote: The local variable still gets cleaned, regardless; there's no leak there. But if the unit object is created in the same line as the variable initialization, instead of in the trigger action, then the unit will be created every time the event response fires.

Ah I see.

The following might be already found by others a long time ago but anyway :

So something that can have some considerable interest for both mappers and modders alike (actually something that does cross the border considerably) is the SC2 editor's ability to save and load "as components".

What it does is saving a folder (.SC2Components) containing mod-like files of your map file. I didn't poke much into maps in a MPQ-like way but I strongly suspect it's files that you would extract off a map with programs such as WinMPQ.

The mod-like files it does save seem very identical to files you would extract off the Starcraft2's MPQ files. This include triggers, various data editor's stuff (ButtonData.xml, UnitData.xml, etc.), map's strings and so on.

Some of the very interesting possibilities are pretty much the following :
1) For modders that like the editor, you can do quite a bit of work via the Data Editor and Trigger Editor THEN extract your work that way to move on from that point by XML/TXT editing.
2) If you want to transfer any kind of data from one map to another, it's probably the way as you extract both maps' components, copy over the needed files and load the modified component folder into a map.
3) Probably could be useful to mass export a file's imported files along the way with mod files

I am unsure how well loading component files would work from a modder's direct XML/TXT modifications into the editor but it could be worth a try by modders.

Could do that with wc3, too.

Though not imported files - the editor wouldn't recognize them when I tried that part.

Post contains map + picture as attachment

So I poked even more with the dialogs as I wanted to fetch data that was more annoying to get until you find out how.

For example, I wanted to make a multi-level research tech in which triggers would auto-modify the corresponding button AND increase the mineral/gas/time costs for the next level of that same tech.

However, finding out how to access the catalog parts for those were annoying until I figure out how to fetch said data correctly. It's a step extra than the array part. As it's based on the "record" mentality as you can have aaa[0].bbb[0]

For example, the field I wanted to fetch was called "CAbilResearch_InfoArray_Resource" (in raw) off the ability "ArmoryResearch" (in raw too). I wanted to get the mineral and gas cost off Terran Vehicule Plating Level 2

I poked around for the correct field path until I discovered I had to write it out the following way :

Catalog : Abilities
Entry : ArmoryResearch
FieldPath : InfoArray[3].Resource[0] (for mineral)

Catalog : Abilities
Entry : ArmoryResearch
FieldPath : InfoArray[3].Resource[1] (for gas)

Catalog : Abilities
Entry : ArmoryResearch
FieldPath : InfoArray[3].Time (for time)

The 3 is because this specific research is the 4th research in the ability "ArmoryResearch"  (remainder : [0] = 1st, [1] = 2nd, etc.)

Btw, in the map, I properly modified the gas from 175 to 176 to allow to see the difference (also shown in picture)

Now, what I would still need for my own purposes is to fetch the REAL strings via triggers (ex : getting the Armory's real tooltip instead of  "Button/Tooltip/Armory" to show up on dialog buttons). So if somehow you know it, it would be very appreciated that you do tell.

Bah, it's refusing to change the catalog height value of a unit for some reason even though it reads it fine.

Xenon wrote: Bah, it's refusing to change the catalog height value of a unit for some reason even though it reads it fine.

Just to be sure, you did write then re-read to see if the height was still the same and you are not basing it on spawning a new unit of said type to see its height difference?

It gives an automatic debug message that says the value wasn't written.

What value are you using for entry and field? If you're modifying the damage for an effect, your entry might be "GhostSnipe" and the damage field is "Amount" (not "CEffectDamage_Amount" like it would show in View Raw Data mode).