antinuke flyover

[Google_Frog]

Split from viewtopic.php?f=12&t=33587. (Silentwings)

I consider antinuke flyover blocking (although my solution may be to reimplement it in lua).

[hokomoko]

I consider antinuke flyover blocking (although my solution may be to reimplement it in lua).

A weapon ignoring targets that are in its range is the anomaly. Since as you said this can be implemented as a gadget using GetProjectileTarget, this is in no way blocking and imo shouldn't be implemented in the engine.

[Silentwings]

I don't think reimplementing interceptors in lua is a good way to 'solve' that issue. Fixing it only needs a tiny improvement to the engine. But its not a recent regression so I do agree its not blocking.

edit: Ok, didn't know AllowWeaponInterceptTarget existed, so controlling interceptor targets via lua is not so bad.

A weapon ignoring targets that are in its range is the anomaly.

The targets, in https://springrts.com/mantis/view.php?id=4780, are not in the anti-whatevers range, they are behind and outside of its range. Or rather, they were, before the engine regressed and decided its range was now a infinitely tall cylinder instead of a patch of ground.

[Google_Frog]

I consider antinuke flyover blocking (although my solution may be to reimplement it in lua).

A weapon ignoring targets that are in its range is the anomaly. Since as you said this can be implemented as a gadget using GetProjectileTarget, this is in no way blocking and imo shouldn't be implemented in the engine.

My solution would be to completely ignore the engine interceptor code and build my own from scratch. It is not a good solution. I am not going to do this soon because I hope a better solution can be added to the engine.

Non-instant hit interceptors are always going to have to ignore projectiles which are inside their range because if they shoot at something on the edge of their range they are not going to hit it before the projectile impacts. I mainly want nukes to only be intercepted if they are in antinuke range because then it is clear to players how the interceptors interact. There is also the fact that I have heard nobody ask for this change and the two main games with playerbases seem to want a way to configure things to act with the old behaviour.

There also seems to be a bug in the current behaviour. If a nuke is launched outside the interception range of the antinuke then the antinuke will not fire until the nuke enters the interception range (in 2D? 3D? Hard to tell). This leads to stupid behaviour where the nuke is within interception range for a few seconds before impacting. If the antinuke is going to intercept a projectile which eventually enters range then at least make it intercept the projectile properly.

[hokomoko]

You should differ between weapon range and anti protection range

1) Use AllowWeaponInterceptTarget to decide what range is covered by the anti.
2) Set the anti's range to cover whatever range makes sense to allow interception in time.

[Silentwings]

(2) results in the wrong range circle being displayed to the player & the wrong range exposed to lua.

[hokomoko]

weapon range != protection range.
these are not the same.

You want a weapon to target something further, give it a larger range.
As the protection limit will be implemented in lua, use customparams to store the protection range.

I can't remember at the moment if there's an option to disable range circle from being drawn, if not, there should be.

[Silentwings]

weapon range != protection range

Only because of a regression.

if there's an option to disable range circle from being drawn

There is hacking away at cmdcolors, which would hide it for all games unless you saved/restored cmdcolors, which is frankly getting mad as a fix for a regression. And even then you'd have to redraw with gl.DrawGroundCicrcle and it would be in slightly the wrong place because that isn't ballistic, which matters for the typical use case of nukes.

So I still don't buy this, it looks like hacks to cover up bugs to me.

[hokomoko]

Hmm, it seems it has always been this case because of the "coverage' tag which I entirely ignored.

I'll make some tests and get back to you.

[Silentwings]

Oh, I didn't realize you meant coverage for protection range. They are potentially not equal because e.g. missiles can run out of flying time, or there might be water/hills in the way of the flight path, etc. Let me know if you want me to test anything.

[hokomoko]

I had to test on BA because ZK's gadget handler didn't contain this callin.

Silentwings, this worked with BA:
http://paste.springfiles.com/view/55656a96
You may want to edit it, to prevent multiple missiles from being fired on the same nuke.

[Silentwings]

Ok, gadget works & jK points out that since AllowWeaponInterceptTarget screens targets before targeting takes place, there are no special cases for lua to worry about.

Google_Frog, in case you missed #sy, your second issue with inceptors not firing quickly enough is:
<hokomoko> they have 4500 as interceptor range and 2500 as coverage range
So there is no need for hiding range circles, coverage and weaponrange are already different.

[Google_Frog]

That was not my bug then. The bug is that an interceptor only fires when the projectile enters interception range unless the projectile is going to hit within interception range.

[hokomoko]

I can't reproduce this.
Can you post a replay?

[Google_Frog]

Second nuke of this replay demonstrates the bug. I don't mind though because I have implemented the behaviour I want with AllowWeaponInterceptTarget (which I did not know existed).