StarMade News

Hello and welcome to StarMade,

---

EDIT: fixes in 0.19228: New blocks now have recipes. Lag should be much less for other players when someone mines (still will be optimized even more). Also:
#RM1788 Cannot delete waypoints
#RM1961 Fix hidden error message for faction names too short.
#RM1127 Fix float rounding causing imprecise build helper values.
#RM1692 Fix escape key not closing all windows, and sometimes closing parent window.
#RM156 Fix build mode flashing issues
#RM337 Fix outer radius size of atmosphere.
#RM2039 planets and asteroids now have a default power capacity of 501

---

Finally the time has come to release the much anticipated Rail System. This update contains a full redesign of the docking and turrets system, as well as a lot of new features. The new rail/docking system also solves a lot of old problems.  

Furthermore, thanks to the new devs, a lot of work has been done to fix bugs. With them getting more and more familiar to the huge codebase, bugfixing and work on new features will continue to pick up the pace.

Here is the news in youtube form:

https://www.youtube.com/watch?v=PUEGEXCbwww&feature=youtu.be

Here you will also find a list of tutorial youtube videos by bench:

https://www.youtube.com/playlist?list=PL76wZEm2fRBsB-UDoQZDtt_nVxSBCuun5

Rail System

 

Here is a short overview of all the systems. They are explained in detail at the bottom.

 

Complete Redesign

Due to the lack of usability and dynamic in the old docking system, we have decided to completely redesign the system from the bottom up. The new design is a lot more suited for all the current demands, as well as things to come.

 

The old system is still functional and no ships, blueprints, or other structures will break. The only restriction is that the docking beam is replaced with a pure activation beam, but if necessary the docking can be turned back on in the server config.

    

Rail basics (docking)

The new Magnet block can be docked to any Rail so long as the docking ship will not encounter a collision by doing so. This means no more docking zone boxes. Also, the orientation of your docked vessel can now be fully customized.

 

Rail movement

In addition to the removal of the docking zone, Rail blocks can be chained together in paths to allow for docked objects to move along them. The system is completely dynamic and allows for full control with the logic system.

 

Rail rotation

Rails are not the only new block allowing for docked objects and movement. Rotor blocks can be placed in your rail designs, or separately from them. The direction and angle of rotation can also be customized.

 

Rail interaction

Logic signal interactions and linked speed control blocks can dictate the direction, distance and speed of movement/rotation of the new Rail and Rotor blocks. Also, power and some of the shields are now shared between the rail-docks and the mothership, as well as every object in between.

 

Rail logic

The new rail blocks also come with complete integration with the the logic system in Starmade.  

New Turret System

Since the old docking also included the turret system, it now has also been redesigned. Turrets can now be divided into multiple rotational axes. In the most common example that would be a turret base that can rotate horizontally, and a turret top which would rotate vertically.

 

New logic blocks

Several new logic blocks were added to expand the functionality of the logic system with StarMade’s gameplay and to help integrate the new Rail system.  These new blocks include:

 

• Button block (Provides a short (0.5 sec) ON signal then deactivates)
• Flip-Flop block (Will only change its output when receiving an ON signal)
• Wireless block (Allows logic systems to connect from ship to ship)
• Remote block (Allows access to ship logic to be triggered from your action bar. Each block’s label can be changed by hitting ‘R’ on it)

 

Bug fixes

 

An issue has been resolved that caused lag spikes whenever a new player join on more populated server. Also the configuration for the hotbar is now set by ship. That means when you load a blueprint after setting it, you will get the exact hotbar you saved the blueprint with.

This unfortunately had the effect that currently all hotbars reset once, but in the long run the new system is a lot more comfortable.

 

The login procedure on servers that require authentication has been improved so that non-uplinked players now get an explanation as well as a prompt to enter their credentials or go to the registry to setup a new account. Also, the pesky error messages which blocked the real message have been gotten rid of.

 

We fixed some bugs probably causing a lot of java version errors, making the code more strict to its version dependencies, so hopefully a lot less problems for new players will occur related to that.

 

Closed:

