SC2Mapster

Quote from temhawk: Go

Arrays are just lists of values of the same type. They can be ordered or unordered...

Which is what makes me think that should work... It seems like there should be a way to detect item 12 on list one and return item 12 on list two. And in theory, modify item 12 on list three.

@BigDonRob: Go

And one way I WANT to use arrays, which I think I can, is to set up a record array. I think. I have 3 records (2 will be local, 1 global)

One is a list of zerg unit types. Two is the burrowed version of the same unit types. The global is a record of integers (kills) matching those same unit types.

In the above example, can I not ask for the assigned number of Record one, assign a local variable to the same assigned number of record 2, and modify the same assigned number of record 3? Without the 30 long string of If Then Else statements I'm currently using?

Quote from willuwontu: Go

I notice that you still want help with when to use arrays.

I'm going to fool around with arrays eventually, but I've learned I need to limit the number of things I'm trying to teach myself each day. lol.

I've finally figured out records (a bit), but I have a few questions about controlling variables in general.

If I make a record and set up a local variable to be that record, then have my trigger change the value of one of the variables inside the record, will that change be permanent, or will it last only until the trigger ends and it wipes?

Event> Unit dies

Local Variable "Record of Deaths"

if unit type, modify unit type in "record of deaths" plus 1

If a have 3 records for numbers, and want record 1 variables to be expressions of values pulled from records 2 and 3 (variable 1a = (variable 2a * variable 3a), would I need to nest record 3 inside record 2, and then nest record 2 inside record 1?

Is there not simply an option to mark a variable as "hidden" so that it doesn't show up again until it's no longer marked hidden? This would make things so much easier.

@MaskedImposter: Go

While I did change some costs, I never changed the cost of the swarmlings, and I have since reset all of the other units to their default. So the Burrowed and unburrowed units should be the same cost, as well.

I just noticed that enemy swarmlings don't unborruw automatically when a unit gets close. Everything else unburrows because I have the "enable campaign AI for all players" on initialize. Is there a separate campaign AI for specialty units?

And what is the easiest way to alter the "chase" distance on enemy units? The AI is being a little funny and having units chase after a dead unit, burrow, pause, unburrow, and finally head back to it's spawn location.

    Untitled Trigger 001
    Events
        Unit - Any Unit takes Fatal or Non-Fatal Any damage (from Any effects)
    Local Variables
    Conditions
        (Unit type of (Triggering unit)) == Barracks
        ((Triggering unit) Life (Percent) (Current)) <= 33.0
    Actions
        Unit - Set (Triggering unit) Life (Percent) to 100.0
        Unit - Rescue (Triggering unit) for player (Damaging player) and Change Color

Try that. It factors in abilities and effects, and it should bypass the (attacking unit) function.

Quote from ArcaneDurandel: Go

if they even knew how to make mods and separating stuff from a main map file.

Is it possible to turn a map file into an actual mod? It'd be nice to know I could steal from myself for future projects.

More importantly, is there a way to remove dependencies once they're in place?

Monthly Trigger Exercise 8

The trigger exercises didn't last long, but they have some nice ideas that you can review.

EDIT: Didn't notice you were asking about structures. NVM

@zuPloed: Go

Well, I started my map as more of an exercise in editing, so everything I learn from the experience is a win. But it's a tower assault. You don't control any of the units. They march forward towards certain death, earning you resources you use to upgrade future waves. I intend to have a UI power system, with player activated abilities that provide temporary bonuses on cooldowns, but I shied away from even adding Hero units because I didn't think they'd mesh well with the style of the game.

At most, I was going to add in NPC "Heroes" that would just be unique additions with powers, with only one being on the "Cattlefield" at a time, but the player being able to swap out new heroes at will or at stages.

I am doing my first true tests of the upgrade system, which only covers the first available unit. Once I get the system implemented and learn a little more about data editing, I should be able to get everything up and rolling a lot faster. But with the zerg (who you're "in charge of") ground game is a bit limited over the long haul, so I'm trying to vary up their abilities with an upgrade system that keeps them fresh as the game goes on.

Quote from temhawk: Go

Or would something like this be more to your liking?

That is absolutely perfect. I still haven't decided what kind of icon I want in the background, But that style is exactly what I'm looking for.

Quote from DrSuperEvil: Go

@BigDonRob: Go

Well he did ask for a data solution in the data forum.

I know, and I'm not knocking anything you've said. I simply don't understand much of what you say. While my hate for editing data is lessening, I still look at every problem as "how can I do this with a trigger?".

But if a unit has veterancy established in the data, then I believe the trigger can set the level of the unit. It's one of the options listed under properties, at least.

@JEGCPR: Go

That's why you're receiving the error. Because revive is tied to a morph. Think Kerrigan from HoTS. If you want a blank slate unit reviving in the same place, then you need to use create unit.

If your trigger is simply when your unit dies. Set up a point variable (position x of (triggering unit),position y of (triggering unit))

Then you create new unit at point(your variable) You need to add in a wait and some effects to make it look nice, but that's the jist of it.

Quote from temhawk: Go

A word of caution: the "pick each..." family of actions suffers from a couple of weird bugs that can cause errors for no apparent reason whatsoever. They cannot be relied upon and as such I recommend getting in the habit of using the "for each..." actions instead.

Interesting. I've actually only stumbled across "for each" once, and it was in the 101 thread about using do while loops. At least I believe the one the TC was comparing it to was "for each". It only compared "while loops" with "for loops".

@joppeownaaj: Go

Is it not compiling the script or is it simply not working in game? And do you have more than one type of "tower" you're trying to take over or are they all the same unit type?

@temhawk: Go

I'd considered it, but the icons there are something I would actually like to leave as is. The upgrades that normally go there will still be displayed there. If I changed them (the weapon, at least), you would no longer be able to see the unit's damage, correct?