Hey guys, these are the patch notes for the upcoming update! We'll set the update live on the beta branch during the next 16 hours.

PLEASE NOTE: The beta branch is for testing experimental changes and for finding and fixing errors. Use at your own risk!

WARNING: The current version is INCOMPATIBLE with your latest save files. WE WILL ADD BACKWARDS COMPATIBILITY to existing saves during the week to ensure that you can use your old saves. You will be able to use your old saves once the update is live on the default branch.

These are preliminary patchnotes and might not contain all changes that will have been made once the update will be live on the default branch.

• Players can now found alliances
• Invite other players to join your alliance
• Alliances work like their own factions: They have money, resources and an inventory
• Players can be assigned ranks, defining permissions in the alliance
• All alliance members are visible to all other alliance members on the map
• Alliance members share all information on the galaxy map
• When flying an alliance ship, the player does everything he does in the name of his alliance

• Alliance ships can now be flown by multiple players
• Added seat management for crafts to manage who is able to do what (steering, firing, etc)

"We'll be adding some more means for better control of which sectors will actually get updated on multiplayer servers. For now, sectors with lots of stuff will have a higher priority."

• Sectors with player and alliance content are updated while the player is not inside the sector
• Default amount of updated sectors per player on multiplayer is 6 (the sector the player is in, plus 5)
• This value can be configured in the server.ini settings and will be a lot higher for singleplayer
• If a player has property in more than 6 sectors, this happens:
• Each sector will have a priority score
• The 5 sectors with the highest scores will be updated
• The score in the sectors is 3 for each player station, plus 1 for each player ship

• Steam Workshop integration for ship and station models is complete
• Saved ship plans can now be uploaded to the Steam Workshop
• Subscribe to ship plans on the Steam Workshop

• Added a new flight recorder block
• Flight recorders will mark the death location of the ship on the map
• Flight recorders will only work if they're *still on the ship* when the ship is destroyed
• Trading posts always have dedicated cargo storage
• Added licenses for stolen, dangerous and illegal cargo transportation
• Added multiple mirror planes in building mode
• Removed randomized building mode
• Implemented whole ship modification
• Scaling entire ships
• Upgrading the material of entire ships
• Rotating entire ships
• Added selective block modification
• All but one material or block type are faded out
• Added a search field on the galaxy map
• Turret factories sell a random, more expensive selection of the goods they require for building turrets
• New Turret: Pulse Cannon
• Pulse Cannons shoot ionized projectiles that have a very high chance of penetrating shields
• Added respawning of resource-asteroids in sectors with large asteroid fields (will only be in effect for new sectors)

"We're currently working on making shields less powerful, and one of the means to do that will be adding more weapons that are strong against shields, such as pulse cannons. But we also felt that plasma cannons didn't have the impact on shields that they were supposed to have, so we upped their damage to shields."

• Doubled shield damage of plasma guns

• Reduced darkness of window shadows
• Added a setting for limiting FPS
• Improved rendering performance in sectors with lots of wreckages

• Improved performance of inventory grid displayers
• Added filtering for inventory grid displayers
• Added favoriting of inventory items with right mouse
• Added marking of inventory items as trash with right mouse
• Tooltips are only drawn when mouse is not obstructed by other windows
• Improved borders of inventory items
• Added loading screen tips for various new features
• Added a button to sell all trash immediately
• Added chat message channels for sector, group, everybody (default) and alliance
• Added display of relative or total costs to saved ships window
• Improved handling of multiline text boxes
• Added a key for toggling strategy mode (default: F9)
• Added an option to disable toggling of strategy mode by zooming
• Added various tips about new or old features to the loading screen help
• Gate connections now have a different color than wormholes on the map
• Added a message when changing control scheme
• Improved german translation
• Added a textbox to quickly transfer lots of cargo and crew

"Most important changes here: Better performance on the server (memory and runtime) and improved savegame security."

• Crafts that were destroyed through database corruptions can be restored
• Players can be moved to other sectors, including ships (just rename the files if the names clash)
• Player & Alliance files are saved redundantly to avoid loss of data on file corruptions
• Improved performance when players log in
• Improved overall networking performance
• Improved overall memory performance using lazy initialization of collision data
• Improved performance of traders in sectors without players
• Added detailed output about script memory usage to /status command
• Sector content is now compressed before being sent, reducing traffic when changing sectors by 70%
• Server files are now compressed
• Implemented whitelisting of steam groups
• There's a separate file group-whitelist.txt in the server folder where you can add 64bit steam group ids that should be whitelisted