• Dis-Integrator do not work on asteroids
• unable to track down path calculation failed
• Map: Interface skips the sectors near a system border
• Sniper rifle can zoom in the galaxy map
• Admins getting revoked of admin after logging on/off of server
• Logic on asteroid crashes the game (ClassCastException)
• IndexOutOfBoundsException with some handheld weapons
• Non-linear camera movement speed
• Ending tutorial brings you back to global spawnpoint
• Weapon menu not refreshing correctly
• Tab + F10 - Can be used to see cloaked entities
• Asteroid name mismatch (Zerkaner & Zercaner)
• Large, nearly complete blueprint quotas round to 100%
• NEW claimed systems do not get saved
• Overdrive power consumption doesn't scale with ratio
• 1th and 2th typos in Faction Rank
• Renamed entities cannot be searched for
• cloaked ships still have the "pilot" marker visible
• Cannot enter build block on asteroid - prevent placing it, not entering it
• docking module on asteroid crashes game on activation - prevent placing it, not activating it
• Lag/Freeze on autocomplete
• Tutorial fails to import sector correctly
• Launcher's world manager has no scrollbar
• /search only searching loaded entities

 

Resolved:

• Gui Error - faction menus refresh too fast and endlessly

 

(All bugs fixed caused with the rail system itself are unlisted)

 

Rail Docking Explained

 

This part will serve as an in-depth explanation and reference for all new systems.

Rail docking basics

 

The simplest kind of rail docking, which essentially replaces the old docking system, requires two blocks:

• Rail Basic
• Rail Docker

Rail Basic

The basic rail block serves as a docking access. You can dock to it using your rail docker. Placing only one basic rail serves as a static dock. Using more than one in a line produces a track a docked entity can run on.

 

Rail Docker

This block is needed on the entity that you want to dock to a Basic Rail block. Each placed Rail Docker contains a docking beam that can be assigned to your hotbar in the weapons panel of the ship. On firing, this block emits a docking beam. When that beam hits the Basic Rail Block of another entity, it will attempt to dock to that block.

 

All rail blocks have a direction not only indicating the direction of the track, but also determining the docking orientation. On docking, the arrow of the docker as well as the direction of the Basic Rail, or any other dockable rail block, will be matched together like aligning the poles of two magnets so they will stick together.

 

The only restriction that docking has is that the docked entity has to fit. This means no block of the docked entity may overlap with any block of the structure it wants to dock on, as well as any other already docked entities.

 

Upon docking, a ship will also retrieve the faction ID of the structure it is docked to. This however now only lasts for the time it is docked and will revert to its old id when undocked. Also any ship docked to a rail block that has a public exception block next to it will keep its original faction while docked.

 

The docker has one logic input and one output. Linking an activation block to the Docker will cause that docker to undock on activation. Placing an activation block next to the docker will cause it to activate on docking, and deactivate on undocking.

 

Rail Movement

As said, you are now able to make rail tracks by using the basic rails as well as the rail rotators explained below. Movement can be done in all three dimensions, and the rail docker will move on, as long as it has a tail track it can go to. It will stop if anything is in the way, or if there is no more rail to go onto. The direction of the rail to go onto can be different from the rail the block moves from as long as the primary face of the rail still touches the rail docker block.

Rail Rotator

There are two types of rail rotators. Clockwise and counterclockwise. Upon docking or moving onto this block, the docked entity will do a 90 degree turn, and then move on in the direction the rotator block is pointing if it can. The amount as well as the degree of the block can be dynamically modified with the logic system. Connect up to 9 activation blocks to any rotator block to control the amount of rotation. The amount of active activation blocks determine the block’s rotation. Each active block will add 45 degrees. If all 9 are active, the block will constantly rotate.

 

Keep in mind, that to re engage a rotation, the logic system as explained below can be used.

 

Rail manipulation

Rail manipulation allows for full control of rails. It works like a template copy & paste system:

All logic blocks that are placed next to a rail block have this rail block as an input to overwrite other rail blocks.

That means if you place an activation block with a basic rail block pointing forward next to it, and then connect that activation block to one or more other rail blocks, upon activation, all connected blocks will be replaced with the rail block pointing forward. If more than one rail block is next to an activation block, the system will take one pretty much randomly, so that is not recommended. The same also works for rail rotator blocks. Using it on a rotator block also resets it so if there is an entity currently on the rotator block, it will then rotate again with the new parameters. Basic rail blocks and rail rotator blocks are also interchangeable, allowing for more control over how docked entity move and rotate on a single rail layout.

 

Rail Logic

