Jump to content
Chris

Xenonauts-2 Closed Beta Build V8 Released! (Experimental Branch)

Recommended Posts

Closed Beta Build V8 has now been released on Steam and GOG. Note that this build is only available on our Experimental branch so you'll need to switch over to get this update (instructions on how to do that here). This build is also not being released on Xsolla - all Xsolla backers should now have a Steam or GOG key. If not, please let us know and we'll look into why.

This build includes some significant changes to the way personnel and aircraft are managed, but most of the associated gameplay changes will be arriving in the next build. Please give it a test and let us know whether you can spot any bugs; V9 isn't far away and we're hoping it'll be a major upgrade in terms of gameplay so it'd be nice to fix some of the stability issues beforehand!

Key Features:

  • Multiple Dropship Support: this is the headline feature of V8 and is explained in full below, but players can now purchase or construct additional dropships and the UI is now present to manage soldier assignment to different dropships. The Armory screen now loads straight into the Soldier Equip screen and the dropship arrangement is done on the Aircraft screen.
  • Base Personnel Auto-Assignment: any free space in the lab / workshop is now automatically filled from unassigned scientists / engineers, so manual assignment is no longer necessary for these buildings.
    • Although the functionality is not currently used much, these staff can still be assigned to other buildings (e.g. a Medical Room may need scientists to operate) which do still require manual staff assignment. These manual assignments take priority over auto-assignment, so putting a Scientist in a Medical Room removes them from the pool of workers that are used to fill available Lab slots.
  • Local Forces / Civilian Spawning: we've finished up the system that governs the number of civilians and local forces that spawn on any given map, and manages their loadouts. This is kinda complex because local forces look different and have different equipment based on the biome, must support loadout randomisation (e.g. Terror mission soldiers have a mix of rifles and LMGs) and these loadouts can also change over time (e.g. they eventually get Laser weapons). We've still got to work through some teething issues in the setup of the assets but the code side of this job is now done.

