Chris

Yeah, so this (or something very much like it) is something else we're considering - but then we do run the risk of creating the problem you outlined in your previous, in which almost every mission type could potentially have a timer and then they all start to feel the same.

I wouldn't dismiss it as "fear of Steam refunds", because hiding away your new content so people only see it after playing for an hour or two just means a decent chunk of our playerbase might get bored and switch the game off before they ever reach that point due to feeling like they've just seen it all before. Sure, it's likely to cause Steam refunds and negative Steam reviews, and they're a bad thing - but fundamentally people not enjoying the game is a negative in itself. That's what all the design decisions we make on the project are ultimately trying to prevent. There are other reasons too - it's one of the few mission types containing aliens that doesn't involve a UFO (which would progress the player down the tech tree too fast), and it's more engaging than the current Alien Research Team mission because it does have those special rules with the abduction tubes. Seems to me like a pretty natural fit for that point in the game, really!

Always happy to consider other people's opinions but it was never particularly difficult to get enough Abduction tubes to win the mission, in my experience. The real question was always "how many extra can you get?" which would still be the case now. Indeed, in an ideal world we'd provide a Panic reduction for each surviving civilian (as well as the Alloys from the tube itself) so there's a definite reason to try and rescue as many civilians as possible. The reason for the change is having a hard loss condition in the second mission the player encounters is perhaps a bit harsh, but at the same time we do want to show one of the new mission types early to clearly signal that the game isn't just Xenonauts 1 with nicer graphics.

Just giving this thread a little bump, as I had it hidden for a couple of days!

Yeah, I'll set up a dedicated sub-forum / discord channel for the participants and go into more technical details if we get enough interest, but the standalone mod editor is intended to be a simple tool that allows people to get started on changing the game without requiring any serious technical knowledge of setup time. I'm hoping that producing it won't actually be that demanding on the people helping out. I must admit we'd not actually really considered the concept of a pure-code mod. But that's certainly something we can discuss as part of the wider community tools discussion if the initial standalone editor doesn't prove too challenging.

Thanks for the replies. I'm going to be linking this post in our next Steam update so I'll follow up with people towards the end of the week, once that has gone out. Mapping is not part of the initial scope of this mod tools, no - it's too tightly integrated with Unity to be something we can do in a standalone editor. But if the simpler standalone editor is successful, the next step would likey be a more powerful (but more complex) Unity-based mod editor, as this will likely be required to add new art assets to the game anyway. And a community map editor tool could potentially be part of that.

Xenonauts 2 has been designed from the very start of development to support modding, and we're now approaching the point where our official mod loader is complete. The last remaining task then becomes the creation of a "modding editor" that will allow players to easily access and edit the information held in the game's JSON files (which are already exposed in the game directories, but are difficult to read / edit with a text editor). The underlying work on this tool has already been done by the development team, and what we now need is a GUI to sit on top of it. Specifically, we need to create a standalone cross-platform GUI that calls into the serialization and asset management tools we've made. The bulk of the work here is going to be creating this frontend and figuring out a visual design that can display all the required information to modders in a sensible way. This is something the development team is planning to do, but it's nowhere near the top of our list of priorities - we need to focus on getting the entire campaign playable first, for example. However we've already seen several people attempting to hack modding support into the game, so we were wondering if any community members with a background in programming might be interested in collaborating with us (and aspiring modders) on the creation of this tool. We'd be more than willing to support any such efforts with documentation and technical assistance, and I feel like it could potentially be a win for everyone - the developers can focus on the game, and the community would probably get more user-friendly mod tools (and get them sooner) than if the developers made them. If you are interested in helping out, please just post a reply in this thread or DM me / email me. And if nobody is interested, that's also fine - it was just a thought. As I said, we will get around to making them ourselves, we just need to focus on other things first.

