Leaderboard

Another Game Crash while firing, probably again hard to reproduce During a mission I did pick up an alien rifle While storming the UFO I made sure I had enough TU left for burst fire after running into the room with aliens Shot the bigger one with burst fire 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?

Reproducable with following save-file (after researching comba armor): combat_armor_researched.json go to engineering screen add one combat armor to queue. Result: 160$ left. Quantity-up-button not greyed out and quantity-down-button greyed out - OK (Screenshot 1) click quantity-up 1 time. Result: Quantity is 2. Only 60$ left. Quantity-down button not greyed out but quantity up-button not greyed out either - NOK, expected: quantity up should be greyed out because not enough money (Screenshot 2) click quantity-up again. Result: nothing happens - OK click quantity-down. Result: Quantity is 1. Again 160$ left. Quantity-down and up are both greyed out - NOK, expected: quantity-up should not be greyed out because there is enough money to increase it (Screenshot 3) click quantity-up - Result: nothing happens - NOK, expected: it should be possible to increase quantity as we have the met prerequisites So it looks like the piece of code that determines if we met the prerequisites to increase quantity (and greys out the button if not) actually uses the prerequisite state from before the quantity change, not the state after. As a workaround, it is possible to remove the item completely from queue and add it again, then quantity can be changed up again. Another note: If the add combat armor is clicked 2 times with queue empty, it would add 2 lines: 1xcombat armor, 1x combat armor instead of 2x combat armor. I suppose this is not a bug since the player could have the intention to produce for example item A, item B, item A instead of 2x item A, item B. However it would make kind of sense if the add project button would increase quantity instead if it is the same project that is already at the end of the list. Screenshot 1: Screenshot 2: Screenshot 3:

I started a new game (V2.0) and saved it. After quitting the game and coming back later, I’ve tried to load this save file just in the main menu, but when the load screen reaches 99% (once 100% after I tried to load from a ingame ground battle), nothing happens and the game get stocks The music still is planning and I can move my mouse, but that’s it.

This thing I metioned in other threads when I was playing around with savefiles nearly drove me mad for some time . Because I kept being reset to earlier game states while testing and wondered if I really did press that F5 button or forgot it? But now I did do it in a way that makes it clear for me this is actually happening and made a screenshot each step. And I intentionally did not use the quicksave for it, so I wouldn't have to ask myself what I really pressed after that. made sure I had no preexisting savefile named test (deleted them) started the game from desktop, started a new game and placed my base in Latin Americe (Screenshot 1) saved the new game as "test" (Screenshot 2) quit to desktop started game from desktop again, started a new game and placed my base in Asia Pacific (Screenshot 3) saved the game as "test" again and confirmed the question if it should overwrite the savefile (Screenshot 4) loaded the "test" I did just create (Screenshot 5) ... aaaand magic! the base was suddenly back in Latin America (Screenshot 6) quit to main menu, then loaded the savefile again (Screenshot 7) ... and the base STILL is in Latin Americe (Screenshot 8) - so if you stop here you could think that game failed to actually save, but it gets better quit to desktop load "test" again and here comes the real magic: The base is suddenly in Asia Pacific, right where it was before saving the test a second time! (Screenshot 9) So I think what really happens here is that for loading savefiles there was used some part of code that is intended for files that stay unchanged during the whole runtime of the game (like sprites, sounds, models). So upon accessing the save directories on game start, the engine just thinks "let's load these small files into cache right now, might save time if I need them later". And upon loading the file it would then just load what was already in RAM and never access the file system again to load the actual file, so it appears like the savefile was not saved again until quitting the game to desktop again. Screenshot 1: Screenshot 2: Screenshot 3: Screenshot 4: Screenshot 5: Screenshot 6: Screenshot 7: Screenshot 8: Screenshot 9:

Could it be that this and the other thread actually have a common root cause? Because, 1 time after exchanging interceptor equipment on the aircraft screen and then shooting down a UFO, I got both bugs: I first saved while the drophip was on the way to crash site then after completing the ground mission, game crashed when I tried to load the save, I found it was broken At this time I thought of it an coincidence and did not report it again (and no longer have the savefile). But after trying around a bit, it seems that going to the aircraft screen and back seems to be a reliable way to cause not-loadable savefiles. Here are 2 of them test.json does load perfectly well. test2.json will be stuck on loading. The only action between saving those files was going to the aircraft equipment and back. Interestingly the second file is much smaller despite that. This got me interested and I took a look at the actual content of the savefiles and saw that it misses the whole "ComponentMatrix" part. So maybe the same part of wrong data that makes the game crash on loading back from ground combat actually makes creation of this part of the savefile impossible?

