[V1.3, V2.0, V2.1, V3.0, V3.1, V4 - Ground Combat] CTD after (burst) firing alien rifle or machine gun (or actually any weapon can cause it)

[wulf 21]

Another Game Crash while firing, probably again hard to reproduce

1. During a mission I did pick up an alien rifle
2. While storming the UFO I made sure I had enough TU left for burst fire after running into the room with aliens
3. Shot the bigger one with burst fire
4. Game Crashed right before impact of first projectile, probably when the second projectile should be fired

Logfile shows that it is a completely different part of in code where it crashed than the first crash while firing I reported (and that was fixed):

2018-12-15 10:18:56,448 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:594) 
Queued global::Xenonauts.GroundCombat.Events.ProjectileShotEvent: Projectile Event (ProjectileShotEvent - Projectile TrajectoryHit (rolled 22% (<= is success) against 16.1%) on 4993 from (32.9, 0.8, 11.8) to (60.0, 0.0, 37.2) ([F:0, I:120, J:74] / [X:60, Y:0, Z:37], ID:9962 Type:Corner), impacted at: [F:0, I:76, J:34] / [X:38, Y:0, Z:17], ID:4598 Type:Corner)

2018-12-15 10:18:56,451 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:594) 
Queued global::Xenonauts.GroundCombat.Events.ProjectileShotEvent: Projectile Event (ProjectileShotEvent - Projectile TrajectoryHit (rolled 80% (<= is success) against 16.1%) on 4993 from (32.9, 0.8, 11.8) to (66.5, 3.7, 43.6) ([F:1, I:132, J:87] / [X:66, Y:1, Z:43], ID:26732 Type:Edge), impacted at: [F:0, I:76, J:34] / [X:38, Y:0, Z:17], ID:4598 Type:Corner)

2018-12-15 10:18:56,550 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:594) 
Queued global::Xenonauts.GroundCombat.Events.ShakeCameraCommand: Camera: GlobalEntity 1188