This is a stability update for the default Steam / GOG / Epic branches that contains all the fixes from the 1.32 versions which have been tested on the Experimental branch. Usability Improvements: Quantity buttons in various parts of the game (Base Stores, Engineering, etc) now increase in quantity automatically if you press and hold them, rather than you having to click them every time. Clicking the soldier minitabs at the top of the screen now correctly shows the position of the unit, even if they are unconscious. Balance Changes: Melee weapons no longer ignore combat shields. Updated the move cost of several types of movement so soldiers choose more logical paths through the map: Opening doors now costs 4TU rather than 3TU Vaulting costs 5TU rather than 4TU All jetpack movement costs +1TU per tile, so units will land and walk rather than flying along at ground level Alenium Generator upgrade project now costs $200k instead of $500k The construction time of all upgraded base structures is now the same as the basic version of the structure. Bugfixes / Other Changes: Fixed a rare crash that could occur if you tried to overwrite an existing save game. Fixed a crash that could occur when rebinding keys in a non-English language. Fixed another crash that could occur when you tried to initiate air combat if you had merged two airborne squadrons together using the Launch Aircraft panel. Fixed Flashbangs (and other types of grenade) sometimes incorrectly causing suppression through floors / ceilings. Fixed an issue we introduced recently where Ctrl "force fire" for weapons would frequently not respond to mouse clicks. Fixed rotating when shooting incorrectly not costing TU on Veteran and Commander difficulties. Fixed soldiers not training Strength in the Training Room. Fixed upgrading a building reseting the construction time of any buildings of that type currently under construction. Fixed soldier inventory Time Unit move costs not working properly. This system has now been rewritten so it should now always provide the correct cost (let us know if not). Fixed an ordering issue when tabbing through soldiers in the tactical combat which would place soldier 10 at the very end of the soldier list. Fixed the "stores full" check that blocks engineering work not triggering correctly if you built or demolished a Storeroom. It will now detect both of these actions correctly. Fixed interactive consoles on Cleaner missions showing the gold interactive shader after loading a save, even if they'd already been interacted with. Destroyed bases no longer count towards the base limit, which means players are no longer inexplicably blocked from building a sixth base if they lose one during a campaign.

This update is also only accessible by switching to our Experimental branches (instructions on how to do so here) - although note they have slower load times and worse performance than normal builds due to the extra logging they contain! If all goes well this will be the last significant update for Milestone 1, as the C4 crash fix was the last of the critical bugs we had on our list to address. All future fixes and performance improvements will instead be rolled into Milestone 2 which we'll launch onto the Experimental branches in the coming weeks. Changelog: Fixed a crash that would occur if you try to detonate C4 that had been placed in a saved game. Fixed an issue in the tutorial where a soldier did not have enough TU to fire their shotgun a second time. Fixed an issue where missiles would sometimes not fire in air combat if you had activated the Afterburner at the start of the battle. Game no longer creates an Iron Man save when exiting the game (even if you're not playing Iron Man). Swapping weapons on the Soldier Equip screen now also swaps out the associated ammo for these weapons. Tooltips are now dismissed when you start dragging an item (e.g. on the soldier equip screen). Camera now correctly moves up / down when watching an AI unit climbing a ladder during the alien turn. Quantum Array now correctly shows the additional information on visible UFOs immediately after loading a save. Units attempting to shoot adjacent walls should no longer contort themselves like a pretzel to do so. Cleaner Accelerated Rifle no longer drops to 0% Accuracy as soon as it goes beyond maximum range, unlike other weapons.