Multiple Dropship Support: This is actually a whole host of changes that together allow the player to operate additional dropships and assign soldiers between them. The new UI panels are pretty ugly, but that's because we're reskinning the UI for V9 and I didn't want to spend much time making it look good when it's all going to be reworked anyway!

  • You can buy starting dropships and interceptors by visiting an empty Hangar in the Aircraft screen.
  • It is now also possible to construct new aircraft via an engineering project (although the advanced aircraft don't arrive until V9).
  • The Armory Screen now loads directly into what we called the Soldier Equip screen in X1. The soldier browser element in the bottom right has returned, as has the Assignment dropdown on the soldier info panel.
  • Arranging your soldiers in the dropship is now done on the Aircraft screen, again like in X1.
  • The Soldiers / Personnel screen now has dropdowns that allow you to change both the soldier's dropship assignment and their role loadout. Soldier roles are now stored on the soldier rather than the dropship slot, so soldiers retain their role in a persistent manner.
  • You can now view soldiers that are not assigned to dropships, however they cannot be given items unless they are in a dropship.

Visual:

  • Animation issues for the combat shield should now be fixed.
  • Soldier HPs no longer display decimals on the Personnel screen.
  • Soldier icons no longer slide into position when you access the Armory screen.
  • Fixed aircraft icons on the Geoscape continually resizing a tiny amount / flickering as they moved.

Balance / Gameplay:

  • Training system has been disabled as part of an upcoming rework of the training system.
  • Some additional strategic loss conditions have been added to the game:
    • If the primary Xenonaut base is destroyed by aliens (the first one you place)
    • If X Geoscape regions are lost to the aliens (I believe this is 4 regions at the moment).
    • If the organisation has negative funds immediately after the funding report for two months in a row.
    • If the player fails the ENDGAME mission.
  • The harvester / cruiser / battleship maps have been re-exported so they contain the new dropship and you don't have soldiers stuck in the tail section any more.
  • Teleporters on the Cruiser UFO maps should now work properly.
  • Composite Armour now has 60% resistances instead of 35% resistances.
  • The Energy Blades dropped by Wraith Officers now appear in the base stores and can be sold.
  • Removed a random +8TU flat cost on the Laser Rifle nomal shot.

Bugfixes:

  • Ground combat autosaves should now be functional again.
  • Alien base missions will now find the correct maps.
  • Fixed an issue where Geoscape intercept paths would be nonsensical if an interceptor was trying to intercept an aggressive UFO like a Fighter that was also trying to intercept it.
  • Fixed a hidden movement loop.
  • Fixed a bug where bullets could end up stuck hovering in midair after missing the ground.
  • Fixed a bug where suppression (and "miss" labels) were sometimes being triggered on the shooting unit.

Although it is close to being complete enough to include in the public builds, the air combat sadly did not make it into V8. We are therefore aiming to bring V9 out more quickly than normal so we can get both the air combat and the first stage of the UI revamp into the hands of players as soon as possible. I'm not making any firm promises here but if all goes well then V9 will be with you in less than two weeks, perhaps on Tuesday 15th October.

We'll still likely release at least one hotfix for the build though, so as always please do report any issues you encounter!

Share this post


Link to post
Share on other sites

One small request for the tech team. Would it be possible to change the JSON serialization for saved games to a pretty-printed format with linebreaks? Currently it's just one ginormous line, which means that many editors have trouble working with the file, and it's also harder to manually edit stuff due to it not being pretty-printed.

Share this post


Link to post
Share on other sites
23 hours ago, Solver said:

One small request for the tech team. Would it be possible to change the JSON serialization for saved games to a pretty-printed format with linebreaks? Currently it's just one ginormous line, which means that many editors have trouble working with the file, and it's also harder to manually edit stuff due to it not being pretty-printed.

The problem is that the file is already gigantic (relatively speaking) and pretty printing increases the size even more given how / what we serialize. 
(The pretty print doesn't really concern itself with speed either. For the size we've got an optimization pass planned)
 
If you're Windows based I suggest taking a look at Notepad++ with a JSON formatting plugin which works well even with very large files. (https://github.com/sunjw/jstoolnpphttps://sourceforge.net/projects/jsminnpp/ or https://sourceforge.net/projects/nppjsonviewer/)

Share this post


Link to post
Share on other sites

I'm on Linux, and vim can deal with the save files, but it doesn't make that very convenient.

If you're not going to pretty-print, why not just compress the whole thing? With data like what you have, a quick compression is sure to yield at least a 90% ratio. Yes, you could say it's not then human-editable save files, but frankly I would say the current ones aren't anyway. When you need a special editor or plugins to open the file properly, it means at least some level of tech skill is necessary, and in that case you might as well ask the users to decompress the file first.

If I change a save file so it's prettified, should I expect the game to load it properly still?

Share this post


Link to post
Share on other sites
29 minutes ago, Solver said:

I'm on Linux, and vim can deal with the save files, but it doesn't make that very convenient.

If you're not going to pretty-print, why not just compress the whole thing? With data like what you have, a quick compression is sure to yield at least a 90% ratio. Yes, you could say it's not then human-editable save files, but frankly I would say the current ones aren't anyway. When you need a special editor or plugins to open the file properly, it means at least some level of tech skill is necessary, and in that case you might as well ask the users to decompress the file first.

If I change a save file so it's prettified, should I expect the game to load it properly still?

It's simply a matter of time and manpower but definitely planned - it's just not a priority at the moment. 
You are right in the quick win w.r.t. compression, although we need to do that on part of the file so we can support the Save/Load elements' partial loading. There's a bunch of other optimizations planned as well to do with aliasing the common patterns, etc.

I assumed Windows because I didn't think that on Linux you would have issue pretty-print formatting it efficiently. 
It might be that the Save/Load Element will give issue as it's only partially loading files and scanning for (extremely simple) terminator patterns, but the underlying load system has no issue with formatted JSON.

Share this post


Link to post
Share on other sites

Alright. I can say that simply 

python -m json.tool save.json > save-pretty.json

works well on saves to get them into a readable format (quadrupling the file size!) for some quick edits. If those prove difficult to load, I should be able to get it back into the ugly format with another Python one-liner.

  • Like 1

Share this post


Link to post
Share on other sites
On 10/8/2019 at 12:23 PM, Solver said:

Alright. I can say that simply 


python -m json.tool save.json > save-pretty.json

works well on saves to get them into a readable format (quadrupling the file size!) for some quick edits. If those prove difficult to load, I should be able to get it back into the ugly format with another Python one-liner.

Yeah, and given the file-size problem we have already (until I get to the optimization), you can understand why I really didn't want to have it pretty-print by default! :')

Share this post


Link to post
Share on other sites

Speaking as someone who is just barely technically competent to edit the JSON files as they are (I have gotten very good at reading one ginormous line of text), please don't compress them? I would have never been able to demonstrate the edits I have done in previous versions as I would never have been able to work out how to uncompress the files.

Share this post


Link to post
Share on other sites

You've been editing weapon files though. Those are possible to edit as one line, if inconvenient, without extra knowledge.

Save game files are different. The one line is so long that you need an advanced editor or editor plugins to even be able to load and save the file, and if you can figure that out, then you can also unzip a file.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×