To rule out that there is any interference with previous savefiles here, I actually renamed my safe folder before. So we starte emty. What I did: Start game without having a Save-folder Start new game Accept initial report dummy place initial base Press F5 - quick_save.json (was only save in saves dir after whole process) Quit the game to Desktop Start the game again Click "Continue" Go to Armory Result: there are no items in Armory except the ones you are carrying - all the infinite items are gone away the loadout selection is broken Edit: if you go on a ground combart mission with the already equipped items and finish it, armory goes back to normal when loading to geoscape, so maybe that's why it was unnoticed... Edit2: happens with normal savefiles, too. dragging one of the items to the right does not let them appear again. They are then lost, until next ground mission. This essentially means that every time I continue a saved game from before, I will be stuck with current squad equpment until after next ground mission after ground combat, actually only the infinite items are back - loadout selection will stay broken

I finally found a way to reliably reproduce the issue the existence of which I hinted in: start the game from desktop start new game place initial base go to "Main Base" tab hire 2 scientists - this results in having 16/16 personnel capacity add the 2 scientists to laboratory by left clicking it (Total of 5 in there now - 5 slots from left used) press F5 go to "Soldiers" tab fire 1 soldier go to "Main Base" tab - the personnel capacity is now 15/16 hire 1 engineer - the personnel capacity is now 16/16 add the engineer to the workshop by left-clicking it (Total of 4 in there now - 4 slots from the left used) press F5 - resulting save attached: quick_save.json press F9 Result: The personnel slot button marked in screenshot is broken it is no longer possible to remove the engineer by right clicking the slot button but the 3 buttons left of it are still working right clicking workshop immediately brings up the window that asks if you want to demolish the workshop (which normally only happens after removing the last person in it) it is still possible to add more engineers to the workshop with left click and remove them with right click - the demolition question always appears if right click should remove the engineer off the broken slot the personnel capacity is now incorrectly 15/16 - it is possible to hire one more person the result is permanent in the safe file (you should see it in quick_save) and future save files Notes: I had this symptom before in my savegames but without firing soldiers, so death during ground combat can have same effect If the game is started from desktop, I was not able to reproduce it without step 7. But after trying a lot of stuff and always using "quit to main menu", this was possible At one point in my many tries, the game somehow returned back to a quicksave state I already had overwritten - even if directly loading the quick_save from load menu, only after going to desktop and starting the game again, it was possible to load the correct quicksave - there really seems to be some incorrect RAM caching of savefiles so it would not load from file system. So I would see something I described in Might be cause of some "just happened somehow but can't reproduce" issues if there was saving/loading while it happened originally but not while trying to reproduce them lik Screenshot:

Hi, found this small visual bug. I think it did not appear before because we did not have the MIMIC UFOs before: It will appear if you win an air combat on Geoscape (not autoresolve), and then directly go into next air combat without ground missions etc in between. Then there will be displayed a ghost fighter at the position where you ended the air combat before:

Found yet another way to crash the game: launch an interceptor click the base it was launched from click the hangar of the interceptor click disband click yes Looks lie some part of the code then destroys the entity while another part that does the flying still tries to update it. 2019-02-03 22:12:46,137 [INFO] (D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Screens\Strategy\Systems\Geoscape\WaypointSystem.cs:31) Delete Waypoint 277:Waypoint 2019-02-03 22:12:46,146 [FATAL] (D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Screens\XenonautsMain.cs:441) A fatal error occurred during Update() - System.Exception: Entity 261 was deleted and cannot be modified after destruction. Please use IsAlive() when modifying. Mutation: null into Common.RPG.RangeModifierStorageComponent at Artitas.World.MutateComponentOnEntity (Int32 entityID, Int32 componentID, IComponent previousC, IComponent nextC, Boolean added) [0x0003d] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:297 at Artitas.Entity.Add (IComponent newComponent, Int32 componentId) [0x00017] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\Entity.cs:57 at Common.RPG.ModifierSystem.HandleRangeModifier (Artitas.Entity target, Common.RPG.Modifier`1 modifier, Boolean added, Int32 storageComponentIdx, System.Collections.Generic.Dictionary`2 modificationStrategies, Common.RPG.ModificationStrategy`1 defaultModificationStrategy, Common.RPG.ApplicationStrategy`1 applicationStrategy) [0x00020] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Common\Code\Gameplay\RPG\ModifierSystem.cs:209 at Common.RPG.ModifierSystem.Handle (Common.RPG.ModifierEvent event) [0x0005c] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Common\Code\Gameplay\RPG\ModifierSystem.cs:105 at (wrapper delegate-invoke) System.Action`2<Common.RPG.ModifierSystem, Common.RPG.ModifierEvent>:invoke_void__this___ModifierSystem_ModifierEvent (Common.RPG.ModifierSystem,Common.RPG.ModifierEvent) at Artitas.Core.Utils.ExpressionUtil+<ActionFromMethodInfoFactory>c__AnonStorey1`4[Artitas.Systems.EventSystem,Common.RPG.ModifierEvent,Common.RPG.ModifierSystem,Artitas.IEvent].<>m__0 (Artitas.Systems.EventSystem target, IEvent param) [0x0001c] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\Utils\ExpressionUtil.cs:151 at Artitas.Systems.EventSystem.HandleSubscribers (IEvent event) [0x00050] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\Systems\EventSystem.cs:49 at Artitas.Systems.EventSystem.Handle (IEvent event) [0x00003] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\Systems\EventSystem.cs:26 at Artitas.DefaultProcessStrategy.Process (IEvent event) [0x001c6] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:830 at Artitas.DefaultProcessStrategy.Process () [0x00024] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:773 at Artitas.World.Process () [0x00007] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:643 at Common.Screens.DataStructures.WorldManagedScreen`2[Xenonauts.GameScreens,Common.Screens.DataStructures.IScreenParameters].Update (Single deltaTime) [0x00032] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Common\Code\Lifecycles\ScreenLifecycle\DataStructures\WorldManagedScreen.cs:49 at Common.Screens.ScreenManager`1[Xenonauts.GameScreens].Update (Single deltaTime) [0x000f3] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Common\Code\Lifecycles\ScreenLifecycle\ScreenManager.cs:149 at Xenonauts.XenonautsMain.Update () [0x00066] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Screens\XenonautsMain.cs:438 Attached: output.zip

