when option "fire at radar dots" is disabled, attack move shall ignore radar dots also. for me its always a disgrace to see my snipers dont reach their target to shoot when option is disabled and the enemy unit is on radar. can we tweak this or is there already a way to do this?
+0 / -0
|
I'm actually happy to hear that snipers stay at range. Snipers should pretty much never spot their own targets when you're not actively microing them. If you want your snipers to work on their own, I'd suggest you send a Vulture (Scout Plane) alongside them.
+0 / -0
|
quote: If you want your snipers to work on their own, I'd suggest you send a Vulture (Scout Plane) alongside them. |
you see the point. i would have to build a second fac and scouts just because the sniper decides to stop 1 meter before without any sence. and wouldnt be able to control multiple snipers effectively
+0 / -0
|
If you're actively controlling the snipers I suggest you use move command, it's more responsive anyway. Fight command will only make the snipers clump up and kill themselves. Also: Generally I'd recommend you get the Plane factory still. I'd go as far as calling Vulture the most effective unit past the 10 minute mark.
+0 / -0
|
so there is no way to make them not stop 1 meter before they can actually fire and make any sence? my question is about controls not game style
+0 / -0
|
You could write a widget if you really want to do it, but I prefer to have them stop and not suicide charge into the enemy. A reminder to build scouts isn't bad either.
+0 / -0
|
you seem to have misunderstood something quote:
but I prefer to have them stop and not suicide charge into the enemy.
|
i never said i would like them to suicide into enemy lines just want to make it shoot. no other unit just stops a meter before its able to shoot without reason when i send it to attack move somewhere, why not ignore radar dots when its specially manually turned off?
+0 / -0
|
MouthOfMadness
6 years ago
i would prefer a fix then a dodgy widget tho
+0 / -0
|
i mean to move but not attack there already is the move command, to make them stop and not attack on attack command is pointless. so im pretty sure this change would be an increase. bit ot: why is there no participation in this thread? devs seem only pushing their stuff through github...
+0 / -0
|
Github is the place.to go then
+0 / -0
|
My primary goal with the "Ignore radar dots" setting is to make snipers not waste their shots on missing radar dots. It is partially a conditional hold fire because you can set them to fire at will and they will only fire at visible targets. It is also a way to focus fire on a target because you can tell them to attack a target and set them to hold fire. They will only fire on the target if it is visible. So to me the command tells them not to shoot at enemies, not that they should seek out visible enemies. I think that the current default is fine because it is dangerous for snipers to seek out their own targets. They move slowly, have large decloak distance and have a much lower sight range than their vision range. If a target is just out of your global vision range it is likely that the sniper will have to do a lot of walking before it gains vision on the target. In short, if snipers moved forwards by themselves they would put themselves at risk. Unit AI should implement reasonably beneficial behaviours which are also low risk, at least for fragile expensive units. This means that you can look away from your snipers without worrying about them running into the enemy to get vision. Of course, the current unit AI is not fully expressive. Ideally there would be easy ways to configure more behaviours. I agree that in this case it would be nice to have a way to set units to use a decent but risky unit AI. Perhaps the movestates should be replaced by Take Risks/Be Safe/Hold Position. On the ot: I can have a bit of a break for a weekend and github is easier for me to access. The thread is only four days old. Github is also a better place for bug reports and highly specific design decisions such as the one discussed in this thread.
+1 / -0
|
MouthOfMadness
6 years ago
so will this be fixed? i mean a widget from normal behaviour (attack when i say attack) to actual behaviour (stop without any sence) would be easier then a widget from "stop without reason" to normal attack behaviour....
+0 / -0
|
MouthOfMadness
6 years ago
quote:
Github is the place.to go then
|
sorry i have no github, mumble, discord or anything account, so i guess zk forum is the place to go for zk stuff?
+0 / -0
|
|
quote:
Since nobody else appears to actually have a problem with the current behavior, you can either make a good case for the the change that responds to AUrankAdminGoogleFrog's points, or make a pull request.
|
i think i just gave good case... the actual behaviour can also be done with move command already the intendet behaviour is not possible. also i seen this happen to other ppl too, wondering why their units dont attack already, so, what is a pull request and how do i do this? im just requesting a fix with this thread already
+0 / -0
|
Editing Zero-KAbout pull requestsGit use instructions (beyond those in the first link) not included [Spoiler] If you find this too troublesome, there's always toggling the fire at radar option temporarily, or bringing along Gremlins like you should be doing anyway.
PS: When you have at the very least acknowledged the explanation for why the requested behavior is not the default one, we will be closer to devising a solution that does not introduce undesirable unit behaviors, which I consider a prerequisite to others changing this on your behalf.
PS2: Fight-with-radar-dot-chase is not the same as move (if you have trouble seeing this, consider the scenario where some enemies within chase range are in LOS and others are only dots.)
+0 / -0
|
quote:
About pull requests
Git use instructions (beyond those in the first link) not included
|
shouldnt this be a developer thing? quote: or bringing along Gremlins like you should be doing anyway.
|
you should be able to control multiple snipers just like other units. this control bug is a huge nerf for strategies containing multiple snipers.as this requires hard micoring, this limits me to max 2 snipers plus scouts quote:
PS2: Fight-with-radar-dot-chase is not the same as move (if you have trouble seeing this, consider the scenario where some enemies within chase range are in LOS and others are only dots.)
|
but you can use it instead to make the same situation happen... https://imgur.com/a/wW4Ey top sniper move command, down sniper attack move; both radar dots off... both stand and dont shoot. also the fix wouldnt violate the use of gremlin scouts quote:
PS: When you have at the very least acknowledged the explanation for why the requested behavior is not the default one, we will be closer to devising a solution that does not introduce undesirable unit behaviors, which I consider a prerequisite to others changing this on your behalf.
|
what you cant do is: set ignore radar dots, give attack move command, and then attack and ignore radar dots, which is how i would guess its intended
+0 / -0
|
quote: shouldnt this be a developer thing? |
If you really want something and no-one wants to do it, you can dev it yourself. This is one of the benefits of open source. Staring at the screenshot and thinking it over suggests to me that the current behavior is indeed the lesser of two evils. [Spoiler]
-
The behavior requested in this thread is in a way directly opposed to the fix requested in the Slasher thread.
-
This thread: Units on attack move should chase an enemy out of their current effective range, in order to bring it into effective range, regardless of potential hazards in the target's area.
-
Other thread: Units on attack move should not chase an enemy out of their current effective range, in order to bring it into effective range, regardless of potential hazards in the target's area.
-
I'd say the current Fencer misbehavior and the proposed change to radar dot targeting stem from the same defect: breaking the fundamental assumption that a unit on Attack Move will kill all enemies presently in range before attempting to advance.
-
Arguably it's worse for snipers, since they'll get afflicted even if the selected target has not yet left their range.
-
"You can get the other behavior with move" applies to both the current and proposed behaviors, within the pictured case: manually move so that the sniper can see its target, manually move (stop, rather) so the sniper doesn't go chasing its target.
-
In principle, the latter is preferable, since the former requires active micromanagement to keep the sniper from going not far enough / too far, and to react to new threats. However, I submit that letting a 750 metal, 560 health unit get within 400 elmos of the enemy without user attention is a contraindicated action, and thus the attack-move-chase sniper would require most of that micro anyway.
Is there a compromise? [Spoiler]
-
GoogleFrog's idea is the obvious one: tie it to movestate.
-
Hold pos: don't close
-
Maneuver: close if already within <500 range or such (we're already near, might as well inch forward a bit)
-
Roam: always close (assume this is the "I go wherever I want" state)
-
Tactical AI logic: If don't fire at radar gadget tells us we can't shoot yet, and movestate permits, move slightly towards target repeatedly, until we can shoot.
This is not, on the face of it, exceptionally complicated to implement – but it is still nontrivial. Given that the current behavior is considered entirely adequate by all but one of the people who have bothered to comment, it's going to be low priority to say the least (@Sprung might be interested, you can try asking him).
+2 / -0
|
Considering that units on hold position will not kite at all without an offensive fight order, I would be rather disappointed to have them rush forward at limited move. I generally use limited move if I want units to defend an area. Fight/patrol command is not an option as this will cause units to chase enemy units into defenses. Thus the only remaining movestate would be free roam, for which I'd agree with offensive movement although it might still be unexpected.
+0 / -0
|
|