wulf 21

There is something weird happening with pathfinding at longitude at roughly the eastern spots of Japan/New Zealand. I tried to get the exact coordinates, however this turned out to be impossible, because the numbers at the bottom on Geoscape refer to screen pixels and not world coordinates (So you move the coordinate-system over the world if you move the view. Got 2 cases where it can be reproduced: Case 1: UFO Interception load the GeoBug.json click the UFO-12 launch the interceptor from the base in Australasia I called "Phillipinos" select the second-slowest setting for time fast-forward After start it nearly looks good, however you will see the interceptor flying to a spot east instead of west of the UFO to try and catch it (screenshot 1). Passing some specific longitude the target point will start to deviate from the location of the UFO (target moving to the east while UFO continues to the west). (screenshots 2,3). Interceptor continues until it is out of fuel, then returns to base correctly. Case 2: Skyranger pathfinding I randomly had a crashsite at just the right spot near the eastern end of New Zealand . The skyranger however did not start the ground mission when reaching the location, instead it continued to fly on to the west forever (screenshots 4,5). I do no longer have the savefile with the crashsite in it, however I found it is possible to simulate it by setting a waypoint for the skyranger instead. load the geobug 2.json it contains the skyranger on way to waypoint (obtained by first launching a mission to the Raid location, then using "Select new Target" (Screenshot 6) select the second-slowest setting for time fast-forward You will then see the skyranger bouncing off the waypoint when reaching it and continuing to the west forever until it disappears from screen, however ther sometimes still moves the path over the screen. (screenshots 7,8,9) Screenshot 1: Screenshot 2: Screenshot 3: Screenshot 4: Screenshot 5: Screenshot 6: Screenshot 7: Screenshot 8: Screenshot 9:

While trying if I could get the game to crash with reloading (which I didn't get), I noticed another bug. If you drag ammo onto the Gun in soldier inventory view instead of using the quick slot at the bottom, reloading of the gun comes for free or low TUs. if the magazine slot next to the weapon is empty, if is for free If it is not empty, it has just the TU cost of moving the magazine from one belt slot to another one instead of the TU cost for reloading the gun Additionally, this leads to another bug where the magazine is somehow still logically attached to the gun despite being displayed on belt. Moving it from one belt slot to another then actually unloads the gun (same as moving from gun to belt should do). Edit: This allows to reload the Scatter laser, too, which oherwise displays that it is a weapon that can't be reloaded.

Just this, too. I assume that by "tried to use", you mean that the game crashed after clicking the medic bag (not the target you wanted to heal). Because that is where it crashed for me. Here is my outout log: output.zip To reproduce: left click the medkit in the bottom bar right click somewhere on the map left click the medkit in the bottom bar again Oddly enough I completed a complete playthrough of V2.1 without ever getting this crash. Had to intentionally play around with medkit before getting it. (So it seems I never tried to right click out of the medkit use before because I know this is intended to change fire mode). 2019-03-03 09:33:06,851 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:649) Queued global::Xenonauts.GroundCombat.Events.SwitchItemCommand: SwitchItemCommand [actor: GlobalEntity 6527 - Soldier [Name:Scott Knight - Rank:private] LifeStatus:Conscious, item: GlobalEntity 6545 Item - Name:Medikit] 2019-03-03 09:33:06,853 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:649) Queued global::Xenonauts.GroundCombat.Events.CommandLifecycleReport: Status: Queued, Command: SwitchItemCommand [actor: GlobalEntity 6527 - Soldier [Name:Scott Knight - Rank:private] LifeStatus:Conscious, item: GlobalEntity 6545 Item - Name:Medikit], Details: , Comment: 2019-03-03 09:33:06,858 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:649) Queued global::Xenonauts.GroundCombat.Events.CommandLifecycleReport: Status: Dequeued, Command: SwitchItemCommand [actor: GlobalEntity 6527 - Soldier [Name:Scott Knight - Rank:private] LifeStatus:Conscious, item: GlobalEntity 6545 Item - Name:Medikit], Details: , Comment: 2019-03-03 09:33:06,891 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:649) Queued global::Xenonauts.GroundCombat.Events.CommandLifecycleReport: Status: Started, Command: SwitchItemCommand [actor: GlobalEntity 6527 - Soldier [Name:Scott Knight - Rank:private] LifeStatus:Conscious, item: GlobalEntity 6545 Item - Name:Medikit], Details: , Comment: 2019-03-03 09:33:06,893 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:649) Queued global::Xenonauts.GroundCombat.Events.CommandLifecycleReport: Status: Activated, Command: SwitchItemCommand [actor: GlobalEntity 6527 - Soldier [Name:Scott Knight - Rank:private] LifeStatus:Conscious, item: GlobalEntity 6545 Item - Name:Medikit], Details: , Comment: 2019-03-03 09:33:07,522 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:664) Handled global::Xenonauts.Events.ExceptionReport: ExceptionReport: Exception : The weapon Name:Medikit cannot be used because it doesn't have a WeaponDataBehaviour 2019-03-03 09:33:07,574 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Common\Code\Debug\BugReport\RaygunClientSystem.cs:104) RAYGUN: Message sent. (message:[SwitchItemAct.InstantiateWeaponGameObject:150] Exception : The weapon Name:Medikit cannot be used because it doesn't have a WeaponDataBehaviour, stacktrace: at Common.Boards.System.SwitchItemAct.InstantiateWeaponGameObject (Artitas.Entity item) [0x00072] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\GroundCombat\Systems\Animation\Acts\SwitchItemAct.cs:150 at Common.Boards.System.SwitchItemAct.EquipItemSet (Artitas.Entity actor, Xenonauts.GroundCombat.Scripts.AActorDataBehaviour hdb, Common.Boards.System.EquipSet equip) [0x00143] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\GroundCombat\Systems\Animation\Acts\SwitchItemAct.cs:238 at Common.Boards.System.SwitchItemAct.OnActivated () [0x00087] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\GroundCombat\Systems\Animation\Acts\SwitchItemAct.cs:118

