Kouki

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

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!

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

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)

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

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!

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!

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.

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

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!

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

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.

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!

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.

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)

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.

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.

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.

Hello there, thanks for the bug report! Can you send us the log file so we can see why the game is not loading properly? You can usually find this by going to Documents\My Games\Xenonauts 2\Logs, you should see a .log file named "output" (note that this is different from the files named "output.log". Can you attach said file here so we can give it a look?

Thanks for taking the time to post a bug report! Yeah, this map has a spawn node that was misplaced inside the battleship UFO's hull. We've made a fix for this but it won't be out until milestone 6. As for the game having no sound, does restarting the game restore audio? And is this the first time this happened for you?

Thanks for the response (and checking other people's playthrough as well). Not sure why this is happening as the fixes worked halfway on my playthrough but there definitely is something going on, will bring this up with the rest of the team!

Thanks, not sure why this is spawning inside the hull, will bring this up with the rest of the team and we'll see what's going on

Thanks for the report, we'll look into this!

Yeah, we've discovered this one as well (or it was reported from the community by someone else, can't exactly remember), we've made a fix for this but it won't be out until milestone 6.

That does make sense, although this is a bit of a low priority issue, will bring this up with Chris though the fix might take quite a while as again, it's a rather low priority one. Thanks for the bug report!