Greetings, citizens ~ Here’s another weekly devblog.

What are we working on right now?

We are currently finishing off a redesign of the chunk request system which will make requesting chunks over multiple entities a lot more controllable. This means that chunks close to the player can be requested a lot faster resulting in a much better overall experience with loading times for objects (as e.g. asteroids that are far in the back get less priority over closer objects). Prioritisation did exist in the previous system, but it was more local to the entity. Also, a few prototypes to test out if our plans for the reactors are viable implementation wise have been implemented. One example is a system which can create a convex hull (https://en.wikipedia.org/wiki/Convex_hull) of an arbitrary amount of blocks has been implemented. This system’s focus is to be as fast as possible and to provide a variable amount of precision to simplify complex structures. This is then not only usable to make the distance between stabilizers and main rector actually viable, it can also be used graphically to outline ship systems. Furthermore, Terra has been working on a rather significant launcher update. See below for details!

Launcher update

While most of the work is done, the UI isn’t quite finished yet, so you’ll have to rely on imagination instead of screenshots for now. (Sorry about that!) This update consists of two major changes: Firstly, we’ve merged all of the settings popups into a single dialog. This both drastically improves ease-of-use, and gives us unlimited space to add more settings later, for example logging. (Implementing this required extensive changes throughout the codebase, so the thorough QA required for this will delay release somewhat.) We’ve retained the settings gear icons, but instead of opening their respective popups, they now act as shortcuts into the new settings dialog; this should help with transition. The architecture behind the consolidated options also allows us to implement more complicated and/or settings-dependent features, of which this release’s second feature is a good example: The second is something that people have been requesting for ages: official support for multiple StarMade installs! Adding them is straightforward and easy, and you may have as many as you like. There’s also a dropdown on the main window that allows switching between them quickly. No more manually changing the path. No more version/branch mismatches. No more multiple launchers. There have also been minor tweaks throughout; some visible, some not.

Power feedback

Thank you for the large amount of feedback on our new power proposal. So far it seems that we need to iron out some key issues and tweak the system here and there. The major concerns so far seems to be:

• Restrictive rules that contradict several goals (Simplicity, Logical):
  • 1 active reactor per entity | 1 active reactor for entire ship
  • Minimum block count for chambers
• Tech points are too abstract
• Bad terminology for power related functionality such as Tech Points, Chambers, Skill trees, ...

These are definitely valid concerns. In the next few days we’ll work try to work on resolutions to as many issues as we can and try to improve the power system so that doesn’t have to compromise on build creativity that much yet also not open up for exploits. As a side note, with the power proposal we are of course planning a responsive and informative GUI that will come with the system, which will indicate exactly how the system is functioning so that it’s easily understandable just from that without having to read one word of explanation. Making things work with docked entities Perhaps an interesting topic to talk about and why it’s not that easy to find a solution for it that still follows the goals we’ve set up. With the current in-game power system, the main reason why people use docked reactors, is to bypass the softcap limit that is set per entity. It gives you more favorable power production per block by spreading it out over multiple entities. Anyone that doesn't do this, such as just sticking with a single big ship, will be at a severe disadvantage. In this proposal, we have power reactor blocks scale in a linear fashion, there’s no way to get more power per block by splitting them over multiple entities… But there's still something related to power that can be bypassed which is the minimum distance required between the reactors and stabilizers. That distance scales differently depending on reactor block count. It only influences the amount of volume your ship needs to get more power out of it but it comes down the same exploit but most likely just less severe. There’s a possibility where the distance can scale linear just like the power blocks do, it depends on preliminary playtesting to figure that out. If that was the case, docked reactors would already have a big chance of coming back. There are also power related things we have to care about when talking about docked entities such as chambers, but you can simply disable those from working and it will be just fine from a ship perspective. However, when investigating what exactly is wrong with this, we noticed that there are plenty of other inconsistencies when it comes to docked and undocked ships. Both examples could literally be the same ship yet as soon as you dock one of them, it becomes part of another ship and it loses a part of its systems and functionality. The docked power allowing you to bypass the softcap is far from the only issue StarMade has with inheriting systems and functionality. It’s just the most severe one which is why it’s being focused on so much. Just a few examples that we can bring up:

• Only the main ship, the one at very bottom where everything is docked is too, can control movement.
• Rail connections are weak points, if you combine 2 of the exact same entities with each other through a rail connection, and someone manages to destroy your rail. Your ship that you still control, suddenly lost half of its mass. As if the experimental feature “break off” was enabled.
• No full 2-way inheriting.
  • Shields are inherited from the parent entity
  • Thrust and mass, are inherited from the child entities
  • Rail enhancers, rails only enhance their 1st level child entities <=> entities only care about the enhancers of their parent
  • Mass is inherited 1- way, the bottom ship will be the sum of its own mass, and the chains above it.
  • On top of all this, most of these systems use power, yet power either inherits only from the parent, and/or it uses its onboard power.

There are 2 distinct cases here: Docked entities should be fully independent from their parent and children This would be the safest option when it comes to exploits and amount of work to be done, it would also decrease complexity and make StarMade easier to learn. Yet it comes at the price of limiting creativity a lot and reduce the amount of advanced structures you can make later on. Modular ships would not be feasible with this system. Docked entities should completely merge with them when it comes statistics. This would be the best option gameplay wise, allowing as much creativity but also risk opening up the system for exploits. It could also be too complex for new players to get into this although that’s more of a progression problem than As for some of the advantages of turrets versus fixed weaponry, we can always balance those through AI accuracy, swivel speed or some other system that does not add special rules to the inheriting of systems. We’ll be looking at more feedback of course. As always, thanks for playing StarMade! ~ The Schine Team