Doesn't really solve the problem. Having a second weapon won't cause it to change targets once it has acquired one. Unless you know something I don't...
Another way this might work is there any way to use numbers like a unit in a region, I'm thinking if i had 52 units in a region i could pick one random set it to be first drawn unit. Then move it to a different region so it won't be picked again, until that region has no units thus no repeats and truly random each game. I'm not sure how to do that with numbers tough, And I don't wanna use 52 units just to make this work as it's a very newbie wasteful way of doing it.
Haha, sounds like a pretty ingenious idea to me. If you're having trouble implementing the algorithm in code, I don't see you should shun the idea of using another aspect of the editor to get it done. Unless it's something you're doing very often (aka multiple times a second), I doubt you'll have any performance issues with it. Just do this outside of the players' camera bounds if you're worried about it looking sloppy (or in your words, "newbie") :)
It's me again. I was able to get past the problem with the orphaned regions by adding an extra condition to the "Intercept Missile" trigger to check if the attached unit is still alive. I guess that will have to do.
I also optimized that trigger to be able to handle multiple projectiles at a time by deciding to either push or append the order to attack. A single turret can now destroy both missiles from a single Banshee attack.
The problem I'm having now is that after creating a few units and having them duke it out, the debug window graph will begin to show that events are firing while nothing is really happening. Even though all the view options are set to show all types of events, no events are being shown in the list, yet there are a consistent number of events showing on the graph. This number will grow as I continue to place units and have them fight to the death. It's acting like a memory leak... but why would it show up as events on that graph? Any ideas?
I'm starting to think that there's no way to use "Attach Region to Unit" without having it leak, since there's no way to destroy that region. See? This is why I didn't want to use triggers in the first place -_-
Sorry to keep posting on this thread. I just want to get everything cleaned up and done right before I actually implement this concept in my map, and I know you guys have a lot more experience with this than I do.
Haha, scratch what I said above. Since then I learned about the "Attach Region to Unit" function and Data Tables, which completely negate my stated reason for using triggers in the first place. Oh well, it still works.
However, I am having some trouble with the "Attach Region to Unit" function. Apparently when the unit dies, the region decides to hang round... which is not cool. As far as I can tell, there isn't a way to destroy a region, so I'm resorting to moving the "orphaned" regions off the map once their associated unit dies. However, even with that being done, every now and then I'll get a trigger error from an orphaned region because it hasn't moved in time. Any ideas on how to avoid this from happening?
Anyway, here's the map for you to try out. You'll be able to reproduce the problem if you put a lot of units out at once. Left-click for turets, right-click for enemy Marauders, middle for enemy Banshees. Please let me know if there's anything else I can do to clean up my code or algorithm.
you could attach new region to created unit, add simple unit enters region event and use 'Unit attached to trigerring region'
Wow, didn't know you could do that. Thanks for pointing that out!
Guess I need to spend some more time looking at native functions. BTW, is there an organized list of them anywhere? For some reason I have trouble finding text in the editor browser window.
As you pointed out, there is no galaxy function that will return the reference unit of that event. Why? I think it's simply because Blizzard did not include it.
But I do think there's a way you could logically find the unit you're asking about. Here's how:
Add the event "Any unit enters range R of Unit Y" to a trigger and place Unit Y in Unit Group G.
When the event fires, have the trigger check find all units within distance R of the triggering unit that are members of Unit Group G. That should give you the desired unit(s).
There might be some other checks you'll have to make to take into consideration the possibility of the triggering unit being within range R of multiple members of Unit Group G at the same time (if the triggering unit was teleported or walked into range of more than 1 member of Unit Group G at the same time).
You want to make sure X is evenly divisible by 5, right? X mod Y gives the remainder of X / Y, so in this case you want the remainder to be 0. Unless I'm not understanding your question correctly. By "true number" you mean integer, right?
I see. Well it looks like that's a dead end.
Do you know of any clever and effective way to somehow pass the unit as a variable to the trigger?
Basically when I add a unit to a unit group, they're added to the event "Unit within range" so if anything gets close to them, an action will occur.
I have tons of units going through this at random points throughout the game. It's really a collision detection between particles.
You can look into dynamically adding events to triggers using the "TriggerAddEvent..." native functions. A good tutorial on the subject can be found here: http://starcraft-2-galaxy-editor-tutorials.thehelper.net/tutorials.php?view=155774 (make sure you check the "Use Reference" box for variable types like unitref, which the author did not do in his example)
This allows you to make and use some pretty useful functions that are not normally available in the GUI. In this case you'll be looking into creating a custom action that will add the "Unit within range of Unit" event to a trigger with specific unit(s) defined at runtime (instead of in the editor). You'd still have to specify a single unit for the second parameter in that event, so you'd have to ditch the idea of using a Unit Group to do it, but at least you could reference the unit some other way (as simple variable or event response) at the time of adding the event.
As a disclaimer, just know that I haven't been able to find very much information about adding events to triggers at runtime. I've been using it is many different ways without any trouble, but I'm sure it has its limits. I'd say give it a shot and see what happens.
Does your unit still use a footprint? Footprints disable turning.
Wow thanks! You learn something new every day. I'll give it a shot and see if it fixed my problem.
In the meantime, I've turned to the Dark Side and used some triggers to get it working almost exactly the way I want. Triggers are actually a suitable option in this particular case because:
Each player can only build a certain low number of this particular unit throughout the course of the game (I can use an array to keep track of each turret individually without using too much iteration when searching through them)
The unit is stationary (I can use a circular region to simulate its scan range and not ever have to worry about updating its location)
I wish there was a third reason :(
So there's my rationale (I really don't like using triggers for unit abilities)
Anyway, I think I'll pull the turret and triggers out of my map and uploaded it separately so you guys can have a look as see what you think. It's my first time doing something this involved with triggers, so I'm bound to have some room for improvement. I'll upload it later, hopefully tonight.
Funny, I ran into that same problem just yesterday. The reference unit was stationary (a structure) in my case, so I just ended up using a "Unit Enters Region" event instead. I made a record that included a source unit and a circular region around it with the desired radius, so when the event fired I would reference the source unit associated with the triggering region. It might not apply in your case, but just thought I'd mention a possible workaround.
I need to take a break from this before the editor annoys me to the point of never wanting to use it again :(
I'll go ahead and give an update on my progress: the search effect + issue order combo is working great (without FPS drops) with a period of 0.5 and multiple units in the field. Still no idea how it would affect network latency.
However, the problem I'm running into now is that the turrets behave a bit too randomly for my liking when being attacked from multiple angles. As would be expected, the turret spends lots of time spinning around trying to block everything, and sometimes it succeeds in warding everything off. Other times it doesn't (with the exact same setup).
I don't like that degree of randomness, so rather than increasing its turret speed to something un-animatable (which also kinda defeats the purpose of a turret in the first place) I've decided that I want to limit the arc of the search effect to something like 45. This would add a bit of strategy as it would make the turret much less effective at defending against units from widely varying angles (aka. you can flank it).
Normally this would cause the search arc to follow where the unit is facing (and/or attacking). However, I've learned that when it comes to stationary units with turrets, the search effect arc stays attached to the base unit's facing angle instead of the turret's :( I figured it would be hopeless for me to get the effect to reference the turret's facing angle (please correct me if I'm wrong), so I decided it would fairly simple for me to just get rid of the turret and just have the entire unit rotate to face its targets. Just detach the unit's weapon from the turret, give the unit a turning speed, and enable the "turnable" flag, right? WRONG! I guess I'm missing something because I can't seem to get the unit to turn to its target in that case. Any ideas?
See again I am unsure how you got (Any Unit) owner changes
When I use owner changes line it comes out as
(Unit 1 from [unit group]) owner changes
"Any Unit" is a preset that should be available to use for any event as a <unit> parameter. It's actually the default value for the "Unit owner changes" event. The reason you aren't seeing it is probably because you still have that parameter set to the function "Unit from Unit Group".
Just delete that event and make a new one for "Unit owner changes" and you should see it right away.
So later after toying with it I found out you can use the Random Unit from Unit Group and in this line instead of living/dead unit it can be replaced with Any unit from unit group. Thanx for the usher though Khaztr
The word "Any" in your workaround is saying that the random unit can be either living or dead. It sounds to me like that event won't give you the desired results since I think it's going to just choose a single random unit from that unit group and only trigger when that particular unit changes owner. I could be wrong about that, so please let me know if it works.
BTW, if in fact there are only 2 units in that group, and if that fact will never change, then you might as well do what you said above and provide the 2 specific indexes in that group that point to those units. This would be a little better than what I said above since the event won't fire and check conditions every time a different unit changes owner on your map (which I assume can happen since you're trying to be specific with that event in the first place).
I hope that makes sense. Let me know if it doesn't.
0
Just a thought, but I wonder if changing the "Call for Help" radius in the Default SC2 Gameplay Settings would do the trick.
0
@nytemare3701: Go
Doesn't really solve the problem. Having a second weapon won't cause it to change targets once it has acquired one. Unless you know something I don't...
0
Haha, sounds like a pretty ingenious idea to me. If you're having trouble implementing the algorithm in code, I don't see you should shun the idea of using another aspect of the editor to get it done. Unless it's something you're doing very often (aka multiple times a second), I doubt you'll have any performance issues with it. Just do this outside of the players' camera bounds if you're worried about it looking sloppy (or in your words, "newbie") :)
0
@Khaztr: Go
It's me again. I was able to get past the problem with the orphaned regions by adding an extra condition to the "Intercept Missile" trigger to check if the attached unit is still alive. I guess that will have to do.
I also optimized that trigger to be able to handle multiple projectiles at a time by deciding to either push or append the order to attack. A single turret can now destroy both missiles from a single Banshee attack.
The problem I'm having now is that after creating a few units and having them duke it out, the debug window graph will begin to show that events are firing while nothing is really happening. Even though all the view options are set to show all types of events, no events are being shown in the list, yet there are a consistent number of events showing on the graph. This number will grow as I continue to place units and have them fight to the death. It's acting like a memory leak... but why would it show up as events on that graph? Any ideas?
I'm starting to think that there's no way to use "Attach Region to Unit" without having it leak, since there's no way to destroy that region. See? This is why I didn't want to use triggers in the first place -_-
Sorry to keep posting on this thread. I just want to get everything cleaned up and done right before I actually implement this concept in my map, and I know you guys have a lot more experience with this than I do.
0
@Khaztr: Go
Haha, scratch what I said above. Since then I learned about the "Attach Region to Unit" function and Data Tables, which completely negate my stated reason for using triggers in the first place. Oh well, it still works.
However, I am having some trouble with the "Attach Region to Unit" function. Apparently when the unit dies, the region decides to hang round... which is not cool. As far as I can tell, there isn't a way to destroy a region, so I'm resorting to moving the "orphaned" regions off the map once their associated unit dies. However, even with that being done, every now and then I'll get a trigger error from an orphaned region because it hasn't moved in time. Any ideas on how to avoid this from happening?
Anyway, here's the map for you to try out. You'll be able to reproduce the problem if you put a lot of units out at once. Left-click for turets, right-click for enemy Marauders, middle for enemy Banshees. Please let me know if there's anything else I can do to clean up my code or algorithm.
0
Wow, didn't know you could do that. Thanks for pointing that out!
Guess I need to spend some more time looking at native functions. BTW, is there an organized list of them anywhere? For some reason I have trouble finding text in the editor browser window.
0
@Juxtapozition: Go
As you pointed out, there is no galaxy function that will return the reference unit of that event. Why? I think it's simply because Blizzard did not include it.
But I do think there's a way you could logically find the unit you're asking about. Here's how:
There might be some other checks you'll have to make to take into consideration the possibility of the triggering unit being within range R of multiple members of Unit Group G at the same time (if the triggering unit was teleported or walked into range of more than 1 member of Unit Group G at the same time).
0
@Neonsz: Go
You want to make sure X is evenly divisible by 5, right? X mod Y gives the remainder of X / Y, so in this case you want the remainder to be 0. Unless I'm not understanding your question correctly. By "true number" you mean integer, right?
0
@Neonsz: Go
X mod 5 = 0
I'm not sure how MOD comes up in the editor, but I'm sure it's there.
EDIT: "Math - x mod y" according to http://www.sc2mapster.com/wiki/galaxy/triggers/modulo-integer/
0
You can look into dynamically adding events to triggers using the "TriggerAddEvent..." native functions. A good tutorial on the subject can be found here: http://starcraft-2-galaxy-editor-tutorials.thehelper.net/tutorials.php?view=155774 (make sure you check the "Use Reference" box for variable types like unitref, which the author did not do in his example)
This allows you to make and use some pretty useful functions that are not normally available in the GUI. In this case you'll be looking into creating a custom action that will add the "Unit within range of Unit" event to a trigger with specific unit(s) defined at runtime (instead of in the editor). You'd still have to specify a single unit for the second parameter in that event, so you'd have to ditch the idea of using a Unit Group to do it, but at least you could reference the unit some other way (as simple variable or event response) at the time of adding the event.
As a disclaimer, just know that I haven't been able to find very much information about adding events to triggers at runtime. I've been using it is many different ways without any trouble, but I'm sure it has its limits. I'd say give it a shot and see what happens.
0
Wow thanks! You learn something new every day. I'll give it a shot and see if it fixed my problem.
In the meantime, I've turned to the Dark Side and used some triggers to get it working almost exactly the way I want. Triggers are actually a suitable option in this particular case because:
So there's my rationale (I really don't like using triggers for unit abilities)
Anyway, I think I'll pull the turret and triggers out of my map and uploaded it separately so you guys can have a look as see what you think. It's my first time doing something this involved with triggers, so I'm bound to have some room for improvement. I'll upload it later, hopefully tonight.
0
@Juxtapozition: Go
Funny, I ran into that same problem just yesterday. The reference unit was stationary (a structure) in my case, so I just ended up using a "Unit Enters Region" event instead. I made a record that included a source unit and a circular region around it with the desired radius, so when the event fired I would reference the source unit associated with the triggering region. It might not apply in your case, but just thought I'd mention a possible workaround.
0
I need to take a break from this before the editor annoys me to the point of never wanting to use it again :(
I'll go ahead and give an update on my progress: the search effect + issue order combo is working great (without FPS drops) with a period of 0.5 and multiple units in the field. Still no idea how it would affect network latency.
However, the problem I'm running into now is that the turrets behave a bit too randomly for my liking when being attacked from multiple angles. As would be expected, the turret spends lots of time spinning around trying to block everything, and sometimes it succeeds in warding everything off. Other times it doesn't (with the exact same setup).
I don't like that degree of randomness, so rather than increasing its turret speed to something un-animatable (which also kinda defeats the purpose of a turret in the first place) I've decided that I want to limit the arc of the search effect to something like 45. This would add a bit of strategy as it would make the turret much less effective at defending against units from widely varying angles (aka. you can flank it).
Normally this would cause the search arc to follow where the unit is facing (and/or attacking). However, I've learned that when it comes to stationary units with turrets, the search effect arc stays attached to the base unit's facing angle instead of the turret's :( I figured it would be hopeless for me to get the effect to reference the turret's facing angle (please correct me if I'm wrong), so I decided it would fairly simple for me to just get rid of the turret and just have the entire unit rotate to face its targets. Just detach the unit's weapon from the turret, give the unit a turning speed, and enable the "turnable" flag, right? WRONG! I guess I'm missing something because I can't seem to get the unit to turn to its target in that case. Any ideas?
0
"Any Unit" is a preset that should be available to use for any event as a <unit> parameter. It's actually the default value for the "Unit owner changes" event. The reason you aren't seeing it is probably because you still have that parameter set to the function "Unit from Unit Group".
Just delete that event and make a new one for "Unit owner changes" and you should see it right away.
The word "Any" in your workaround is saying that the random unit can be either living or dead. It sounds to me like that event won't give you the desired results since I think it's going to just choose a single random unit from that unit group and only trigger when that particular unit changes owner. I could be wrong about that, so please let me know if it works.
BTW, if in fact there are only 2 units in that group, and if that fact will never change, then you might as well do what you said above and provide the 2 specific indexes in that group that point to those units. This would be a little better than what I said above since the event won't fire and check conditions every time a different unit changes owner on your map (which I assume can happen since you're trying to be specific with that event in the first place).
I hope that makes sense. Let me know if it doesn't.
0
Nope, active includes all comp players in my experience.
I think the difference is that if a player leaves the game, they are no longer considered active.