View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0021139 | AI War 2 | Graphical Bug | Apr 25, 2019 10:05 am | Jul 31, 2019 3:41 pm | |
| Reporter | Apthorpe | Assigned To | BadgerBadger | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | BETA 0.853 An Officer And A Bunch Of Fleets | ||||
| Fixed in Version | 0.877 The Strikecraft Goldilocks Zone | ||||
| Summary | 0021139: Rapidly flashing diagonal blasts | ||||
| Description | I've often had a graphical bug occurring where rapidly flashing blasts will appear during battles which don't correspond to the actual combat. They always appear diagonally, oriented from the top-right corner to the bottom-left. They don't happen every battle, but when they do happen it's impossible to miss. They're usually yellow but the coloration can vary. They are extremely irritating on the eyes. I've attached a screenshot as well as save game featuring one instance of their appearance (at the Anabas system). | ||||
| Tags | No tags attached. | ||||
| related to | 0021124 | resolved | BadgerBadger | Shots firing in random directions |
| related to | 0020748 | resolved | BadgerBadger | Shots going to bottom left corner |
| related to | 0021428 | resolved | Shot Visualization error |
|
|
|
|
|
I believe those are shots being fired at invalid targets. I would bet this problem corresponds to specific unit types in combat; is there a pattern to when the problem shows up. |
|
|
Here's another save game that shows this problem (from hearthunter) |
|
|
Is this still a thing that happens in the latest versions? A savegame in the new post-fleets stuff would be welcome if anyone runs across one. Thanks! (that savegame is large enough I'm pretty sure it's pre-format-conversion). |
|
|
I've seen it in the current patch. My guess is dead ships with sequential firing at dead targets. |
|
|
That makes sense for ships that are firing sequentially even if they don't have salvos. A lot of ships that are single-ship firing have a time delay before their shots appear. So those shots come into existence not knowing where they are coming from or where they are going, potentially. They presumably should just remove themselves, I guess. It's a part of a second delay that is important for the ship offsets to look right in terms of how they draw. |
|
|
The immediatey cause is actually slightly different. When a Shot object is created it is set in ShotDisplayStyle.HiddenWhileWaitingForDataToDoLerp mode; this says "We don't have information from the Sim to display this shot yet, so retry next Visual Step to see if we have a valid target". The valid target is found in the TryWiringUpShotToTarget() function. If enough time passes then we give up on finding a valid target and use the ShotDisplayStyle TrueLocationByTimeout, which has the comment /// <summary> /// Typically we were waiting for some data that is typically asynchronously updated (a visualship entry for the target may not yet exist, etc), /// and since that data was not forthcoming after a certain point, we're just going with the true location. /// </summary> Unfortunately, hitting this case basically means the shot uses its default location (The bottom left of the screen) and just flies there quickly. You can observe this by going to the DoShotMovement() function and in the switch on this.ShotDisplay, set all the cases to this.ShouldRenderThisFrame = false except for TrueLocationByTimeout. The most obvious fix is to make the TrueLocationByTimeout case say this.ShouldRenderThisFrame = false, which indeed makes the problem go away. However, it's worth noting that in large battles a lot of shots seem to wind up unable to find targets in time, so they never get displayed, which isn't great (it makes battles much less interesting to look at if half the shots never appear). Of course, if the shot's target winds up being dead before it even can appear, that would account for how the target never is found (and thus we get the timeout) |
|
|
Fixed |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Apr 25, 2019 10:05 am | Apthorpe | New Issue | |
| Apr 25, 2019 10:05 am | Apthorpe | File Added: flashing.jpg | |
| Apr 25, 2019 10:05 am | Apthorpe | File Added: flashing.save | |
| Apr 25, 2019 10:05 am | Apthorpe | File Added: flashing.savemet | |
| Apr 25, 2019 11:47 am | BadgerBadger | Note Added: 0051401 | |
| Apr 25, 2019 1:18 pm | BadgerBadger | Relationship added | related to 0021124 |
| Apr 27, 2019 7:51 pm | BadgerBadger | File Added: perfomance.save | |
| Apr 27, 2019 7:51 pm | BadgerBadger | Note Added: 0051435 | |
| Jul 8, 2019 10:58 am | Chris_McElligottPark | Relationship added | related to 0020748 |
| Jul 8, 2019 10:59 am | Chris_McElligottPark | Note Added: 0052081 | |
| Jul 8, 2019 2:51 pm | ptarth | Note Added: 0052101 | |
| Jul 8, 2019 2:53 pm | Chris_McElligottPark | Note Added: 0052102 | |
| Jul 22, 2019 1:56 pm | BadgerBadger | Note Added: 0052294 | |
| Jul 22, 2019 2:18 pm | BadgerBadger | Note Edited: 0052294 | |
| Jul 22, 2019 2:28 pm | BadgerBadger | Note Edited: 0052294 | |
| Jul 22, 2019 2:28 pm | BadgerBadger | Assigned To | => BadgerBadger |
| Jul 22, 2019 2:28 pm | BadgerBadger | Status | new => resolved |
| Jul 22, 2019 2:28 pm | BadgerBadger | Resolution | open => fixed |
| Jul 22, 2019 2:28 pm | BadgerBadger | Fixed in Version | => 0.877 The Strikecraft Goldilocks Zone |
| Jul 22, 2019 2:28 pm | BadgerBadger | Note Added: 0052295 | |
| Jul 31, 2019 3:41 pm | Chris_McElligottPark | Relationship added | related to 0021428 |
