wulf 21

Still happens in V1.3. After playing around a bit, I noticed that it would sometimes load the larger UFO-dummy on the map (the one with one main room, one backroom and 2 siderooms) despite me definitely having shot down a light scout UFO. I think what happens is that if the game is saved and loaded while there is a crashsite on geoscape - it is does not properly restore the type of UFO that was shot down before and instead randomly selects a new type for the crashsite. And it would just sometimes select one where there was not put any dummy for in the game. Update: could not confirm my suspicion so far - each time I loaded a savegame I prepared, it would still display the same UFO-type and terrain-type after loading the savegame. However there is definitely something weird going on with quicksave and quickload - Sometimes F9 would load an older savefile even if the quick_save was the newest - maybe that's why I got the impression it was exchanging UFO types. Not sure how to reproduce this.

On trying to reproduce something else I have in my savegames and not sure how it happens (broken personnel slot buttons in Atlas base), I found a way that reliably makes the game crash. Start new game Place initial airbase anywhere Click "Main Base" Right click the workshop 4 times - this removes all 3 engineers and brings up the "Confirmation Required" window that asks if workshop should be demolished With the window open, left click the workshop 3 times - this adds all the engineers again In the "Confirmation Required" window click yes Result: Crash To Desktop output.log 2018-12-16 09:46:38,301 [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.Strategy.Data.SlotEffects.IncreaseTargetRangeByRatingSlotEffect.Revert (Artitas.Entity mainBase, Artitas.Entity unit, Artitas.Entity slot, Artitas.Entity building) [0x00009] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Screens\Strategy\Data\SlotEffects\IncreaseTargetRangeByRatingSlotEffect.cs:33 at Xenonauts.Strategy.Systems.BuildingsManagementSystem+<UpdatePersonnelSlotFSM>c__AnonStorey6+<UpdatePersonnelSlotFSM>c__AnonStorey5.<>m__0 () [0x0003c] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Screens\Strategy\Systems\Base\BuildingsManagementSystem.cs:458 at Artitas.Systems.DelayedTaskSystem.HandleTimeDelayedEvents (Artitas.Events.DeltaTimeEvent dtEvent) [0x00073] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\Systems\DelayedTaskSystem.cs:234 at (wrapper delegate-invoke) System.Action`2<Artitas.Systems.DelayedTaskSystem, Artitas.Events.DeltaTimeEvent>:invoke_void__this___DelayedTaskSystem_DeltaTimeEvent (Artitas.Systems.DelayedTaskSystem,Artitas.Events.DeltaTimeEvent) at Artitas.Core.Utils.ExpressionUtil+<ActionFromMethodInfoFactory>c__AnonStorey1`4[Artitas.Systems.EventSystem,Artitas.Events.DeltaTimeEvent,Artitas.Systems.DelayedTaskSystem,Artitas.IEvent].<>m__0 (Artitas.Systems.EventSystem target, IEvent param) [0x0001c] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\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)\hotfix-v0.34.1\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)\hotfix-v0.34.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\Systems\EventSystem.cs:26 at Artitas.DefaultProcessStrategy.Process (IEvent event) [0x001c6] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:808 at Artitas.DefaultProcessStrategy.Process () [0x00024] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:751 at Artitas.World.Process () [0x00007] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:621 at Common.Screens.DataStructures.WorldManagedScreen`2[Xenonauts.GameScreens,Common.Screens.DataStructures.IScreenParameters].Update (Single deltaTime) [0x00032] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Common\Code\Screen\DataStructures\WorldManagedScreen.cs:49 at Common.Screens.ScreenManager`1[Xenonauts.GameScreens].Update (Single deltaTime) [0x000f3] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Common\Code\Screen\ScreenManager.cs:149 at Xenonauts.XenonautsMain.Update () [0x00066] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Screens\XenonautsMain.cs:438