• Entity IDs are now 128bit UUIDs
• Script memory footprint reduced
• Scripts that are attached to the same object are loaded into the same lua VM, if possible, to reduce redundant data
• Added namespaces so scripts can be distinguished from each other and to avoid name collisions and functions getting overridden
• Scripts that have DIFFERENT namespaces will be loaded into the SAME lua VM, since name collisions aren't expected to happen
• Scripts that share the SAME namespace will be loaded into DIFFERENT lua VMs
• Scripts that have a namespace must have a comment '-- namespace NAMESPACE' where NAMESPACE is the script's namespace
• Scripts that have a namespace must have a namespace table with the same name as stated in the namespace comment
• Scripts that have a namespace comment must prefix all non-local functions and variables with their Namespace table (see scripts for more details on this)
• Scripts that have no namespace comment statement will always be loaded into different VMs (which is exactly the old model)
• It is STRONGLY recommended to modders that they rework their scripts to use namespaces to save memory performance!
• Lua VMs aren't set to invalid after a normal error, but still on fatal errors (exceptions)
• [Documentation] Fixed methods of inherited script classes not showing up in completion docs
• [Documentation] Fixed broken base classes when base gets a [client] or [server] extension
• CheckBox can be enabled and disabled
• CheckBox can be configured to have its box on the left or right side
• TextBox can have a background text
• Added a VanillaInventoryItem item that can be used for scripting inventory items
• Fixed an issue with infinite recursion in printTable()
• Added a PlanSelectionItem item that can be used in selection grids to display BlockPlans
• Added functions to access all plans that are saved locally or downloaded via the Steam Workshop
• Added Timer and Profiler classes
• Implemented API for async script calls [while theoretically functional, still highly experimental]

• Several small performance improvements all over the place
• Improved logging
• Reduced size of ship .xml files
• Player is placed in last craft upon login

"As usual, user bug reports are marked with [UBR]. Thanks everybody for helping with the game!"

• [UBR] Fixed extreme loading times due to too many inventory items
• [UBR] Fixed a crash that occurred often during instanced rendering (asteroids and such)
• [UBR] Fixed overflow of resources and money
• Resources and money are now 64bit integers, meaning they can go up to 9.223.372.036.854.775.808
• Overflowing is no longer possible
• Fixed player being placed in his drone on use of /teleport command
• [UBR] Fixed space bar not working sometimes in loading screen
• [UBR] Fixed a hang when holo blocks decay due to missing repair crew
• Fixed a (rare) player duplication issue
• Fixed a crash when destroying/deleting a station
• Fixed a crash when loading corrupt scripting values file
• Fixed trading posts not having any cargo storage
• Fixed a crash when loading an object with a script where the script file disappeared
• [UBR] Fixed smuggler's market not working when too many stolen goods are on the ship
• [UBR] Fixed a crash in patrol AI
• [UBR] Fixed a crash in loading screen
• [UBR] Fixed a crash when exiting the game while in strategy mode
• [UBR] Fixed a crash when loading templates.xml
• Fixed ships by faction on map not being saved/loaded correctly
• [UBR] Fixed quick menu buttons being clickable through the building inventory
• [UBR] Fixed keyboard and mouse up events not being registered in loading screens
• [UBR] StructuralIntegrity effect is now always visible on the correct ship
• Fixed translation of EnergyConsumer names
• Fixed mining systems always showing asteroids for all players in a sector

"Some things that still need fixing, that didn't make it into the update. They will be fixed during next week."

• Alliance sectors not being shared correctly on the map
• Notifications for picking up items for alliances

Hey guys, these are the patch notes for the upcoming update! We'll set the update live on the beta branch during the next 16 hours.

PLEASE NOTE: The beta branch is for testing experimental changes and for finding and fixing errors. Use at your own risk!

WARNING: The current version is INCOMPATIBLE with your latest save files. WE WILL ADD BACKWARDS COMPATIBILITY to existing saves during the week to ensure that you can use your old saves. You will be able to use your old saves once the update is live on the default branch.

These are preliminary patchnotes and might not contain all changes that will have been made once the update will be live on the default branch.

• Players can now found alliances
• Invite other players to join your alliance
• Alliances work like their own factions: They have money, resources and an inventory
• Players can be assigned ranks, defining permissions in the alliance
• All alliance members are visible to all other alliance members on the map
• Alliance members share all information on the galaxy map
• When flying an alliance ship, the player does everything he does in the name of his alliance

• Alliance ships can now be flown by multiple players
• Added seat management for crafts to manage who is able to do what (steering, firing, etc)

"We'll be adding some more means for better control of which sectors will actually get updated on multiplayer servers. For now, sectors with lots of stuff will have a higher priority."

• Sectors with player and alliance content are updated while the player is not inside the sector
• Default amount of updated sectors per player on multiplayer is 6 (the sector the player is in, plus 5)
• This value can be configured in the server.ini settings and will be a lot higher for singleplayer
• If a player has property in more than 6 sectors, this happens:
• Each sector will have a priority score
• The 5 sectors with the highest scores will be updated
• The score in the sectors is 3 for each player station, plus 1 for each player ship

• Steam Workshop integration for ship and station models is complete
• Saved ship plans can now be uploaded to the Steam Workshop
• Subscribe to ship plans on the Steam Workshop