It took me a while to notice that this is a bug at all. Logically, it should not be possible to teleport soldiers/equipment from the main base to the skyranger. There is a mechanism that should prevent this (greyed out soldiers/equipment after launch of skyranger in armory). However this mechanism both stops working after: save/load ground combat (so you can exchange euipment/crew on way to new ground combat if there are multiple missions on the map)

Its pretty obvious on screenshot - the aircraft selection at the left just get longer with every aircraft until it is longer than the screen height. Either add a scrollbar if it gets too long or, even better, Tabs that let you switch the airbase and only display the interceptors from one airbase at a time.

What I did: find pyon soldier corps + magnetic rifle in ground mission complete the unlocked researches sell all pyon soldier corpses + magnetic rifles in store find pyon soldier corps + magnetic rifle in ground mission again Result: You are getting the "research unlocked" message again. (However it is just the message, you cannot actually do the research twice).

Build V2.1 Can still reproduce - prepared a savefile to start from as you need to get items from ground missions first + do some research before getting the laser weaponry research. start the game from desktop load the savefile before Laser Weaponry Reaearch.json - there is laser weapon reasearch about 2-3 hours before completion fast forward time until you get the research report and confirm it close the prompt that asks if you want to go to engineering (optional) take a look in the armory, there are infinite laser batteries (Screenshot 1) press F5 - attached quick_save.json press F9 - now you have only one laser battery (Screenshot 2) - try dragging it out and you see that it really is just one (as above) Notes: The issue persists in savefile - as above even if the ram caching of savefiles was fixed, step 1 is still important for reproduction somehow. I could not reproduce it right away a second again without going to desktop in between. Looks like the bug somehow happens because some specific data is missing in RAM while saving the game. Edit: Added one more screenshot (3) to illustrate what happens in build V2.1 if you produce laser weapons in engineering after the bug happened. Only one weapon will ever get the laser battery. The others display some replacement graphic where the laser battery should be (and are not loaded if equipped). Screenshot 1: Screenshot 2: Screenshot 3:

