wulf 21

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?

One of the planes got stuck and I finally figured out how it happened. It requires some precise timing and hopefully can be reproduced with my savefiles: load the dropship_launched.json it contains a dropship en route to the crashsight and an interceptor on way back to base fast forward time (speed 2 or 3) If it happens you will see the dropship reaching the crashsight slightly before the interceptor reaches his home-base. Then the dropship bounces back-and-fouth around the crashsight a bit. While this is happening, the interceptor symbol disappears from screen (like it landed). Then the ground mission starts to load. Finish the ground mission (Just abort it for testing) After return to geoscape and confirmation of mission result, the plane will be stuck The plane is than on the same location as its base but it will not move. It is unclickable (nothing happens if plane, not base is clicked). On Plane Tab it will display the stats from before ground mission loaded (fuel is not empty). So it looks like there actually happen some frames while Geoscape data is prepared for loading it back after ground mission. If one during these frames contains a transition from airborne to landed state, plane will be stuck in some in-between state. It will only happen on the fast forward speeds 2 or 3 - it did not happen if I tried maximum speed. Since it may actually be nearly frame-perfect, I checked with fraps that the Geoscape was running with around 99 fps while it happened. While it is stuck, it was trunning at 150 fps (so it was calculating faster, probably no calculations for the stuck plane done). Furthermore here are my specs should they be needed for this: CPU: Intel Core 2Quad Q9400 @2.66 GHz, GC: NVidia GeForce GTX 570, 6 GB RAM - Game installed on a HDD, but windows on an SSD (so the Xenonauts savefiles are there). Savefile after that: plane_stuck.json Screenshot with the stuck plane (the squadron 2 on the North America Base):

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

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:

Had this happen in V2.0 today. However it happened after getting shot by alien for me instead of a self-kill, so it looks like it will appear randomly on Xenonaut death. Might actaully be the same glitch as dead alien standing upright after death - So I additionally did send an F11-report that was asked for in these threads. Edit: the character to the right the alien is looking at with the blood is the one that is actually dead.

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

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:

Thanks for the update. I Like the new Music. Nice seeing some things that were suggested already being put into the game

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

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:

Still happens in V2.0

Well, @Chris is regularly checking these forums. I think you will get an answer to your question on monday during US work hours.

Well the kickstarter was advertised in the Xenonauts 1 game launcher - appearantly this was enough advertisement as they actually met most of their stretch goals. I guess early access release date can't be nailed, yet, because they can't know how many bugs we will still find once all the major features are put in the Closed Beta.

After having in mind that saving and loading might play a role as I speculated in other thread, I found a pretty solid way to reproduce. It is not even necessary to produce any laser rifles I just found it odd that I never encountered it on my complete playthrough of 7-day period with multiple safes/loads etc - probably the precise sequence of events plays a role. Minimal Case: start game from desktop start new game place initial base fast forward time until dummy research is complete go to research and start laser weaponry research go to Geoscape and fast forward time until reasearch complete When offered to go to engineering cancel dialogue press F5 - quick_save.json attached press F9 Result: In armory, there can be seen the issue. Laser battery does not have a infinity sign right from the start, even before dragging one out, which is different than Chris describes - Screenshot 1 while dragging it out, the whole laser battery button disappears (intead of disappearing infinity symbol) - Screenshot 2 after dragging it out, the button stays disappeared and the gap where it was is closed - Screenshot 3 The issue persists in savefile - you should see it if you load it. Additinally, if you start producing laser rifles after loading the broken save, they will not be automatically equipped with a laser battery. The one dragged out really is the only one in existence for the rest of the game after it happened. Screenshot 1: Screenshot 2: Screenshot 3:

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:

I managed to break the "end turn" button just by repeatedly clicking it, directly at start of ground combat mission. At first few clicks, aliens were just coming and killed by reaction fire, but then"end turn" button just stopped doing anything.

related: It is possible to demolish living quarters in Atlas base, even if the living capacity is lower than required after that.

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.

After second ground engagement with Laser Rifles equipped, I noticed on selling the alien stuff that there were suddenly displayed 4 laser rifles in my supplies. despite having produced only 2. After going into armory, I noticed that these 4 actually were additional to the 2 I already had equipped. So I had a total of 6. To make sure it's not just a display bug, I unequipped all the rifles, then equipped 6 team members with them. So, yes, I really had 6 laser rifles. Looks like each time you carry laser rifles into ground combat and complete the mission successfully, it will additionally add the laser rifles to the inventory (treated same as picked up alien equipment).

Minor usability issue: Unlike with frag grenades it is currently not possible to know wether it is save to blow up C4 without hurting Xenonauts. The obvious place to display the radius would be when you mouse over the remote detonator like I have done in the screenshot. (GOG galaxy somehow takes screenshots without mouse pointer but it can be seen that the background of the detonator is slightly brighter). Another place where it would be possible is while planting it, but there it is not displayed either.

Found 2 more not climbable ladders. As was already noted in one response in the release announcements I found after creating this thread, ironically climbing works only if placement of ladder looks totally wrong: Not climbable: Place where climbing a building is possible (ladder can just be seen clipping through roof): Same building from the inside:

Found yet another UFO-Terrain combination can crash the game: UFO: Scout Terrain: Village (located in a desert region) Load the attached savefile and forward time - it will crash the game about 50% of times. quick_save.json output.log 2018-12-16 12:33:35,362 [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.Systems.Objectives.DefeatTeamGCObjective.<GetTargets>m__0 (Artitas.Entity t) [0x00001] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Screens\GroundCombat\Systems\Objectives\KillTeamGCObjective.cs:74 at System.Linq.Enumerable+<CreateSelectManyIterator>c__Iterator12`2[Artitas.Entity,Artitas.Entity].MoveNext () [0x00000] in <filename unknown>:0 at System.Collections.Generic.List`1[Artitas.Entity].AddEnumerable (IEnumerable`1 enumerable) [0x0001a] in /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Collections.Generic/List.cs:128 at System.Collections.Generic.List`1[Artitas.Entity]..ctor (IEnumerable`1 collection) [0x00025] in /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Collections.Generic/List.cs:65 at System.Linq.Enumerable.ToList[Entity] (IEnumerable`1 source) [0x00000] in <filename unknown>:0