koonschi

The reply is still the same. Each sector is updated by its own thread - until a synchronization point. If a single thread takes a lot longer than the rest, the other threads will wait for it, and rest idle. I'm not sure what to say here except for: We're working constantly on improving on this behavior, but that's how it works.

Thanks for the report. We know of this issue currently and are working on a solution.

The time has finally come! The patch for version 0.12 is now officially available on the beta branch! We want to use the time on the beta branch to find errors and bugs to ensure polish for when the update comes to the default branch. 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. You can find the full patch notes here: http://steamcommunity.com/games/445220/announcements/detail/1316588270895403776 Thanks for testing and have fun!

Patch 0.12 Date: June 11th, 2017 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. Alliances 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 Co-Op Flying 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) Out-of-sector simulation "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 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 Gameplay 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) Balancing "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 Client Reduced darkness of window shadows Added a setting for limiting FPS Improved rendering performance in sectors with lots of wreckages UI 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 Server "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 Scripting API 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] Misc Several small performance improvements all over the place Improved logging Reduced size of ship .xml files Player is placed in last craft upon login Bugfixes "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 Known Issues "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

Time for another update! 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 Future Plans 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. Combat and Stealth 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 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. Fighter Rework 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. Okay great, but when? 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!

When updating, the game has to wait for all sectors to finish their update tick and when one of them takes exceptionally long (which it shouldn't in the first place, hence my asking for the profiling data) then it can slow down the entire server, yes.

The thing is, that the server is not measuring its load in actual CPU load. When updating sectors the server has to wait until the slowest sector has finished updating, for technical reasons, which can slow down overall server performance a lot. If you encounter this, please enable profiling in your server.ini and type /status in the chat. It will print a detailed breakdown of what happened and why the server is slow. This would help tremendously.

We've been a "we" since the Kickstarter, it's just that over the last couple of months Philipp had to focus on his graduation (which, of course, has absolute priority). Which is why you've mostly seen me. But these investigations and lots of the decision making was done by the both of us.

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. Alliances & Progress 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 annyoing 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 and Out-Of-Sector Performance Improvements 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. The improved Scripting API 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. Alright that's it for now! 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. OMG I DON'T CARE UPDATE WHEN!? 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!

Thanks. Was there a wreckage with loot floating around or was the ship just gone?

Development 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 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!

Concerning overpowered shields: That's on the radar and I agree that this is the point that's problematic. As I stated here in the "Further down the road" paragraph, I'm working on solutions to this. Concerning customizable turrets: Please everybody who has a strong opinion on this answer me the following questions. Don't take them too literally, it's about the principle of why you want something. I'm looking to fix the problem and not treat the symptoms. Please also tell me which of those is the most important for you. 1. Do you want to configure a turret's stats (as in Damage, Range, etc.)? 2. Do you want to create more of the same turret (so your ships look less random)? 3. Do you want to adjust the size of turrets? 4. Do you want to change the appearance of turrets? 1. is already possible at a turret factory, and the rest will be coming later on. If you don't like the turret factory then please tell me why (and don't just say "it's buggy" because I know very well that there are some issues).

All features will also be available in single player, except for those where you actually need a second player to do things (like trade or co-op piloting). But you'll be able to found an alliance and have your own faction.

Oh it's not a bug. As we said, we're constantly working on improving the atmosphere of the game and getting a cohesive look.

Hey everybody, As we already said in our previous announcement, we always strive to improve the graphics of Avorion. For this small update, we've updated the planet visuals so they match the rest of the game better. The changes are subtle and might even be overlooked when you don't pay attention. We want Avorion to look great and unique and this is one of many steps that we will take to improve the atmosphere and achieve a more cohesive, exciting graphics style. It may not be completely realistic, but we think that the overall feel of the game will have improved by a lot. You can check them out ingame after you got the update. We'll be rolling out the changes over the next 24 hours, and you may have to restart Steam to get the update. Depending on your region, the update might take a little longer to be active, but everybody should get it within the next 24 hours. Have fun!

Hey everybody! I'd like to give you a short update on what we've got planned for the future. First off: We're currently busy working on the Alliances Update, and we want to make sure to get it right and not release a rushed version. This means that it'll take a little longer than you (and we as well) may have anticipated, but we'll make sure that the wait is going to be worth it. We'll take a few more weeks until it's finished, and you shouldn't expect any big updates for the time being. Of course we'll still address critical problems, such as performance problems, exploits or crashes immediately if we can. Until then: No ETA, except for: We hope to release it in a few weeks, and we'll keep you posted on how it's going. On another note, we're currently looking to make the visuals of the game a little more cohesive, so that the ships, shots, asteroids, background, planets and effects all work together really well. Alliances Update? For those not knowing about the Alliances update: It will allow players to form alliances, that will count as their own factions, very similar to guilds or clans in other games. We'll add a lot of content and features to make sure that you can actually experience Avorion on a bigger scale - for example performance improvements so we can actually hold all the sectors with alliance or player ships in memory and update them. You won't have to stay around to have your factory or miner gain money. Time to finally build your empires! Here's a rough outline for the features that we have planned for Alliances: Alliances Update Features Alliances that will be formed by players Co-op ship piloting Sectors staying in memory while a player is online Improved building mode for easier editing (scaling, moving, transforming) of whole ships Player backups so your progress is not lost on server failure of any kind Custom fighter plans and Steam workshop support for ship and station plans, and entire faction sets Better inventory and map navigation Further down the road After the Alliances we're looking to make a Combat & Stealth Update, where we'll add more and more meaningful weapons and warfare features, so that combat isn't just standing-still-and-waiting-for-your-enemy-to-die. We'll give you more details on that later on, so stay tuned! Have fun!

There's been an update. Please restart Steam to get the update. Your issues will most likely be resolved then.

It's really hard to say anything if you don't post your client log and system specs.

Patch 0.11.0.7844 Date: March 27th, 2017 In this patch we've improved a few features and improvements that we actually wanted to add to the groups update from last time, but that didn't make it in time. We also improved the compatibility for Intel HD graphics, so if you have one of these onboard Intel GPUs, please try out the current build since we'd love to hear how Avorion is performing now. We have a few devices that we can test on, but it's impossible for us to test on every since Intel GPU there is, so we need your feedback! Here are the full patch notes: Gameplay Infinite turrets in creative mode You'll still have to find the turrets, but you can build as many as you want once you found one [*]Added hotkeys for toggling ship systems These hotkeys are unassigned at first, you'll have to assign them yourself [*]Big infected asteroids can no longer be claimed [*]Military outposts have turrets [*]Number of crew members at crew boards scales with distance to galaxy center [*]Very large numbers for crew boards when in creative mode [*]Added numeric display of velocity and hyperspace cooldown [*]Added new hints for death, dropped items, insurance and reconstruction sites Balancing Reduced reputation gain by trading Resource depots have a max amount of reputation that can be gained during a time period This is to prevent buying reputation at a faction Scripting API Added an interface to the EnergySystem component that allows management of energy for ships and stations Sounds can now be played via scripts Client Improved loading performance on first loading screen when players have very many inventory items Loading screen is now more responsive Windows shouldn't complain about the application not responding any more (which was a false positive anyways) [*]Improved logging for potential graphics problems [*]Improved support for Intel HD 3000 (should be working now) [*]Improved support for Intel HD 4000 (should be working now) [*]Driver warning doesn't get obstructed by main window any more [*]Added a x0.25 subsampling setting [*]Added a --gl-debug option to client command line options to explicitly enable debug GL contexts Server Added --version command to print server version Improved performance and data output of /status command Misc Improved crash handler for windows builds to give more accurate information Improved log file naming so sorting by name also sorts by date Fixes "These were all user bug reports, so thank you very much for reporting these and helping us improve Avorion!" Fixed Xsotan attacking a sector again and again even if nothing ever happens, leading to massive amounts of ships in the sector Fixed a crash when turrets register wrongly at another non-craft object Fixed a few typos Fixed a crash in fake distress signal Fixed a crash when deleting root block and pressing undo Fixed a crash when client and server mods are out of sync (the mods still won't work though, but the game won't crash anymore but print an error) Fixed non-homing missiles of turrets with independent targeting Fixed an error where shaders would unnecessarily be printed to log on Intel Fixed a few cases where docking AI would get stuck

That's bad wording from my side, you're of course correct. The number of blocks is irrelevant, the volume is what's important.

Entity Index Change to UUIDs I'd like to inform you beforehand that we'll be changing the Entity.index from a 32bit number to a 128bit uuid. This will most likely not affect you if you're not writing mods, and even then it might not affect you, but I found it important to tell you this. Why's that? Because it's about damn time! I wanted to do this for a long time but I always thought "later will be a better time". Well, it is later now. We're doing this change because we've always run into problems with the 32bit number. Entity indices have to be changed often, for example whenever changing the sector, leading to issues when turrets (which are their own entities) have to find their parent, which has been an issue that's been popping up recently. With the introduction of the new 128bit number, we can easily assign fixed, server unique IDs to entities, without having to worry about duplicates, even on a server-global scale. When is it coming? Sooner, rather than later. I'm not sure how and when we'll introduce the change, but we're currently working on this since it will pave the way for other features, fixes, improvements and simpler code. It might come this week, next week or in a month. But it will definitely be part of one of the next patches. Why are you telling us this? I'm telling you, because I wanted to give you a head's up of a fundamental change that might affect you. If you've been using the Entity.index property as a number, then you'll have to adjust your mod. If you've been using it solely for comparing entities or checking if an entity is there, etc. then you probably won't even see a difference. I'm working on making this transition as painless as possible. But I don't want to adjust my mod, can't you just work around this? No. We've been working around this problem for a long time and it's lead to more problems than it avoided. It's time that we make this change, even if it might break a few things or if things have to be adjusted. This is the long-term solution and it will make a lot of things a lot easier. I wrote a mod that uses the index, what should I do now? If you've been using it only for comparing entities or checking if an entity is there, etc. then you probably won't have to do anything. Entities will receive unique IDs upon first loading of a save, and they will keep those ids. If you've saved IDs into files or in other places, then you will have to adjust that. How will the new Ids look like? They'll be normal UUIDs, meaning they'll have 128 bits and when you print them they'll look like a string of hex numbers, separated by dashes: 6a12a4d5-e9e6-4568-afcc-34c70b24a668 I think that's all you have to know for now. I'll let you know if anything else comes up. Have fun!

Entity Index Change to UUIDs I'd like to inform you beforehand that we'll be changing the Entity.index from a 32bit number to a 128bit uuid. Why's that? Because it's about damn time! I wanted to do this for a long time but I always thought "later will be a better time". Well, it is later now. We're doing this change because we've always run into problems with the 32bit number. Entity indices have to be changed often, for example whenever changing the sector, leading to issues when turrets (which are their own entities) have to find their parent, which has been an issue that's been popping up recently. With the introduction of the new 128bit number, we can easily assign fixed, server unique IDs to entities, without having to worry about duplicates, even on a server-global scale. When is it coming? Sooner, rather than later. I'm not sure how and when we'll introduce the change, but we're currently working on this since it will pave the way for other features, fixes, improvements and simpler code. It might come this week, next week or in a month. But it will definitely be part of one of the next patches. Why are you telling us this? I'm telling you, because I wanted to give you a head's up of a fundamental change that might affect you. If you've been using the Entity.index property as a number, then you'll have to adjust your mod. If you've been using it solely for comparing entities or checking if an entity is there, etc. then you probably won't even see a difference. I'm working on making this transition as painless as possible. But I don't want to adjust my mod, can't you just work around this? No. We've been working around this problem for a long time and it's lead to more problems than it avoided. It's time that we make this change, even if it might break a few things or if things have to be adjusted. This is the long-term solution and it will make a lot of things a lot easier. I wrote a mod that uses the index, what should I do now? If you've been using it only for comparing entities or checking if an entity is there, etc. then you probably won't have to do anything. Entities will receive unique IDs upon first loading of a save, and they will keep those ids. If you've saved IDs into files or in other places, then you will have to adjust that. How will the new Ids look like? They'll be normal UUIDs, meaning they'll have 128 bits and when you print them they'll look like a string of hex numbers, separated by dashes: 6a12a4d5-e9e6-4568-afcc-34c70b24a668 I think that's all you have to know for now. I'll let you know if anything else comes up. Have fun!

Do you actually own the game on steam and did you let it update?

What version are you on? Did you update the game on steam? Because this is fixed in the update.

Your image is broken.