Greetings, citizens ~
Here’s another weekly dev blog!
What are we working on right now?
In the wake of the power update, we’ve identified a few features that overlap nicely with the new power system and other ideas we’ve had for quite some time.
One of these features is the ability to draw groups of blocks separately and apply various graphical effects to them. Among other uses, this will allow us to display the inner workings of ships quite nicely, e.g. highlighting a specific salvager/weapon array, a circuit, damaged blocks, etc. There are several existing uses for this, but it will be especially useful on future features, such as: scanning other ships, getting an overview of your reactors, highlighting potential issues therewith, etc. We’re aiming to do a release with this feature implemented in quite a few areas.
We will be updating Advanced Build Mode with increased functionality. This will include the above highlighting, as well as new tools. This update will not only make reactor design much easier (and allow integration of their features), but it will also give players better building tools in general. Among these planned features is a fill tool, which will allow you to progressively fill any area, as well as tools to draw lines and possibly arcs.
Thank you again for additional feedback. We went through most it, and we will be addressing more of your concerns later on where needed.
After reading all of the concerns and debates over the new power system, we can address two of our major concerns players had with the mechanics. The first is that players are limited to a single active reactor per ship, and the second is that only a single reactor would ever be active for a group of docked entities. We agree that some of these issues may be valid, but are not something we can easily solve in a balanced way.
We came to the conclusion that implementing a working multi-reactor system right now would compromise the whole reactor system as we do not know that system on its own works in-game.
That’s why we’ve decided that after implementing the base system (and after its initial balance passes) we will look into the concerns about the single-reactor issue again, to have a better overview on the possibilities in this system. Specifically, we will re-examine allowing docked entities to have their own active reactor, and possibly even allow multiple active reactors per entity to see if we can find a balanced, non-exploitable way to implement them without introducing countless rules and restrictions.
Even so, coming up with something to allow docked reactors only solves a small part of the bigger problem mentioned here: https://starmadedock.net/threads/starmade-devblog-may-22nd-2017.29057/
What’s next? / Conclusion
We definitely appreciate all of the feedback we’ve received thus far. It has gone a long way to help shape and solidify StarMade’s next steps. Given the work we’ve been doing, we are planning a pre-release build in a week or two. Be on the lookout for that build, and if you have questions on our release cycle, please refer to the following:
And as always, thank you for playing StarMade!
~ The Schine Team
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!
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.
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
We have an update on the power update as well as an exciting announcement for you.
What are we working on right now?
One new thing is that in our internal builds fleets are now saving orders on logout and server start and restart. You can expect fleets to save orders in future dev builds. As previously mentioned, we have been constructing a comprehensive power document to share with the community. It is now being finalized along with a video to give an easily digestible overview of the entire proposal. These will be released simultaneously later this week.
Be sure to check our last news post [prev dev blog] for more specifics, since we are still discussing those internally.
New developer joining the team
For the past two and a half months we've been getting a new game developer familiarised with the code and how we work. Some of you will already be acquainted with him as an active community member, welcome to @nightrune (Sean Sill)!
Thanks for playing StarMade,
~ The Schine Team
It’s been a little while since the last news update. However, we decided, that with a new flexible release schedule it would be best to do weekly news posts when possible from here on out. This is all detailed in a forum post here: https://starmadedock.net/threads/starmade-release-cycle-news-posts.28895/
What are we working on right now?
One major addition will be a new request system, that will give better overall performance and superior logic for requesting chunks allowing for larger entities. Fleet commands will be made consistent between server restarts, as well as improved local movement, and we will be looking to make fleet fight-or-flight behavior a lot better.
We are also working on other projects in the background, but we can’t reveal everything just yet. The level of planning and discussions has probably increased tenfold since StarMade’s next steps will be quite large, so what we can reveal right now is in the next section. Much of these discussions have revolved around our end goals document. We’ve been working on a public version that we would like to release soon.
Our current focus is on outlining the final gameplay elements of the game as a whole and making sure we cover the aspects of exploration, movement, building, fighting and developing your empire in an interesting and satisfying way for the player.
For this to work properly, we have to adapt our current universe layout. We are discussing and planning how the next version of resource distribution will work in the universe. The game’s present universe is very uniform and doesn’t lend itself to a more dynamic universe we would like to see. This leads us to discuss and work on two specific things. Where resources are and how, you as the player, use them. The current system we are designing will be moving to more points of interest and contention in the universe. Meaning only specific capsules and ores will exist in specific parts of each galaxy. The crafting system will also have to take this into account and will be revised the same way.
Our discussion internally is based around a concept of points of interest within the universe. A point of interest could be many things. It could be a sector, a set of sectors a planet or other stellar phenomena. All points of interest will/should have a gameplay purpose within the galaxy. These will become focal points for contention, and exploration. There will be more information about the specific locations and stellar objects in future news posts.
While we prepare for all of that, bug fixing will once again be focused to establish more overall stability this includes fleets and AI. Work is still moving forward on audio, and our new power proposal. Both which will have quite the impact on the universe, but more on power next week.
Thanks for playing StarMade,
~ The Schine Team
The spring cleaning update is finally released. As you probably already know, we changed our release cycle to be a lot safer. You can check out our release cycle here (still a work in progress). For this update we focused on solving a lot of new and old bugs.
A few of the bugs were extremely hard to fix. There are also a few smaller features coming with the fixes.
Features and more noteworthy bugs
Fleets/ships losing entities
After many iterations and tries, this error seems finally fixed. The main problem was a faulty database query when a fleet changed sector. It was supposed to bring all of their dock with it, but due to the bug only brought some of them. To catch this bug we implemented debug functions, so that fleets would be able to monitor themselves patrolling between sectors.
There is one leftover issue which is catched by a fallback method, and therefore doesn’t affect the game at all. It will just notify the admins with a small popup to send in the logs, since using a fallback isn’t the cleanest way solve this left over.
Thanks to all the testers and helpers on this bug! You really helped a lot finally squashing this pesky bug.
Collision solving for lagging sectors
Server has a lot of problems when there were a lot of bad spawns caused by either a bug or intentional griefing. It goes so far that some servers has scripts to detect those sectors and despawn objects.
It comes down to that when multiple physical objects were in the same space, the physics would slow down the whole server. In the past this could happen with fleets spawning or asteroids in rare cases. These issues have been fixed. However, should it still happen, the game has now its own detection system, automatically warping objects to a save closest position after the sector was detected to lag from that object causing too much physics lag.
Rail logic switching
Switching rails through logic interaction seemingly worked well but block data was not properly refreshed. You would end up with ghost connections and depending on building, could create an invalid link. A safety check done by the game would prevent any rail working on that entity because of it. This would most likely explain why quite a few rails stop working.
Rolling ships has been significantly improved. By redesigning the algorithm used, rolling while looking around now feels a lot more natural and doesn’t do these strange figure eights anymore.
We apologize for taking a bit longer to fix some of the more pressing OSX issues. Macs can finally use framebuffer and advanced graphics functions to speed up the game using the optimizations that come with that. Also some crashes with videos and some text input issues have been fixed.
If you find more problems that are OSX related, please report them and we will try to fix them for the next release.
We fixed a number of exploits. Thanks to all the players reporting them.
One of the more difficult things was implementing a system that would check connection validity without affecting performance, because it would be horrible to check every block that has a connection. The system we came up with distributes the load to check connections over time. It also only checks when the numbers “don’t check out”.
~ The drawing for display blocks has been significantly improved
~ Logic activation sending has been improved significantly, reducing bandwidth and improving performance
~ Fleets can now cloak
~ Fleets can now radar jam
~ Bobby AI can now be activated via logic
Size Restriction via GameConfig.xml
Admins can now restrict the ship and station size per entity they want to allow on their server. The exact syntax has been added to /data/config/GameConfigDefault.xml
Also there is a general size restriction in the server.cfg now. RESTRICT_BUILDING_SIZE will restrict building size to multiples of sector size. The value in the GameConfig.xml has priority if set.
List of Bugs fixed
Here’s the full list of all 85 tasks we’ve worked on:
Private issues are exploits or issues that, if known to the public, would cause a lot of harm.
Even though we fixed them, knowing the steps to reproduce could give you ideas on finding a way to bypass the fix and still abuse it, for that reason we do not share.
~ T2349 (Private): Grouping issue
~ T2139 (Private): Power and shield drain issue
~ T2138 (Private): Player max build area not working properly
~ T1969 (Private): Performance issues with logic
~ T1963 (Private): Missile and AI targeting issue
~ T1931 (Private): Shop module crash
~ T1851 (Private): Transporters and grapple beam issue
~ T1828 (Private): Jumpdrive/inhibitor charge issue
~ T1823 (Private): Bounding box issue
~ T1627 (Private): Performance issues with logic
~ T1602 (Private): Linking update issue
~ T1575 (Private): Undo issue
~ T1570 (Private): Ion issue
~ T1558 (Private): Crash when enabling shadows
~ T1299 (Private): Rail logic switching issue
~ T1227 (Private): Collision issue
~ T1145 (Private): Derelict stations issue
~ T1080 (Private): Faction protection removal issue
~ T1050 (Private): Docking issue
~ T1023 (Private): System claiming issue
~ T941 (Private): Docking issue
~ T895 (Private): Faction rank permission issue
~ T840 (Private): Asteroid respawning issue
~ T823 (Private): Another Ion issue
~ T659 (Private): Logic issue
~ T654 (Private): Warhead issue
~ T643 (Private): C+V linking issue
~ T512 (Private): Design issue
~ T2353: Sector Import fails to load ships docked to planet plates/asteroids
~ T2352: (Prebuild only) Shipyards causing disconnect and class cast exceptions
~ T2347: Caps-lock mouse interaction on OSX
~ T2339: /load_as_faction crashes server
~ T2333: Nullpointer being spammed in server console
~ T2309: /destroy_uid_docked command not working properly
~ T2294: Gold, silver and bronze bar icons missing
~ T2291: Autofill “ingame player name” from launcher
~ T2289: Make Bobby AI activation logic controllable
~ T2278: Cannot dock here
~ T2273: Adjust starter equipment for the new block selection method
~ T2270: Server deadlock, unknown cause
~ T2267: Server crash related to physics, and meta objects
~ T2252: Registry has a max password length of 128 characters but not stated anywhere
~ T2249: Flip flops not working properly
~ T2246: Torch cannot destroy faction module
~ T2214: Navigation menu mass of docks is always 0.1 and 0.0 for stations/planet plates
~ T2181: Nullpointer with processErrorDialogException
~ T2150: Radar jammer and cloak stay active on exiting core for fleet ships
~ T2140: Display module performance issues
~ T2118: Add dimensional limits to game config
~ T2101: Rail detection with rotators and set rotation broken
~ T2100: Sell available and price updates at the wrong time
~ T2099: Place order edit button is switched around
~ T2094: Fleets losing docked entities
~ T2044: /despawn command with fleet entities fails
~ T2009: Derelict stations get false positive removal for “ship only blocks”
~ T2004: Crash when attempting to access online play without internet connection
~ T1995: Importing sector fails with ArrayIndexOutOfBoundsException
~ T1980: Cargo spaces can be reused by multiple storages
~ T1957: C+V Rail detection doesn’t send false signals
~ T1776: Converted blueprints have undocked entities as response fleet
~ T1678: Uplink doesn’t save for OSX
~ T1664: Loading sector causes mass timeouts with colliding asteroids
~ T1658: Shop price not set without ownership doesn’t allow moving blocks in between
~ T1639: Nullpointer with joystick connected
~ T1616: ArrayIndexOutOfBoundsException with missiles or effects
~ T1553: Error handling for version mismatch and missing uplink insufficient
~ T1525: ffmpeg causing crash for OSX
~ T1510: Nullpointer in character file
~ T1466: Frame buffer capabilities not detected for OSX
~ T1465: Nullpointer with projectiles, causing invisible beams
~ T1422: NaN illegal comparison with shootout rail
~ T1384: Nullpointer when charging shields
~ T1337: Wedge blast door texture reversed
~ T1318: Spawning ships with same names as formerly existing one may lack docked entities
~ T1282: Creative mode doesn’t allow dropping specific block quantities
~ T1257: Incomplete build mode undo/redo
~ T1004: New unchanged stations turn into red hull blocks
~ T990: Rolling not working properly
~ T684: Shop permission resets when server restarts
~ T524: Weapons hitting deeper inside your ship
~ T428: Not staying attached to ship when logging out
~ T355: AHP and SHP is capped
~ T325: Asteroids can spawn in solid entities
~ T252: Startup crash with custom Windows theme
~ T25: C+V Linking memory leak
We also did around 20 smaller fixes and issues reported directly by server owners. Crashes, database issues and performance problems were fixed along the way resulting in a more stable environment.
Thank you for playing StarMade,
~ the schine Team