Milestone 2 is not yet ready for public consumption, but it is available in a rough form for people who want to help us experiment with a few new mechanics. To access the build, enter the branch password xenonautsproto and switch to the Prototype branch. However, please read the whole post before doing so! We're testing out a few new mechanics that we want to get people's opinions about before we commit to updating the UI and getting new artwork done etc. I'll spend a bit more time than normal explaining the logic behind the design decisions here, as that will hopefully allow people to tell us whether they think the changes achieve their intended goals or not. Panic: One of the biggest problems with Milestone 1 is that there's no easy way to reduce Panic in a specific region, which means that on harder difficulty settings you need to build additional bases and aircraft as quickly as possible otherwise you'll quickly reach the point where you start losing regions. Panic will now decrease by 10% in each region at the end of each month. However, the Panic reduction for shooting down UFOs has been halved from -2 to -1. This means that Panic generated from Cleaner activity or Alien Bases or failed tactical missions will dissipate more quickly, while making interceptor coverage *slightly* less beneficial (although it's still pretty strong). Note that due to a bug this is happening before the region loss check (which means you need ~110 Panic to lose a region) but we'll change this if the change is popular. Also, this change only solves half of the problem in Milestone 1, as the player still lacks a targeted way to reduce Panic in a region. However I think it's a useful first step. Funding: Funding is no longer dependent on Panic level. A region will grant you full funding (which increases as you progress down the storyline) unless you lose the region, in which case funding will fall to zero. This change was made to support some other experimental changes I've not put in this build. But it means that building a base in a region doesn't increase income as much. Previously you'd get extra funds from shooting down UFOs and completing the crash sites, but then also gain extra funding from the fact keeping Panic low in the region granted extra funding. This hopefully means it's less essential to rush to cover the whole world with your planes as soon as possible. Mission Order: The game now starts with a Cleaner deathmatch mission, which is then followed by a Secton Abduction site. The plan is to make the opening Cleaner mission a bit more exciting - potentially even a continuation of the base defence mission from the tutorial where you clear the base of the attacking Cleaners, then evacuate to your new base. But the goal is to add an extra Cleaner mission and use that as a way to introduce them better at the start of the game. We've then slightly slowed down the progression over the next three months, and in particular we've moved the Cleaner Intel Hub mission back a couple of weeks so it comes after the first UFO crash site. We're open to ideas about how we can make the Cleaner mission sequence a bit more interesting, as it seems like not everyone likes the Cleaner Network idea where the main way to advance is just to capture more Cleaner Data on missions. Feel free to throw ideas out on this topic. Tech Tree / Item Upgrades: One of the recurring discussion points on the forums is whether Accelerated Weapons are a "trap" or not, and I've attemped to make their purpose a bit more clear through some tech tree changes. Accelerated weapons are now an upgrade for Ballistic weapons - i.e. a one-off project that permanently upgrades all Ballistic weapons to be Accelerated weapons. The same is also now true for the Warden Armour, which is now an upgrade for Defender Armour which increases the protection offered. As such, I've moved Guardian Armour forward in the tech tree so it can be unlocked off Scout UFOs rather than Destroyers. This means the player is given the choice of two relatively quick and cheap upgrades at the start of the game, but are also given the option to research more advanced weapons (lasers) and armour (Guardian) within the first month. But you're also presented the option to pursue the story research, which increases your funding - so hopefully this presents the player some interesting choices in the early game to try different strategies. To stop this being overwhelming, I've moved the Dragonfly and Phantom to be unlocked off Destroyers rather than Scouts. Finally, I've tried to expand the item upgrade options. There's a project that allows you to reduce the weight of Defender Armour, and Laser Weapons now have two upgrades that provide Recharging Ammo and increased Damage respectively. Guardian Armour also has an upgrade that increases the protection it offers which is unlocked from Destroyers. I'd be interested to know whether people like these increased upgrade options. Soldier Module System: I've removed all the existing soldier "modules" which could be placed in the soldier tactical vest and these are now replaced by the following set up: Extra Armour: all armour now weighs less and offers less protection, but there's a Heavy Armour toggle in the bottom right that will increase protection at the cost of extra weight. This is designed to make the armour more flexible rather than "heavy" armour like the Guardian being useless for low-Strength soldiers. The only gameplay consideration is "can the soldier carry the extra weight?" Armour Module: you can now choose a single module from a second dropdown below the existing Armour dropdown. At the start you can either choose from a rebreather that provides smoke protection, a +3 Acc boost or a +5 Bravery boost, however almost all the modules from Milestone 1 reappear as you progress down the tech tree. Obviously the question is simply which one module you choose to use. Jetpack: as previously, the jetpack is another toggled option. I just don't think it's useful enough that anyone would ever use it if we made it part of the Armour Module list. My question here is simple - do you prefer this to the module system in Milestone 1 where your inventory was full of modules? There's scope to add extra artwork and improve the UI if people like the basic idea, but it'd be nice to know people's initial impression of the changes. However, from a design perspective there's some overlap with the Item Upgrade system above. Some of the modules could potentially be folded into upgrades for the armour (particularly the Jetpack) - although then the danger is that you have soldiers that can do everything, and once your armour is upgraded you no longer have to choose between say a +TU boost, or a +ACC boost, or health regeneration, etc. Let me know your thoughts on this setup and where you'd like to see the design go. Incomplete Balance Changes: These are further balance changes I expect to make prior to Milestone 2 reaching our main Steam branches: Panic will be checked for region loss before the -10% monthly decrease occurs. Abduction missions will not end when the timer expires. Instead, the tubes will be present for X turns before teleporting away, and you get rewards for each one you open. However all the aliens must still be eliminated for victory. Starting Cleaner mission will probably happen immediately after beginning the game, before you go to strategy (rather than being a mission you do on day 2 or so).

So the intended behaviour has always been that if you update the equipment in a role, it will automatically update the equipment for all other soldiers that share that role UNLESS their loadout did not match the previous loadout (i.e. if their loadout was in some way unique). Is that what was happening here? Or is it working incorrectly?