It is still in V2.0. And it affects civilians as well as aliens. I don't know if I just did not notice that earlier or something was changed in this version but: As soon as the civilian did move out of line-of-sight, the game actually fast-forwarded (like it does for all the hidden movement). So it looked like the civilian was teleported to its final position. For better understanding, I marked the movement path on screenshot. The green path was about the way the civilian moved inside my line-of-sight. The red path was the way he was "teleported" - which is wrong, because I should have no way to know where he is without looking there. (Small OT: Game Design wise it would make kind of sense to leave a transparant ghost to mark a position where NPCs was last seen - but giving the player an information he should not have is clearly a bug). Reported that instance of the bug with F11 aditionally. (Maybe there is some useful information in that auto-collected data)

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

I am also experiencing this - load screen progress bar stops at 99%. I have tried 4 times with the same result (though once it stopped at 98%). Game should be loading into the Geoscape. There is a mission on its way to a crash site when I made the save. When the progress bar reaches 99% the loading music cuts out and another track starts, I think this is the Geoscape soundtrack. I have left it in this state for 10 minutes with no change. Update: I managed to repeat the error. Started a new game, did one mission, saved and tried to reload. Similar result, but stopped at 90% this time.

Had this, too. Not sure how to reproce. Here is the broken save file: quick_save_broken.json (I did rename the quick save after realizing it was broken) Screenshot where game is stuck:

Still happens in V2.0. Turns out you don't even need an empty hangar to trigger this, just: start new game place initial base click the base click the squadron click "relocate" - it will offer you only the 1 hangar in existence click authorize relocation Screenshot of broken interface (note how the base is completely missing in the radar circle):

I can still reproduce this in V2.0 The only modification to reproduction steps is in Step 12, it is now "Total of 3 in there now - 3 slots from the left used" - because 1 engineer now starts in radar. The slot that gets broken is now the 3rd from the left because of that. Another quick note: On first try after starting up V2.0 without having any V2.0 saves created before, only old saves, the game did not load the new quicksave with F9 in step 14. Looking into the ESC-menu, the Qicksave was was displayed as Version "0.0.0" despite being new. I had to use the save menu and save a test.sav, after loading it the issue was in the test.sav. Strangely enough, after loading the test.sav the quicksave now was displayed as Version "0.37.0" and it was possible to load it. It seems there is some strage thing that lets the game mix up partial information from saves that were loaded into RAM before saving again with information from the actual save files... Quicksave from V2.0 with broken slot inside: quick_save.json Screenshot with broken slot marked as it looks in V2.0. Living capacity still 15/16 despite having 16 personell before saving in step 13:

I already posted that in another thread - it is unfortunately not abvious to find that it was already reported because the other thread title only describes the symptom, not what causes it. I found that it is possible to avoid these symptoms by making sure that really the empty slot is selected (click the empty slot twice, so it gets yellow and and the other slot white) - however even then the relocate would not work properly and the aircraft stay in airborne state forever.