Everything rails is controllable via the logic system. The rails have inputs which is the rail manipulation mentioned above, but they also have outputs. Every activation block that is next to a rail is activated when the rail docker block of the docked entity moves on it, and deactivated when it leaves it. The new button block also works in this way to detect a docked entity, sending out a 0.5 second on signal when the rail docker block passes over the rail next to it.

 

Rail Speed Control

The rail speed controller is another block that can be used to manipulate how fast a rail moves a docked entity. It can be connected to any amount of activation blocks. The ratio of active blocks to inactive blocks determines how fast the rail will move in percent of the maximal speed. So connecting 5 active and 5 inactive is 50% speed, the same as connecting 100 active and 100 inactive. The rails that should be under influence of the speed controller also have to be connected to it. Using shift-V on rails connects straight lines of rails quicky. Also, mass plays a role in rail speed. Should the mass get too high, the speed of the rail will get slowed down eventually to a minimum. To combat this speed decrease, rail mass enhancer blocks have to be placed to increase the load every rail on the ship can take. These blocks do cost a little power.

 

Reasoning why rail controls work this way

Some people might think: “Why can’t I just set the amount of rotation and speed in a menu?”. The reason is, that it would be then a static value, unless scripting is used. The rail system is fully dynamic and gives visual feedback. So you can change speed, rotation, and rail directions at any time manually or triggered by the logic system. Having it in a script would firstly be harder to understand and learn, secondly break with the game’s principle of using block architecture to solve problems, and lastly would be more a simulator or programming studio than a game.

Allowing dynamic control through logic enables a lot more control of movement.
 

Here’s one example of this as created by Crimson-Artist

 

Rail Turret

With the rail system, turrets have been completely redesigned, too. Over are the times where turrets would glitch into the ship, and would look awkward with limited options to manipulate and control them.

The new system works with a 2-axis system. That means you can use at minimum one and at most 2 separate entities to form a turret.

The first one is the turret basis. This one can only be moved horizontally (rotate left/right), probably best imagined like a turret works on a battleship. The second one is the turret’s barrel, that, again like on a battleship can move vertically (rotate up/down). The cool thing is, that if you enter the turret on the barrel, you will have control over both parts at the same time, which would allow for turrets with full 360% freedom in all directions. However be aware that the turrets also now check the collision with its mothership and other docked entities and will restrict its movement in doing so.

The AI is fully integrated as well, and will work with almost any turret when placed on the barrel part. While in the turret its rotation can be reset by pressing ‘C’. You can also reset all turrets to the orientation they were in when you docked in the structure menu (under ‘rail system’).

AI will also reset the turrets after a while of not fighting. Currently it’s instant movement on reset to avoid getting stuck, but in the future the reset will also be smooth.

Please not there are still some minor issues with some turrets controlled by AI getting stuck. We are trying to fix that ASAP. Meanwhile please use teh reset feature.

 

Power and Shield Sharing

To provide even more freedom when designing rails, you can now use the full power provided by the mothership and any docked entity in between.

The same goes for shields: If a turret or other dock gets hit, the chain to the mothership will check if any ship in between can take the hit. The requirement for overtaking a hit is that the ship must have above 50% of its shields and at least as many shields to take the full hit for the turret.

 

 

Thats all for now,

Thanks for playing StarMade,

- schema and the Schine Team

Greetings Players,

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?
Yes

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:

http://starmadepedia.net/wiki/Blueprint_File_Formats

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:

http://starmadepedia.net/wiki/Power_Systems

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?
Also planned

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.

AI fleet? 
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:

“All”,
“Allies Only”
“No enemies” and
“Faction only”

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

Hello players,

---

HOTFIX #1 (v0.19171):

• Server
  • 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
• Client
  • Fixed window not scrolling to the bottom on multilined chat

HOTFIX #2 (v0.19173):

• Server
  • 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.

 

Redesigned Chat

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.

 

Channels

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).

 

On-Hud-Customization

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.

 

Auto-Rejoin Channels

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.

 

Other stuff

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

Hello players,

 

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

 

Hello players,

 

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.

 

Forcefield doors

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.

Balance changes

 

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

 

Other changes:

 

• 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.

 

Gameplay changes:

 

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.

 

Bugfixes

 

Bug 1769: Nocx Charged Circuit Wedge (typo bug)

Bug 1538: Brown paint can be bought in the shop; it can't be crafted

Bug 1285: Active circuit wedge have no animated texture

Bug 834: Ice Crystal Wedges missing from shops

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

 

Graphics

 

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

 

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