This update is also only accessible by switching to our Experimental branches (instructions on how to do so here) - although note they have slower load times and worse performance than normal builds due to the extra logging they contain! Changelog: Fixed combat shields not offering any protection. Fixed flashbangs sometimes causing suppression through floors / ceilings.

August has been a busy month for us here at Goldhawk. Although it's not been quite as crazy as the two weeks immediately after our Early Access launch, the last four weeks have been very intense in a different way. Expanding the Team: This is mostly because the development team has expanded significantly over the last couple of weeks. When we launched into Early Access the team here at Goldhawk was only three full-time employees (one designer and two programmers) and there's just not enough hours in the day for a team that small to run a project of this size effectively, even if you're all working evenings and weekends. In practice this has resulted in a situation where we've collected a lot of useful gameplay improvements / suggestions and bug reports from our community, but we've only been able to tackle the most urgent of those issues. This is frustrating for both the team and for the players, as the other tasks are still important things we want to fix - they're just not as important as the stuff we actually have been fixing. As the only way to make a serious dent in the task lists was to get more manpower, this month we hired one additional full-time programmer (who is actually an old friend that worked with us on the original Xenonauts) and two more highly-experienced part-time programmers. Many thanks to anyone that applied for a position on the team after reading our last update - we really appreciated seeing so many enthusiastic people reaching out to us! Furthermore, we've also hired an additional full-time level designer / QA assistant, and two part-time designers who will be helping with the level design and game design / balancing respectively. Our goal is to respond to all community bug reports within one working day, to start delivering new maps with each major update, and generally to be able to respond better to player feedback and suggestions. I've been spread WAY too thin over the past few months. Improving the Game: We've continued to improve the game over the past four weeks, adding community-requested features like the option to modify the length of mission timers and the ability to break apart / merge together airborne squadrons, plus successful fixes for the memory leaks in the game and all sorts of other gameplay bugfixes. However, work on the game has been slower than normal due to all the recruitment we've been doing - if you're a small team, it takes a lot of time to be reading through CVs and code samples / portfolios to evaluate applicants, it takes time to interview candidates, and it takes time to get employment contracts signed. And most of all, it takes time to get people set up on the project and get them up to speed on our huge codebase or to teach them how to use a complex tool like our level editor. Time spent on this will quickly pay off, but it does slow things down in the short term. This has affected Milestone 2 most badly. We're now hoping to release this onto the Experimental branches at the end of next week or the beginning of the week after. I'll also mention the loading times briefly here, as I know they are important to many people. We took a look at them earlier this month but it quickly became clear any serious attempts to speed these up would change the structure of the saves and therefore break save game compatibility. As a result, we've pushed this work back to Milestone 2 (as each new Milestone build is likely to break save games anyway, due to the significant balance changes). Community Mod Tools: One thing we did spend a bit of time on this month is the mod loader and Steam Workshop integration, which is now nearly complete. However, we've not yet started work on the official mod creation tools and it may be a few months until we do given our focus is currently on upgrading the core game. If anyone is potentially interested in helping design a GUI that hooks into our code so modders can more easily edit the game files, please take a look at this thread! Conclusion: That's it for this month's announcement. We've made decent progress but most of our time this month has been spent expanding the team so we can make faster progress in future. Thanks for reading, everyone!

Thanks. I'll have a chat with the coders about this in the next couple of hours and let you know if we need any more information from you about it. I'm guessing the save game doesn't get created? The last logs were talking about an issue with the save game C:/Users/Max/Documents/My Games/Xenonauts 2/Saves/silver_queen/user_day_19_crash_site_manual_save-7.json EDIT - also, how many files are actually in your save game directory? are there files for any of the "disappeared" save games from older versions?

This update is also only accessible by switching to our Experimental branches (instructions on how to do so here) - although note they have slower load times and worse performance than normal builds due to the extra logging they contain! This is a small patch for 1.32 that fixes a couple of bugs played have encountered. Changelog: We've removed the "swapping weapons swaps out the ammo" feature on the soldier equip screen, as that was causing issues where weapons were not swapping correctly. That will return in the next patch once we've had a chance to correct that issue. Fixed another crash that could occur when you tried to initiate air combat if you had merged two airborne squadrons together using the Launch Aircraft panel. Quantity buttons in various parts of the game (Base Stores, Engineering, etc) now increase in quantity automatically if you press and hold them, rather than you having to click them every time.

