Loading...
  OR  Zero-K Name:    Password:   

ignore radar dots bugged does not ignore radar dots

20 posts, 1139 views
Post comment
Filter:    Player:  
sort
MouthOfMadness
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

6 years ago
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
MouthOfMadness
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
MouthOfMadness
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

6 years ago
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
MouthOfMadness
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
MouthOfMadness
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

6 years ago
Github is the place.to go then
+0 / -0


6 years ago
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


6 years ago
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.
+0 / -0
MouthOfMadness
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-K

About pull requests

Git use instructions (beyond those in the first link) not included

[Spoiler]
+0 / -0
MouthOfMadness
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]

Is there a compromise?
[Spoiler]

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

6 years ago
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
MYrankAdminHistidine has said it all. The current default is better than the proposed behaviour for the reasons stated. What you want is non-default behaviour which is not yet implemented. You are adding weight to the task "rewrite movestate" but that task is large and the benefits are small relative to other things I could be doing.
+2 / -0