• Added a new flight recorder block
• Flight recorders will mark the death location of the ship on the map
• Flight recorders will only work if they're *still on the ship* when the ship is destroyed
• Trading posts always have dedicated cargo storage
• Added licenses for stolen, dangerous and illegal cargo transportation
• Added multiple mirror planes in building mode
• Removed randomized building mode
• Implemented whole ship modification
• Scaling entire ships
• Upgrading the material of entire ships
• Rotating entire ships
• Added selective block modification
• All but one material or block type are faded out
• Added a search field on the galaxy map
• Turret factories sell a random, more expensive selection of the goods they require for building turrets
• New Turret: Pulse Cannon
• Pulse Cannons shoot ionized projectiles that have a very high chance of penetrating shields
• Added respawning of resource-asteroids in sectors with large asteroid fields (will only be in effect for new sectors)

"We're currently working on making shields less powerful, and one of the means to do that will be adding more weapons that are strong against shields, such as pulse cannons. But we also felt that plasma cannons didn't have the impact on shields that they were supposed to have, so we upped their damage to shields."

• Doubled shield damage of plasma guns

• Reduced darkness of window shadows
• Added a setting for limiting FPS
• Improved rendering performance in sectors with lots of wreckages

• Improved performance of inventory grid displayers
• Added filtering for inventory grid displayers
• Added favoriting of inventory items with right mouse
• Added marking of inventory items as trash with right mouse
• Tooltips are only drawn when mouse is not obstructed by other windows
• Improved borders of inventory items
• Added loading screen tips for various new features
• Added a button to sell all trash immediately
• Added chat message channels for sector, group, everybody (default) and alliance
• Added display of relative or total costs to saved ships window
• Improved handling of multiline text boxes
• Added a key for toggling strategy mode (default: F9)
• Added an option to disable toggling of strategy mode by zooming
• Added various tips about new or old features to the loading screen help
• Gate connections now have a different color than wormholes on the map
• Added a message when changing control scheme
• Improved german translation
• Added a textbox to quickly transfer lots of cargo and crew

"Most important changes here: Better performance on the server (memory and runtime) and improved savegame security."

• Crafts that were destroyed through database corruptions can be restored
• Players can be moved to other sectors, including ships (just rename the files if the names clash)
• Player & Alliance files are saved redundantly to avoid loss of data on file corruptions
• Improved performance when players log in
• Improved overall networking performance
• Improved overall memory performance using lazy initialization of collision data
• Improved performance of traders in sectors without players
• Added detailed output about script memory usage to /status command
• Sector content is now compressed before being sent, reducing traffic when changing sectors by 70%
• Server files are now compressed
• Implemented whitelisting of steam groups
• There's a separate file group-whitelist.txt in the server folder where you can add 64bit steam group ids that should be whitelisted

• Entity IDs are now 128bit UUIDs
• Script memory footprint reduced
• Scripts that are attached to the same object are loaded into the same lua VM, if possible, to reduce redundant data
• Added namespaces so scripts can be distinguished from each other and to avoid name collisions and functions getting overridden
• Scripts that have DIFFERENT namespaces will be loaded into the SAME lua VM, since name collisions aren't expected to happen
• Scripts that share the SAME namespace will be loaded into DIFFERENT lua VMs
• Scripts that have a namespace must have a comment '-- namespace NAMESPACE' where NAMESPACE is the script's namespace
• Scripts that have a namespace must have a namespace table with the same name as stated in the namespace comment
• Scripts that have a namespace comment must prefix all non-local functions and variables with their Namespace table (see scripts for more details on this)
• Scripts that have no namespace comment statement will always be loaded into different VMs (which is exactly the old model)
• It is STRONGLY recommended to modders that they rework their scripts to use namespaces to save memory performance!
• Lua VMs aren't set to invalid after a normal error, but still on fatal errors (exceptions)
• [Documentation] Fixed methods of inherited script classes not showing up in completion docs
• [Documentation] Fixed broken base classes when base gets a [client] or [server] extension
• CheckBox can be enabled and disabled
• CheckBox can be configured to have its box on the left or right side
• TextBox can have a background text
• Added a VanillaInventoryItem item that can be used for scripting inventory items
• Fixed an issue with infinite recursion in printTable()
• Added a PlanSelectionItem item that can be used in selection grids to display BlockPlans
• Added functions to access all plans that are saved locally or downloaded via the Steam Workshop
• Added Timer and Profiler classes
• Implemented API for async script calls [while theoretically functional, still highly experimental]

• Several small performance improvements all over the place
• Improved logging
• Reduced size of ship .xml files
• Player is placed in last craft upon login

"As usual, user bug reports are marked with [UBR]. Thanks everybody for helping with the game!"

• [UBR] Fixed extreme loading times due to too many inventory items
• [UBR] Fixed a crash that occurred often during instanced rendering (asteroids and such)
• [UBR] Fixed overflow of resources and money
• Resources and money are now 64bit integers, meaning they can go up to 9.223.372.036.854.775.808
• Overflowing is no longer possible
• Fixed player being placed in his drone on use of /teleport command
• [UBR] Fixed space bar not working sometimes in loading screen
• [UBR] Fixed a hang when holo blocks decay due to missing repair crew
• Fixed a (rare) player duplication issue
• Fixed a crash when destroying/deleting a station
• Fixed a crash when loading corrupt scripting values file
• Fixed trading posts not having any cargo storage
• Fixed a crash when loading an object with a script where the script file disappeared
• [UBR] Fixed smuggler's market not working when too many stolen goods are on the ship
• [UBR] Fixed a crash in patrol AI
• [UBR] Fixed a crash in loading screen
• [UBR] Fixed a crash when exiting the game while in strategy mode
• [UBR] Fixed a crash when loading templates.xml
• Fixed ships by faction on map not being saved/loaded correctly
• [UBR] Fixed quick menu buttons being clickable through the building inventory
• [UBR] Fixed keyboard and mouse up events not being registered in loading screens
• [UBR] StructuralIntegrity effect is now always visible on the correct ship
• Fixed translation of EnergyConsumer names
• Fixed mining systems always showing asteroids for all players in a sector

"Some things that still need fixing, that didn't make it into the update. They will be fixed during next week."

• Alliance sectors not being shared correctly on the map
• Notifications for picking up items for alliances

We're proud to announce that the feature development for the Alliances update has finished! This means that we'll go into testing soon, after we did some internal testing as well.

The reason why this update took so long was that we had a lot of features that fit thematically into the update. There were just too many things that we wanted included in the update, so we thought "yeah, that one would be quite cool, too!" leading to a never-ending stream of cool ideas and features that we wanted to ship with the update, delaying it further and further.

We have all the most important features in and we've decided that now it's enough and we'll just ship it so you won't have to wait any longer. This also means that there are a few features that we initially wanted to include that didn't make it. But we'll release them in future updates.

These are the features (roughly) that will make it into the game with the update. A more detailed list of these will be posted with patch notes once the update goes live on the beta branch.

• Alliances, ie. player-founded factions, similar to guilds/clans in other games
• Steam Workshop support for ship and station models
• Co-Op ship steering of alliance ships
• Out-of-sector simulation for player ships and stations
• Improved server performance (less lag, less memory consumption)
• Whole Ship modification, ie. upgrading materials, scaling, rotating, modifying internal blocks
• UI improvements, searching on galaxy map, filtering in inventory

In the future we'll most likely do smaller, but more regular updates again. We tried an experiment with this update as we thought that huge content updates might be somewhat more impactful, but we realized that while it made development easier, it didn't help you guys a lot. So we'll be moving back to the system where we'll release smaller updates, but a lot more regularly.

We've got a few updates planned already, not necessarily in that order though. I'll give you a quick description on what we've planned in these updates.

We want combat in Avorion to be more exciting than just flying in front of each other, shooting at shields and seeing that my firepower is slightly stronger than the enemies shields so I win. We'll add more specialized weapons that will be capable of destroying or bypassing shields a lot better, making shields a lot less overpowered, completely necessary thing. But don't worry, you'll see what you're up against so you can prepare for a fight against an enemy that won't care about your shields.

We'll rework the way fighters work. Right now they can be very strong in terms of firepower, but they die off very quickly, making them nearly unusable. We want them to be a strong alternative to turrets, that's equally strong and just works differently. This includes easier replacement of destroyed fighters and their pilots, as well as specialized weapons against fighters. And customized fighters. This is actually something we initially wanted to include in the Alliances update (since it would fit in perfectly) but we realized that this is easily a week's worth of work, so we'll ship it in a separate update.

Now that we're done with all the features we want in we'll do some more internal testing and if everything goes well the update will hit the beta branch by the end of next week.

Thanks for reading everybody, and stay tuned!

We're proud to announce that the feature development for the Alliances update has finished! This means that we'll go into testing soon, after we did some internal testing as well.

The reason why this update took so long was that we had a lot of features that fit thematically into the update. There were just too many things that we wanted included in the update, so we thought "yeah, that one would be quite cool, too!" leading to a never-ending stream of cool ideas and features that we wanted to ship with the update, delaying it further and further.

We have all the most important features in and we've decided that now it's enough and we'll just ship it so you won't have to wait any longer. This also means that there are a few features that we initially wanted to include that didn't make it. But we'll release them in future updates.

These are the features (roughly) that will make it into the game with the update. A more detailed list of these will be posted with patch notes once the update goes live on the beta branch.

• Alliances, ie. player-founded factions, similar to guilds/clans in other games
• Steam Workshop support for ship and station models
• Co-Op ship steering of alliance ships
• Out-of-sector simulation for player ships and stations
• Improved server performance (less lag, less memory consumption)
• Whole Ship modification, ie. upgrading materials, scaling, rotating, modifying internal blocks
• UI improvements, searching on galaxy map, filtering in inventory

In the future we'll most likely do smaller, but more regular updates again. We tried an experiment with this update as we thought that huge content updates might be somewhat more impactful, but we realized that while it made development easier, it didn't help you guys a lot. So we'll be moving back to the system where we'll release smaller updates, but a lot more regularly.

We've got a few updates planned already, not necessarily in that order though. I'll give you a quick description on what we've planned in these updates.

We want combat in Avorion to be more exciting than just flying in front of each other, shooting at shields and seeing that my firepower is slightly stronger than the enemies shields so I win. We'll add more specialized weapons that will be capable of destroying or bypassing shields a lot better, making shields a lot less overpowered, completely necessary thing. But don't worry, you'll see what you're up against so you can prepare for a fight against an enemy that won't care about your shields.

We'll rework the way fighters work. Right now they can be very strong in terms of firepower, but they die off very quickly, making them nearly unusable. We want them to be a strong alternative to turrets, that's equally strong and just works differently. This includes easier replacement of destroyed fighters and their pilots, as well as specialized weapons against fighters. And customized fighters. This is actually something we initially wanted to include in the Alliances update (since it would fit in perfectly) but we realized that this is easily a week's worth of work, so we'll ship it in a separate update.

Now that we're done with all the features we want in we'll do some more internal testing and if everything goes well the update will hit the beta branch by the end of next week.

Thanks for reading everybody, and stay tuned!

DISCLAIMER: I will speak about what happened, progress and performance optimization over the last few days and since it's mostly been coding, it will get kind of technical. I could post some images but there really is nothing new on them that I could show you, so I don't see the point of doing it. This will most likely also be more like a blog post or something. We'll see.

Over the last weeks we finished up on the alliances mechanics, meaning: Alliances are basically finished (feature-wise)! They need more testing, but the features are all in.

However, there's a lot of other features that we want to ship alongside alliances with the next update, the most important ones being Steam Workshop support for ship and station models and out-of-sector-updates for player ships and stations. We want to ship them all at once because we know that if we ship them one by one they will break their own database structures (ie. corrupting your saves) or we'd have to add a converter each single time (which is actually not an option if we have to do it for lots of small updates) since we're doing a lot of work in that area right now.

I also improved how player ships are saved and, most importantly, restored when there are database corruptions. Right now ships are always stored in the sector files, since technically speaking, they belong to a sector. But this lead to annoying ship losses in a few cases when the server crashes before a sector can be written to disk. With the new system, which will be shipped with the update, player ships and stations will be saved in the player's file. In addition to that, the server will now save multiple instances of the player's file, meaning even if a player file gets corrupted due to lack of HDD space, BSOD, a power outage or other reasons, there are 5 other fallback saves which you can access so at max only the progress of the last 5 minutes is lost. This also means that you can now transfer entire players, including their ships (!) to another server by copying that player's file. It also means that sector and player files no longer need to be written out every time a player changes sectors, which should improve performance of multiplayer servers dramatically.

This also allowed me to fix an issue where the entire database would get written out in some cases to ensure a consistent state. This has been identified as the major cause for those huge lags that tended to occur on large servers (like the public test server) whenever a player logged in or whenever a new faction was created (ie. when a player changed sectors into a region of a new faction).

Steam Workshop implementation should be quite straightforward. If its ease of implementation is similar to the other Steam API features that I've used in the past it should be realized quite quickly. Performance optimization for holding lots of sectors in memory at once, however, has proven quite the problem (but a solvable one, phew) over the last few days.

When we're talking about keeping lots of sectors alive at once, The most important things are update performance and memory consumption of the server. Now, sectors without players are actually really lightweight when it comes to update performance, since the game is using a simplified update variant for these, however they can still easily use 100 - 150 MB of RAM per sector while in memory. And players tend to visit the populated sectors more often since they're a lot more interesting than empty space. So we have to improve on the memory consumption most importantly.

So we profiled what was actually causing the high memory consumption. At first we thought "obvious, it's all the geometry of the objects". After measuring memory consumption before and after stripping down all the plans of all the objects in several highly populated sectors we realized that those only took up 2 - 5 MB of RAM, out of 130MB. So that clearly wasn't the cause for the high RAM consumption. Which was to be honest both scary and a relief. A relief because if it were the block structures, we'd have to strip them every time a player leaves a sector and re-add them every time a player reenters the sector, which would lead to a myriad of special cases where components and scripts would always have to check if a plan was actually loaded or not (have fun, modders, haha). But it was also scary since it had to be something that we hadn't thought of before, and that's never good.

After further investigation it turned out to be the lua scripts. In highly populated sectors we saw that there were on average around 220 scripts active (basically nearly every single station or ship interaction is its own script). But it wasn't the scripts themselves, it was the fact that we were using a single lua VM for each unique script. This might sound ludicrous, but at the time it seemed like a good idea since these VMs are actually rather lightweight, and each script could be cleaned up easily when it's being detached or deleted. Well, they were lightweight until we started adding the Avorion Scripting API, which blows each VM's memory consumption from 5 - 20KB (depending on which built-in lua libs we offered) to at least 130KB. 130KB times 220 is 28.6 MB, so we had at least 28.6 MB per sector. And we're not yet counting any initialization or actual scripts, this is just the absolute minimum basis per script. Initialized scripts could take 500KB to 2.5MB. After profiling some more we saw that the scripts used up to 80 MB per sector - quite the amount. The big issue here is that when using a separate VM for each script, there will have to be a lot of redundant data available to each VM, since the VMs themselves don't know that there are other VMs.

So what I've come up with now is simple: Use a single lua VM for each entity, and no longer for each script. We were forced to make a few script API changes in order to do this, but the good news is: We managed to do it in a way that will NOT kill current mods! I'd still strongly advise modders to adjust their scripts to make use of the improved memory consumption, though. The changes are as follows:

• Since every script defines functions that will be called from the main game, and these functions have to have the same names, I've added modules or namespaces (I'll decide on which term we'll use later). Each script can define a namespace/module in which its functions will live that it'll expose to the main program. By separating them into different modules or namespaces they will no longer have the same name in the VM and they won't get overridden when another script is loaded into the VM.
• When loading a script, Avorion will check if it's using a namespace, and if yes and if there are no duplicates it will be injected into the existing lua VM of the object.
• If no namespace is defined or the namespace exists already (basically whenever there's a potential for methods being overridden by the newly loaded script) the script will be run in a new VM. This is basically exactly the same as the old model that we've been using so far.

We've profiled this change and so far it's been looking very promising. Script memory consumption has been more than halved and it looks like we might even be able to reduce it to 20% of its previous amount, which is actually crazy good. We only adjusted the major scripts and we already got the memory consumption down from 130MB to ~40MB for four loaded sectors. We'll be on the lookout for more of these optimizations, but that's what we've got so far.

Another great feature of the new system is that you can now easily access other scripts in the same entity - provided that they're loaded in the same VM (which they should be, by default): Just check and access the namespace of that script. With these changes we also paved the way for improved modding support where you won't have to merge files manually or with tools but should be able to just copy them into, let's say, a specific folder and they'll work.

If you made it here, congratulations and thanks for reading! Hopefully I managed to give you an insight on what we're doing right now.

I won't give another date right now because this stuff is really (and I mean REALLY) hard to predict, but I want you all to know that we're working hard on new features and improving the game and we've been making some great progress over the last weeks.

As I said in the last announcement: Software engineering is a complex thing and there can always be unforeseen issues (these issues I just talked to you about are basically the proof) so telling an exact date is hard if we want to ship with as little issues as possible. There's a reason why lots of companies just say "when it's done".

But to give you at least some feedback: About 50% of the work of the update is done, and hopefully the rest will be more straightforward so let that be an indicator for you.

Oh, and there will be more new screenshots of nice new features in the next update, promise :)

Have fun and see you all soon!

DISCLAIMER: I will speak about what happened, progress and performance optimization over the last few days and since it's mostly been coding, it will get kind of technical. I could post some images but there really is nothing new on them that I could show you, so I don't see the point of doing it. This will most likely also be more like a blog post or something. We'll see.

Over the last weeks we finished up on the alliances mechanics, meaning: Alliances are basically finished (feature-wise)! They need more testing, but the features are all in.

However, there's a lot of other features that we want to ship alongside alliances with the next update, the most important ones being Steam Workshop support for ship and station models and out-of-sector-updates for player ships and stations. We want to ship them all at once because we know that if we ship them one by one they will break their own database structures (ie. corrupting your saves) or we'd have to add a converter each single time (which is actually not an option if we have to do it for lots of small updates) since we're doing a lot of work in that area right now.

I also improved how player ships are saved and, most importantly, restored when there are database corruptions. Right now ships are always stored in the sector files, since technically speaking, they belong to a sector. But this lead to annoying ship losses in a few cases when the server crashes before a sector can be written to disk. With the new system, which will be shipped with the update, player ships and stations will be saved in the player's file. In addition to that, the server will now save multiple instances of the player's file, meaning even if a player file gets corrupted due to lack of HDD space, BSOD, a power outage or other reasons, there are 5 other fallback saves which you can access so at max only the progress of the last 5 minutes is lost. This also means that you can now transfer entire players, including their ships (!) to another server by copying that player's file. It also means that sector and player files no longer need to be written out every time a player changes sectors, which should improve performance of multiplayer servers dramatically.

This also allowed me to fix an issue where the entire database would get written out in some cases to ensure a consistent state. This has been identified as the major cause for those huge lags that tended to occur on large servers (like the public test server) whenever a player logged in or whenever a new faction was created (ie. when a player changed sectors into a region of a new faction).

Steam Workshop implementation should be quite straightforward. If its ease of implementation is similar to the other Steam API features that I've used in the past it should be realized quite quickly. Performance optimization for holding lots of sectors in memory at once, however, has proven quite the problem (but a solvable one, phew) over the last few days.

When we're talking about keeping lots of sectors alive at once, The most important things are update performance and memory consumption of the server. Now, sectors without players are actually really lightweight when it comes to update performance, since the game is using a simplified update variant for these, however they can still easily use 100 - 150 MB of RAM per sector while in memory. And players tend to visit the populated sectors more often since they're a lot more interesting than empty space. So we have to improve on the memory consumption most importantly.

So we profiled what was actually causing the high memory consumption. At first we thought "obvious, it's all the geometry of the objects". After measuring memory consumption before and after stripping down all the plans of all the objects in several highly populated sectors we realized that those only took up 2 - 5 MB of RAM, out of 130MB. So that clearly wasn't the cause for the high RAM consumption. Which was to be honest both scary and a relief. A relief because if it were the block structures, we'd have to strip them every time a player leaves a sector and re-add them every time a player reenters the sector, which would lead to a myriad of special cases where components and scripts would always have to check if a plan was actually loaded or not (have fun, modders, haha). But it was also scary since it had to be something that we hadn't thought of before, and that's never good.

After further investigation it turned out to be the lua scripts. In highly populated sectors we saw that there were on average around 220 scripts active (basically nearly every single station or ship interaction is its own script). But it wasn't the scripts themselves, it was the fact that we were using a single lua VM for each unique script. This might sound ludicrous, but at the time it seemed like a good idea since these VMs are actually rather lightweight, and each script could be cleaned up easily when it's being detached or deleted. Well, they were lightweight until we started adding the Avorion Scripting API, which blows each VM's memory consumption from 5 - 20KB (depending on which built-in lua libs we offered) to at least 130KB. 130KB times 220 is 28.6 MB, so we had at least 28.6 MB per sector. And we're not yet counting any initialization or actual scripts, this is just the absolute minimum basis per script. Initialized scripts could take 500KB to 2.5MB. After profiling some more we saw that the scripts used up to 80 MB per sector - quite the amount. The big issue here is that when using a separate VM for each script, there will have to be a lot of redundant data available to each VM, since the VMs themselves don't know that there are other VMs.

So what I've come up with now is simple: Use a single lua VM for each entity, and no longer for each script. We were forced to make a few script API changes in order to do this, but the good news is: We managed to do it in a way that will NOT kill current mods! I'd still strongly advise modders to adjust their scripts to make use of the improved memory consumption, though. The changes are as follows:

• Since every script defines functions that will be called from the main game, and these functions have to have the same names, I've added modules or namespaces (I'll decide on which term we'll use later). Each script can define a namespace/module in which its functions will live that it'll expose to the main program. By separating them into different modules or namespaces they will no longer have the same name in the VM and they won't get overridden when another script is loaded into the VM.
• When loading a script, Avorion will check if it's using a namespace, and if yes and if there are no duplicates it will be injected into the existing lua VM of the object.
• If no namespace is defined or the namespace exists already (basically whenever there's a potential for methods being overridden by the newly loaded script) the script will be run in a new VM. This is basically exactly the same as the old model that we've been using so far.

We've profiled this change and so far it's been looking very promising. Script memory consumption has been more than halved and it looks like we might even be able to reduce it to 20% of its previous amount, which is actually crazy good. We only adjusted the major scripts and we already got the memory consumption down from 130MB to ~40MB for four loaded sectors. We'll be on the lookout for more of these optimizations, but that's what we've got so far.

Another great feature of the new system is that you can now easily access other scripts in the same entity - provided that they're loaded in the same VM (which they should be, by default): Just check and access the namespace of that script. With these changes we also paved the way for improved modding support where you won't have to merge files manually or with tools but should be able to just copy them into, let's say, a specific folder and they'll work.

If you made it here, congratulations and thanks for reading! Hopefully I managed to give you an insight on what we're doing right now.

I won't give another date right now because this stuff is really (and I mean REALLY) hard to predict, but I want you all to know that we're working hard on new features and improving the game and we've been making some great progress over the last weeks.

As I said in the last announcement: Software engineering is a complex thing and there can always be unforeseen issues (these issues I just talked to you about are basically the proof) so telling an exact date is hard if we want to ship with as little issues as possible. There's a reason why lots of companies just say "when it's done".

But to give you at least some feedback: About 50% of the work of the update is done, and hopefully the rest will be more straightforward so let that be an indicator for you.

Oh, and there will be more new screenshots of nice new features in the next update, promise :)

Have fun and see you all soon!

Let's do a quick update on what's happened so far with the alliances!

Over the last weeks I had to get a lot of backend and business stuff done so progress was sometimes a little slow and when there was progress, well, there was nothing that I could show since it's been background and database changes.

But now the backend coding is mostly done and I've started implementing more of the front-end features, which I will quickly show you here! Sadly, over the last weeks progress wasn't going just as well as I had hoped, but we're confident that we'll be releasing the update in the next few weeks. I'd love to be more specific on the release date, but there are always unforeseen problems in software development and I prefer finishing the next updates up nicely before pushing them into the beta branch to avoid frustration and bugs.

Alliances will work like a faction. You can invite people to join your alliance, and from then on they can, depending on their permissions, contribute to that alliance and fly crafts of it, build and so on.




You can invite people over the members list which can be seen here:



And of course there's going to be an alliance vault, where you can store and items and resources. These items will be available to everyone building and flying alliance ships, so you'll be using up resources from the alliance when managing its ships.

Another nice and highly asked-for feature will be filtering in the inventories! I added a filter function which will match strings with the tooltips so you can highlight and easily find items you're looking for. I also drastically improved the performance of the inventory UI, so it's going to be a lot more fluid.



The filtering feature will be applied to all the occurrences of the inventory, including the building mode and the research station as well.



Links to all the pictures in high resolution so you can actually see something:


Alright guys, thanks for your attention and have fun! I'll go back to development of the alliances and all the other features we've planned for the update!

Let's do a quick update on what's happened so far with the alliances!

Over the last weeks I had to get a lot of backend and business stuff done so progress was sometimes a little slow and when there was progress, well, there was nothing that I could show since it's been background and database changes.

But now the backend coding is mostly done and I've started implementing more of the front-end features, which I will quickly show you here! Sadly, over the last weeks progress wasn't going just as well as I had hoped, but we're confident that we'll be releasing the update in the next few weeks. I'd love to be more specific on the release date, but there are always unforeseen problems in software development and I prefer finishing the next updates up nicely before pushing them into the beta branch to avoid frustration and bugs.

Alliances will work like a faction. You can invite people to join your alliance, and from then on they can, depending on their permissions, contribute to that alliance and fly crafts of it, build and so on.




You can invite people over the members list which can be seen here:



And of course there's going to be an alliance vault, where you can store and items and resources. These items will be available to everyone building and flying alliance ships, so you'll be using up resources from the alliance when managing its ships.

Another nice and highly asked-for feature will be filtering in the inventories! I added a filter function which will match strings with the tooltips so you can highlight and easily find items you're looking for. I also drastically improved the performance of the inventory UI, so it's going to be a lot more fluid.



The filtering feature will be applied to all the occurrences of the inventory, including the building mode and the research station as well.



Links to all the pictures in high resolution so you can actually see something:


Alright guys, thanks for your attention and have fun! I'll go back to development of the alliances and all the other features we've planned for the update!

Hey everybody,

I'd like to thank you for participating in this little joke (of you wanted to or not, heh), and I'd like to point out officially here that it was actually an April Fool's joke.

Cubic planets were a nice opportunity for us as an April Fool's joke since it took not even 5 minutes to swap out the models for the planets and to add the date check for them to be activated. This "improvement" was easy to add and purely visual, without impacting gameplay. That made it the perfect opportunity for April 1st. So for those worried tht we're wasting our precious dev time: We didn't actually lose any work time over this.

Since some people are actually thinking that our focus lies on planet visuals instead of new content: Yeah, that's of course not the case. We like our planets, we might improve them in the future, but right now we're very busy with the Alliances update. It's a lot of work but coming along nicely. Once we have more to tell you, I'll make another announcement.

Oh, and in case you did like the cubic planet visuals, you can add the following line to your client.ini file in your %appdata%\Avorion or ~/.avorion folder to enable them:

Look for the [Background] category and add the following line (or edit the value in case the line already exists):

Have fun!

Hey everybody,

I'd like to thank you for participating in this little joke (of you wanted to or not, heh), and I'd like to point out officially here that it was actually an April Fool's joke.

Cubic planets were a nice opportunity for us as an April Fool's joke since it took not even 5 minutes to swap out the models for the planets and to add the date check for them to be activated. This "improvement" was easy to add and purely visual, without impacting gameplay. That made it the perfect opportunity for April 1st. So for those worried tht we're wasting our precious dev time: We didn't actually lose any work time over this.

Since some people are actually thinking that our focus lies on planet visuals instead of new content: Yeah, that's of course not the case. We like our planets, we might improve them in the future, but right now we're very busy with the Alliances update. It's a lot of work but coming along nicely. Once we have more to tell you, I'll make another announcement.

Oh, and in case you did like the cubic planet visuals, you can add the following line to your client.ini file in your %appdata%\Avorion or ~/.avorion folder to enable them:

Look for the [Background] category and add the following line (or edit the value in case the line already exists):

Have fun!