I had this happen on a Raid mission, too, now (however I can't reproduce that, yet). It seems that if it happens on a raid mission, it will cause a game crash on going back to Geoscape (log looks like the game is attmepting to execute some post-mission code that was intended for crashsite missions instead of Raids) 2019-03-02 11:27:56,622 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:664) Handled global::Xenonauts.Events.ExceptionReport: ExceptionReport: NullReferenceException : Object reference not set to an instance of an object 2019-03-02 11:27:56,824 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Common\Code\Debug\BugReport\RaygunClientSystem.cs:104) RAYGUN: Message sent. (message:[GCToStrategyMissionReturnParameters.AttemptToGrabUFOFromStrikeMission:289] NullReferenceException : Object reference not set to an instance of an object, stacktrace: at Xenonauts.Strategy.GCToStrategyMissionReturnParameters.AttemptToGrabUFOFromStrikeMission (Artitas.Entity mission) [0x0004b] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\Strategy\GCToStrategyMissionReturnParameters.cs:289 at Xenonauts.Strategy.Systems.StrategyLogicSystem.ProcessCombatResults (Xenonauts.Strategy.Events.ProcessCombatResultsCommand command) [0x0016f] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\Strategy\Systems\StrategyLogicSystem.cs:247 Attached: output.zip

In a ground mission, Alien weapons suddenly healed my Xononauts instead of damaging them (Screenshot 1). It is reproducable with the following savefile quick_save.json (just load it, fast forward to ground combat and find aliens to shoot you). I think it may be somehow related to the item duplication bug (https://www.goldhawkinteractive.com/forums/index.php?/topic/19767-v13-v21-geoscape-after-combat-laser-rifles-and-other-producable-items-duplicated/) If you suppose that they actually carry multiple armors over each other, this might explain it (if the armor protection is > 100%, the alien damage would be multiplied by a negative value?). Maybe the armory displays a Xenonaut as with no armor if the Xenonaut has an even number of combat armors. Edit: Just noticed that I have completed a medical room in atlas base before the ground mission. Now that I think about it, this could very well be the reason, too. Edit 2: No it is definitely not related to item duplication. Got it with composite armor, too. So most likely the change before I started seeing this is the medical room. Screenshot 1: Screenshot 2:

Found following crash to desktop: load the savefile: quick_save.json - it contains 2 crashsites, Skyranger en route to one of them click Skyranger click "select new target" click the other crashsite The result is a crash. Notably it does not happen if you click the new target crashsite instead and then use the mission planning - launch mission. Log looks like it is using some part of the code that is intended for intercepting UFOs instead of flying to ground combat mission. 2019-03-01 20:54:25,675 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\Strategy\Systems\Geoscape\GeoscapeAirTheaterOfWarSystem.cs:283) Squadron-1: Target Lost (Crashed) 2019-03-01 20:54:25,688 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:664) Handled global::Xenonauts.Events.ExceptionReport: ExceptionReport: NullReferenceException : Object reference not set to an instance of an object 2019-03-01 20:54:25,913 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Common\Code\Debug\BugReport\RaygunClientSystem.cs:104) RAYGUN: Message sent. (message:[TailAircraftMission.SetAirCombatStance:69] NullReferenceException : Object reference not set to an instance of an object, stacktrace: at Xenonauts.Strategy.Data.Missions.TailAircraftMission.SetAirCombatStance (Artitas.Entity mainBase, Artitas.Entity activity) [0x0000e] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\Strategy\Data\Missions\TailAircraftMission.cs:69 at Xenonauts.Strategy.Data.EntityEffects.ActionEffect.Apply (Artitas.Entity mainBase, Artitas.Entity target) [0x00009] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\Strategy\Data\EntityEffects\ActionEffect.cs:33 at Xenonauts.Strategy.Data.EntityEffect.HandleEffects (IEnumerable`1 effects, System.Object[] args) [0x00098] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\Strategy\Data\IEntityEffect.cs:128 Attached: output.zip

Build V2.1 After randomly getting this myself, I had an idea and I am able to reproduce it now. Steps: load the savegame: quick_save.json - it contains an interceptor craft on its way to a waypoint (Screenshot 1) fast forward time a bit - the game determines that the fuel reserve is now just enough to return to base, so it reroutes the interceptor back to base. However since the interceptor is close enough to its destination it triggers the "destination reached" instead of the "aircraft fuel exhausted" message (Screenshot 2) - I think it may be the same if the destination is a UFO and the interceptor runs out of fuel near the UFO choose "select new target" and select a new target - the "aircraft fuel exhausted" message comes up now (Screenshot 3) choose OK - the an interceptor will however not return but continue to fly to the new waypoint it is now impossible to get it to fly somewhere else before reaching the new waypoint because the game thinks it is already returning to base out of fuel. (Screenshot 4) On reaching new waypoint it is always possible to reroute it to a new target, it can even shoot down a UFO with the 0 fuel. The only limitation is that you can never select a new target before reaching the current target (Screenshot 5) Screenshot 1: Screenshot 2: Screenshot 3: Screenshot 4: Screenshot 5:

Got this, too. However I noticed that it does not necessarily need to be a second ground combat. In my game I have some rooms in atlas base under construction. And as soon as a room construction was finished, I did not get a message that room construction was completed. Instead I got the message that some soldiers were promoted. Seems that some event that triggers new message needs to happen before the promotions will register. Edit: Here is a savefile where the issue can be seen. It contains a room that will finish construction in 2-3 hours. Just load it and fast forward a bit. When the room finishes contruction, Kahana will be promoted: test.json

Had a ground mission where I first made my turn, then during the first alien turn some aliens made their move until game finally crashed. Notably it was the first ground mission where an psyon commander was present on the map. The log looks like game crashes when the psyon commander should make his move (happened on actor 5367 and this one is later listed as the commander). 2019-02-28 22:38:19,459 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:664) Handled global::Xenonauts.GroundCombat.Events.AnimatorTriggerCommand: Actor: 5367, Trigger: RotatingState, Active: False, Sticky: True 2019-02-28 22:38:19,461 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\GroundCombat\Systems\Rendering\AnimatorSystem.cs:218) Setting RotatingState on Animator for 5367 to False 2019-02-28 22:38:19,522 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:664) Handled global::Xenonauts.Events.ExceptionReport: ExceptionReport: NullReferenceException : Object reference not set to an instance of an object 2019-02-28 22:38:19,609 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Common\Code\Debug\BugReport\RaygunClientSystem.cs:104) RAYGUN: Message sent. (message:[MoveAnimationAct.set_Clip:68] NullReferenceException : Object reference not set to an instance of an object, stacktrace: at Common.Boards.System.MoveAnimationAct+Node.set_Clip (Xenonauts.GroundCombat.Systems.Animation.RuntimeAnimationClip value) [0x00072] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\GroundCombat\Systems\Animation\Acts\MoveAnimationAct.cs:68 at Common.Boards.System.MoveAnimationAct.CreatePath (Common.Boards.System.MovementAct parent, ISequenceTraceable trace, System.Collections.Generic.List`1 path, Common.Boards.Board board) [0x001fa] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\GroundCombat\Systems\Animation\Acts\MoveAnimationAct.cs:399 at Common.Boards.System.MoveAnimationAct.OnStarted () [0x00049] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\GroundCombat\Systems\Animation\Acts\MoveAnimationAct.cs:203 at Common.Boards.System.Act.PrivateOnStarted () [0x00026] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\GroundCombat\Systems\Animation\Acts\Act.cs:526 at Common.Boards.System.Act.PrivateOnActivated () [0x00002] in D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\GroundCombat\Systems\Animation\Acts\Act.cs:532 ... Actor: ID:5367 HP:105|105 Address:[X:25, Y:0, Z:44] Name:Name:Psyon Commander Body:psyon_default Rank:commander LifeStatus:Conscious - Edit: Just noticed I forgot the attachements. And additionally, it is perfectly reproducable with the save file. Just load the savefile, launch ground mission to crashsite and then end your own turn. Looks line all aliens will make there move first until game gets to the psyon commander that crashes the game. Attachements: output.zip + quick_save.json

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

Just had the following situation: followed a UFO, while it was both inside my base radar range and the interceptor radar after the UFO left the base radar range, it vanished from Geoscape (and I got the contact lost message) despite still being inside the fighter radar Looks like the UFO contact gets assigned the radar it was detected by first, then when it is detected by a second radar the second one is ignored. If flying out of range of the first one, the contact finally is defined as "out-of-range" and the game does not check if it actually was inside another radar. On the screenshot can be seen, that I practically was flying through the UFO (it left some event in the path where my interceptor just flew after loosing it) but the interceptor could not see it.

Just bumping this because the bug is still in V2.1. While I did not research laser rifles, yet, combat armor is now a producable item. I just fought 2 battles with one of my crew one combat armor equipped. After these battles I notices that I had suddenly 2 combat armors left over on supply screen despite having produced only one. Looks like it affects all producable items (in V1, the laser rifle was the only producable item ofc).

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.

Oh, this did not take long: This savegame the crashsite terrain is "junkyard" but the ground combat loads to desert and than instantly completes the mission: attached quick_save.json and output.zip for this case as well. Did not encounter the case again that it was random after loading wether the instant complete happens or not, yet. Will tell if I do. (but maybe the randomness in earlier versions actually was because of a savegame issue that is fixed now?). Edit: Actually the savefile in thread linked below is junkyard, too, and does not instant mission complete. So it is not the case for specific terrains. However some change in 2.x certainly did remove the randomness. If a crashsite is in the savefile, it will either always instant mission complete or never it seems now.

just happened to mit in V2.1 again. This time I have a savegame where it happens 100% of the time after loading it and fast forward time. It does not seem to be ralated to the save/load mechanism itself this time, because it did happen even the first time (i.e right after shooting down the UFO, before saving and loading in between). I suppose, it is because of the Game chose the dockyard terrain for the crashsite mission, which does not seem to work (actually the game does load the jungle map, not dockyard). Edit: Just got into ground mission where terrain dockyard was visible in Geoscape but it did load into jungle and NOT instant mission complete. So this is not the reason... In the log it can be seen that it does only spawn Xenonauts and Civilians, but no aliens and mission is determined to be completed right after spawning everything: 2019-02-27 21:34:51,380 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\GroundCombat\GroundCombatInitialization.cs:556) #Spawning# Spawned Reference: Template - Soldier [Name: - Rank:civilian] {No LifeStatus on target} (AIArchetype:aggressive) on [F:0, I:119, J:61] / [X:59, Y:0, Z:30], ID:7988 Type:Centre 2019-02-27 21:34:51,383 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Screens\GroundCombat\GroundCombatInitialization.cs:438) #Spawning# <color=#18F> Spawned 3 units </color> in total for player Players:local. 2019-02-27 21:34:51,385 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:649) Queued global::Xenonauts.GroundCombat.Events.CameraRegisteredEvent: Camera: GlobalEntity 2459 2019-02-27 21:34:51,392 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.37.1\Assets\Code\Libraries\Common\Code\Lifecycles\ScreenLifecycle\ScreenManager.cs:131) MoveTo GroundCombat was successful, removing from queue So, this instance of the instant mission completed was obviously introduced with the V2.0. But since It did happen before, I will let you know if I find it again with a UFO mission that is not displayed as dockyard terrain. attached: quick_save.json + output.zip

