I'm trying to make an auto-turret that will target both non-missile and missile units, but favors missiles. I have gotten the first part to work (it targets missiles and blows em up) but I'm having a rough time thinking of a way that would cause the unit to attack missiles instead of its current target. I've tried disabling the weapon flags that force the weapon to only fire on the currently targeted unit, but the gun will still stay set on its original target unit it's dead or gone.
From the bit of fooling around I've done, I've learned that once units have acquired a target from scanning (as opposed to an attack order), they won't scan for any other targets unit the original one either becomes untargetable or leaves range. I thought the "Continuous Scan" flag would change that, but it apparently doesn't. Anyone know of a way to circumvent this behavior?
If there is no way to change the way a unit acquires new targets, is there some other way I could go about doing this?
Oh and btw, I'm using a switch effect on the weapon which points to my "interceptor" damage effect if the target is a missile (which instantly kills the target), otherwise it uses the normal damage effect.
EDIT: Of course, now that I post this, I think of another thing I could try. I could have a buff on the unit that gives it a period search effect to look for missiles. If it finds one, use an issue order effect to attack it. I'll try it tomorrow unless someone has a better idea by then (hopefully they do, cuz I'll have to set the period to something really small, which sounds CPU expensive to me)
Yeah, I've been looking there a lot. That's where I got the idea to enable "Continuous Scan". However, as I said above, I do have the missile interception part working. It's just getting the unit to acquire missiles as new targets whenever possible that I can't seem to get working.
BTW, I did get it working using a behavior with a periodic search effect (as explained above). I have to set the period to 0.05 (or less) for it to work consistently :( I don't know if I'm making a big deal out of nothing, but having multiple units in the field searching every 0.05 seconds sounds like it could be hard on the CPU. Does anyone have any input on whether I should be concerned?
@Khaztr: Go Many guys here report that periodic search can cause lag, I use them whenever I need and never had problems. But I think none of my uses is frequent or numerous. I'd you can give it a try and see if you get lag.
Also, I want to know if you will get a good result from it because I want to make a unit attack both missiles and standard units too. I don't know if it will be a standard attack or maybe a separate ability but your result will be useful to me anyway.
BTW, I did get it working using a behavior with a periodic search effect (as explained above). I have to set the period to 0.05 (or less) for it to work consistently :( I don't know if I'm making a big deal out of nothing, but having multiple units in the field searching every 0.05 seconds sounds like it could be hard on the CPU. Does anyone have any input on whether I should be concerned?
I cannot confirm any lag. If no visuals are involved, the data editor can handle a huge amount of periodic effects etc.
However, you could also try to give all your missile units a higher Attack Target Priority than the normal units, this way the turret should switch the target automatically.
@Khaztr: Go
Also, I want to know if you will get a good result from it because I want to make a unit attack both missiles and standard units too. I don't know if it will be a standard attack or maybe a separate ability but your result will be useful to me anyway.
Well, it's working well so far. I've only tested it with 2 autoturrets at a time, and locally, so I'll let you know how it turns out when I try it on Battle.net w/ more than 2.
One problem I've run into with it is trying to get the death animation of the missile to play when it's shot down. It just disappears :( It's annoying because there's no visual or audio feedback to tell the user when it's been shot down (other than noticing the the missile disappeared mid-air). As a workaround, I created a new actor that applies an impact model to the point of the effect, but it still doesn't look that great IMO. I might need to try using a trigger to get this to work properly.
@Khaztr: Go
However, you could also try to give all your missile units a higher Attack Target Priority than the normal units, this way the turret should switch the target automatically.
I've tried fiddling with priority, but the same issue applies: the unit will not change targets until the initial target is dead, out of range, or otherwise untargetable for whatever reason.
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?
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.
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.
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.
Instead of trying to fiddle with the targeting system, why not just give the auto-turret a second weapon that only targets missiles. If you need a reference, the Goliath hero in Special Forces has a dual targeting system.
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...
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I'm trying to make an auto-turret that will target both non-missile and missile units, but favors missiles. I have gotten the first part to work (it targets missiles and blows em up) but I'm having a rough time thinking of a way that would cause the unit to attack missiles instead of its current target. I've tried disabling the weapon flags that force the weapon to only fire on the currently targeted unit, but the gun will still stay set on its original target unit it's dead or gone.
From the bit of fooling around I've done, I've learned that once units have acquired a target from scanning (as opposed to an attack order), they won't scan for any other targets unit the original one either becomes untargetable or leaves range. I thought the "Continuous Scan" flag would change that, but it apparently doesn't. Anyone know of a way to circumvent this behavior?
If there is no way to change the way a unit acquires new targets, is there some other way I could go about doing this?
Oh and btw, I'm using a switch effect on the weapon which points to my "interceptor" damage effect if the target is a missile (which instantly kills the target), otherwise it uses the normal damage effect.
EDIT: Of course, now that I post this, I think of another thing I could try. I could have a buff on the unit that gives it a period search effect to look for missiles. If it finds one, use an issue order effect to attack it. I'll try it tomorrow unless someone has a better idea by then (hopefully they do, cuz I'll have to set the period to something really small, which sounds CPU expensive to me)
Check the Point Defense Drone's Data. mainly the weapon :), i'll do some looking too.
@Doubleclick123: Go
Yeah, I've been looking there a lot. That's where I got the idea to enable "Continuous Scan". However, as I said above, I do have the missile interception part working. It's just getting the unit to acquire missiles as new targets whenever possible that I can't seem to get working.
BTW, I did get it working using a behavior with a periodic search effect (as explained above). I have to set the period to 0.05 (or less) for it to work consistently :( I don't know if I'm making a big deal out of nothing, but having multiple units in the field searching every 0.05 seconds sounds like it could be hard on the CPU. Does anyone have any input on whether I should be concerned?
@Khaztr: Go Many guys here report that periodic search can cause lag, I use them whenever I need and never had problems. But I think none of my uses is frequent or numerous. I'd you can give it a try and see if you get lag.
Also, I want to know if you will get a good result from it because I want to make a unit attack both missiles and standard units too. I don't know if it will be a standard attack or maybe a separate ability but your result will be useful to me anyway.
I cannot confirm any lag. If no visuals are involved, the data editor can handle a huge amount of periodic effects etc.
However, you could also try to give all your missile units a higher Attack Target Priority than the normal units, this way the turret should switch the target automatically.
Well, it's working well so far. I've only tested it with 2 autoturrets at a time, and locally, so I'll let you know how it turns out when I try it on Battle.net w/ more than 2.
One problem I've run into with it is trying to get the death animation of the missile to play when it's shot down. It just disappears :( It's annoying because there's no visual or audio feedback to tell the user when it's been shot down (other than noticing the the missile disappeared mid-air). As a workaround, I created a new actor that applies an impact model to the point of the effect, but it still doesn't look that great IMO. I might need to try using a trigger to get this to work properly.
I've tried fiddling with priority, but the same issue applies: the unit will not change targets until the initial target is dead, out of range, or otherwise untargetable for whatever reason.
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?
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:
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.
@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.
@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.
Instead of trying to fiddle with the targeting system, why not just give the auto-turret a second weapon that only targets missiles. If you need a reference, the Goliath hero in Special Forces has a dual targeting system.
@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...