Still happens in build V1.3 - 10th Dec It is caused by trying to relocate an aircraft to the same hangar where it is already located. Reproducable with the attached saves (new game started in buid V1.3) load the savefile after_buy_hangar.json click the base named "Pacific" click the only plane (hangar 0) click "relocate squadron" - there will be displayed 2 hangars in window: the same where aircraft is already located (Pacific: Hangar 0) + the free hangar (Egypt: Hangar 1) - both selected (yellow) click "Egypt: Hangar 1" - note that this actually deselects the clicked option and "Pacific: Hangar 0" will be the selected option click "Authorize Relocation" Result: time and interface is frozen. It is still possible to close the open windows with ESC but everything glitches, it is not even possible to enter the menu with ESC except for trying fiddeling around with clicking bases and pressing ESC real fast. It is still possible to quicksave in this frozen state with F5: quick_save.json. However, loading this broken quicksave will make time run forward again and crash the game after a few seconds when the window of the "Pacific" base is opened and closed again. output.log 2018-12-15 23:50:33,166 [FATAL] (D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Screens\XenonautsMain.cs:441) A fatal error occurred during Update() - System.InvalidOperationException: Operation is not valid due to the current state of the object at System.Linq.Enumerable.First[Entity] (IEnumerable`1 source) [0x00000] in <filename unknown>:0 at Xenonauts.Strategy.UI.Components.GeoscapeSquadronInfoController.SetTypeText (Artitas.Entity squadron) [0x0000d] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Screens\Strategy\UI\Components\GeoscapeSquadronInfoController.cs:68 at Xenonauts.Strategy.UI.Components.GeoscapeSquadronInfoController.OnSetup () [0x00020] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Screens\Strategy\UI\Components\GeoscapeSquadronInfoController.cs:54 at Common.UI.DataStructures.UIController`1[T].SetTarget (.T target) [0x0002c] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Common\Code\UI\DataStructures\UIController.cs:86 at Common.UI.DataStructures.UILayoutController`2[Xenonauts.Strategy.UI.Components.GeoscapeSquadronInfoController,Artitas.Entity].Setup (IEnumerable`1 targets) [0x000aa] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Common\Code\UI\DataStructures\UILayoutController.cs:101 at Xenonauts.Strategy.UI.GeoscapeGeobaseElement.<OnCreate>m__10 (Artitas.Entity hangar, Boolean isOn) [0x00037] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Screens\Strategy\UI\Elements\Geoscape\GeoscapeGeobaseElement.cs:83 Further update: actually clicking "Pacific: Hangar 0" which deselects it in step 5. has the same effect. The only way to make the relocate work properly is clicking "Egypt: Hangar 1" twice to select it and only it. Yet another update: Turns out that clicking "Egypt: Hangar 1" twice does not work properly either. The interceptor will be no longer assigned to "Pacific: Hangar 0" and get visible in "Egypt: Hangar 1" immediately. However it turns out that it never arrives there and stays in Airborne state forever. ETA in interception menu behaves like it is calculated from the Pacific base. Basically, relocate mechanic is completely broken.

In this round, I wanted to throw a smoke grenade to protect me from the alien fire. Because I had exactly 15 TUs left so no TU spare to turn, I threw it against the cliff like illustrated in screenshot (I took the screenshot after actually throwing it and selected the next grenade just for the purpose of displaying how exactly the grenade was aimed). The result was that the smoke grenade actually exploded inside the cliff, so you see the upper part of the smoke just clipping out of the high ground in the screenshot (the same as if you would throw a smoke inside a building). Expected would of course be that if the cliff is hit that the grenade would roll off it to the tile next to it.