This is a little surprising, to be honest. The vehicle explosions only inflict 60 damage (except the snowmobiles which did 100 until I just fixed that) - which is quite a bit, but the Exosuit should provide good protection against it. The problem is that if it reduces the unit to 0 HP then they're gibbed, because it is explosive damage. So a unit on 5HP would be gibbed if they took even 6HP of explosive damage once their armour was taken into account. But the Exosuit offers 35HP of protection so a 61HP soldier shouldn't be killed by an exploding pickup. A snowmobile would have done it, but if the pickup is doing it then that's a bit concerning.

Hi - this is a really strange bug then. I've just downloaded the game on GOG and it doesn't seem to crash either on the Experimental branch or the standard branch for me - and I tested three times on the standard branch. Does it crash every time for you on the normal branch? The sequence of actions during the enemy turn should be slightly different each time and I was wondering if that made a difference? Anyway, at least you can continue your playthrough by playing on the Experimental branch. You can just take a save after the mission and then switch back to the normal branch. But it's hard for us to fix the crash without getting the logs from the Experimental branch where the game isn't crashing, so I'm not sure there's anything we can do here. But if the issue turns up again please let us know!

Hi - thanks for the bug report, sorry to hear you're having issues. Would you mind providing a save game for us to check the issue in? I can't reproduce it in a fresh campaign. The save game folder is /My Documents/My Games/Xenonauts 2/Saves/ and it'd be helpful to get a save before and after the dropship is moved, if possible.

This update is also only accessible by switching to our Experimental branches (instructions on how to do so here) - although note they have slower load times and worse performance than normal builds due to the extra logging they contain! Usability Improvements: On the Soldier Equip screen, if you drag a new weapon on top of an existing weapon, the game will automatically swap out all ammo clips for the previous weapon with those used by the new weapon. Clicking the soldier minitabs at the top of the screen now correctly shows the position of the unit, even if they are unconscious. Balance Changes: Melee weapons no longer ignore combat shields. Updated the move cost of several types of movement so soldiers choose more logical paths through the map: Opening doors now costs 4TU rather than 3TU Vaulting costs 5TU rather than 4TU All jetpack movement costs +1TU per tile, so units will land and walk rather than flying along at ground level Alenium Generator upgrade project now costs $200k instead of $500k The construction time of all upgraded base structures is now the same as the basic version of the structure. Bugfixes / Other Changes: Fixed a rare crash that could occur if you tried to overwrite an existing save game. Fixed a crash that could occur when rebinding keys in a non-English language. Fixed an issue we introduced recently where Ctrl "force fire" for weapons would frequently not respond to mouse clicks. Fixed rotating when shooting incorrectly not costing TU on Veteran and Commander difficulties. Fixed soldiers not training Strength in the Training Room. Fixed upgrading a building reseting the construction time of any buildings of that type currently under construction. Fixed soldier inventory Time Unit move costs not working properly. This system has now been rewritten so it should now always provide the correct cost (let us know if not). Fixed an ordering issue when tabbing through soldiers in the tactical combat which would place soldier 10 at the very end of the soldier list. Fixed the "stores full" check that blocks engineering work not triggering correctly if you built or demolished a Storeroom. It will now detect both of these actions correctly. Destroyed bases no longer count towards the base limit, which means players are no longer inexplicably blocked from building a sixth base if they lose one during a campaign. Destroyed bases no longer show their radar range on the Geoscape once the Radar is upgraded. Alenium and Alloys are no longer listed twice in the recovered items at the end of missions. Soldier inventory screen in tactical combat now shows Max HP as the modified max HP, not the unmodified HP (so it now shows the correct value if you go into battle with a wounded soldier). Fixed dead MARS units showing a full health bar on the post-mission debrief screen. Fixed the empty UOO-1 research popup appearing at day 300. Laser Recharge engineering project no longer has a tooltip.

Thanks. Apologies for the slow reply, appreciate you giving us your thoughts!

@Oskimi thanks for your thoughts, I've given them all a read now!

The Wraith enemies are capable of teleporting in Xenonauts 1, so it could have been one of them?

Ah, yeah, thanks. We'll get that fixed.

Thanks for the report. I can't reproduce this from the save file you provided though (even if I revert back to 1.30). Can you still reproduce it? If so, would you mind switching to the Experimental branch and grabbing the logs?

Every new Milestone will break saves. All the current updates are all for Milestone 1, but as soon as Milestone 2 arrives it'll break saves (although you can continue playing Milestone 1 for a while on the legacy branches if you want).