Recently the team was contacted by members of our Russian speaking community asking if us to contribute to a Q&A that they might translate for their fellow players. The following is what was discussed so that all Starmade players might have some more insight into our current and future plans.
-Q&A with the dev team-
Bobby AI, would it be able to be coded, or more commands and modes available.
Ingame coding. Scripting like in Space Engineers?
This is planned so far, but not in the near future. Lua support is already in the game, although it is currently only used for conversation scripting with NPCs. Although, it is not an easy task to create more specific commands before all game mechanics are fully implemented.
Official mods, will it be able to mod the game via official API?
If available, what abilities will get the API? Change NPC, balance, gameplay, blocks, AI?
There are already a lot of options to alter the game server-side without need of any third party files being installed.
Besides the “server.cfg” located in root directory of the server,
please check /data/config/ directory of the server.
FactionConfig.xml - Alters all faction point related settings
GameConfigDefault.xml - Allows setting the starting items, credits, blueprints
blockConfig.xml - Edit every blocks hitpoints, texture, armor, other stats (supports adding new groups for the shop for example)
blockBehaviorConfig.xml - alter all weapon stats, jump settings, it is even possible to create or remove the ability to link specific weapons
there will be a lot more, and there is a full API planned, but as long as the game is not finished yet (particularly missing features), it wouldn’t make any sense to release a full api, as many mods would have to be rewritten on every release, and this causes a lot of confusion, delays to updates for players and also some problems that we may not be able to predict at the moment.
However, almost everything is already moved to config files, so its already possible to replace and alter all blocks and functions in the game and also their behaviour to some extent.
Official documentation of game formats (like .sment, smb2 etc.)
this is partially done already in our wiki:
More logic blocks, elements?
We are open to all useful additions, feel free to forward suggestions to us.
Availability to restrict any kind of entities, like planets, asteroids, pirates, stations etc. via config?
This is currently only possible in battle-mode, this allows a size and mass limit per ship.
Restricting the total server wide amount of entities of some type is not planned at the moment, though it might be something the API would allow later on.
Will we be able to configure servers in a way to make it accessable only for players who bought the game, like Minecraft? For ex. I don't want to accept players without buying the game to prevent griefing or something.
While we are still free to play, there is no configurable difference between “upgraded” and “limited” accounts.
However, it is already possible and default to require an account per ingame name (there is also a server setting to allow a set number of names per account).
Beware: even “upgraded” accounts can have multiple ingame nicks.
But with both options form server.cfg:
USE_STARMADE_AUTHENTICATION = true //allow star-made.org authentication
REQUIRE_STARMADE_AUTHENTICATION = true //require star-made.org authentication (USE_STARMADE_AUTHENTICATION must be true)
You can enforce every nickname on the server to be identity safe.
To limit everyone to one-identity you have to use the whitelist feature.
You can either whitelist accounts, which allows every account to have multiple in game names on the server, or whitelist names, which effectively limits every name to be registered with your administrators (together with above settings they are also protected to belong to a single name then.)
What about rails? When?
There is no fixed ETA at the moment, but they are one of the next two main features coming up.
Reactors are now very complicated, will you make it simpler, or harder, or may be you will change formulas for other blocks?
Reactors are not very complicated at the moment, Please read our wiki regarding this:
its currently relative easy to set them up.
However, this concept is not set in stone,
once we see the need for a change or addition we may change it.
Other blocks like shields and weapons are constantly tweaked to the needs of players and other development steps. We are often considering improvements to various systems, whether or not we actually plan to change them.
New mobs? Custom models for mobs?
Animals, aliens, evolution, meteor strikes, quests during space adventure and so on?
New Mobs, yes, they are planned, (evolution might be a hard thing to pull off though.)
However, the other functions (quests, aliens/npc-factions) are a sure thing for the future but not for now.
Gas and gas planets? Anomalies?
We would like to add these yes.
Moons for planets?
Shipyards? Automatic building ships?
Yes shipyards are a confirmed long term feature we are working towards.
The blueprint meta item was one step towards them. Rails are also a step on the way to have automated shipyards of some type.
Repairing ships via blueprint?
Yes, this is planned.
Limit of ship size via configs?
Currently only in battlemode,
although this implies it could become a regular server setting in the future.
Commands to AI?
Yes, we have plans to implement AI and fleet control functions as well as personal commands you can issue to NPC’s under your control.
Economy, what's next?
The universe overhaul was one step for it, in the long term it’s planned to build some automated and self sustaining economy by utilizing AI-Fleets and NPC-Factions to create a universe that lives and reacts to player actions. Like flooding one area with cheap system blocks will make the price drop in that area and cause NPC-Fleets to distribute them to other systems, while this may lead to another set of tasks, quests for the player (escort fleet, Paid cargo transfers, etc.)
Automatic prices change, availability to change the range?
This functionality is in the config now, some of the controls were more recent, others have existed for some time. Further controls are also planned (custom rarity settings per block per shop, bulk purchases of low value item types; ie, dirt/rock/plant stacks for less than 1 credit per item.)
Factories on ships?
Factories on ships is possible now, however, we have held off on implementing them, as we feel there needs to be a method of counterbalancing this “perk” on a ship. We have a type of non combat system balancing planned called “capital systems” this won’t make your ship a capital ship, but it would typically apply to things you would find on larger ships with a specific non combat role (like a giant factory ship.) These will dynamicly apply a range of potential downsides depending on what and how much you have of number of non combat functions.
Cabin for pilot, not the abstract core?
We have talked about this, and are interesting in implementing it yes. We’re pretty sure how we want to go about it, we just have not had the time to update this yet.
Armor, that will take % of damage, not fixed values?
May indirectly be covered by an upcoming armor/hitpoint overhaul.
Limit size of storages?
Yes, planned by limiting stack sizes at some later point in the game.
Version 1.0? When?
Version 1.0 will happen when we have implemented all the major features that we feel are vital to gameplay and have resolved the bugs that come up as these features are completed. Theres never really an accurate ETA on this.
Changing of build mode? More tools in advanced mode?
Build mode will be limited in some way, once the shipyards are done.
However, there are already a lot of tools like replace, build helpers and templates to copy and paste sections between ships and stations. If there is anything useful/awesome missing, feel free to bring it to our attention in the suggestions section.
Weapon system, will it behave more realistic? For example like linear ships XVIII ages. I mean weapon sight can't deflect more than 10-20 degrees?
The topic of restricting the aiming reticle is pretty highly contested. However, we believe there is a dynamic solution (for all types/sizes) available that we will try out at some point.
Newton physics? Movement like in reality?
There are currently some settings in your configs to modify the linear and rotational drag you experience in the game. In addition to this, we are looking at modifications to our flight mechanics (ships & missiles) to cause them to perform in a more natural (and less limited) manner.
Faction module. Individual permissions?
Currently its only possible to set edit permissions per faction rank.
We would like to have name based permissions, but this may end up being difficult to achieve without potentially impacting performance, as it means additional meta data needed per ship per name. Still, it would be cool to have.
Shops, availability to control shop for few persons or whole faction?
It is already possible to add individual owners to a shop, leading to a per-person control over the shop. Adjusting the groups able to use the shop is currently generalized to:
“No enemies” and
As multiple stations in one system are no problem, it would be no problem to set up one shop for the faction, and another for the public, or even a separate for allies only.
-- Schine Team
HOTFIX #1 (v0.19171):
- Console input using /chat will now be sent to the general channel.
- The /chatchannel "channelname" "message" command can be used to send to specific channels.
- Chat output in log has been restructure to be easier to parse for server admins.
- Skin validation has been fixed, so skin distribution should now work again
- Skin upload/download rates can now be defined in the server.cfg
- Fixed window not scrolling to the bottom on multilined chat
HOTFIX #2 (v0.19173):
- fixed server crash on specific skin upload requests
- fixed server crash and general problems of the unique id of entities being too big (DATABASE TRUNCATION)
- fixed log output spam from requesting zones
another update has just been uploaded. While work is still going on on all the new gameplay features, which will hopefully come out in short succession to each other, here is an update that will make chatting ingame a lot more comfortable to use and manage.
Since we didn’t want to go for an only slightly better chat, we tried to go for the full package: That means a full channel systems with passwords, moderators, auto-rejoin, and on-hud-customization.
The chat is now structured in channels. There is a general output always on your hud where all messages from systems, and channels you have joined but aren’t currently open for hud are displayed.
But of course if you open the channel and fix it to the hud, the messages will only display there.
There are a few default channels that are autocreated. These channels also can’t be left and there is no moderation. The General channel, and the Faction channel (which is auto-created for each faction). Moderation in the General chat is equal to moderation of admins in general. Moderation for faction channels can be done by removing someone from a faction.
But the most important channels are the custom channels. Any user may create temporal channels. These channels exist as long as there is at least on online player in it, and will automatically be removed otherwise (to prevent channel spam and abuse).
Furthermore admins can create permanent channels, which exist as long as an admin doesn’t delete it. It will also still exist if the server restarts. The channels password/options are saved.
Each channel has moderators. They have the ‘@’ sign in front of the name. Furthermore you can now identify server admins have the ‘§’ sign additionally. Admins always have moderator powers, and can join any password protected channel.
Also all messages are still logged on server in ./chatLogs, now by channel. The protection against other clients has been improved significantly. It is now impossible to hack a client to read other players PM’s and messages of a channel the client isn’t in. This is done by single casting messages only to the clients that are supposed to get it. It’s a more complicated system to design, but has many other advantages also, like less bandwidth used.
You can private message now with any player conveniently by just right clicking on his name in any chat. A private message channel is handled like a temporal channel and will only exist as long as both players are online (in fact the channels exist on the clients only, as the server just forwards the message to the specific clients).
Also all chat panels can now be pinned to the hud. that means multiple chat windows can be displayed at all times exactly where you want them to be. This will get some additional improvements in the future like color coding of the background, and more.
Channel positions and options are also saved on logout. While a client will also never receive a password of a channel, the system saves the last password the client has used.
This means on rejoining (each by server of course), the system will automatically attempt to rejoin all channels that were open.
ATI and Intel problems
There have been some bugfixes for both Intel and ATI cards. If there are further problems, please create a ticket and we will try to solve the problem asap.
I feel a little bad for not bringing any gameplay features lately, so I will work extra hard to get new shiny things to you as fast as possible!
Thanks for playing StarMade,
- schema and the Schine Team
EDIT: Hotfix 0.189997: fixed sector claims sometimes not working, as well as removed a library that is flagged by some antivirus softwares (it was an IRC lib I was planning to use for the new chat system. It wasn't used at all in the version, anyway)
this version is mostly for fixes to the current version. It got a little delayed to figure out the various graphical glitches a lot of ATI users have. Some shader fixes have been done to fix some drawing problems, but there is now also a draw option disabled for ATI users, which can be re-enabled in the in-game options (named 'MultiDraw' in the graphics settings) for machines where the gamed worked before,a s it saves some OpenGL call overhead.
Also, some problems are due to some ATI drivers and can be solved by switching on Framebuffer in the advanced options.
Furthermore the price setting for personal shops have been re-enabled and can be done by shop owners in the main shop menu.
There are also some updates to balance:
We changed a few things on punch through and piercing effect blocks again. After some more testing we noticed a bug. You would always deal 2 times more damage than we intended.
The listed damage would apply more total hull damage than the listed number.
Example: a 10 000 damage listed weapon would on punch through do: 10,000 -> 5,000 -> 2,500 -> 1,250 -> 625 -> ...
If you make the sum of that, you get near 20,000 damage which is not what we want.
This has now been fixed, that means these 2 effects will deal 50% times less damage (still a whole lot better than not using any hull effect).
We also noticed that piercing effect, even though it does double block damage and has an armor efficiency bonus, it was slightly less effective against non-armored blocks than a double sized punch through array.
Because of that, the damage loss on the next block is less than punch through now. Piercing will go around 2-3 blocks deeper, providing you have the damage of course.
We hope that this is now enough to justify the 100% shield damage debuff.
Thanks for playing StarMade,
- schema and the Schine Team
this update is something very special. While we are still working on a lot of new features, we took the time to take an indepth look at several systems. Mainly the graphics and the network code.
A lot of this game’s choices in terms of style and design have been made to make the game as big and as scalable as possible. This is the whole reason we stayed with the block only system as opposed to detailed polygon graphics, as blocks present a unique set of optimizations and designs that would be lost in a conventional LoD (level of detail) polygon system.
To tell the results upfront, we managed to increase the performance of both graphics and network immensely.
In numbers, this means an almost doubled framerate (depending on hardware), and a decrease of average network traffic to about 10% of what it was previously (profiled by stress tests on the server).
These kind of improvements are some of the most technical ones to be made for any program. A vast amount of hours went into analyzing and profiling, while in other areas like the network that even required to write additional modules to make analyzation even possible.
A big thanks to servers who gave us profiling information as well as the tester team and players creating stress tests to verify and improve the changes.
For any one interested, there is a more technical explanation of methods used and designs on the end of this post.
before/after the optimization on the same planet with the same settings
But while we have a lot of more features in queue to come very soon, there are also some additional little features added to this version:
Custom Starter Gear
Servers are now able to define their own starter gear for new players. This includes credits, blocks, meta items, and blueprints (filled or not).
To edit the starter items, after the first start in this version a GameConfig.xml will appear in the starmade base directory, which should be fairly self-explanatory to edit.
This new door types added by kupu adds wonderful looking new doors.
Faction permission changes
A lot more options for customization has been added to faction roles. There are now permissions to control relationship changes (declare war, personal enemies, etc), faction news posting, taking/abandoning a homebase, and territory claiming/clearing. If you are a faction leader be sure to check and adapt your roles accordingly.
Calbiri, Lancake, as well as the tester team modified and gave feedback to a whole bunch of balance changes.
Hull blocks have been buffed in order to improve the survivability of ships:
Normal hull has 75 HP now.
Standard armor now has 60 armor and 100 HP, bringing it to 250 EHP.
Advanced armor now has 75 armor and 250 HP, bringing it to 1000 EHP.
Power supply beams have been buffed to bring it back to near pre-rework levels.
They are slightly less effective compared to what they used to be but they still offer around 5 to 6 times more power regen than their onboard equivalent in pure power regen blocks.
Power supply/tick: 40 -> 240
Power consumption/tick: 50 -> 270
The piercing defensive effect cap has been decreased but the amount of blocks you need to achieve max percentage has been decreased. This will bring the max achievable EHP to 2500!
Shield capacitors have now 2 times more shield HP, this is to make fights last longer and increase the chance of surviving high alpha damage.
Regen rate has remained unchanged.
Shield Capacity Total Mul: 55 -> 110
Warheads (dis-integrators) have doubled block damage.
Missile + Pulse
Radius has been nerfed to 48, with explosive you can get 58
Slightly faster, nerf: 4 -> 3
Does more damage, buff: 1 -> 2
Missile + Beam
Slower so anti missile turrets have less chance of missing buff: 2 -> 1
Ingots and crystals are 2 times cheaper to make it easier to craft advanced and crystal armor.
Shield cap and rechargers are 2 times cheaper.
HP of the more expensive systems, mainly weapons and support tools, has been increased by a factor of 2-3 in most cases.
The punch through damage system now has an effective penetration depth of around 7 blocks.
It used to make the other hull damage effects more or less obsolete and is in large groups gamebreaking. It is now equal to the piercing and explosive system in terms of block destruction per hit.
The piercing effect blocks are now switched over to the punch through damage system, with its double damage for blocks it would be ideal to use this system to destroy heavily armored ships.
This is also great for low damage weapons but with the drawback of doing no to low shield damage, depending on effect ratio.
The punch through effect blocks use the piercing damage system, making it capable of damaging blocks below armor without really destroying the armor itself first. It did lose its armor efficiency bonus though so if you want to destroy armor, piercing is the way to go. It doesn’t have a shield debuff though.
Explosive has not changed. It doesn’t exactly penetrate but it can damage a wide surface area with a minimum of weapon groups.
To clear things up, these are the current 3 hull damage types (not blocks):
Piercing damage system: Damage applied on a block gets halved and goes to the next block. This will automatically lead to a softcap at around 7 blocks deep. This also makes it able to destroy/damage blocks below armor plates without destroying that first.
Punchthrough damage system: Damage applied on a block gets deducted with that block’s EHP, then it is halved and passes to the next block. This also has a softcap at around 7 blocks.
Explosive damage system: ⅙ of damage gets applied to all touching blocks.
Unfortunately these changes do require an overhaul in ship design. Because of the stronger shields, and more durable hull, it would be highly recommended to put more armor and weapon blocks on your ships and sacrifice some shields.
Any constructive feedback is appreciated.
Bug 1769: Nocx Charged Circuit Wedge (typo bug)
Bug 565: Pentas are actually Heptas
All fixed prices have been adjusted so that they are around 1.5-3 times higher than their dynamic price.
There also have been some bugfixes to combat the slowdown of sound played, as well as more rare problems like driver crashes from the new GUI, and a lot of smaller bugfixes that caused crashes and glitches.
Technical explanation of optimizations
To begin with, these optimizations will only work with occlusion culling off. Occlusion culling is a nice concept with a fata backdraw: It’s very hardware dependant and will be slower, cause glitches, or straight up crash on crash on some systems.
For graphics the main work was to find out the bottleneck of the graphics systems. There were two main bottlenecks, which are either CPU or GPU bound. StarMade graphics are not CPU bound right now, which means there is something in the GPU processing causing the longest wait per frame.
Since OpenGL is a pipeline design, waits are not identifiable by just checking how long the code needs to execute on the specific commands. What happens is that the graphics card works asynchronous to the program execution. That means that all calls to openGL may be executed at an undefined time within the frame. If the program is GPU bounds it usually takes longer for the instruction to synch change to the next frame at the end, as the CPU waits for all the instructions that haven’t finished yet.
To actually find out what part in the code there has to be a deep analysis of graphics processing, which means switching of parts of graphics processing one by one to identify where exactly a framedrop happens, while keeping the graphics card processing large amounts of work.
In openGL (and other systems) there are 5 main bottlenecks to check: Framebuffer Fillrate, Vertex processing, Fragment Processing, Light processing and Texture Fetches.
By turning off specific parts of graphics processing combinations of what parts make the graphics run faster can be used to identify the bottleneck.
In StarMade’s case, there was a severe bottleneck going on with fragment processing (putting the pixels into the polygons and the screen). This started the second tier of finding the bottleneck within the fragment shader. It turned out to be the shire load of passing interpolated variables like occlusion and normals to the fragment shader.
To combat that I first changed the simpler per vertex lighting to look exactly like the per pixel lighting, and that would have worked overall, but it would look worse at close distance as wella s completely disable bump/normal mapping which depend on per pixel normals.
The solution to finally break this was to do preprocessed shaders, which use a simpler lighting on distance and a more advanced up close. The result was immense giving about 70% more fps to a planet of ~230 radius.
The next bottleneck identified was fillrate of textures. Since on high res, the textures have to lookup and interpolate pixels a lot more than on low res, another optimization was made to use low res textures at a distance. This also had the nice effect of eliminating texture noise when viewing objects at a distance.
Lastly the render queue has been optimized to greatly reduce draw calls and depth lookups by separating drawing in opaque and transparent parts, and also using chunked multi-drawing to the chunks of whole objects called with just one command.
Overall the optimizations yielded that a frame with large objects on it can be drawn in half the time it used to, which essentially doubles the graphics performance.
Furthermore these optimizations will also greatly benefit the shadow system, which also should be a lot faster now.
Network profiling is a lot more tricky as all you see on a basic level is individual bytes. Even listing packets is not very efficient as for one it itself costs a lot of performance, and secondly, it’s very hard to interpret.
Thanks to the design of our network protocol it was easy to aggregate per class and fields of time, which made it possible to exactly analyze network traffic and where it came from.
Furthermore, a profiling tool was build to help catch any fluctuation in the traffic by sent and received. It can even save individual timeframes for later analysis. if you are interested, you can look at it with F12, as well as turn on the live graphs in the options.
There were several bottlenecks identified immediately:
Block modification: All modifications to blocks, be it by battle, or by building were sent to all players which meant a huge load for players that have nothing to do with what happens in another part of the Galaxy. These are now made into private channels to only be sent to people in the area. Other players entering the area will get all the changed with the usual chunk requests. (note that making private channels is not advisable for everything as the cost for building and sending individual packets can outweigh what private channels would actually save).
There were a lot of other small places where making things private saved a lot of basic bandwidth.
The biggest optimization however was to bigger ships and their control structure. In order for client and server to synchronize, the data of what block connects to what has to be transmitted as soon as that ship is loaded. This was already done on a private channel, but a bigger ship, even with compression and everything turned on, cost 2.8 mb of data per player in the area. That is of course not acceptable, as it caused servers to burst data, and depending on provider entering a slow mode to compensate.
This was solved with a specially developed algorithm. By taking advantage of the block system once again and how ship systems work, a 2D map based on the shortest two dimensions can be made and per line regression can be applied. While this is a little to complicated to explain in details, here is the result: That 2.8mb ship now only took 14Kb, which is an improvement by 2000 times
What comes next
As said a lot of features are in queue. Foremost the rail system and the advanced chat (maybe even with IRC interface)
Thanks for playing StarMade,
schema and the Schine Team
this update contains a fix for servers freezing up (clients can't connect but the server will not hard crash).
It also contains a few other fixes like asteroids turning brown after revisiting a sector. All asteroids that were affected by it will turn back retroactively, as long as they have not been moved or edited.
Some GUI fixes are also done like new sliders with better usability as you can now click in the lane and new progress bars, as well as some smaller functionality fixes.
Oh and one bigger thing is that you can now switch to chests or factories from the inside of your ship/build block. The new option "cargo" is in the ship/station dropdown on the top task bar. You can also access all the named inventories from any chest from the panel's dropdown in the top right.
You first have to rename at least one chest/factory though which can be done from within the inventory panel. You can name up to 16 inventories per structure for the moment, but it is going to maybe get raised depending on its data usage on servers.
Thanks for playing StarMade,
- schema and the Schine Team