Noticed this small bug. How to reproduce: have 2 frag grenades (and maybe other grenade types, I think I had at least 2 smokes additionally) in inventory throw a frag grenade after selecting it from quick slot --> the quick slot still does display that you have 2 frag grenades after that (Screenshot 1) left click the quick slot --> nothing happens (grenade is not selected) right click the quick quick slot --> now the quick slot correctly displays that you just have one frag left (and you can throw it) Looks like the quick slot actually treats grenades as individual items and has still the same (now empty) slot selected after throwing - which is why the picture in the slot with the number of grenades does not update. I think, ive seen too that the quick slot was empty later during ground combat despite the solder having more grenades - which confirms my suspiction that the quick slot can stay selected at an empty slot in inventory. (OT: Had to scale down the screenshots again. Looks like the forum software does not accept files > 2 MB. However it does not tell me that, the upload just is displayed as "queued" forever and not start). Screenshot 1: Screenshot 2:

Right after alien turn was over, I got displayed 2 alien warnings. One of the aliens actually was in complete darkness (undiscovered part of map). I moused over darkness with xenonaut selected until I found the location of the alien and then cicled throuh my xenonauts until I found that it was the shield guy (PVT Markov) of whom the game thinks that he can see the alien. Something weird must be happening there. It can be seen that the alien is out of viewing range and weapon range, however probably there is no view-blocking obstacle in between. Maybe the viewing range calculation for the alien indicator/mouseover actually does restart with 0 range from a non-view-blocking obstacle (the low pile of boxes) or something like that. Additionally sent a quick report with F11 while it happened (maybe something in that auto-collected data). Screenshot scaled down to 75% of side length, because Forum somehow did not let me upload original 2.4 MB file.

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