There happened crash to desktop right after trying to throw a smoke grenade directly onto another xenonaut. I clicked actually at the xenonaut, not the ground where it is standing on, confirmed by the log: 2018-12-15 13:40:45,870 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:594) Queued global::Common.RPG.AbilityEvent: AbilityID: Prime and Throw, Source: GlobalEntity 4649 Item - Name:Smoke Grenade, Target: GlobalEntity 4759 - Soldier [Name:Klara Bergman - Rank:private] LifeStatus:Conscious ... 2018-12-15 13:40:46,325 [FATAL] (D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Screens\XenonautsMain.cs:441) A fatal error occurred during Update() - System.ArgumentOutOfRangeException: Argument is out of range. Parameter name: index at System.Collections.Generic.List`1[Xenonauts.GroundCombat.Abilities.Shoot.Shot].get_Item (Int32 index) [0x00024] in /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Collections.Generic/List.cs:635 at Artitas.Utils.ListExtensions.Pop[Shot] (IList`1 list) [0x0000c] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Plugins\Xenonauts\Artitas\ListExtensions.cs:39 at Xenonauts.GroundCombat.Abilities.ThrowingAbility.FireProjectile (Common.RPG.AbilityState state) [0x00027] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Screens\GroundCombat\Factories\Abilities\GrenadeAbility.cs:331 at Xenonauts.GroundCombat.Abilities.ThrowingAbility.<AnimateThrow>m__0 (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\GrenadeAbility.cs:314 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.AllEffect`1[Common.RPG.AbilityState].Apply (Common.RPG.AbilityState state, IEvent event) [0x0004b] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Common\Code\RPG\Ability\Effects\CompositeEffect.cs:118 at Common.RPG.AnyEffect`1[Common.RPG.AbilityState].Apply (Common.RPG.AbilityState state, IEvent event) [0x0003a] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Common\Code\RPG\Ability\Effects\CompositeEffect.cs:73 at Common.RPG.AbilityState.ExecuteEventEffects (IEvent event) [0x0002c] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Common\Code\RPG\Ability\AbilityState.cs:244 at Common.RPG.AbilityState.Execute (IEvent event) [0x000d8] in D:\Jenkins\workspace\X2 (Build)\hotfix-v0.34.1\Assets\Code\Libraries\Common\Code\RPG\Ability\AbilityState.cs:207 Attached output.log Update: I was not able to reproduce the crash - it just happened one time so far

While the original issue is indeed solved - there is still a minor issue left in build V1.3. I thought I'll post it here rather than create new thread. Reproducable with following save (obtained by researching Laser Rifles adding one to queue and reordering them): 1_laser_in_queue.json load the savefile click Engineering click up one time on laser-rifle (screenshot 1) click down one time on laser rifle (screenshot 2) try to click up again - will not work and downbutton will stay highlighted (screenshot 3, unfortunately does not display the mouse pointer but it was over the up-button again while taking it) Up-Button will be working again after switching to Geoscape and back. Screentshots:

To give Feedback to this: Looks like everything regarding actual TU value increase was solved - did not observe any abnormal increase after mission again. The only thing left now (Build V1.3) is the visual bug that in Soldiers Tab, there is displayed current TU at end of last mission (Kistina Petrova in Screenshot, did the last kill), while the armory correctly displays the max TU value.

If I try to click on the upper floor of the barn, the game does not find any path up the ladder. I could see in desert scenarios that climbing is already implemented in the game (there were places where climbing a cliff is possible), so I am assuming that it's a bug in the map. The ladder looks like it was placed incorrectly (should cennect one side of a lower-floor-tile to another one on the upper floor but actually is somewhere near the middle of the tile) Upper floor: Lower floor (clicked the tile to see there are enough TU left + to see placement of ladder better)

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?

Stun gas grenade exploded right next to the wall. The gas should surely go over the was but it is awkwardly blocked by it. Update: Happens only with stun gas. Smoke does go over the wall (in following screenshot smoke exploded down off the wall, smoke goes over in upwards direction. Stund gas exploded upwards next to wall, does not go over wall:

I randomly noticed how this plays out it the line-of-sight indicator is off: The alien would stay visible during whole alien turn but would vanish from screen after alien turn is finished. If the indicator is on, it stays on screen. Actually both behaviours are not correct: Alien should become invisible for player as soon as it steps on first Tile that is not currently within any Xenonaut line-of-sight, even during alien turn.

I just got the issue myself in build V1.3. It was definitely not the last alien on the map (was short after start) that caused it, however the last one in my view. What happened in the round is that I killed the other alien I threw a gas grenade directly on the alien as the alien was not stunned, I added a smoke so it wouldn't hit me on alien turn, then I ended my turn It looked like the alien was stunned after trying to start moving So my interpretation is that it may happen on any alien if it is stunned by gas before being able to finish the move that was planned by the AI and the AI would then simply stop doing anything and never finish the alien turn. output.log Note: Additionally reported this instance of the bug with F11 while the soflock happened, maybe there is something helpful in the data that it collected, too. Edit: Just noted that the recording file was useless as it was from 07.12. - it was totally unrelated.

That was reported already. Ground comba saving is a not yet implemented.

That was actually in the game in the first 2 builds, but it caused animation glitches (shield clipping through soldier), so it was taken out again. I can imagine that the decision wether or not it should be allowed is not final, yet, maybe when they have an idea how the game balance works out once all the features that are yet to come are in the game. But it will definitely cause some more work on their side if they want to do it properly.

Still happens in V1.3 Just a note on reproduction, it looks like it will crash even if multiple turns pass between loading the shock ammo and the death of the Xenonaut, so you can just execute steps 1 and 2 with ZHOU and then run around the map with her until finally finding an alien then kills her while selected.

Well actually the shortest path between Greenland an Australia is over the north Pole, then south. Sorry, couldn't resist .

It was a fresh new round started after release of V1.2

Looks like it's reproducable: Just load the savefile, fast forward to ground engagement, execute steps 1 and 2 with PVT ZHOU (no need to shoot the alien), run up to an alien and let ZHOU be killed. She needs to be selected to make the crash happen (so killing her with another Xenonaut is not an option). Death does not need to be during alien turn, reaction fire has same effect.

After loading the quicksave die_ctd_quick_save.zip a few times (from the other thead), I suddently saw the "mission complete" screen right after the ground mission loaded. Here is the debrief screen right after that: There just were no aliens on the map at all: In the log it can be seen that the random map generator somehow generated the map without any places where it would be possible to spawn aliens: 2018-12-09 21:54:03,191 [ERROR] (D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\GroundCombat\GroundCombatInitialization.cs:471) #Spawning# Skipped <color=#ADC> Reference: Template - Combatant - Species:psyon, RoleGroup:default, Ethnicity:default, Gender:default :: {No LifeStatus on target} (using SpawnRegionComponent [Player: Players:alien, Target: SpawnTarget:General, Number: 0],SpawnRegionComponent [Player: Players:alien, Target: SpawnTarget:General, Number: 0]) </color> as no appropriate spawn location could be found 2018-12-09 21:54:03,193 [ERROR] (D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\GroundCombat\GroundCombatInitialization.cs:471) #Spawning# Skipped <color=#ADC> Reference: Template - Combatant - Species:psyon, RoleGroup:default, Ethnicity:default, Gender:default :: {No LifeStatus on target} (using SpawnRegionComponent [Player: Players:alien, Target: SpawnTarget:General, Number: 0],SpawnRegionComponent [Player: Players:alien, Target: SpawnTarget:General, Number: 0]) </color> as no appropriate spawn location could be found 2018-12-09 21:54:03,196 [ERROR] (D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\GroundCombat\GroundCombatInitialization.cs:471) #Spawning# Skipped <color=#ADC> Reference: Template - Combatant - Species:psyon, RoleGroup:default, Ethnicity:default, Gender:default :: {No LifeStatus on target} (using SpawnRegionComponent [Player: Players:alien, Target: SpawnTarget:General, Number: 0],SpawnRegionComponent [Player: Players:alien, Target: SpawnTarget:General, Number: 0]) </color> as no appropriate spawn location could be found 2018-12-09 21:54:03,198 [ERROR] (D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\GroundCombat\GroundCombatInitialization.cs:471) #Spawning# Skipped <color=#ADC> Reference: Template - Combatant - Species:psyon, RoleGroup:default, Ethnicity:default, Gender:default :: {No LifeStatus on target} (using SpawnRegionComponent [Player: Players:alien, Target: SpawnTarget:Guard, Number: 0],SpawnRegionComponent [Player: Players:alien, Target: SpawnTarget:General, Number: 0]) </color> as no appropriate spawn location could be found 2018-12-09 21:54:03,200 [ERROR] (D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\GroundCombat\GroundCombatInitialization.cs:471) #Spawning# Skipped <color=#ADC> Reference: Template - Combatant - Species:psyon, RoleGroup:default, Ethnicity:default, Gender:default :: {No LifeStatus on target} (using SpawnRegionComponent [Player: Players:alien, Target: SpawnTarget:General, Number: 0],SpawnRegionComponent [Player: Players:alien, Target: SpawnTarget:General, Number: 0]) </color> as no appropriate spawn location could be found 2018-12-09 21:54:03,202 [ERROR] (D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\GroundCombat\GroundCombatInitialization.cs:471) #Spawning# Skipped <color=#ADC> Reference: Template - Combatant - Species:psyon, RoleGroup:default, Ethnicity:default, Gender:default :: {No LifeStatus on target} (using SpawnRegionComponent [Player: Players:alien, Target: SpawnTarget:General, Number: 0],SpawnRegionComponent [Player: Players:alien, Target: SpawnTarget:General, Number: 0]) </color> as no appropriate spawn location could be found 2018-12-09 21:54:03,204 [ERROR] (D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\GroundCombat\GroundCombatInitialization.cs:471) #Spawning# Skipped <color=#ADC> Reference: Template - Combatant - Species:psyon, RoleGroup:default, Ethnicity:default, Gender:default :: {No LifeStatus on target} (using SpawnRegionComponent [Player: Players:alien, Target: SpawnTarget:Commander, Number: 0],SpawnRegionComponent [Player: Players:alien, Target: SpawnTarget:General, Number: 0]) </color> as no appropriate spawn location could be found 2018-12-09 21:54:03,206 [INFO] (D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\GroundCombat\GroundCombatInitialization.cs:499) #Spawning# <color=#18F> Spawned 0 units </color> in total for player Players:alien. Attached the logfile and recording: mission_complete_bug.rar

Game crashed right after death of a xenonaut. Maybe this crash can even be consistently reproduced, as it happened after trying something out for the first time. One soldier carried a shotgun and 2 regular magazines + 2 shock ammo magazines into battle (you can look up the loadout in the quicksabe file I made before starting the ground engagement) During my turn, I first loaded shock ammo by dragging it into the hidden inventory slot in the shotgun, then moved directly next to an alien (I was on the tile diagonally to the upper left of the alien) I shot the alien and missed 2 times, however the alien was suppressed as the result during alien turn, alien turned around and killed the Xenonaut I did above steps with What I am no longer sure about is if the Xenonaut that died was selected when I ended my turn. Logfile looks sure like crash is inside the inventory system code: 2018-12-09 21:11:42,251 [FATAL] (D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\XenonautsMain.cs:513) [INITIAL CRASH] System.NullReferenceException: Object reference not set to an instance of an object at Xenonauts.UI.PlayerControlElement.ValidQuickItemsFromBelt (Artitas.Entity actor) [0x00007] in D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\GroundCombat\UI\Elements\PlayerControlElement.cs:576 at Xenonauts.UI.PlayerControlElement.ReorderAndSelectQuickItem (Artitas.Entity actor) [0x0003a] in D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\GroundCombat\UI\Elements\PlayerControlElement.cs:549 at Xenonauts.UI.PlayerControlElement.<OnCreate>m__14 (Artitas.Entity e) [0x0000f] in D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\GroundCombat\UI\Elements\PlayerControlElement.cs:275 at Artitas.Family+<ComponentUpdate>c__AnonStorey8`1[Xenonauts.Common.Components.Item.InventoryLink].<>m__0 (Artitas.Family family, Artitas.Entity entity, Int32 cID, IComponent rem, IComponent add) [0x00014] in D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\Family.cs:593 at Artitas.Family.RemoveEntity (Int32 entityID, Int32 componentID, IComponent previous, IComponent next) [0x0006f] in D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\Family.cs:510 at Artitas.Family.UpdateEntity (Int32 entityID, Int32 componentID, IComponent previous, IComponent next) [0x00050] in D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\Family.cs:491 Attached die_ctd.zip (output.log, recording_1.rec (has right timestamp)), die_ctd_quick_save.zip

Well, I found the shields very useful in xenonauts 1 (at least until the point was reached where everyone had the best armor). The concept of a secondary weapon did not exist in the same way then, however there was one 3x2 area on the belt where either a pistol or a stun-baton would fit. You would actually have to drag the shield out of and weapon into the soldiers hands in inventory, which conts some TU, but still running up close and then stunning the alien or finishing him with the pistol was a working tactic, mainly because it was nearly a guaranteed hit. (btw. I am wondering why meelee weapons have just 40 % hit chance now?). At the beginning aliens were unarmored, so two or three pistol shots would actually kill at least the weak race, later you would develop better pistols (laser, plasma, mag-pistol), so pistols were a valid option for a great part of the game. Still yes, choosing a shield instead of a weapon would make the soldier more inefficient. But the main advantage of the shield came from the fact that it is not only protecting the soldier him/herself, but the soldier behind, too. This made it extremely useful in tight situations in bases or larger UFOs where you at some needed to open a door to some corridor with multiple aliens that would immediately reaction-fire and kill soldiers without shields. The shield-bearers would go first, then duck and the rest of the squad can shoot over their head. And paraxodically, in open areas with virtually no cover it was useful, too, so you could hide a second soldier behind the shield and keep moving, instead of crawling from one of the rare covers to the next. And Generally this was a good advantage as you would never want to find yourself in a situation where a soldier runs around a corner and spots an alien with the last TU and noone being able to help. If this was a shield-barer it would not really matter and you still had one more turn to correct the mistake. And giving the shield-bearer a grenade-heavy loadout was always an option in later stages of the game as the strength of everyone grew, however this option was taken out as a design-decision in Xenonauts 2 because it produced more fiddeling with loadouts (you could save loadouts, but always had to remove stuff if the soldier was just not strong enough after loading it). Maybe it is a little too early in the game development to discuss precise balancing issues, however I don't think that making the overall efficiency of an individual shield-bearer up-to-par with a normal soldier is a good idea. Then you could just equip the whole squad with shields. The advantage should come from working with other soldiers, ie. a shield soldier with 2 normal soldiers behind should be more efficient in storming tight spots as 3 normal soldiers.

This already happened the second time, after having noticed in in V1.1 before already shortly before update came out. I think there is a pattern. I was playing with the line-of-sight indicator on since round 2 of the ground engagement. The following sequence of events happened: the alien was standing where the purple blood is visible in the screenshot I shot him with the soldier visible in the middle. The shotgun soldier in the upper right corner shot another alien before going into cover behind the rock in the same turn, so he could see the alien at the end of my turn. I moved the soldier in the middle behind the trees. so he was facing away from the alien and had cover from the alien at the end of my turn Then during the alien turn, the alien did move to where it is standing now in the screenshot That means: the alien started his move within the line-of-sight of sight the place where the alien ended the move was in line-of-sight during my turn, but not during alien turn Therefore, I should not have been able to see where the alien ended his turn, but I was. I checked, too that I could still see the alien after disabling the line-of-sight-indicator. The reason why I checked this was that in another ground combat mission, it was working correctly (alien moving out of line-of-sight disappeared from screen), but I had not enabled the line-of-sight incidator at that time. After enabling it, I saw the reason the alien disappeared and the alien stayed disappeared after enabling it. So it might be that it only happens if the indicator is activated at the time but the result stays, no matter if it is activated/deactivated after. But on the other hand, it might be a coincidence and the reason why it worked correctly was that not all the above conditions were true. There might be something helpful in the same logs I posted in the Medkit Game Crash thead: logs.zip as this was the same ground combat round that then ended with the crash. Screenshots:

Yep, definitely happens in Build V1.2. Ran into it myself. Not sure what the conditions are that it crashes. What I did was trying to let a wounded soldier heal herself. She had full TUs damage left to heal. Crash in output.log: 2018-12-07 21:00:56,960 [FATAL] (D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\XenonautsMain.cs:513) [INITIAL CRASH] System.NullReferenceException: Object reference not set to an instance of an object at Xenonauts.GroundCombat.Abilities.MedikitAbility.<Create>m__1 (Common.RPG.Ability ability, Artitas.Entity weapon, Artitas.Entity target, System.Object rawConflict) [0x00025] in D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\GroundCombat\Factories\Abilities\MedikitAbility.cs:136 at Common.RPG.Ability.CanTarget (Artitas.Entity source, Artitas.Entity target, Optional`1 parameters) [0x00017] in D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Libraries\Common\Code\RPG\Ability\Ability.cs:78 at Xenonauts.GroundCombat.UI.Fragments.SelectionFrameFragment.HandleLeftClickTarget (Common.Input.MouseCodeStateReport report) [0x00088] in D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\GroundCombat\UI\Fragments\SelectionFrameFragment.cs:104 at Xenonauts.GroundCombat.UI.Fragments.SelectionFrameFragment.HandleClick (Common.Input.MouseCodeStateReport report) [0x00075] in D:\Jenkins\workspace\X2 (Build)\release-v0.34.0\Assets\Code\Screens\GroundCombat\UI\Fragments\SelectionFrameFragment.cs:70 Attached: logs.zip (contains output.log and the last written .rec in same folder) PS: Seems the forum gets me " There was a problem processing the uploaded file. -200 " if file is more than 1mb, which is odd because I already uploaded a 3.9 MB uncompressed output.log earlier. PPS: I noticed that by pure coincidence the soldier that should heal herself was the selected one in the screenshots I took for:

should prabably be made to work on different ammo types, too, as currently the only way to reload a different ammo type seems to be dragging the ammo inside a slot that is hidden inside the primary weapon slot.

Hmm, just to test if my memory is correct I just fired up Xenonauts 1 - and the Spacebar works as I describe (second press returns to previous speed). In GOG galaxy it says I have "1.65 GOG Hotfix" and I have the "Skitso's Ultimate Megamix Map Pack" installed, so maybe one of these 2 modded it in, or is this function actually a bug in this version of Xenonauts 1 XD? Additionally, upon the second spacebar press in Xenonauts 2, it just looks like the game intends to click the previous time warp (button dark for short time) and if this just would not work.