Hi, so I've been working on a little tron map for SC2, mainly to practice my skills in the editor, I doubt I'll go for an actual release. I've hit a major roadblock though, with a problem that I just can't figure out how to fix.
Basically, I have a trigger that creates a unit. I want another trigger, to recognise that a unit is being created, check that it's that particular unit type, and then do something. I just can't figure out how to do that for the life of me. I've had the same problem TONS of times earlier while making this map, and I've had to resort to silly work arounds.
Back in the Warcraft III days I also enjoyed programming maps, and I clearly remember that back then, I could easily do what I'm trying to do here, but now it just seems impossible.
Any help please :)?
edit: Aha, I may have figured it out now, it's incredibly convuluted though, and you basically have to reverse the comparison condition and use an unfamiliar kind of function. Gah.
edit2: Well, it should work, but now I get an error ingame, that says that the trigger doesn't work, because when it returns "EventUnit", there's nothing there. The trigger still does something though, it's simply doing it incorrectly.
'Created unit' refers to a specific unit, rather than a unit-type. Therefore it will only let you compare this with other units.
Instead of choosing 'created unit' for your comparison, navigate to the 'units' section and choose 'unit type of unit'. Then select 'created unit', and you can compare the unit type of the created unit.
Basically:
(Unit type of (Created unit)) == [Insert Unit-Type Here]
Edit: I'm not actually entirely sure if units spawned via triggers will set-off a 'Unit is created' event. You'll have to test this.
If the two triggers don't trigger immediately after one another, don't use Last Created Unit. In fact, in nearly all cases you need to see a unit you created in the past it's wise to set it to a variable to call back, as Last created unit is a garbage var that can change a lot (refer to it only immediately after creation). You can set this unit into a variable unit or unit group and track where it is for the comparison later.
As far as unit type comparisons, I would probably do a switch.
Switch (value -> Unit Type of Unit -> *insert unit variable you set previously in here*).
Add Action -> Switch Value -> Value -> Select the unit type you want to compare it with.
In it's action section below this, do what you want in this scenario.
Add another action to the Switch as you have more type checks, and it should come out about as clean as possible for any number of scenarios with unit type-based actions.
I'm going to have to explain exactly what I'm doing, which is why I can't do what you guys are suggesting, I think.
Basically, you got a hellion driving around, the lightcycle (tron). I have 4 points surrounding it, basically up, down, left and right, and then a last point where the hellion is. These points update their position around the hellion every 0.02 seconds. In order to make the hellion move with WASD keys, I basically order the hellion to move to the corresponding point. For example, if you want the hellion to move up, pressing W, the hellion starts moving towards the point above it (so to speak), and this trigger keeps repeating itself, until another movement trigger is initiated. This way you don't have to spam keys or hold keys down in order to move.
The cube spawning trigger, the light trail from the hellion, basically spawns the cubes on the point on the opposite side of the hellion. Here's a video to demonstrate how it looks:
Now what I need, is for the light trail to kill any unit it comes in contact with, ie. the lightcycles. The way I want to do this, is to detect when a cube is spawned, then add a rectangle, on the position of the created cube, to an already existing region (when you enter that region you die). Now, if you watch the video, you will see that the cubes spawn on top of the hellion. Therefore, I can't just add the rectangle to the region right away, or the lightcycle will die instantly. I need a delay long enough for the lightcycle to move out of the way, before the trigger runs. This delay means that I can't really use variables, due to multiple instances of the trigger running at the same time. If I store the location of the cube in a variable, then wait 1 second, and create the rectangle, the variable's stored information will be changed by a new instance of the trigger, and the original instance of the trigger will then position the rectangle on the incorrect cube. I tried solving this by using an array of positions, where I upped the array number being used everytime by 1, so that the location information was being stored in the same variable array, but different parts of it, so to speak. This didn't really seem to work though for some reason.
If any of this makes ANY sense, then hit me with some ideas, because I sure can't figure out how to make the lighttrails kill lightcycles, even though it should be incredibly simple :(
You could store the direction the light cycle is moving in a variable (I assume you do anyway) and have the cubes spawn on one of the surrounding points, assuming they're not too near.
Another option would be to use an immolate style type ability on the cubes which only starts half a second or so after the cube spawns. I don't have the editor in front of my so I can't give you a complete walkthrough on that, but the basic principle would be to have a pair of persistents, the first one with a single half second duration period with "Effect: Final" set to create the second persistent and the second persistent with a large count (-1 might work for unlimite) or short duration periods, maybe 0.1s or so. Then set the periodic effect to a search effect, searching a small radius for any units and set the effect on that to be fatal damage to the light cycle. You'd probably need a validator of some sort to stop the cubes killing each other though.
While that could work in theory, I don't feel like it's the proper way to pull it off. I did try giving the cubes guns, but that failed because they had to turn before they could shoot, which ruined their look and sometimes didn't quite work. I feel killing the lightcycles with a trigger is much more clean and will work better generally.
So picking up the idea of not using a delay for your region/immolation/whatever - In your movement trigger you probably handle things this way:
1) Move Unit
2) Spawn cube ontop of unit
Or maybe the two are the otherway round. Doesn't matter. What you can do is:
1) Store the Unit's current position.
2) Move Unit
3) Spawn cube on the previously saved position.
That way you won't need delay (since the unit's gone already) and don't have to keep track of aaaall the cubes.
And I would suggest using a buff with a small search area effect to kill off the lightrunners. It'll give you less troubles if you want the trail to disappear a few meters behind you instead of being there all the time (you can just give the cubes a timed life of X seconds).
First thought:
Create an array like you already have with the center point of the last region created stored in it.
use the player number as the index counter.
blah blah create region.
LastPoint[PlayerIndex] = center point of last created region
Now you have an event that runs whenever a unit enters a region, I assume, that kills players that go on the cube spots.
Inside there, do a for loop for each tron player. Then write a condition check seeing if the center point of the triggering region equals lastpoint[PlayerIndex], and if triggering player is playerindex. If both true, don't kill the player, you know he just made this spot and needs to leave still.
Create a new event when a user leaves any region. Do the same for loop through each tron player, and compare with the same condition (center point triggering region equals lastregion[playerindex]). If this is the case, set lastregion[playerindex] to no point (null it out), making him die now if he re-enters it. (this part technically doesn't need to be done, since the moment he creates a new region the last point stored would be done away with, but for ensuring he dies to a last created region this could be done)
There you go. This would cause a tron player who gets immediately behind another tron player's trail to die, while the tron player who just laid it down will still be safe, and all you need is to store a single point for each unit, the center point of the last region created.
I'd review your code and see how you manage regions, noting if any overlap. If they overlap my solution may not work. From how the cubes look on your video clip though, it seems they are spread out evenly and don't overlap, so it's not possible for a unit laying down the cubes to enter two regions he created in the past at once as he's driving out, I hope.
Well if you insist on using triggers; you could make a 'collision check' trigger to run just before the looping movement trigger. It could move a region just infront of the hellion and check to see if there are any light cubes within. If so, kill the hellion.
A non-animated ability would still be far less complex/resource intensive than these trigger-based alternatives, though. But I too am still mistrustful of that data editor at times ><
EDIT: Yea there are lots of ways around this particular problem apparently. Take your pick!
So picking up the idea of not using a delay for your
region/immolation/whatever - In your movement trigger you probably
handle things this way:
1) Move Unit
2) Spawn cube ontop of unit
Or maybe the two are the otherway round. Doesn't matter. What you can do
is:
1) Store the Unit's current position.
2) Move Unit
3) Spawn cube on the previously saved position.
That way you won't need delay (since the unit's gone already) and don't
have to keep track of aaaall the cubes.
And I would suggest using a buff with a small search area effect to kill
off the lightrunners. It'll give you less troubles if you want the trail
to disappear a few meters behind you instead of being there all the time
(you can just give the cubes a timed life of X seconds).
I'm not teleporting the lightcycle, I'm telling it to move, so I'll need a delay in order to do what you're suggesting, which won't work, because the cube spawning is based off the position of the lightcycle.
First thought:
Create an array like you already have with the center point of the last
region created stored in it.
use the player number as the index counter.
blah blah create region.
LastPoint[PlayerIndex] = center point of last created region
Now you have an event that runs whenever a unit enters a region, I
assume, that kills players that go on the cube spots.
Inside there, do a for loop for each tron player. Then write a condition
check seeing if the center point of the triggering region equals
lastpoint[PlayerIndex], and if triggering player is playerindex. If both
true, don't kill the player, you know he just made this spot and needs
to leave still.
Create a new event when a user leaves any region. Do the same for loop
through each tron player, and compare with the same condition (center
point triggering region equals lastregion[playerindex]). If this is the
case, set lastregion[playerindex] to no point (null it out), making him
die now if he re-enters it. (this part technically doesn't need to be
done, since the moment he creates a new region the last point stored
would be done away with, but for ensuring he dies to a last created
region this could be done)
There you go. This would cause a tron player who gets immediately behind
another tron player's trail to die, while the tron player who just laid
it down will still be safe, and all you need is to store a single point
for each unit, the center point of the last region created.
I'd review your code and see how you manage regions, noting if any
overlap. If they overlap my solution may not work. From how the cubes
look on your video clip though, it seems they are spread out evenly and
don't overlap, so it's not possible for a unit laying down the cubes to
enter two regions he created in the past at once as he's driving out, I
hope.
This sounds really complicated, and I think there's an easier way to do this.
I have figured something else out though. Instead of making cubes deadly, I'm thinking I can use the 4 points that surround the lightcycle. I can create 4 triggers that turn on and off according to which direction the lightcycle is moving. The trigger will go if a unit moves within range of a point, ie. one of the surrounding points. So if the lightcycle is moving left, the trigger keeping an eye on the left point will be active. I fear this might kill the lightcycle, even if it turns before hitting a trail though. Any ideas on this?
What's complicated about my route? XD I thought you were already creating regions to flag each cube as deadly. As long as you are doing that, my suggestion is really easy. *shrugs*.
What's complicated about my route? XD I thought you were already creating regions to flag each cube as deadly. As long as you are doing that, my suggestion is really easy. *shrugs*.
I just looked through your suggestion once more, and it actually makes sense now, I just misunderstood it first off. There is a problem though. You can't, apparently, create new regions in the Galaxy Editor, you can only add more parts (rectangles or circles) to an already existing region. Thus, the center of the region will not actually be where the lightcycle is, but rather some weird random point on the map, depending on where the extra region "addons" have been placed so far.
Pretty sure you could create regions through triggers back in Warcraft III. Pretty lame :/
edit: Ah, triggers doing things to regions were even more limited in Warcraft III apparently haha
Is is just me or should Tron bikes not even be using regions.....
wouldnt it be better to create a unit behind the Bike every time the player turns and then have these created units cast a "beam between eachother and the bike .. this will create a line with the path of the bike...
second you would have this beam effect do aoe dmg in a very small aoe so that if anything touches the beam the unit dies.....
and thats about that..... then i would maybe take these same units set one in each corner of the playable area and then you have walls that kill people too...
All this would require is ..... alot of custom data settings. And then triggers to create the invisible dummy casters for the wall each time the bike changes direction and then another trigger to set which dummy units are spose to be casting the wall ability on which dummy units to connect the points.
wouldnt hurt to keep and array of units so you can easily loop through it and assign the proper targets for the wall ability as more units are created.
I played the current version of this online and it was garbage.
Hi, so I've been working on a little tron map for SC2, mainly to practice my skills in the editor, I doubt I'll go for an actual release. I've hit a major roadblock though, with a problem that I just can't figure out how to fix. Basically, I have a trigger that creates a unit. I want another trigger, to recognise that a unit is being created, check that it's that particular unit type, and then do something. I just can't figure out how to do that for the life of me. I've had the same problem TONS of times earlier while making this map, and I've had to resort to silly work arounds.
Back in the Warcraft III days I also enjoyed programming maps, and I clearly remember that back then, I could easily do what I'm trying to do here, but now it just seems impossible.
Any help please :)?
edit: Aha, I may have figured it out now, it's incredibly convuluted though, and you basically have to reverse the comparison condition and use an unfamiliar kind of function. Gah.
edit2: Well, it should work, but now I get an error ingame, that says that the trigger doesn't work, because when it returns "EventUnit", there's nothing there. The trigger still does something though, it's simply doing it incorrectly.
@Rambowjo: Go
'Created unit' refers to a specific unit, rather than a unit-type. Therefore it will only let you compare this with other units.
Instead of choosing 'created unit' for your comparison, navigate to the 'units' section and choose 'unit type of unit'. Then select 'created unit', and you can compare the unit type of the created unit.
Basically: (Unit type of (Created unit)) == [Insert Unit-Type Here]
Edit: I'm not actually entirely sure if units spawned via triggers will set-off a 'Unit is created' event. You'll have to test this.
How is the second event being triggered?
If the two triggers don't trigger immediately after one another, don't use Last Created Unit. In fact, in nearly all cases you need to see a unit you created in the past it's wise to set it to a variable to call back, as Last created unit is a garbage var that can change a lot (refer to it only immediately after creation). You can set this unit into a variable unit or unit group and track where it is for the comparison later.
As far as unit type comparisons, I would probably do a switch.
Switch (value -> Unit Type of Unit -> *insert unit variable you set previously in here*).
Add Action -> Switch Value -> Value -> Select the unit type you want to compare it with.
In it's action section below this, do what you want in this scenario.
Add another action to the Switch as you have more type checks, and it should come out about as clean as possible for any number of scenarios with unit type-based actions.
I'm going to have to explain exactly what I'm doing, which is why I can't do what you guys are suggesting, I think.
Basically, you got a hellion driving around, the lightcycle (tron). I have 4 points surrounding it, basically up, down, left and right, and then a last point where the hellion is. These points update their position around the hellion every 0.02 seconds. In order to make the hellion move with WASD keys, I basically order the hellion to move to the corresponding point. For example, if you want the hellion to move up, pressing W, the hellion starts moving towards the point above it (so to speak), and this trigger keeps repeating itself, until another movement trigger is initiated. This way you don't have to spam keys or hold keys down in order to move. The cube spawning trigger, the light trail from the hellion, basically spawns the cubes on the point on the opposite side of the hellion. Here's a video to demonstrate how it looks: Now what I need, is for the light trail to kill any unit it comes in contact with, ie. the lightcycles. The way I want to do this, is to detect when a cube is spawned, then add a rectangle, on the position of the created cube, to an already existing region (when you enter that region you die). Now, if you watch the video, you will see that the cubes spawn on top of the hellion. Therefore, I can't just add the rectangle to the region right away, or the lightcycle will die instantly. I need a delay long enough for the lightcycle to move out of the way, before the trigger runs. This delay means that I can't really use variables, due to multiple instances of the trigger running at the same time. If I store the location of the cube in a variable, then wait 1 second, and create the rectangle, the variable's stored information will be changed by a new instance of the trigger, and the original instance of the trigger will then position the rectangle on the incorrect cube. I tried solving this by using an array of positions, where I upped the array number being used everytime by 1, so that the location information was being stored in the same variable array, but different parts of it, so to speak. This didn't really seem to work though for some reason.
If any of this makes ANY sense, then hit me with some ideas, because I sure can't figure out how to make the lighttrails kill lightcycles, even though it should be incredibly simple :(
You could store the direction the light cycle is moving in a variable (I assume you do anyway) and have the cubes spawn on one of the surrounding points, assuming they're not too near.
Another option would be to use an immolate style type ability on the cubes which only starts half a second or so after the cube spawns. I don't have the editor in front of my so I can't give you a complete walkthrough on that, but the basic principle would be to have a pair of persistents, the first one with a single half second duration period with "Effect: Final" set to create the second persistent and the second persistent with a large count (-1 might work for unlimite) or short duration periods, maybe 0.1s or so. Then set the periodic effect to a search effect, searching a small radius for any units and set the effect on that to be fatal damage to the light cycle. You'd probably need a validator of some sort to stop the cubes killing each other though.
Could you not just create an active weapon that targets and kills any hellions within the immediate vicinity to the cubes?
EDIT: Yea, something similar to what the above poster is suggesting.
While that could work in theory, I don't feel like it's the proper way to pull it off. I did try giving the cubes guns, but that failed because they had to turn before they could shoot, which ruined their look and sometimes didn't quite work. I feel killing the lightcycles with a trigger is much more clean and will work better generally.
@Rambowjo: Go
So picking up the idea of not using a delay for your region/immolation/whatever - In your movement trigger you probably handle things this way:
1) Move Unit
2) Spawn cube ontop of unit
Or maybe the two are the otherway round. Doesn't matter. What you can do is:
1) Store the Unit's current position.
2) Move Unit
3) Spawn cube on the previously saved position.
That way you won't need delay (since the unit's gone already) and don't have to keep track of aaaall the cubes.
And I would suggest using a buff with a small search area effect to kill off the lightrunners. It'll give you less troubles if you want the trail to disappear a few meters behind you instead of being there all the time (you can just give the cubes a timed life of X seconds).
First thought:
Create an array like you already have with the center point of the last region created stored in it.
use the player number as the index counter.
blah blah create region.
LastPoint[PlayerIndex] = center point of last created region
Now you have an event that runs whenever a unit enters a region, I assume, that kills players that go on the cube spots.
Inside there, do a for loop for each tron player. Then write a condition check seeing if the center point of the triggering region equals lastpoint[PlayerIndex], and if triggering player is playerindex. If both true, don't kill the player, you know he just made this spot and needs to leave still.
Create a new event when a user leaves any region. Do the same for loop through each tron player, and compare with the same condition (center point triggering region equals lastregion[playerindex]). If this is the case, set lastregion[playerindex] to no point (null it out), making him die now if he re-enters it. (this part technically doesn't need to be done, since the moment he creates a new region the last point stored would be done away with, but for ensuring he dies to a last created region this could be done)
There you go. This would cause a tron player who gets immediately behind another tron player's trail to die, while the tron player who just laid it down will still be safe, and all you need is to store a single point for each unit, the center point of the last region created.
I'd review your code and see how you manage regions, noting if any overlap. If they overlap my solution may not work. From how the cubes look on your video clip though, it seems they are spread out evenly and don't overlap, so it's not possible for a unit laying down the cubes to enter two regions he created in the past at once as he's driving out, I hope.
Well if you insist on using triggers; you could make a 'collision check' trigger to run just before the looping movement trigger. It could move a region just infront of the hellion and check to see if there are any light cubes within. If so, kill the hellion.
A non-animated ability would still be far less complex/resource intensive than these trigger-based alternatives, though. But I too am still mistrustful of that data editor at times ><
EDIT: Yea there are lots of ways around this particular problem apparently. Take your pick!
I'm not teleporting the lightcycle, I'm telling it to move, so I'll need a delay in order to do what you're suggesting, which won't work, because the cube spawning is based off the position of the lightcycle.
This sounds really complicated, and I think there's an easier way to do this.
I have figured something else out though. Instead of making cubes deadly, I'm thinking I can use the 4 points that surround the lightcycle. I can create 4 triggers that turn on and off according to which direction the lightcycle is moving. The trigger will go if a unit moves within range of a point, ie. one of the surrounding points. So if the lightcycle is moving left, the trigger keeping an eye on the left point will be active. I fear this might kill the lightcycle, even if it turns before hitting a trail though. Any ideas on this?
What's complicated about my route? XD I thought you were already creating regions to flag each cube as deadly. As long as you are doing that, my suggestion is really easy. *shrugs*.
I just looked through your suggestion once more, and it actually makes sense now, I just misunderstood it first off. There is a problem though. You can't, apparently, create new regions in the Galaxy Editor, you can only add more parts (rectangles or circles) to an already existing region. Thus, the center of the region will not actually be where the lightcycle is, but rather some weird random point on the map, depending on where the extra region "addons" have been placed so far.
Pretty sure you could create regions through triggers back in Warcraft III. Pretty lame :/ edit: Ah, triggers doing things to regions were even more limited in Warcraft III apparently haha
Let me create a test file for you. Give me a few. Do you have an IM?
Sure. erik.username [at] gmail.com - live messenger, replace username with my username on here
Is is just me or should Tron bikes not even be using regions.....
wouldnt it be better to create a unit behind the Bike every time the player turns and then have these created units cast a "beam between eachother and the bike .. this will create a line with the path of the bike...
second you would have this beam effect do aoe dmg in a very small aoe so that if anything touches the beam the unit dies.....
and thats about that..... then i would maybe take these same units set one in each corner of the playable area and then you have walls that kill people too...
All this would require is ..... alot of custom data settings. And then triggers to create the invisible dummy casters for the wall each time the bike changes direction and then another trigger to set which dummy units are spose to be casting the wall ability on which dummy units to connect the points.
wouldnt hurt to keep and array of units so you can easily loop through it and assign the proper targets for the wall ability as more units are created.
I played the current version of this online and it was garbage.