[[V5.38.1 - Ground Combat] 100% grenade toss fails due to hitting a sloped roof]

On 7/13/2025 at 8:18 AM, Ascylon said:

Description: In some cases 100% throws fail to hit the indicated tile and hit a roof instead. I have two examples of this, with the first screenshot for each indicating the tile to throw the demo charge and the second the roof that it hits instead. The save games are also attached.

user_100percentfail-61.json 3.76 MB · 0 downloads user_100percentfail2-63.json 3.78 MB · 0 downloads

Thanks for the report! We'll give this a look and see what's going on

[[V5.38.1 - Ground Combat] Soldier inventory and armor refreshes when going directly from one ground mission to another]

On 7/13/2025 at 8:43 PM, Ascylon said:

Description: When you finish a crash site and go to another crash site without going back to your base first, armor, shields and any ammo clips are refreshed to full and the only missing items are those completely removed from inventory (grenades and fully used clips) as well as lost soldier health. This also applies to the transition between Operation endgame P1 and P2, making P2 easier due to inventory, armor and shield refreshing. I'm not 100% sure but destroyed shields might even come back.

Expected: Soldiers should keep their current state completely (even unhealed healable HP) until the dropship returns to base, especially in the transition between Operation endgame P1 and P2.

Thanks for the report! We're aware of this issue as well, especially the item refresh on transition from endgame 1 -> 2. We do plan to fix this eventually but Uufortunately we haven't been able to make a fix for it yet as we've decided to focus on more immediate issues for now.

[[V5.38.1 - Ground Combat] Pathing "knows" about enemy units and prevents movement to their tile before they are spotted]

On 7/13/2025 at 8:11 AM, Ascylon said:

Description: When trying to move units to a tile occupied by a unit, sometimes you get the error message that unit could not path to location, while sometimes the unit starts moving but stops well short of the destination. An example of the first (just without a save) are two screenshots below (the unit refuses to path to where the cyberdrone is, despite it not having been spotted this turn.

 

For the second case you have a soldier start moving to the spot in the screenshot behind the door (the tile contains a Sebillian). The movement, however, abruptly stops at the tile in the second screenshot and then refuses to continue movement to the indicated tile when you reclick it, but without an error message. The save game for this scenario is attached, since it is a more specific kind of scenario (movement starts but stops before the xenonaut actually spots the enemy and when reattempting the same tile to continue movement, no error message is shown but also movement does not commence).

 

Expected behavior: Pathfinding should not care about unspotted enemies or neutral units outside current vision when calculating paths, and only stop the soldier movement once one is actually spotted.

user_pathfindweird_1-51.json 3.66 MB · 0 downloads

Thanks for the bug report! We're aware of this one and we're working towards getting this and other shroud related issues fixed on milestone 6.

[[V5.38.1 - General] When alttabbing from the game so that the window is not active and visible, CPU and GPU usage go high]

On 7/13/2025 at 7:19 AM, Ascylon said:

Description: Playing on Borderless Full Screen on two monitors, when the game window is active CPU and GPU usage is low, but if I alt tab and cover the game windows with e.g. notepad, CPU and GPU spikes high (GPU usage normally is 5% or so. The screenshot shows the spike that occurs, the exact steps to reproduce are:

* Open Xenonauts 2, leave it in the starting menu (though this happens everywhere, in menu, geoscape, tactical, but can be replicated simplest in the starting menu)
* Alt-tab out of Xenonauts 2
* Maximize any other window (Notepad, for example) on top of the game window
* CPU and GPU go brrr
* Make Xenonauts 2 window active again, and resource usage returns to normal

I noticed it only because the GPU power draw was sufficient to make my UPS fan turn on, normally the load does not require it, but with slower hardware it might cause problems for other people if they also like to alt tab to do other things at times while taking a break etc.

Thanks for the bug report! I tried this out on my own machine but I haven't been able to repro the same increase in cpu/gpu load. Will have to check in with the rest of the team and see what they think, though we might end up asking for some of your logs later

[[V5.38.1 Geoscape] Panic multiplier not applied correctly to funding]

Thanks, we'll look into it!

[[V5.38.1 - Air Combat] Enemy multishot weapons can track beyond their targeting cone after the first shot]

On 7/13/2025 at 5:53 AM, Ascylon said:

Description: In air combat, if a multishot weapon (example bomber frontal weapon) manages to get the first shot off when you are in the cone, but you dodge outside the cone, the remaining shots of that salvo will track the aircraft wherever it goes without the cone restriction. Hopefully illuminated by the screenshots, note how the first shot is within the cone, but the rest do not care about the cone.

Expected: The shots of the salvo should never be aimed outside the cone.

Thanks, we'll look into this and get it fixed

[[V5.38.1 - Ground Combat] UFO outside visual model does not align with pathable tiles]

On 7/13/2025 at 6:04 AM, Ascylon said:

Description: When getting ready to breach the UFO and gathering soldiers next to it, some tiles appear to be outside the UFO, but pathing thinks the best way to get there is from inside the UFO (see screenshot). I have encountered this on several different UFOs, but did not remember to take notes of which ones specifically have the problem. This is especially annoying, because I usually speed time with the spacebar when positioning soldiers, and premature breaching has been close on several occasions.

Expected: The tiles should be unpathable.

Thanks for the report! Yeah - this is a known issue and we're working towards getting it fixed, we've tried a band aid solution for it but unfortunately that didn't work so we're working towards implementing a proper solution for this bug, which might take us awhile.

[Small visual issue on UFO hull]

On 7/12/2025 at 1:47 PM, Skitso said:

This is not that important issue, but I'll just put it here so you can file it in as a thing to fix at some point in the polish phase.

Thanks for the report! Yeah, pretty sure this is a known issue, we'll get it fixed. (eventually!)

[[V5.38.1 - Ground Combat] Shot accuracy modifiers shown outside visible area allow "wallhacking"]

On 7/13/2025 at 6:13 AM, Ascylon said:

Description: When free-aiming, all shot accuracy modifiers for the trajectory are visible even outside the vision cone. This allows for scanning for enemies, because upright aliens/xenonauts are pretty much the only things that cause a -25% drop in accuracy at least within UFOs (-20% if they are crouching). This allows you to scan the UFO (or the map for that matter) before breaching to see where units are located and how many there are. In attached screenshot, for example, the two -25% modifiers are two aliens inside the UFO, and by sweeping the free-aim trajectory you can scan the entire floor to get a count and location.

Expected: Accuracy modifiers should not be shown beyond the currently visible area (within the current vision cones, so not just undiscovered black area but also previously discovered area that is not within the current vision cones).

Thanks for the report! We've been going through a bunch of fixes for the shroud, so I'll have to check in with our tech lead if this has been taken into account. Very nice catch though!

[[V5.38.1 - Ground Combat] Vanguard armor extra TU not applying to shot percentage calculations]

On 7/13/2025 at 5:46 AM, Ascylon said:

Description: With vanguard armor, weapon TU percentages are still calculated from unit's base TU without the +12 bonus (might be intentional, but allows extra shots like 2 aimed shots with sniper or 2x 3x with heavy etc). So with 112 TUs (100 soldier, 12 vanguard), sniper rifle aimed shot should take 0,51 * 112 = 57,12 TUs, but only takes 0,51 * 100 = 51 TUs.

Thanks for the bug report! Will have to double check with Chris as this might be intended, but we'll 100% look into this.

[[m5.39.0 - General] Display anomaly with dead andron and smoke.]

On 7/12/2025 at 8:47 AM, Melee said:

Description:  Dead andron in smoke yields a moving red hash as camera is rotated.

Update:  Smoke isn't necessary.  Red alien unit tile hash appears for dead androns but not other dead aliens.

user_day_390_red_hash-771.json 6.18 MB · 0 downloads

Thanks for the bug report! We're aware of this issue (came across it while I was doing my own playthrough), it's unfortunately reproducible from loading saves so we're not sure what causes yet but we've got a good hunch on what does. We'll get it fixed once we've got more dev time to spare as we're currently a bit loaded on fixing some of the more serious issues (shroud bugs and the like) and pushing out stuff for milestone 6 (and 7)

[[5.38.1 Ground combat] Clicking on Inventory Button of hex with dead soldier causes crash]

On 7/12/2025 at 12:26 AM, maxm222 said:

Thanks for all the suggestions, will try them.

Btw if it's not in any of those locations I've provided above, it most likely is here

%userprofile%\AppData\LocalLow\Goldhawk Interactive\Xenonauts 2

 

[[V5.38.1 - Ground Combat] When an alien bleeds at the end of its turn, the blood is visible even outside vision]

On 7/13/2025 at 6:22 AM, Ascylon said:

Description. If you shoot an alien so that it starts bleeding, and the alien moves to an undiscovered (black) tile during its turn, the blood generated from the bleed at the end of turn is visible. In the attached screenshot a sniper shot a Wraith at the location of the blood pool on the top left side of the screen. The wraith moved to the location on the right with the blood pool, and the screenshot is taken at the start of the following xenonaut turn. This provides the player information that should not be available about the location the alien moved to.

Expected: The blood pools generated from aliens outside vision cones on their turn should not be visible.

Thanks for the bug report! This should be part of the shroud fixes we've been working on that will come out w/ milestone 6, hopefully we get to release a stability test of it sometime this month (most likely next week). If this shows up again once milestone 6 drops, please let us know!

[[V5.38.1 - Air Combat] Sometimes the aircraft placement area is very subdued in color]

On 7/13/2025 at 6:53 AM, Ascylon said:

Description: The color blends so well to the background at least on my monitor, that sometimes I forget I can move the planes around. I thought I had a save and I tested that it was replicable in the save, but it was an interception autosave that I did not remember to backup before continuing to play on and it got overwritten. I did manage to take a screenshot of what I mean exactly, hopefully it gives enough hints. This is not extremely rare (but not common either), and has happened several times during a campaign. I'll try to remember to attach a save file if necessary when I encounter it again. The second screenshot is there for comparison for what the normal color is for me.

 

Thanks for the report! Yeah - I can see what you mean here, we're currently reworking the visuals of the Air Combat layer so we won't be making any changes to the current AC, but we'll keep this feedback in mind!

[Milestone 5.39.0 Released! (Experimental)]

On 7/6/2025 at 9:55 PM, OTZ said:

I am noticing that rewards for additional operational points are not adding to the daily count. I have activated a few missions and I am stuck at 8 OP/day. 

I just checked this on my end it seems to be working fine, can you create a bug report post in Xenonauts-2 Bug Reports - Goldhawk Interactive so we can look into it? Please attach a save file as well so we can have a better idea of what's going on.

[[5.38.1 Ground combat] Clicking on Inventory Button of hex with dead soldier causes crash]

On 7/9/2025 at 12:17 AM, maxm222 said:

Thanks for your response!  When I clicked on the knapsack icon I was actually thinking that "this is the only way I can look at what's on the ground;" I didn't think of it as clicking on a dead soldier's belongings.  Yeah, I'm an idiot even after 1,400 hours in Xeno2.

The problem with my using the new bug reporting system is that I can't locate any folders called "Bug Reports" or a "save folder."  When I ask Steam where my Xeno2 files are, they showed the first screen shot (edited) I attach.  I found a folder in Windows 11 (see second screen shot) under "Users" which has a single folder containing the output files.  I looked through every single sub-folder in both Xeno folders.

I also didn't get any prompt to generate a crash zip file that I noticed. 

I assume that all the folders you mentioned should be included in 5.38.1?  Any advice on where to look?

Thanks for the reply! The bug report and saves folder usually should be in the same location as the log folder, but it looks like that is not the case here. Are you by any chance using one drive or a networked location for your saves? You might've also set an alternative save location on your game's launch options. If you're on Steam you can check if you have anything like this string in your launch options (Right click game on library -> General)

-gameSaveFolder=<save_location>

Not sure how to change this on GoG but if that's what you use I can also look into it, just in case. If you're not using a networked drive for your saves and the save location hasn't been overridden in Steam's launch options as well, then please let us know so we can help you find it.

Alternatively you can check if your saves in the location below as well.

%userprofile%\AppData\LocalLow\Goldhawk Interactive\Xenonauts 2

 

[Hi, I’m stuck at day 550, all research done, and no Eternal or final mission appears. Can you help unlock the end mission in this save?]

17 hours ago, FitnessAndChocolate said:

I have problem whit prograssion. I have played this campain for 100 hours and i simply want to finish it so i can play on higher difficulty, but I cannot finish the game. Devs, Can you please help me?

Hello there, can you send us your campaign's save so we can give it a look? Your saves should be in Documents\My Games\Xenonauts 2\Saves. Just attach the save here when you post your reply, then we can figure out what's going on with your campaign, thanks!

[[m5.38.1 - General] Map crates appear to be floating.]

On 7/5/2025 at 8:45 AM, Melee said:

Description:  UFO's antigrav emitters seem to be causing crates to levitate.

 

user_day_375_floaty_crates-727.json 6.08 MB · 0 downloads

Thanks as always for the reports! We'll get it fixed

[[5.38.1 Ground combat] Clicking on Inventory Button of hex with dead soldier causes crash]

On 7/5/2025 at 1:55 AM, maxm222 said:

I had a dead soldier on the ground & wanted to check his equipment (to pick up).  As an experiment, I tried clicking on the hex with the casualty, and then clicked on the inventory button (knapsack icon).  The game immediately crashed back to home screen.  I obviously won't do this any more, but I can see at least a few other players trying it.

output.log 172.35 kB · 0 downloads output.log.1 10 MB · 0 downloads

Thanks for the bug report! That's interesting, normally you shouldn't be able to open a deceased soldier's inventory so I'm not sure how that happened. We'll give the logs a look but it would be very helpful if you can send us the crash report .zip file as well, there should be a prompt to generate this whenever you relaunch the game after the crash. The .zip file should be in a folder called Bug Reports in the same directory as your save folder.

[Schrodinger's Mentarch!]

3 hours ago, BeelzeBubba said:

I completed my first downed UFO mission, where I managed to capture a mentarch. I interrogated it, which upon completion opened up the mentarch corpse research option. I started researching the corpse, and then went to my base stores. I was able to sell the captured mentarch, alive. 
 

Schrodinger's mentarch! Both alive and dead!

Thanks for the bug report! I might be wrong but iirc this isn't necessarily a bug but more of a temporary solution to allow captured mentarchs to be used for corpse research as we didn't want to disincentivize people from capturing aliens instead of killing them (as capturing is a bit harder than killing). I will double check it with Chris though as I might be wrong, it's been a while since this change was made!

[[5.38 stable - tactical] 2 same crash site maps in a row]

23 hours ago, Skitso said:

I don't want to sound diificult, but why isn't the game picking the least used map on the second crash site then? I mean if you have such a system implemented, shouldn't the map that was played just 10 minutes ago be diaregarded from the random map pool?

Edit: but yeah, as you said, it's a rare thing and if it needs lots of work to fix it, I'm sure you have more pressing issues to work on.

What most likely happened on the second crash site map was that the dockyard maps had an equal amount of times used, which meant the second crash site map got randomized, it was just a bit of bad RNG that it ended up choosing the same map.

Map 1 - 34
Map 2 - 34
Map 3 - 33 + 1(from the first crash site) = 34

so now it randomizes for the second crash site and it just so happened it chose map 3 again. We could add a way to make sure that the last chosen map doesn't get picked again, but again two consecutive maps in the same biome shouldn't be happening often, and even then there's only a 1/3 chance of it happening.

[[5.38 stable - tactical] 2 same crash site maps in a row]

On 6/30/2025 at 11:26 PM, Skitso said:

ok, here you go. There's a save before the first crash site (geoscape), a save from the last turn of the first crash site (tactical), a save just before the second crash site (geoscape) and a save from the first turn of the second crash site. (tactical). Hope this helps.

user_before_first_destroyer-2.json 523.96 kB · 0 downloads user_last_turn_of_first_destroyer-3.json 2.68 MB · 0 downloads user_before_second_destroyer-4.json 510.61 kB · 0 downloads user_first_turn_of_secord_destroyer-5.json 2.59 MB · 0 downloads

Thanks! Appreciate you going through the trouble to find the saves. I tested it and yeah it's basically just the randomisation of the maps causing the same map to appear twice (the game picking the least used map, then randomizing the next one). We won't make any changes for now as this should be a relatively rare thing, but I'll take note of this just in case this case gets brought up again (which might mean it's happening more frequently that it should)

[Crashed]

14 hours ago, Angl0saxon1961 said:

bug_report_2025-07-02-18h37_wn_5.38.1_unhandled_exception_0.zip 8.47 MB · 0 downloads crash_info.html 1007 B · 0 downloads crash_info.json 660 B · 0 downloads

Noticed that you've accidentally made a duplicate post, but we've basically made a bunch of fixes that should prevent stuff like this from happening again once the next patch (5.39) comes out.

[Crashed]

14 hours ago, Angl0saxon1961 said:

bug_report_2025-07-02-18h37_wn_5.38.1_unhandled_exception_0.zip 8.47 MB · 0 downloads crash_info.html 1007 B · 0 downloads crash_info.json 660 B · 0 downloads

Thanks for the report! We've made a bunch of safeguards that should prevent crashes like these happening once 5.39 is out. Said patch should be hopefully out today, if not before this week ends.

[[5.38 stable - tactical] 2 same crash site maps in a row]

On 6/29/2025 at 2:42 PM, Skitso said:

I shot 2 destroyers down back to back and both generated same crash site maps. Are there even more than 1 dock map for destroyers available currently, or is there a bug?  (also, why I'm not surprised both were against sebillians? ;))

auto_groundcombat_turn_1_start-120.json 2.59 MB · 0 downloads

Hey Skitso, thanks as always for the reports! Do you still have the geoscape save for this? Ideally if you have both saves before and after the UFOs were shot down, that'd be great.

As for the sebillian crew thing, we're changing a bunch of stuff for milestone 6, but basically the the first scout spawns a guaranteed mantid crew while the first destroyer is guaranteed to be a sebillian spawn, we're changing some of those guaranteed ufo crew spawns (not sure if we're changing the first scout ufo, but the first destroyer will be changed) so that should help with the crew spawning the same alien type all the time.

I've tested this a bit as well on 5.28 and 27 to make sure and was able to get a psyon ufo crew on both cases in around the first 5 ufos (scouts and destroyers), so I think it should be working properly. Was this not the case on your playthrough?

EDIT: Took a look at the dockyard maps(there are currently 3 for the small crash site per biome) and it looks like it was setup correctly. What most likely happened here is that the game picked the least used map for said biome and then randomized the next crash site map(if the maps were all used the same amount of times, it will randomize the next one) which coincidentally gave the same map.