View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
---|---|---|---|---|---|---|---|---|---|
0003963 | Spring engine | General | public | 2013-08-25 22:05 | 2013-10-14 22:49 | ||||
Reporter | abma | ||||||||
Assigned To | abma | ||||||||
Priority | normal | Severity | major | Reproducibility | always | ||||
Status | resolved | Resolution | fixed | ||||||
Product Version | 94.1.1+git | ||||||||
Target Version | 95.0 | Fixed in Version | |||||||
Summary | 0003963: lasers don't "switch off" when differnt target is slected | ||||||||
Description | looks like units have a laser targeting system. | ||||||||
Steps To Reproduce | current ba stable: attack ground, while units shoots, select new attack destination. the laser still shoots while unit is retargeting / rotating. | ||||||||
Tags | No tags attached. | ||||||||
Checked infolog.txt for Errors | |||||||||
Attached Files |
|
Notes | |
Kloot (developer) 2013-08-25 22:09 |
that is called "working sweepfire" |
abma (administrator) 2013-08-25 22:22 |
ooops, sorry! |
abma (administrator) 2013-08-25 22:24 |
i've set this major because units damage each other now, not sure if thats (also) by intention. |
Kloot (developer) 2013-08-26 01:02 |
Some important notes to make about this after testing a bit: 1) BA's armcom has a secondary "underwater-only" laser that is normally blocked from firing by its script above water but will still spawn sweep beams (because sweepfire code does not interact with the script in any way except to call QueryWeapon), which is probably unwanted 2) sweepfire in general requires that the aiming script causes the weapon piece to line up with the direction it would point in if the sweep were executed manually, but this is not exactly the case for either of armcom's lasers (contrast XTA's arm_penetrator) so sweepfire should probably be disabled on them (or their types changed to regular lasers) 3) unfortunately the AimWeapon script callin usually checks angular constraints (by blocking fire until wait-for-turn completes), so if the engine were to call it sweepfire would not work at all |
Kloot (developer) 2013-08-26 01:05 |
also, wrt. "units damage each other now": for this to happen the weapon must already have collideFriendly = true (which is the default) |
abma (administrator) 2013-08-26 01:19 Last edited: 2013-10-08 05:56 |
is changing the default for sweepFire from false to true in the WeaponDef.cpp by reason? imo it breaks a bit of stuff. https://github.com/spring/spring/commit/45fb80754913a74caec63926ead5bcbb5a594326#diff-2e65dce0c9f95710b824fc340ad2a2dcR64 |
Kloot (developer) 2013-08-26 20:49 |
Reason is I set sweepfire to true locally while testing and accidentally commited that change with the rest, then later realized but thought it might be useful to discover issues quickly and let gamedevs think about whether they want this feature. With weapondefs_post it's simple enough to disable. |
FLOZi (reporter) 2013-08-26 23:04 |
Having sweepfire default to true for testing releases is fine, sensible even, but please do not change the default for the actual release of 95.0, especially as it was not originally intended |
abma (administrator) 2013-10-14 22:49 |
@kloot: i hope its ok to set default to false again, didn't see any bug report related to it for a while... |
Issue History | |||
Date Modified | Username | Field | Change |
---|---|---|---|
2013-08-25 22:05 | abma | New Issue | |
2013-08-25 22:09 | Kloot | Note Added: 0011400 | |
2013-08-25 22:09 | Kloot | Status | new => closed |
2013-08-25 22:09 | Kloot | Assigned To | => Kloot |
2013-08-25 22:09 | Kloot | Resolution | open => no change required |
2013-08-25 22:22 | abma | Note Added: 0011401 | |
2013-08-25 22:24 | abma | Note Added: 0011402 | |
2013-08-26 01:02 | Kloot | Note Added: 0011403 | |
2013-08-26 01:02 | Kloot | Status | closed => feedback |
2013-08-26 01:02 | Kloot | Resolution | no change required => reopened |
2013-08-26 01:02 | Kloot | Status | feedback => closed |
2013-08-26 01:02 | Kloot | Resolution | reopened => no change required |
2013-08-26 01:05 | Kloot | Note Added: 0011404 | |
2013-08-26 01:05 | Kloot | Status | closed => feedback |
2013-08-26 01:05 | Kloot | Resolution | no change required => reopened |
2013-08-26 01:05 | Kloot | Status | feedback => closed |
2013-08-26 01:05 | Kloot | Resolution | reopened => no change required |
2013-08-26 01:19 | abma | Note Added: 0011406 | |
2013-08-26 01:55 | abma | Status | closed => feedback |
2013-08-26 01:55 | abma | Resolution | no change required => open |
2013-08-26 20:49 | Kloot | Note Added: 0011424 | |
2013-08-26 20:49 | Kloot | Status | feedback => closed |
2013-08-26 20:49 | Kloot | Resolution | open => no change required |
2013-08-26 23:02 | abma | Assigned To | Kloot => |
2013-08-26 23:02 | abma | Status | closed => new |
2013-08-26 23:04 | FLOZi | Note Added: 0011429 | |
2013-10-08 05:56 | abma | Note Edited: 0011406 | View Revisions |
2013-10-14 22:48 | abma | Changeset attached | => spring develop fba7471e |
2013-10-14 22:48 | abma | Assigned To | => abma |
2013-10-14 22:48 | abma | Status | new => resolved |
2013-10-14 22:48 | abma | Resolution | no change required => fixed |
2013-10-14 22:49 | abma | Note Added: 0011769 |