2019-08-21 07:29 CEST

View Issue Details Jump to Notes ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0004780Spring engineGeneralpublic2015-06-16 20:19
ReporterGoogle_Frog 
Assigned Tohokomoko 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusresolvedResolutionno change required 
Product Version98.0.1+git 
Target VersionFixed in Version 
Summary0004780: Feature: Old antinuke behaviour (no flyover target)
DescriptionThis request is a tag for interceptors which makes them only fire at targets which are going to impact inside their interception range. This makes the antinuke coverage behaviour predictable for players.
TagsNo tags attached.
Checked infolog.txt for lua Errors
Attached Files

-Relationships
+Relationships

-Notes

~0014469

silentwings (reporter)

Last edited: 2015-05-17 09:26

View 3 revisions

I would like this also. Afaics the current behaviour is basically a bug, even if it was coded intentionally, and players also interpret it as a bug.

~0014588

abma (administrator)

just in case:

https://springrts.com/phpbb/viewtopic.php?f=12&t=33575&p=570437

(tag vs callin)

~0014589

hokomoko (developer)

Change != Bug
You can use Spring.GetProjectileTarget to only intercept projectiles of your choice and get the old behaviour.

~0014590

silentwings (reporter)

Last edited: 2015-06-15 18:40

View 2 revisions

I can? How?

Afaics I can't use GetProjectileTarget until the interceptor projectile has fired, at which point if I decide that I don't want to incept the target, one anti-something missile (which probably cost resources, and might be the last of a stockpile that takes time to replenish) was just wasted.

~0014591

hokomoko (developer)

GetProjectileTarget of the nuke

~0014592

Google_Frog (reporter)

hokomoko where are you suggesting to use Spring.GetProjectileTarget? In Script.BlockShot? Wouldn't that make no antinukes intercept the target?

Provide a more complete lua solution to regain the old behaviour because I am not convinced.

~0014593

silentwings (reporter)

Last edited: 2015-06-15 18:55

View 3 revisions

> GetProjectileTarget of the nuke

That would require a tangle of lua to handle cases where multiple missiles are shot towards multiple interceptors, and to handle issues of reload timings + "can this interceptor reach a missile of this type from here to some guess at where the missile might fly too in this time".

I don't rate that as a solution, it pointless hard work and there is low chance of exactly replicating the old behaviour in anything but the simplest case of "interceptor travels so fast that it can reach the missile whatever".

~0014594

hokomoko (developer)

Last edited: 2015-06-15 18:55

View 2 revisions

Not if you use AllowWeaponInterceptTarget callin.
It's a simple check of target distance from owner.

~0014595

silentwings (reporter)

Ok, didn't know that callin existed, thanks.

~0014600

Google_Frog (reporter)

AllowWeaponInterceptTarget seems to do what it needs to do. This can be closed.
+Notes

+Related Changesets

-Issue History
Date Modified Username Field Change
2015-05-14 15:10 Google_Frog New Issue
2015-05-17 09:23 silentwings Note Added: 0014469
2015-05-17 09:25 silentwings Note Edited: 0014469 View Revisions
2015-05-17 09:26 silentwings Note Edited: 0014469 View Revisions
2015-06-15 12:54 abma Note Added: 0014588
2015-06-15 18:20 hokomoko Note Added: 0014589
2015-06-15 18:40 silentwings Note Added: 0014590
2015-06-15 18:40 silentwings Note Edited: 0014590 View Revisions
2015-06-15 18:42 hokomoko Note Added: 0014591
2015-06-15 18:51 Google_Frog Note Added: 0014592
2015-06-15 18:53 silentwings Note Added: 0014593
2015-06-15 18:54 silentwings Note Edited: 0014593 View Revisions
2015-06-15 18:55 silentwings Note Edited: 0014593 View Revisions
2015-06-15 18:55 hokomoko Note Added: 0014594
2015-06-15 18:55 hokomoko Note Edited: 0014594 View Revisions
2015-06-15 19:05 silentwings Note Added: 0014595
2015-06-15 20:28 jK Changeset attached => spring develop 3dfcc893
2015-06-16 20:02 Google_Frog Note Added: 0014600
2015-06-16 20:19 hokomoko Status new => resolved
2015-06-16 20:19 hokomoko Resolution open => no change required
2015-06-16 20:19 hokomoko Assigned To => hokomoko
+Issue History