I did mention it in the thread I link at the bottom, however I am starting a new thread, since the other problem was fixed. So it is obviously something different. To Reproduce: start new game and place initial base go to the armory - and click the loadout selection button, it displays the 4 predefined loadouts (Screenshot 1) get out of armory with ESC repeatedly, save the game load the game just saved after going into armory and clicking the loadout selection button again, the default loadouts can not longer be selected (screenshot 2) Note: It is still possible to update the default loadout with the "update" button (which changes the equipment of all soldiers with same loadout selection, too, not sure if this is intended) and to equip the selected loadout with the "euip" button, so the loadouts actually still do exist somewhere, only not displayed and consequently cannot be selected by other soldier. As a workaround if you want to apply the loadout to another soldier, it is possible to just save it as a "new loadout" (the game even does allow to enter the same name as the default loadout again when saving it). Edit: Just noted that actually ALL loadouts are affected by this instead of just the default loadouts. Screenshot 1: Screenshot 2: Reference:

The developers already made it clear several times that they won't return to Xenontauts 1 model. I am curious what the plans are to put more tactical depth in the new model, because I really would like if you exchange the fast reactions in X1 by more tactical depth. But ATM it just feels like both the reactive gameplay and the tactical depth (for example not longer possible to do bait and then destroy coming in from side) have been removed. I don't know but I really would like if there was reintroduced some more "2D-ness" in the new model rather than pure 1D-gameplay we have now. For example it could make a difference at what angle you came in on geoscape - so you could have a harder time closing in fast coming from behind as opposed from the side, while coming heads-on you could maybe accidently overshoot (add an escape zone behind the UFO and UFO would actually come closer during alien turn). It could be indicated by some speed incidator for the UFO that could point towards you, to up or nowhere at all if it is just moving sideways and allowing that vector to change during alien turn. But what I find positive about the new model is that it removes some logical inconsistency there is in X1: It just doesn't make any sense forcing the UFOs to have missile lock and firing arc at the front and have them move only forward like aircraft - if alien technology involves things like anti-gravity and thrusters mounted in every direction, nothing prevents them from turning in any direction and firing backwards.

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: