Latest stable version: Checking...
Registry status:


    Changelog from 469-472:

    ~ Fixed old (chunk16) blueprints not being usable in chunk32

    ~ Fixed bug where all rails would stop moving on a ship

    ~ possible fix for servers that have chunk errors (to admins that have a server with this problem: please turn on DEBUG_EMPTY_CHUNK_WRITES in the server.cfg for more logging should the error still happen)


    Changelog from 359-468:

    ~ Greatly improved performance on ships with rail-docks that are actively causing collisions

    ~ Fixed deadlock on removing shop module (in rarer cases)

    ~ Eliminated error where chunks would get time from the future and therefore not save

    ~ Fixed error where exit to desktop would interrupt saving process, causing several hard to replicate bugs

    ~ Fixed several crashes

    ~ Fixed false positive on stations checking themselves for being empty, removing it



    Greetings, citizens ~


    In this release we’re making good on our earlier promises of performance improvements and updating some of the existing systems, focusing on combat.


    Huge swarms of missiles no longer cripple servers, nor cause disconnects or “rubber banding.”  This should also help with balancing, as users can no longer disconnect their opponents with ridiculous numbers of missiles.


    Cannon projectile hits now require considerably less processing than before. As an example of just how large of an improvement this is: a shot penetrating through hundreds of blocks previously caused a half-second freeze, give or take.  The processing from this same shot now takes 5 milliseconds -- barely even noticeable.


    We hope these two major optimizations make combat much more enjoyable.


    Missile Performance Update

    We developed an algorithm that is capable of handling any amount of missiles without adding extra network load. It is based on a lock step algorithm plus adaptive updating. This enables missile paths to become deterministic, even when chasing a moving target, and when that target is not in the same position for server and client, e.g. due to network delay.


    With the previous system, 500-1000 missiles would generate a half-megabyte per second load (or more). With the new system, not only is the initial burst of data when firing much smaller, even a cluster of a thousand or more missiles only require a few bytes per second while flying.


    Even the smaller servers should be able to easily handle 2000+ missiles flying at once without causing slowdown.


    We will look into faster rendering and explosion calculations in the future.


    Projectile Performance Update

    We’ve also made some major optimizations for projectiles (cannon fire).  Projectiles’ penetration always caused major lag on both client and server, which restricted our ability to balance the weapon system.


    The new system uses a much leaner and more straightforward method to handle projectile penetration.  We’ve offloaded some of the effort into threads, such as bounding box recalculations (which, since the box only gets smaller in this case, isn’t needed right away).  Not only does cannon fire process literally hundreds of times faster now, it is also more accurate in terms of damage done.  In addition, not having restrictions due to performance will help us balance weapons a lot better in the future.


    The simultaneous destruction of large numbers of blocks still creates network load, but we have plans to reduce this.


    Power Overhaul Thread


    We would like to thank everyone that has provided constructive criticism. Thanks to you, we’ve already made some major (positive!) changes to our proposed design, and eliminated some of its shortcomings.


    We will still need a few days to present our plans in as clear a manner as possible so there’s no misunderstanding.  We’ll write a more informative post about this soon.


    As for implementation:

    Granted we can remedy the flaws the community points out, we will make the new power system available via an opt-in config option during its development.  When (and if) it is ready for release, we’ll aim for a transition phase similar to the release of rails, wherein both versions are available simultaneously (though this may not be possible).


    (If there are irreparable issues with the power system, we obviously will not implement it.)



    A few minor bug fixes:

    • T235: Overridden blueprints show wrong mass

    • T2234: Galaxy map stops reading scroll wheel inputs

    • T2180: Placing wrong block when swapped on the hotbar with another


    We’ve added a keyboard shortcut to open the shapes men. (It’s bound to ‘T’, moving sitting to ‘O’.) It only works when the currently selected block has multiple shapes.




    As always, thank you for playing StarMade

     ~ The Schine Team