2018-12-15 10:18:56,556 [FATAL] (D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Screens\XenonautsMain.cs:441) 
A fatal error occurred during Update() - 
System.NullReferenceException: Object reference not set to an instance of an object
  at Xenonauts.GroundCombat.Abilities.FirearmAbility.FireProjectile (Common.RPG.AbilityState state) [0x00055] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Screens\GroundCombat\Factories\Abilities\FirearmAbility.cs:712 
  at Xenonauts.GroundCombat.Abilities.FirearmAbility+<AnimateShotsTimeline>c__Iterator0.<>m__1 (Common.RPG.AbilityState state, IEventEffect`1 effect, Artitas.Events.DeltaTimeEvent arg3) [0x00001] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Screens\GroundCombat\Factories\Abilities\FirearmAbility.cs:659 
  at Common.RPG.DelegateSingleEventEffect`2[Common.RPG.AbilityState,Artitas.Events.DeltaTimeEvent].Apply (Common.RPG.AbilityState state, IEvent event) [0x0000f] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Common\Code\RPG\Ability\Effects\EventEffects.cs:119 
  at Common.RPG.SequenceEffect`1[Common.RPG.AbilityState].Apply (Common.RPG.AbilityState state, IEvent event) [0x0004e] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Common\Code\RPG\Ability\Effects\CompositeEffect.cs:154 
  at Common.RPG.LoopEffect`1[Common.RPG.AbilityState].Apply (Common.RPG.AbilityState state, IEvent event) [0x00004] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Common\Code\RPG\Ability\Effects\CompositeEffect.cs:191 
  at Common.RPG.SequenceEffect`1[Common.RPG.AbilityState].Apply (Common.RPG.AbilityState state, IEvent event) [0x0004e] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Common\Code\RPG\Ability\Effects\CompositeEffect.cs:154 
  at Common.RPG.SequenceEffect`1[Common.RPG.AbilityState].Apply (Common.RPG.AbilityState state, IEvent event) [0x0004e] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Common\Code\RPG\Ability\Effects\CompositeEffect.cs:154 

Attached output.log - it looks liek there was somehow written no .rec file. The last one was from 7.12., so maybe this was changed in 1.3?

Edited April 17, 2019 by wulf 21
changed title to account for new version/not necessarily burst fire

[wulf 21]

Seems this specific crash was not fixed, yet in Build V2.0. It happened to me a second again, this time I was firing with machine gun.

Crash did happen right before impact of first projectile again, 3 Projectiles were already in the air, so maybe it happened when the fourth projectlie should be fired. It is the same part of the code where it happened again:

2019-02-03 12:05:16,529 [INFO] (D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:631) 
Handled AnimatorStateEvent<global::Xenonauts.GroundCombat.Animations.CombatantStateTransitionListener.Tags>: AnimatorStateEvent<CombatantStateTransitionListener.Tags> ( Trigger: OnEnter, Payload: Idle, Actor: (Clone) (Xenonauts.GroundCombat.Animations.CombatantStateTransitionListener), StateName: StandingIdle, Payload: Idle, Behaviour: 6100 ), Info: 1305036771

2019-02-03 12:05:16,561 [WARN] (D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Screens\GroundCombat\Factories\Abilities\Shoot\Projectile.cs:372) 
Ignoring because target impact entity was destroyed.

2019-02-03 12:05:16,562 [INFO] (D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:616) 
Queued global::Xenonauts.GroundCombat.Events.ProjectileMissEvent: Projectile Event (ProjectileMissEvent - Projectile TrajectoryMissOffBoard (rolled 89% (<= is success) against 14.84%) on -1 from (19.3, 0.8, 33.0) to (16.4, 0.0, 25.7) ([F:0, I:33, J:51] / [X:16, Y:0, Z:25], ID:6612 Type:Centre), impacted at: [F:0, I:33, J:51] / [X:16, Y:0, Z:25], ID:6612 Type:Centre)

2019-02-03 12:05:16,596 [INFO] (D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:616) 
Queued global::Xenonauts.GroundCombat.Events.ShakeCameraCommand: Camera: GlobalEntity 881

2019-02-03 12:05:16,603 [FATAL] (D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Screens\XenonautsMain.cs:441) 
A fatal error occurred during Update() - 
System.NullReferenceException: Object reference not set to an instance of an object
  at Xenonauts.GroundCombat.Abilities.FirearmAbility.FireProjectile (Common.RPG.AbilityState state) [0x00055] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Screens\GroundCombat\Factories\Abilities\FirearmAbility.cs:721 
  at Xenonauts.GroundCombat.Abilities.FirearmAbility+<AnimateShotsTimeline>c__Iterator0.<>m__1 (Common.RPG.AbilityState state, IEventEffect`1 effect, Artitas.Events.DeltaTimeEvent arg3) [0x00001] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Screens\GroundCombat\Factories\Abilities\FirearmAbility.cs:668 
  at Common.RPG.DelegateSingleEventEffect`2[Common.RPG.AbilityState,Artitas.Events.DeltaTimeEvent].Apply (Common.RPG.AbilityState state, IEvent event) [0x0000f] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Common\Code\Gameplay\RPG\Ability\Effects\EventEffects.cs:119 
  at Common.RPG.SequenceEffect`1[Common.RPG.AbilityState].Apply (Common.RPG.AbilityState state, IEvent event) [0x0004e] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Common\Code\Gameplay\RPG\Ability\Effects\CompositeEffect.cs:154 

Attached output.zip

[Chris]

Thanks. We'll have a look at that and see if we can fix it up, I think the logs will be helpful.

[Chris]

So we can't reproduce this, and don't have enough information to track it down in the code from the existing crash data we get. The next update will have additional information in the logs that should help us track it, so if it happens again please do report it again.

[wulf 21]

The crash did happen again in V2.1. I can see that it is the same code line where it crashed again.

This time I was firing a rifle and it was just single fire actually (selected aimed shot). The crash happened right after the animation of aiming the rifle was finished, probably right when the shot should be fired.

2019-02-26 20:32:16,029 [FATAL] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\XenonautsMain.cs:448) 
A fatal error occurred during Update() - 
System.NullReferenceException: Object reference not set to an instance of an object
  at Xenonauts.GroundCombat.Abilities.FirearmAbility.FireProjectile (Common.RPG.AbilityState state) [0x00055] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\GroundCombat\Factories\Abilities\FirearmAbility.cs:721 
  at Xenonauts.GroundCombat.Abilities.FirearmAbility+<AnimateShotsTimeline>c__Iterator0.<>m__1 (Common.RPG.AbilityState state, IEventEffect`1 effect, Artitas.Events.DeltaTimeEvent arg3) [0x00001] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\GroundCombat\Factories\Abilities\FirearmAbility.cs:668 
  at Common.RPG.DelegateSingleEventEffect`2[Common.RPG.AbilityState,Artitas.Events.DeltaTimeEvent].Apply (Common.RPG.AbilityState state, IEvent event) [0x0000f] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Common\Code\Gameplay\RPG\Ability\Effects\EventEffects.cs:119 
  at Common.RPG.SequenceEffect`1[Common.RPG.AbilityState].Apply (Common.RPG.AbilityState state, IEvent event) [0x0004e] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Common\Code\Gameplay\RPG\Ability\Effects\CompositeEffect.cs:154 
  at Common.RPG.LoopEffect`1[Common.RPG.AbilityState].Apply (Common.RPG.AbilityState state, IEvent event) [0x00004] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Common\Code\Gameplay\RPG\Ability\Effects\CompositeEffect.cs:191 

I hope the logfile does this time contain the info you need: output.log

Edited February 26, 2019 by wulf 21

[wulf 21]

the crash happened yet again, here is another one of these output files: output.zip

Edit: nearly forgot to mention - place time when it crashed was exactly as last time when trying to fire a single shot with rifle, right after aiming animation was finished.

Edited February 28, 2019 by wulf 21
Situation added

[wulf 21]

Encountered it yet again in V2.1. This time it was again with the machine gun. 3 Shots were already in the air, crash did happen, when the fourth should be fired.

attached: output.zip

[Chris]

@wulf 21 So for this specific bug it would be great if you could report it again if you encounter it in V3. Based on the information you've managed to collect for us in this thread we now know where the error is (it's caused by shots being queued and then failing to resolve correctly), but our coders can't see any reason as to how the game got into that state in the first place based on the info in those logs.

We've once again added more information to the logs, so hopefully in V3 if this happens again we'll be able to figure out how the game is getting into this state. That should allow us to both fix the bug and prevent other similar issues occuring again in the future.

[wulf 21]

Hi,

it happened again already in Build V3. This time it was a normal grenade launcher shot queued.

output.zip

[Gijs-Jan]

You seem to have a knack for finding this specific bug somehow, as it's not popping up from anyone else.
And to top it all off, I need to add in specific logging because the crash itself doesn't make much sense!

Having said all that, keep the Q/A coming, and thanks for all your hard work!

[wulf 21]

6 hours ago, Gijs-Jan said:

You seem to have a knack for finding this specific bug somehow, as it's not popping up from anyone else.
And to top it all off, I need to add in specific logging because the crash itself doesn't make much sense!

Having said all that, keep the Q/A coming, and thanks for all your hard work!

Thx. Indeed strange if I only I seem to get it, but, the nature of this crash is that it seems totally unpredictable and random. I can play through several ground combats without getting it and then I would suddenly get it again. And I do not remember doing anything special when it happens, just regular shooting aimed on aliens (and it turned out that it is totally independent from fire mode and weapon.) Maybe others who get it just don't deem it worth reporting because it is so random and rare or don't realize they just got the same crash... Or maybe there actually is something special about my computer (is it possible to determine from the automatic crash reports if they all were from the same computer?). Random unpredictable things usually happen with multithreading - maybe my computer for some reason sometimes executes some code in different order than it usually happens. As I already mentioned somewhere my CPU is Intel Core Quad Q9400 with 4 real cores (hyperthreading was not invented back then) and as the game uses 50% total CPU time even in background it must be using at least 2 of them in parallel.

[Gijs-Jan]

The error is popping up in the interaction between logic and animation - a pretty notorious (in it's instability) section of Unity's API. 
That specific code is not multi-threaded (90% of our core logic is single-threaded, only the FOW calculations run off-thread and they are isolated).
We have been able to replicate the issue once or twice (in the past two years) on build, every time adding new logging and getting a new piece of the puzzle.

If there is anything unique about your setup I suspect it might be in how you issue orders.

[wulf 21]

It happened in V3.1 again. I can see that the output logfile really contains a lot more information, so here it is: output.zip

It happened again during a machine gun burst, right after the second shot was fired (so probably it tried to fire the third).

I know you said it is not multithreaded, but these duplicate log entries before the crash just look like 2 threads trying to do the same thing at the same time so maybe if this API calls back game logic code, it somehow can do this in a multithreaded way that you were completely unaware of?

On 3/18/2019 at 9:26 AM, Gijs-Jan said:

If there is anything unique about your setup I suspect it might be in how you issue orders.

No idea if this is reproducible (probably not, does not always happen when I do that), but keeping this sentence in mind, this is as exactly as I remember what I have done before the crash:

• there was an obstacle in the way to the alien, so I prepared a movement command a little to the side
• checked that I had enough TU + free firing line by holding shift + pointing on the alien (not force-fire mode)
• shift+clicked alien - soldier did the move and was facing 45 degrees away from the alien at the end
• clicked the alien --> 2 shots fired, then crash

[wulf 21]

Yet another "Data Point": output.zip

Crash happened after aimed (not scoped) firing of sniper rifle. Steps done were basically same as above ie first moved around an obstacle with shift+click then clicked the alien again.

[Chris]

We'll have a look at this tomorrow; I strongly suspect the cause of the issue is related to the Shift + Click. It's not a well known feature which would explain why you're apparently the only person experiencing the crashes, and it's not really a feature we use internally when doing dev cheat testing either.

[Chris]

On 3/19/2019 at 7:38 PM, wulf 21 said:

It happened in V3.1 again. I can see that the output logfile really contains a lot more information, so here it is: output.zip

It happened again during a machine gun burst, right after the second shot was fired (so probably it tried to fire the third).

I know you said it is not multithreaded, but these duplicate log entries before the crash just look like 2 threads trying to do the same thing at the same time so maybe if this API calls back game logic code, it somehow can do this in a multithreaded way that you were completely unaware of?

No idea if this is reproducible (probably not, does not always happen when I do that), but keeping this sentence in mind, this is as exactly as I remember what I have done before the crash:

• there was an obstacle in the way to the alien, so I prepared a movement command a little to the side
• checked that I had enough TU + free firing line by holding shift + pointing on the alien (not force-fire mode)
• shift+clicked alien - soldier did the move and was facing 45 degrees away from the alien at the end
• clicked the alien --> 2 shots fired, then crash

EDIT - ignore my previous comment. So I've tried to reproduce this but still can't find any issue. The logs imply that your soldier has had their shot cancelled for some reason after a rotate has occurred. This leaves the shot queued, so when you try to fire a second shot it will try to resolve both at the same time and crash the game.

We still can't figure out how this could occur, though - do you have any idea? Our first guess was that the actions were being cancelled as a result of spotting an alien, but that's not necessarily the case and perhaps you might have some idea yourself now you know an interrupt is the issue?

[wulf 21]

56 minutes ago, Chris said:

EDIT - ignore my previous comment. So I've tried to reproduce this but still can't find any issue. The logs imply that your soldier has had their shot cancelled for some reason after a rotate has occurred. This leaves the shot queued, so when you try to fire a second shot it will try to resolve both at the same time and crash the game.

We still can't figure out how this could occur, though - do you have any idea? Our first guess was that the actions were being cancelled as a result of spotting an alien, but that's not necessarily the case and perhaps you might have some idea yourself now you know an interrupt is the issue?

I think it shouldn't interrupt the action because of spotting the alien in these cases, because I could see the alien during the same turn already (at least that how I think this should work - movements interrupted only if a soldier spots an alien that was not seen in same round at all until that). And I did not spot a new alien because of the rotation.

And actually I do not remember having clicked a third time after the first fire attempt was interrupted (will pay more attention though if it happens again.) If there were 2 shots queued, maybe it would actually queue the first one after the shift+click movement already and cancel it when I let go off the Shift button? Intuitively it would make sense for the soldier to first move and fire on shift+click because it shows the summed up TU cost for both actions before the click. But that is just speculation at that point because I don't know if I Shift+Clicked everytime it happened. However, it is not unlikely that the soldier was always facing in another direction when it happened (so it needed to rotate+shoot always).

[Chris]

Yeah, that's what was confusing me as well. The alien only interrupts the movement / actions the first time, and in my testing it seems impossible to engineer a situation where you're shooting at target you haven't already revealed.

Ah well, I'm sure we'll figure this out eventually!

[wulf 21]

Well, I have 2 more times where it happened here. At one time I almost thought I found out how to reproduce it, but no, I don't seem to be able to do it willingly, it just happens.

But what I can definitely say is that it was NOT like click alien to shoot --> some interrupt --> click again, but rather just Shift+Click to issue the movement command, then click again after movement was finished.

Interestingly, the second time happened on throwing a stun grenade and the Exception which crashes is something else (ArgumentOutOfRangeException instead of NullPointer), however I can see that it basically is the same in log - ie. the throwing action of the same stun grenade was queued 2 times. I can only assume that there is some specific way to do the Shift+Click input (order at which buttons are pressed and released for example) that will somehow queue up a shot already but it just should issue the movement command. Then probably it is the movement itself that interrupts the shot (I can see in log that there was first queued the first shot and then the Interrupt is logged just milliseconds before first MakeStepSound)

First one: output.zip

The one with grenade: output_stun_grenade.zip

Edited March 21, 2019 by wulf 21

[wulf 21]

It happened yet again with normal rifle shot. Took another look in the log and what I can see there is that there is MoveToEvent and AbilityEvent for the shot just 30 ms apart. Since I don't do 30 inputs per second it appears to me that it basically must be the same input that triggers both events (like the shift+click).

 

2019-03-21 21:47:11,798 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.40.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:651) 
Queued global::Xenonauts.GroundCombat.Events.CommandLifecycleReport: Status: Started, Command: MoveToEvent([F:0, I:97, J:49] / [X:48, Y:0, Z:24], ID:6418 Type:Centre), Details: , Comment: 

2019-03-21 21:47:11,800 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.40.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:651) 
Queued global::Xenonauts.GroundCombat.Events.MovementStartedReport: MovementStartedEvent: [F:0, I:91, J:59] / [X:45, Y:0, Z:29], ID:7702 Type:Centre, 6064

2019-03-21 21:47:11,801 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.40.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:651) 
Queued global::Xenonauts.GroundCombat.Events.CommandLifecycleReport: Status: Activated, Command: MoveToEvent([F:0, I:97, J:49] / [X:48, Y:0, Z:24], ID:6418 Type:Centre), Details: , Comment: 

2019-03-21 21:47:11,836 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.40.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:651) 
Queued global::Common.RPG.AbilityEvent: AbilityID: normal, Source: GlobalEntity 6080 Item - Name:Ballistic Rifle, Target: GlobalEntity 6216 - Combatant - Species:psyon, RoleGroup:default, Ethnicity:default, Gender:default :: LifeStatus:Conscious

Attached: output.zip

[Alienkiller]

I and the others don´t have that problem.

Seems only yours. Check for Virus, newest drivers, upgraded Windows etc. If there is no Virus / Hack you can go to the next step.

After that try a repair from Steam. If it finds nothing (wrong or missing file normaly) make a normal or new game. Sometimes your saves are damaged.

If that won´t work (and Step 1 finds nothing too) then you have to delete the Game completley [and all saves etc.] that there is nothing and I mean absolutely nothing is left.

Then make a completely clean and fresh install. That´s all what you can do.

 

 

Edited March 22, 2019 by Alienkiller

[Gijs-Jan]

1 hour ago, Alienkiller said:

I and the others don´t have that problem.

Seems only yours. Check for Virus, newest drivers, upgraded Windows etc. If there is no Virus / Hack you can go to the next step.

After that try a repair from Steam. If it finds nothing (wrong or missing file normaly) make a normal or new game. Sometimes your saves are damaged.

If that won´t work (and Step 1 finds nothing too) then you have to delete the Game completley [and all saves etc.] that there is nothing and I mean absolutely nothing is left.

Then make a completely clean and fresh install. That´s all what you can do.

 

 

While I appreciate trying to help in the issue, the problem is most definitely in the code and is an issue we should fix.
To be clear, doing the above will not fix the issue and I do not recommend it for this issue. :-)

[Chris]

17 hours ago, wulf 21 said:

Well, I have 2 more times where it happened here. At one time I almost thought I found out how to reproduce it, but no, I don't seem to be able to do it willingly, it just happens.

So I've reproduced this at my end once, but I can't do it again despite trying for a good 10-15 minutes. I'm pretty sure the crux of the issue is how many times you're clicking your mouse, because it turns out you can queue up multiple actions just by clicking too many times - e.g. you can doubleclick on an alien and your soldier will fire his weapon twice if you have enough time units. I didn't know that because I always use high-cost fire modes when playing the game so my soldiers never have enough TU to perform two actions, but you're not supposed to be able to do that.

This is probably a problem for you more than anyone else because you're using Shift + Click, and it turns out that doubleclicking on an alien with a fire path up and Shift+Click held down will order your soldier to move to that location and then shoot without any further interaction from the player. Presumably something is interrupting the move and leaving the shot queued, and a second shot will crash the game. I think in my case the interrupt came from spotting a new alien; maybe you're using the TU reserve system or something?

As I said, I'm not able to reproduce the crash I got earlier but I had clicked two or three times whilst using / having just used Shift + Click and for some unknown reason my soldier then stopped moving, obviously with a shot still queued up.

I strongly suspect that just ensuring the player cannot queue up actions will prevent this bug from occurring any more. You can test this by seeing if the bug occurs in future playthroughs by ensuring you just single click when you have your cursor over an alien?

[wulf 21]

18 hours ago, Chris said:

I strongly suspect that just ensuring the player cannot queue up actions will prevent this bug from occurring any more. You can test this by seeing if the bug occurs in future playthroughs by ensuring you just single click when you have your cursor over an alien?

Will try, but I am pretty sure I am just single clicking. One thing I noticed however when I do the click really slow is it that it is enough for the soldier to start moving with the Shift down + left mouse button down, and that I hear an in-game click sound later on left mouse button up - hence my assumption that the game can somehow generate 2 input events depending on the precise timing of mouse down, mouse up, shift down, shift up and where the cursor is currently pointed on all of these.

[wulf 21]

Have a new occurence here, this time normal shot with shotgun. Made sure I really just single clicked and that I pressed shift before clicking and let go the Shift button after clicking, while the soldier was moving already. The click itself was completely on the alien and fast (mouse up before the soldier started moving).

This time, no turning away or towards the target was involved at all, just straight movement one tile forward to be able to shoot over a desk and then straight ahead shooting. And no TU reserve was activated. So we can pretty much exclude the possibiities that the movement gets interrupted by spotting another alien or the TU reserve.

I should also note that when it happens, I see no visual interruption of the actions of the soldier at all. The Shift+click will issue the movement order that the soldier does finish without interruption and then the click on the alien starts the aiming anomation then crash on firing. One thing I noticed however is that when crash is about to happen the camera centers on the soldier right at the start of the movement, which normally does not happen. I think that the camera center on soldier normally happens on interrupt. Therefore I think what happens is that I can somehow issue the movement and shoot command at the same time (maybe even on the same frame), then both try to play back at the same time and the movement would then interrupt the shooting, so only the movement gets really done.

Attached: output.zip

Edit: well actually the center of camera on Xenonaut does not always happen, I think it only happens if the game determines the Xenonaut is not in view (It does go to xenonaut and track the shot if its far away). So rather the queued-up shot at the start of the movment seems to be the cause of the camera centering, and not the interrupt.

In this occurence again, no visual interruption of the soldiers actions. He just moved to the end of the path on shift + Click. What is interesting here is that this time I manually needed to turn towards the alien with right-click before the soldier could shoot (was facing away at the end of the movement) - seems the queued-up shot does "survive" even that.

I left fraps running in background this time, just to check the framerate and I had drops to 20 fps. So maybe low framerate somehow increases the probability of it happening (will try to play on lower resolution to test that). Maybe what is actually happening in my case is that I finish the complete mouse click (button down and up) before the soldier does even start the movement animation, which leaves room to interprete the click a second time as firing command.

Another remark: Seems the for the crash to happen, the soldier must have a "firing solution" to the alien already at the start of the movement (hit probability any value > 0%) or it wont queue up the shot.

Attached: output_2.zip

Edit2: No, actually, FPS seems not to be related to it. Just tried it with lower resolution + fastest graphics settings. Game was smoother (no drop below 30 fps) but crash did still happen (this time machine gun again). But even in this case: Just one click during the shift+click.

output_3.zip

Edited March 23, 2019 by wulf 21