StarMade-Servers.com Blog Feed en https://starmade-servers.com/ Fri, 31 Jan 2020 18:49 CET StarMade-Servers.com is a StarMade servers list. Its goal is to provide an efficient way for players to find a server that suits their needs and also for servers owners to get more players on their servers. 60 STARMADE V0.202.86 - BALANCE CHANGES https://starmade-servers.com/blog/80/starmade-v020286-balance-changes/ https://starmade-servers.com/blog/80/starmade-v020286-balance-changes/ Fri, 31 Jan 2020 18:49 CET


The universe update is well underway and the code bases are now so different that any change on the old version takes a lot of time because of migrating. For this reason, this will probably be the last update on the non-universe-update version of StarMade.



It introduces balance changes that the Quickfire initiative developed and tested.

Unobfuscation
To make modding and general extensions of the game easier the game's code is now unobfuscated.


Quickfire
The Quickfire Initiative configs are very different from the old defaults. The config set was created by Quickfire's core team of configurators, with input from other members of the community, including PvP enthusiasts, creative builders, and others.

This is a complete overhaul of the game's configs. Most systems are balanced very differently than they were previously, including power consumption, mass, potency per block, and even some aspects of mechanics. As such, you should expect that most ships will require refits to function.

The Quickfire team is available for any support, question, suggestion for changes, or barrage of rotten tomatoes on their thread here https://starmadedock.net/threads/the-quickfire-initiative-rebalancing-starmade.31326/ , or in their discord server https://discordapp.com/invite/45zmQBe




OVERVIEW



The Quickfire config changes cover a broad spectrum of StarMade's systems, which have been determined to be broken or imbalanced in the vanilla game. The following is a short overview of the most important changes, with a more comprehensive document of all changes available via a link below.



Power:

-Disabled stabilizer distance.

-Set maximum power from stabilization to 100%. (25% was pointlessly unintuitive)

Chambers:

-Rebalanced chamber capacity requirements across the board (see document below)

-Changed chamber size formula, to not force certain reactor sizes for optimal mass efficiency

Thrusters:

-Nerfed thruster scaling overall. There should be more variance in ship maneuverability and top speeds now depending on ship size and design.

-Made diminishing returns on thrust harsher.

-Increased TWR cap for max speed to 5.0

Armor:

-Made armor lighter and more effective.

-Made armor layering/stacking significantly more effective. (should make thick or slanted armor more viable)

Shields:

-Buffed shields relative to weapons overall

-Nerfed/adjusted Anti Low Damage chamber to only block actual low damage relative to shield capacity

-Buffed Anti High Damage chamber, lowered threshold for "High Damage" to better protect against large hits.

Weapons:

-Rebalanced weapons across the board

-Removed cursor recoil on cannons

-Helped to track down and resolve the infamous 'tunnelling' bug with cannon projectiles

-Replaced the broken Doom Beam with a high-range pulse laser

-Worked with Schine to fix missile guidance

-Made missile capacity less restrictive

-Adjusted bomb to hopefully be more usable (see document below)

Other:

-Buffed Tractor Beam

-Adjusted some chamber abilities, such as scanning and Thrust Burst.



A more detailed document is available here: https://docs.google.com/document/d/1qrqa4wB13Djx09Ql1atWfHxKD7MJCubFsidHwQgV3x4/edit



Additional notes are available here:

https://docs.google.com/document/d/1ilNdPmw-8wMq2nooUcBZhrYG3Z1IWA59vwSo8hhF9Js/edit

Thanks to all the quifire members who developed and tested these changes.

This will also likely be the last major change to balance for ships. Unless it’s absolutely necessary, changes after this will only affect smaller aspects.



Thanks for playing StarMade,

- The Schine Team

]]>
STARMADE V0.202.86 - BALANCE CHANGES https://starmade-servers.com/blog/79/starmade-v020286-balance-changes/ https://starmade-servers.com/blog/79/starmade-v020286-balance-changes/ Fri, 31 Jan 2020 18:49 CET here.]]> Big performance increases (I/O) - Universe update dev dump 4 [30 OCT - 7 NOV] https://starmade-servers.com/blog/78/big-performance-increases-i-o-universe-update-dev-dump-4-30-oct-7-nov/ https://starmade-servers.com/blog/78/big-performance-increases-i-o-universe-update-dev-dump-4-30-oct-7-nov/ Sat, 30 Nov 2019 14:30 CET Screenshot and station build by SkylordLuke.[starmadedock.net]

This is the fourth universe update dump copied from our official Discord server, in the channel #universe-update-dev-news-dump. To receive universe update news as it happens, join our Discord channel here: Join the StarMade Discord Server![discord.gg]

Previous Discord dumps:

TL;DR

Between the dates of the 30th of October - 7th of November, the following was done:

Write/read overhaul, the goal being to eliminate lag caused by sector changes entirely. Sector changes would be hidden internally, and we'll switch to a more straightforward region system. This is split up into three main parts.
  • Decoupling of data accumulation and the actual writing. Essentially we no longer need to synchronise the writing thread during writing, making I/O operations not affect performance.
  • System to mark objects in a sector for writing, as well as a spawn/cleanup system for new sectors and for sectors no longer loaded.
  • Sector change performance tweaks to make switching sectors a seamless experience.
Further information:

As part of the decoupling, we've switched block data to off-heap memory (unsafe native memory). This is a lot faster in pretty much all operations. Memory for block chunks is preallocated in one big chunk of memory. This is so the access speed is as fast as possible by reducing cache misses.

It is then segmented for maximum optimisation for memory I/O. For writing, a second chunk is allocated as a buffer and memory can be copied over and queued up to be written. That copy operation is extremely fast, and that subsequent disk I/O operation would be done completely independently in another thread without the need to sync. The only thing we need to make sure of is that the object does not get unloaded while it's writing. This wouldn't cause a bad write (the data is already copied), but a load would read old data. The current system already has the same conditions, so nothing actually changes there.

The drawbacks for this are that if something does go wrong, it goes spectacularly wrong. So far, there does not seem to be any issues since switching to unsafe native memory. Excitingly this same procedure can be used to speed up other aspects of the game, such as lighting calculations. And since the new planet generation is written in C++, we can potentially eliminate overhead of passing arrays back and forth, since we can just tell the C++ library the memory address to store a chunk in.


What's coming up:
  • New universe creation details, creating an ultimate goal for the game, conquer the galaxy! This would be a separate gamemode from our standard sandbox experience. Compacting resources and gameplay into a central area.
  • Population system plans. A new "resource" to fuel and grow an empire, represented by physical NPCs!
  • New planet discussion and screenshots of some of the planet work we've currently got in development! 🪐
--- Below is the more detailed discord posts about development done ---

October 30th

likely starting on the write/read overhaul now. The goal is to eliminate lag etc from sector changes, making sector changes in general something that can be hidden internally, and instead use a more simple region system for the game (as was planned)
This update would incorporate different things
step one would be the decoupling of data accumulation and the actual writing. Doing that will enable putting removing any necessity to synchronize the writing thread during the actual writing, making I/O operations not affect the game at all.
The second one is the system that marks objects of a sector for writing as well as the spawn/cleanup system for new sectors and for sectors no longer loaded
The third one would be the actual sector change, making that as smooth as possible for the player.
This is likely one of the biggest parts of the universe update. because once that is in, i'll be able to restructure the universe.
After that I'll likely work on the new planets. I'm aiming to have both done so I can give a small snapshot this year. This snapshot version would be completely dysfunctional of course, but hopefully people could test out some of the new stuff under the hood.


October 31st

as part of the uncoupling, I'm switching block data to off heap memory. This is a ton faster in pretty much all operations. it's pretty unsafe in case of mistake. However it is worth it. So the plan is that memory for block-chunks is preallocated in one big chunk of memory which is then segmented for the maximum optimization for memory I/O. For writing, a second chunk is allocated as a buffer and memory can be copied over and queued up to be written. That copy operation is extremely fast, and that subsequent disk I/O operation would be done completely independenly in another thread without the need to synch (only thing is to make sure the object doesn't get unloaded while it's writing. not because that would cause a bad write since the data already copied, but because a load would read old data. However, the current system already has the same conditions anyways, so nothing really changes there)

Happy Halloween!


1st of November

Alright, chunk data is now running on unsafe native memory. So far there seems to be no issues. I added a manual range check just for debugging, which can be deactivated later for another little performance boost. It's now also possible to speed up some other aspects using the same tech (e.g. the lighting calculations)


4th of November

Still in the middle of memory stuff. But this is the kind of stuff i love doing most in programming.


7th of November

Ok. Got a nice manager going for the chunks stored in native memory. Memory will be reused as chunks get unloaded. Also protection against leaks my making sure that every chunk unregisters itself from that page.
This is also one huge chunk of memory, which means that access speed is as fast as it can be, by reducing cache misses.
Wouldn't get the same result with a heap array, since it is not guaranteed to be one continuous chunk of memory even. There is a flag for java to use big memory pages, which helps a little. This flag of course is only relevant for the heap. However, the chunks are now outside of the heap in spooky scary manually managed memory.
Using this kind of memory completely bypasses all java heap functionality, including garbage collection. The advantage is of course a fastest possible access speed, the disadvantage is that IF something goes wrong, it goes wrong spectacularly. With raw data as blocks, the potential of complete meltdown is relatively simple, as long as you make sure you only address the memory you allocated.
You could also store whole objects etc on there in which case any misstep would lead to catastrophe from random fields changing to complete object corruption.
Another nice side effect is, that since the new planet generation is written in C++, we can potentially eliminate the overhead of passing arrays back and forth since we can just tell C++ library the memory address to store the chunk in.]]>
Audio system finished, GUI scaling and better resource loader! [11 OCT - 29] https://starmade-servers.com/blog/77/audio-system-finished-gui-scaling-and-better-resource-loader-11-oct-29/ https://starmade-servers.com/blog/77/audio-system-finished-gui-scaling-and-better-resource-loader-11-oct-29/ Sat, 23 Nov 2019 14:05 CET Image is of USS Endeavor, by Wilavid7[starmadedock.net]. You can check out the progress of his ship here[starmadedock.net].
Background image taken by 12yanogden[starmadedock.net].


This is the third universe update dump copied from our official Discord server, in the channel #universe-update-dev-news-dump. To receive universe update news as it happens, join our Discord channel here: Join the StarMade Discord Server![discord.gg]

Previous Discord dumps:
TL;DR

Between the dates of the 21st of October - 29th, the following was done:
  • Audio system finished.
    • Remote audio events now implemented, allowing the server to send an audio event. These events are only sent to players in range of the actual source of the audio (with the option of sending globally). Saving bandwidth and removing a potential area for bugs.
    • Advanced audio events implemented.
    • New audio settings integrated. SFX is split up into sub mixers for GUI and in-game (engines, explosions etc.) allowing more control over audio volumes.
    • The only thing that's left is bugfixing and actually creating a soundtrack and SFX to put into the game and subsequently assigning them to audio events.
  • Settings redesign, cleaner code, slightly faster access to settings and a ton more versatility. Since the system has been changed, settings will reset when this update hits. Old settings.cfg files will not be compatible (server.cfg will be compatible). This is needed to integrate audio settings into the game and also paves the way for GUI scaling.
  • GUI scaling work began, updating the settings system makes it a lot easier to handle. Settings menus now have GUI scaling (see images below).
  • Refactored and modernised the resource loader (for loading audio, images, meshes, textures etc.) Now more modularised and robust.
What's coming up:
  • Overhaul of the individual block system. Putting all block variants into a better structure (wedges etc.), and an LoD system! LoD (level of detail) system basically decreases the complexity of a 3D object, for StarMade this would simplify a cube mesh to make a low poly representation of chunks. This should drastically increase rendering thoroughput, giving a performance boost and potentially allowing us to scale new planets up a bit.
  • Write/read overhaul, massive performance increases! Moving chunk data to unsafe native memory.
  • New universe creation.
Looking for screenshots!

We're looking for StarMade screenshots to use in promotional materials and on the Steam library/store/news. Post your screenshots here: https://starmadedock.net/threads/screenshots-for-official-use.31422/


--- Below is the more detailed discord posts about development done ---

October 21st

The integration of the settings redesign is still in progress. Still gotta adapt a good chunk of settings references. Payoff is a much cleaner code, as well as a slightly faster access to settings, as well as a ton more versatility (settings can be any type now)
This of course will mean that all settings will reset when the update hits, but they would anyways. old settings.cfg files will not be compatible, server.cfg will be compatible however (even though it now runs on the new system)


October 22nd

Not much news. Still adapting the code. SHould be done with that today or tomorrow

Had to switch to a different IDE, as my current one keeps freezing on a class.

Once i adapted it, it was all fine again


October 23rd

Yeah looks like eclipse does NOT like enums using lambdas in the constructor.
However. I'm all done with the settings refactor
spread over 4 commits it was quite sizable
713 additions and 420 deletions.
1,233 additions and 657 deletions.
152 additions and 278 deletions.
2,590 additions and 3,487 deletions.


October 24th

updating the setting system made it a lot easier to handle the GUI scaling. This is the gui scaled for 4k (in 2k resolution, so it looks a bit oversized). There is also a scaling in between.




October 25th

Just spent about 3 hours on a bug involving clip areas checking in drop down menus. The problem was that the newly integrated graphics framework GLFW uses mouse Y positions counting from the top of the screen while the old lwjgl counted from the bottom.

Good results though. Now got nice drop downs and sliders in the options instead of having to click though every single selection.



(which was basically the requirement for the audio settings, so now i can include the audio mixer into the settings)


October 26th



the new audio settings. I split up SFX into sub mixers for GUI and ingame (engines, explosions etc) (to have more control over audio)


October 27th

Refactored and modernized the resource loader (for audio, images, meshes, textures, etc). Much more modularized, and robust.
Implemented the last steps for the audio mixers and successfully assigned the first few sounds and it works as intended ingame.
Only thing left is to test out the more complex sounds ingame as well as remotely triggered sounds.


October 28th

Advanced audio events are now implemented


October 29th

Remote audio events are now implemented (Server can send audio events. Those events are only sent to players in range of the actual source of the audio (with the option to send it globally, although it probably isn't needed since global event usually have a trigger on the clients anyways, so it can just fire directly).
This saves on bandwidth, and removes a possible source of bugs (sounds from distant parts in the universe playing).

This pretty much concludes the implementation of the sound system (minus possible bugs and actually assigning sounds for all the events. Assigning can be done by anyone (which was the goal here)) [/url]]]>
Audio system finished, GUI scaling and better resource loader! [11 OCT - 29] https://starmade-servers.com/blog/76/audio-system-finished-gui-scaling-and-better-resource-loader-11-oct-29/ https://starmade-servers.com/blog/76/audio-system-finished-gui-scaling-and-better-resource-loader-11-oct-29/ Sat, 23 Nov 2019 14:05 CET here.]]> More audio work! Universe update dev dump 2 - [11th of October - 20th] https://starmade-servers.com/blog/75/more-audio-work-universe-update-dev-dump-2-11th-of-october-20th/ https://starmade-servers.com/blog/75/more-audio-work-universe-update-dev-dump-2-11th-of-october-20th/ Tue, 19 Nov 2019 14:30 CET Image is of 116-2 Marksman[starmadedock.net], by MeRobo[starmadedock.net].

This is the second universe update dump copied from our official Discord server, in the channel #universe-update-dev-news-dump. To receive universe update news as it happens, join our Discord channel here: Join the StarMade Discord Server![discord.gg]

Previous Discord dumps:

TL;DR

Between the dates of the 11th of October - 20th, the following was done:
  • Continuation of the Audio Engine. Audio Manager's event tracer was completed, events represent an audio asset triggered by the game. Events come with special arguments for spatial properties as well as control indicators for start/stop/onetime.
  • Finished audio asset manager, which has a list of all available sounds. Ability to assign an (audio) asset to either a tag group or individual event ID, e.g. a GUI button sound might be assigned to a GUI button tag group. If we wanted to have one button with a different sound, we'd simple assign an (audio) asset to its individual event ID.
  • Worked on a music manager which will essentially work the same was as the audio asset manager, using the same tag system. It'll be a little different in that the player will have a collection of AudioTags that would describe its current state. E.g. if the player is near its homebase, it'd get the HOME tag, in enemy space the ENEMY tag, flying around would get exploration tags based on location e.g. a PLANET tag. There'd be tags for all sorts, such as pirates, other players, building, mining, factory and so on. We could play a custom soundtrack that suits each activity, adapting to the player's current gameplay. Music will not always be playing, silence is as much a part of the space experience as sound.
What's coming up:
  • Overhaul of the individual block system. Putting all block variants into a better structure (wedges etc.), and an LoD system! LoD (level of detail) system basically decreases the complexity of a 3D object, for StarMade this would simplify a cube mesh to make a low poly representation of chunks. This should drastically increase rendering thoroughput, giving a performance boost and potentially allowing us to scale new planets up a bit.
  • GUI work, most importantly GUI scaling to support larger resolutions.
  • Resource loader refactor (for audio, images, meshes, textures, etc).
  • Write/read overhaul, massive performance increases!

Looking for screenshots!

We're looking for StarMade screenshots to use in promotional materials and on the Steam library/store/news. Post your screenshots here: https://starmadedock.net/threads/screenshots-for-official-use.31422/

From the last post, soundcloud link to our soundtrack in progress: https://soundcloud.com/danieltusjak/sets/starmade-demos-in-progress


--- Below is the more detailed discord posts about development done ---

October 11th

First part of the manager is done, which is the event tracer



next step is to be able to click on events and have the all details.
After that is an audio asset manager (to have a list of all available sounds)
Then the ability to assign an asset to either a tag group or an individual event ID.
After that would be the advanced event handling (start/stop, spacial, etc), as well as more options like volume, range, layered range (multiple asset assignments and playing different sounds depending on range)
No promises, but goal is to finish this by sunday

After that I'll enhance the manager with the music manager which will work the same essentially, using the same tag system but with a different kind of dynamic.
the player itself will have a collection of AudioTags that would describe the players current state:
If the player is close to his home base for example it would get the HOME tag, if they are in enemy space the tag would reflect that as well.
if they flew around a lot, especially into unknown terriory, they would get EXPLORATION, and tags on location like PLANET etc
If they fight they would get a FIGHT tag for a while, plus another tag on what they were fighting against e.g. PIRATE or PLAYER
More tags would be BUILDING, MINING, FACTORY, etc

The actual music playlist would then adapt depending on what tags the player currently has. it would also keep track so that songs are not repeated too much.

Music wont be constantly playing, too.


October 12th

Alright, most of the structure work is done. The data is structures into 4 data structures:

* AudioEvents: as explained above these represent an audio event triggered by the game. They come with arguments for spatial properties as well as control indicators for start/stop/onetime

* AudioAssignment: Comes in 2 types (TAGS, MANUAL). An assignment holds a AudioAsset and AudioSetting. One assignment can be assigned to multiple AudioEvents. Each AudioEvent holds an AudioAssignmentID which holds the type as well as a reference to the assignment. These are resolved on startup from the config so access is in constant time.

* AudioAsset: This represents an interface for anything that can play/stop. Be it an mp3, ogg, wav, etc doesn't matter. An audio asset can also be a composition of multiple assets for layered audio. They also determine the resource loading way (preload/streaming)

* AudioSetting: Is part of an assignment and determines the play settings for the audio (loop, volume, start/end times, radius, pitch)

On startup all events are read from config as well as all assignments. They are then resolved so each event has an assignment (they get type "none" if nothing is assign, but default is play by tag)

The assets are read from config as well and cross referenced with the resource loader, so the sound files can be loaded. I likely give assets a different kind of tag to be able to load just GUI for the main menu for example).
So when an audio event is fired, the audio controller looks up the event and with that the assignment. This, together with the event arguments are then processed.
If it's a GUI sound, the assignment will reflect that (play for client at a constant volume independent from location)
if it's a spatial sound the argument will contain a reference to location.
if it's a looping spatial sound it will also keep track of the object it was spawned on, so it can be ended by a second "stop" event.

October 13th



the event manager is mostly done.
can now filter fired audio events (to for example only list events that dont have a sound attached to them yet).
The rest is relatively selfexplanitory.
you can use a tag assignment, an individual assignment, or you can turn sound off for this event.
If you change the event by tag, all events using that assignment use that change.


October 14th





Alrighty. The manager is mostly done. Just have to implement some smaller things.

Essentially, audio assets are now meta, but can be created automatically from a directoy.
each asset can then be edited directly (the way it is loaded, basic volume)

When an event plays, the actual volume would be the volume of the event times the asset volume and optionally the spatial volume.

Audio assets can be just dragged onto the asset fields of an event.

The asset loading is somewhat self-aware in that if you add new files or move files it will try to reuse the existing data using file hash codes.


October 15th

Integrating the system into the new Audio System I have already done. When finished you will be able to test audio, as well as different paramaters on the fly. The sounds would be handled just like it would be ingame so it's all fully setup at that point.


October 16th



we got sound. spatial and effects are working well.
spatial only works with mono (since it has to be a singular point source), so im working on a converter in the meta data, so you can just switch mono on/off depending on what you use a sound for.

October 17th

had to do some general fixing for the config load/save, since this whole data structure has become quite complex. It will pay off big time in time saving from here, though.
Might still need another view with all possible evens listed, to get a good idea on how many events still need a sound attached.


October 18th



Working on music now. Essentially every track gets tags
The client will emit tags dependent on the player's state
the music with the most common tags will play next. Tags have a refresh time and a max time they can be active
if more than one track is selected for the same set of active tags, the track that wasnt played recent is played
I hope the whole sound system is finished by sunday.
Next up is the overhaul of the individual block system. Putting all block variants into a better structure (wedges, etc), as well as the LoD system, since everything is very spread out at the moment and it's hard to track bugs. Stuff like this usually happens when you dont plan for extensions of a system (since this system was very early on). This whole overhault will hopefully not take long, since it's mainly refactoring existing stuff.


October 19th

Alrighty. Code has all the music tags and the system is almost ready to go (will still need to import the actual music, but that is just a matter of copying the files and clicking on checkboxes)


October 20th

Implementing Audio Mixers and submixers, so volume can be managed. This lead to a complete refactoring of the settings system upgrading to a new system I have prepared eariler that year. My IDE is giving me some problem randomly crashing and freezing but i'll get it under control. [/url]


]]>
Universe update discord dev dump - [1st of October - 10th] https://starmade-servers.com/blog/74/universe-update-discord-dev-dump-1st-of-october-10th/ https://starmade-servers.com/blog/74/universe-update-discord-dev-dump-1st-of-october-10th/ Sat, 16 Nov 2019 22:14 CET Join the StarMade Discord Server![discord.gg]

We'll be posting more of these dumps over the next few days to get up to date with where we're at now. All update news is available for reading in our Discord server. This post is for those of you not in our Discord channel.


TL;DR

Between the dates of the 1st of October - 10th, the following was done:
  • New network protocol implemented, which provides much needed optimisations. Message handling is easier to synchronise, resulting in less errors from multi-threading. NIO implemented, which works on native memory as opposed to heap. This memory is much faster to access from native functions. Finally an interface-driven callback/listener system, resulting in far less unnecessary calls and more control over what called which listener.
  • Audio Engine, designed in a way to be highly customisable, easily implementable into our existing codebase and focuses on performance. Also, allowing playermade soundpacks to be created. The system we're using can also be extended for particle effects and maybe even modding! Much work on the audio engine was done during this time, with many events in the game now having audio events attached to them.
You can have a listen to our work in progress soundtrack here: https://soundcloud.com/danieltusjak/sets/starmade-demos-in-progress

1st of October

Currently working on the network protocol, replacing it with a new one I've been working on for quite a while. This cleans up a lot of things and provides much needed optimisations. The biggest aspect is that message handling will be easier to synchronise, which should result in less errors resulting from multi-threading. It also utilises more NIO (new input output), which works on native memory as opposed to heap. This memory is faster to access from native functions, like a socket reading to it.


At the same time I'm removing every Observer pattern in the code, which was deprecated in Java 11. I'm replacing it with an interface-driven callback/listener system. This results in far less unnecessary calls as well as much more control over what called which listener. I already wrote all of the network code for a separate framework, so all that needs to be done is to integrate it into StarMade.


2nd of October

All the above was completed after 14 hours. The refactoring was quite massive, 369 changed files with 5,733 additions and 7,207 deletions.


3rd of October

Ok, so after much thought, these are the requirements I want for our audio system:
  • Ease of use, one of the hardest things is to organise sounds in groups, so that you can assign a sound to multiple events of a similar type. For example, assigning one sound for all OK buttons. However, it should also have the freedom of being granular so that we can assign a sound for an individual action if needed.
  • Code clutter, putting out an event for audio should not take more than a line, and also auto manage itself into a meta state, so that audio can be assigned within a config and a tool.
  • Management: Tools for audio that handle the assignment, type and parameters of the sound.
After a lot of more complicated approaches, I've finally found a simple one that satisfies all of these requirements. Not only that, but it is reusable for other things as well.

I'm going to use a tag system in combination with a pre-processor. What that essentially means is that all audio events don't take more than a line of code. Simple broad grouping can be made with tags like GUI, OK, WEAPON, BEAM, CANNON etc, adding more as needed. Each tag also has a hierarchy weight so they can be sorted (GUI > OK).

This assignment will be done using annotations, prepping it for the pre-processor, which will then read the code.

The pre-processor will then auto-assign unique numerical IDs to each line that fires an audio event (maintaining and updating old already assigned ones, removing deleted ones, and adding new ones into a config database). In-game, all that line will do is fire the numerical ID, which means it takes minimal overhead.

What happens with the event is then decided by what is assigned in the config to that ID. The config will be read at startup, so all audio events have an endpoint.

The config can then be edited with in-game tools. Essentially you get a list of tag groups like this:

ID 2342: GUI, MAIN_MENU, CLOSE with some more context autogenerated from the preprocessor (class and package name of the event origin).

Audio is assigned to combinations of tags instead of individual events most of the time, even though individual overwrite is always possible.

The tool will also have a feature to display what events just fired. So if you do anything that still needs a sound attached, the tool will live display it. This should be the best and fastest way to give everything a sound with minimal organisational effort and minimal code clutter.

All the sound modification can be baked into the config too (eventual pitch, length, optimisation parameters) as well as attaching a position to a sound. It would just fire the sound with positional data as well as a control option START/UPDATE/STOP.


4 hours later

Alrighty. All GUI actions should have an audio event attached to them that should be tagged the right way (I'll make it so i can flag possibly wrong tagging later and change it to auto reflect back into code). Another big refactor (2,029 changed files with 6,306 additions and 9,051 deletions)


4th of October

Today was fixing bugs with the integration of the new network code. The network code is fully working now. Going to do some more audio work in the evening.


5th of October

Did some more work to audiofy the code, for weapons/modules. In the meta data there will also be options to layer audio depending on distance (explosions sound different from far away than close up)


6th of October

More "audiofying" of events. Some smaller new requirements popped up for that:

  • Remote events that only trigger on the server but the client received a more general event (e.g. activation gate). It will use the same system (server will not trigger normal sound events but handle sending of remote ones. Just required more info on where to send the event to (object id etc)
  • Sub-ID for events. Some events that require state changes (start, stop), need an extra ID to handle events (e.g. beams fired and stopped) automatically
  • Ship Ambience: some blocks will emit ambient sound (like reactors, factories, thrusters, etc). The same system is made to handle those, but an extra layer of management to automatically start/stop as well as update sound events for block collections (<- I'm here)
After this, I'll implement the meta layer, and the preprocessor to assign the ids for fast processing, as well as the remote event handling

One nice thing is that this system can be reused for general event handling, e.g. particle systems and possibly modding.


7th of October

Just implementing the ambience manager still.


8th of October

Alright. A lot of things have audio events attached to it now, including metadata of keeping track of events that need to be started and stopped. Now I'll implement the pre-processor function that will read all the events in code and attaches an ID to it, as well as transferring it into a ID->Event config. After that the tool to attach an actual sound to an event can be made.


9th of October

During my research I found javaparser/javaparser[github.com] which seems to be perfect for preprocessing. I've read the documentation and did a few examples during research.

It is a very powerful tool that essentially parses java code and puts it into a meta model.

So instead of having to parse each file line by line using regular expressions specifically for the function calls, which in this case would be a mess and quite error-prone, I'm using this library which does all the parsing for me.

It gives you a complete tree of your code, including symbol solving (metadata from imports), so you can just search for the specific function, extract all arguments, and modify the data, and output into code.

So what I'll be doing is looking for calls of "fireAudioEvent", which has multiple versions depending on complexity. The simplest ones are client global events for GUI audio, like clicking a OK button. In this case the arguments of this functions would just be the audio Tags AudioTag.GUI, AudioTag.BUTTON, AudioTag.OK etc. What the preprocessor would do is assign that event a unique ID, then it would put that ID and the tags into a config file. After that it would change the function fireAudioEvent to fireAudioEventID which only has that ID as an argument. Any future changes of Tags would be done in-editor which modifies the config file. That means the meta way to specify the function is just the entry point to classify the audio event initially. Any event can of course be easily reverted to its original state.


3 hours later


Alrighty. Got that working.

For a test class this would be the snippet in code:

...

fireAudioEvent(AudioTags.GUI, AudioTags.BUTTON, AudioTags.PRESS, AudioTags.HOVER);

...

as the simplest form of an audio event (a gui event that would fire when hovering over a button)

The parser catches that call and makes sure it is indeed that method being called by resolving the type (so essentially this wouldn't fail even if I had the same method name declared somewhere else).

It produces a new entry, which is then saved to the config as

<Entry>
<Id>1</Id>
<Version>1</Version>
<Tags>
<Tag>BUTTON</Tag>
<Tag>GUI</Tag>
<Tag>PRESS</Tag>
<Tag>HOVER</Tag>
</Tags>
<Name/>
<Param>ONE_TIME</Param>
<IsRemote>false</IsRemote>
<HasArgument>false</HasArgument>
<Output/>
</Entry>

(The output tag would be where all the data on what to do on that event goes)



At the same time the code id modified using the new ID:

...
fireAudioEventID(1);
...

So performance-wise, there is close to no overhead from the system itself since all it's going to do in-game is call a function with an ID.

For the editor in-game you will have a list of events fired available. So when you hover you would see this event with the ID 1 being fired, you would then click on that and either directly assign a sound individually or assign a sound to that set of Tags, which would then cover all hover sounds unless it's been overwritten by an individual assignment for that ID.

next up is implementing the more advanced calls that have context (sounds that need spatial information and/or context on what object it belongs to (e.g. an ambient sound that is emitted by a ship))


10th of October

Alrighty. Preprocessor is done and now we have a nice config file with 960 entries for audio events. Next will be the actual handling of audio events and the playing of sounds at the according times. [/url]]]>
Universe update discord dev dump - [1st of October - 10th] https://starmade-servers.com/blog/73/universe-update-discord-dev-dump-1st-of-october-10th/ https://starmade-servers.com/blog/73/universe-update-discord-dev-dump-1st-of-october-10th/ Sat, 16 Nov 2019 22:14 CET here.]]> Modding + QuickFire balance (dev build v0.202.0) https://starmade-servers.com/blog/72/modding-quickfire-balance-dev-build-v02020/ https://starmade-servers.com/blog/72/modding-quickfire-balance-dev-build-v02020/ Tue, 20 Aug 2019 13:08 CEST
We've released a dev build that introduces two things:
  • Implemented QuickFire balancing project configs as default.
AND:
  • This build has been (mostly) unobfuscated, to reduce the barrier for our community to mod StarMade.
See image below for how to install the dev build.



In the next dev build, we will be fixing issues with beams and possibly changing shield mechanics to a customizable shield system (using rectangular dimensions instead of spheres. A bit like the ancient docking zones). This will enable ships to customize their shields a lot better.

Also, the build GUI will be cleaned up and simplified to reflect the config (a lot lighter since distance/bonus etc can be removed). Overall this will make building , in‌ ‌general, lot simpler.


Modding


In an effort to make modding more accessible, we've decided to take a few steps that don't take us a lot of time to implement, but have a massive impact.

What we've done so far:
  • As of dev build v0.202.0, StarMade is unobfuscated. (Apart from the new planets scheduled for release in the universe update.)
  • From the 8th of August till today, we were distributing unobfuscated builds to modders that requested it (this is no longer needed).
  • Opened a discord channel for modders to communicate what they need to make their projects easier/possible. We want to make sure there's a strong relationship between Schine and the modding community.
  • Invited members from our own modding community, as well as those from outside it to give their input on how we should go about supporting modding in StarMade.
  • Released our game's launcher under the MIT license on GitHub. We saw some of our community were trying to modify it to add mod support, so we thought why not release it. (Schine/StarMade-Launcher[github.com])
  • Granted git repo read access to the current lead ([USER=417003]NZSmartie[/user]) of a modding toolchain and API for StarMade, DistortSM. Also granted the same permissions to gabizou, a lead developer for Sponge (Sponge - Minecraft: Java Edition Modding API[www.spongepowered.org]) who has expressed interest in helping StarMade modders.

A modding proposal based on the input we received from modders has been created by Zidane and Gabizou from the Minecraft Sponge Team[www.spongepowered.org]. You can check that out here[docs.google.com].

We plan to follow this document when implementing further modding support over the coming months.

Modpack considerations/proposals have been made by progwml6 and Benevolent27 here: modpack format[docs.google.com]

The input we've received has been keeping in mind the following:
  • We want to eliminate as many barriers as reasonably possible before our next major update (universe).
  • We want to focus most of our efforts on the universe update. However, suggestions that don't take a lot of time for us, but make modders lives a lot easier are fantastic.
  • Ideally, we can continue to add/modify things that would aid in mod development during/after the universe update.

If you're a modder and would like to give your input on modding in StarMade, we'd love to hear it over on our Discord #modders-dev channel here: Join the StarMade Discord Server![discord.gg]

Alternatively, you can email DukeofRealms here: tai@schine.games


Thanks to all the modders who helped us

We received a lot of useful feedback and input from modders, we'd like to thank those that helped us so far here:

The Fabric team[fabricmc.net] (asie[github.com], sfPlayer1[github.com], Prospector[github.com], Grondag[github.com] and modmuss50[github.com]) who have given us very useful advice for modding, specifically with regards to mod-loaders. Also for accommodating changes to fabric-loader to help DistortSM, a StarMade fork of some of Fabric's projects. Also, thanks to asie for pointing us in the right direction and giving us solid advice to base our ideas for modding support off.

The Sponge team[www.spongepowered.org] (Zidane[github.com], gabizou[github.com], progwml6[github.com], jamierocks/jmansfield[github.com], Katrix[github.com] and Snowie[github.com]). Zidane and gabizou for creating the StarMade modding proposal google doc, putting a lot of their own effort/input and collecting others' input from our Discord channel into the document. progwml6 for putting a lot of thought into the security and specifics for mod syncing and modpacks. Katrix and Snowie for sharing their expertise about mod repos, from their development of the Sponge mod repo (Ore).

Thanks to kashike[github.com], DemonWav[github.com], madmaxoft[github.com], darkhax [github.com]and Clienthax[github.com] for joining our Discord modding channel and giving their input on StarMade modding.

Thanks to Benevolent27[github.com], Alendon[github.com] and TheDerpGamerX[github.com], members from our own modding community, who have provided invaluable feedback and are working on some awesome projects.

Special thanks to all the people below for enduring the endless number of questions and conversations about modding:
  • asie[github.com] - tons of feedback about modding and considerations we should take about our policies.
  • jamierocks/jmansfield[github.com] - above and beyond answering our questions and giving feedback, even in an hours long voice call! Went through an unobfuscated build, giving feedback and input.
  • gabizou[github.com] - Gave a ton of input in Discord DMs and our Discord channel. Went through an unobfuscated build, giving feedback and input.
  • Zidane[github.com] - Gave a ton of input in Discord DMs and our Discord channel. Started the mod proposal google doc, which is very comprehensive.
  • progwml6[github.com] - Gave a ton of input in Discord DMs and our Discord channel. Created the modpack google doc with Benevolent27, which goes into details that we never would've thought of.
  • jaredlll08[github.com] - Gave a ton of input in Discord DMs and our Discord channel.

Finally, NZSmartie[github.com] for starting the DistortSM[github.com] project, which aims to provide a working mod loader (which they've achieved) and a community created API. He's worked with us to help bring modding into StarMade, getting involved in many conversations. He's been a massive help to kickstarting a StarMade modding community.

I’ve tried to include everyone if I missed you, I’m very sorry, we’ll rectify it ASAP :)



QuickFire project

QuickFire is a community-run project to balance a wide range of systems/features in StarMade. This is done through our extensive configuration files.

For more details about the project, check out our news post about QuickFire from last week here:https://starmadedock.net/threads/cs-quickfire-initiative-rebalancing-starmade.31361/

Important details:
  • "Quickfire's configs will not work with vanilla ships. Power costs and proportions of systems and weapons are very different from vanilla, and desirable armor configurations in vanilla (i.e. very little, if any) are potentially very different from what may work well in Quickfire. Some chamber setups will need changes as well. Using this config means a full refit of systems on any existing ships & stations." - QF Team
  • Community-run and always seeking feedback, suggestions, testers etc.
  • We've put their changes in a dev build because we want to bring exposure to the project, so they are able to get feedback and improve their config. So please give them your feedback in either their Discord server (Join the Starmade Quickfire Initiative Discord Server![discordapp.com]) or forum thread (https://starmadedock.net/threads/the-quickfire-initiative-rebalancing-starmade.31326/).
  • QuickFire configs are always changing, as further testing and feedback are done. Values in this dev build will likely be different in a few days after this news post, a month from now it might be very different. To test the latest QF configs, join their server here: QuickfireSM.com:4242
  • The goal is to eventually implement well-received config changes the community has made, provided they reach a state where both our community and we are happy with them. This does not necessarily have to be the QF config changes; however, this is the most popular (and only) config pack so far. The QF team have put a lot of effort into their config, reaching out to many different members of our community. They've been testing and taking feedback to create balanced gameplay. Ultimately, we understand that not everyone will be able to come to a consensus on what the "best" settings will be. Whether this is adopted into our release branch depends on your feedback, so again, please give some :)

Check out our news post about QuickFire from last week here:https://starmadedock.net/threads/cs-quickfire-initiative-rebalancing-starmade.31361/

Important links:

Thanks to the QuickFire team and all those who have/will contribute to the project. We will be adding names to this post and future ones when we get a list from the QF team :)


Thanks for playing StarMade,

~ The Schine Team]]>
CS: Quickfire Initiative: Rebalancing StarMade https://starmade-servers.com/blog/71/cs-quickfire-initiative-rebalancing-starmade/ https://starmade-servers.com/blog/71/cs-quickfire-initiative-rebalancing-starmade/ Mon, 12 Aug 2019 23:52 CEST This post is a Community Spotlight (CS), where we're bringing attention to cool community-driven projects for StarMade. We'll be posting some more of these in the near future.

Check out the "Discuss with the Devs" that happened in our official Discord last month here: https://starmadedock.net/threads/discuss-with-the-devs-july-18-2019-sis-shortform.31343/

---

Quickfire Team:

Quickfire is a community-run project to modify the game’s configuration files for a more balanced, fun, and interesting game experience. The QF team consists of members from every part of the StarMade community, including several veteran PvP specialists, creative builders with technical knowledge, and a long-time administrator of one of the most historically popular StarMade servers, as well as several other veteran StarMade players.


While the mechanical changes that can be made within configs are somewhat limited, we have done our best to correct the issues the community has been having with the current game and enhance combat gameplay. The Quickfire Initiative has also worked with Schine on refining certain game mechanics (e.g. armor stacking). We have, at the same time, made an effort to avoid undermining key design elements of the power and weapons updates (e.g. the chamber system and arrangement) when not absolutely necessary.

We have also played a key role in testing, tracking down, and confirming several critical bugs with weapons and systems, which were fixed in the most recent patches.


Quickfire has created a config package that includes everything from fine-tuned missile guidance to rebalanced chamber costs. Every system in the game has been looked over and re-tuned to address various balance issues brought up by the community and/or our team members.

We have also adjusted or modified all of the weapon combos, with the goal of creating greater diversity, viability, and utility for each where possible. Weapon changes include eliminating the troublesome cursor recoil mechanic from cannons, significantly improving acid damage application from beams (reducing the need for output spam), adjusting missile guidance, flight speed, and turn rate, and eliminating the extremely exploitable Death Beam.


Currently, we have addressed most of the issues and features that we intend to (aside from some minor tweaks), and have a configuration set available for testing. We are now in the phase of refinement and testing, and for this, we need the community! Feedback, suggestions, and thoughts on our settings for weapons, systems, and chambers are welcome, and will help us improve and refine the Quickfire Initiative’s configs and make StarMade a better experience for everyone. Our in-progress configuration set is available on a public Github[github.com] (updated often), and we also have a public creative/test server running our configs, at QuickfireSM.com:4242.


You can find an overview of Quickfire’s changes in this document[docs.google.com]. A longer, more complete list of changes and the explanations behind them is available here[docs.google.com].


If you have feedback, suggestions, questions, issues, or other comments about our config set, please post them in the project thread[starmadedock.net]. You can also join the Quickfire Initiative Discord server[discord.gg].


---

Schine:

We'll be adopting the Quickfire config changes in the next week or so. At the same time, we'll also begin to start making efforts to lower the barrier for modding. We've been working with modders from our own community as well as others to come up with a plan to make modding StarMade much easier, without taking a big chunk of dev time from the universe update. If you're interested in modding StarMade, head over to our official Discord (Join the StarMade Discord Server![discord.gg]) in the #modders-dev channel.

If you don't get a chance to test QF configs out before then, we'll be taking feedback with the Quickfire project when we officially adopt their changes and continue to address balance concerns.

Thanks for playing StarMade,

- The Schine Team]]>
Small Status Update https://starmade-servers.com/blog/70/small-status-update/ https://starmade-servers.com/blog/70/small-status-update/ Thu, 20 Jun 2019 03:12 CEST
sorry for the long time without an update. There was a lot of smaller technical stuff, as well as some research and other projects which made it hard to talk about specific things. What I can do, however, is give you a summary about the upcoming items we’ll be working on for the Universe update in the following months:
  • Graphics Engine Update
    • Switch to deferred rendering for dynamic lighting: Deferred rendering will greatly increase the quality of rendering as it allows for a lot more light sources than forward rendering. The nice thing about this is that it will be possible to use the prebaked information as part of the deferred rendering to simulate ambient occlusion. And since even deferred rendering has limits in terms of light amount (around 50-100 light sources), we can use the prebaked system in a LoD system being able to still show unlimited amount of lights without slowdown.
    • Optimizations:
      • An all new backwards LoD system that will decrease the number of polygons very significantly.
      • Fast treebased occlusion culling, so areas that wouldn’t be visible can be discarded before drawing.
  • Block container revamp
    • This is basically refactoring how block types, rotations, etc are handled. This will make it much easier to deal with bugs and to introduce new blocks.
  • Block Engine Update
    • The load system for sectors will be revamped. The goal is to preload data more efficiently, so that sector changes would be virtually unnoticable.
    • Saving and the block save structure will be revamped to be more efficient and safer (more guards against data loss/corruption, as well as features to prevent newer players from losing work due to a ship getting blown up (automatic versioned save feature on ships))
    • Moving all block data to direct memory, as well as possibly moving more expensive functions to native c++ code (lighting calculation, saving/loading)
  • Audio System
    • Research completed on best designs. System will make it possible to live edit sound effects ingame
  • Particle System
  • AI
    • AI Collision System
    • AI LoD (Collision sphere sweeping)
    • Crowd AI (AI positioning without fighting over space)
    • AI behavior layering (macro actions like getting to a position in the universe and micro like fighting against another ship)
    • AI mission system
    • AI behavior
  • Universe recreation
    • New structure
      • Hirachial Region System
      • Region ownership system
    • New NPC structure
      • overall NPC behavior
    • Place of Interest creation
    • Key area creation
    • Area specification
    • New stellar objects
    • New planet injection
    • Difficulty flow (for single player)
    • Event System
    • Void System
  • Population system
    • Low level NPC population
    • Population resources
I’ll be talking more about each item during and after it is implemented (some of which are already partly done)

Thanks you for playing StarMade,

- The Schine Team]]>
StarMade V0.201.363: CONDITIONS, ACTIONS & FIXES https://starmade-servers.com/blog/69/starmade-v0201363-conditions-actions/ https://starmade-servers.com/blog/69/starmade-v0201363-conditions-actions/ Fri, 15 Feb 2019 15:52 CET
here is a small feature and fix update. There will be several of those along the universe update roadmap (roadmap blogpost on www.star-made.org). Durking the update, we'll be working ~1 week per month on fixes and small features (especially for the rule system), while spending the rest of the time on the universe update.

Universe update Roadmap News: On the universe update, we are currently in the middle of GUI scaling, and close to starting to implement the sound system.

This update features a lot of new conditions and actions. The system now supports rules of different types, depending on the target (players, factions, sectors, etc). Actions are transferable to other entities: e.g. if condition on a ship is true, you can execute a player action for all players on that ship.

Here is the full changelog:

UI

added minimize button to advanced build mode panels on the right

Rule System

  • Player Mod Faction Points
  • Player Set Faction Points
  • Entity Mod Faction Points
  • Entity Set Faction Points
  • DateTime fixes
  • Entity Weekly duration
  • FactionRules
  • FactionIsInRange
  • FactionAddFP
  • FactionSetFP
  • FactionHasMemberCount
  • FactionHasFpCount
  • Action Bridges
  • Entity -> Sector / Player / Faction
  • Sector -> Entities / Players / Factions
  • Player -> Sector / entered Entity / Faction
  • Faction -> Players
  • 'Entity system claimed by' condition
  • player warp to sector action
  • player set credits action
  • player mod credits action
  • player kick action
  • player ban action
  • player in sector cond
  • player say cond (regexp)
  • player send message action
  • player last joined condition
  • player kick out of ship action
  • player kill action
  • segment controller in sector range condition
  • all faction condition parameters now range
  • sector chmod condition
  • sector range condition
  • sector contains entity count condition
  • sector chmod action
  • sector admin command action
  • Added inverse conditions (condition group feature)
  • recurring actions
  • player: add credits over time
  • player: add blocks
  • player: add blocks over time
Fixes:

  • fixed missing integrity triggers
  • fixed beams not active on server when using logic to toggle them (logic salvage beam not working)
  • fixed linear reactor level calcs
  • fixed activatable modules not synching correctly (cloak drive)
  • fixed torch damaging stick shops
  • fixed error that would respawn Asteroids over and over if they were moved

Balance

  • blockBehaviorConfig now has global defense of blocks based on type (shield, armor, block) additionally to the previous individual block effect defense (which would be a mess to adjust)
  • Note: it's now possible to set defense value for all block types depending on if it's armor, normal or shield that is hit. The defense value is put against the offense value of the weapon. This now enables a balance where some weapons can be better/worse against shield/armor/normal
  • beams now use calculated armor values for damage reduction
  • Note: Beams now do damage calculations in a similat way as cannons in that the armor depth is calculated upon hitting a surface. The damage of the beam is reduced depending on armor thickness. Values have been added to config.
  • General Balance Note: The current config values for the new balance additions are currently experimental and in no way final


Thank you for playing StarMade,

- The schine team]]>
StarMade v0.201.337 LOD Blocks, Rule System, Balance, Fixes https://starmade-servers.com/blog/68/starmade-v0201337-lod-blocks-rule-system-balance-fixes/ https://starmade-servers.com/blog/68/starmade-v0201337-lod-blocks-rule-system-balance-fixes/ Tue, 08 Jan 2019 16:39 CET
  • Fix for servers with custom config coming up (not being able to move astronaut, crashes and other various issues this bug caused)
  • Fix for torch beam (didn&#39;t do enough damage to compensate for the fullhp encoding (has to do at least one byte of damage)
 
Hotfix#3 (0.201.340): 
  • Fixed possible crash when applying rules when entities apply changes at the same time
  • Fixed rail logic so only adjacent activation and basic button activate (still any logic block can be connected with c+v) (fix of hotfix#1 didn&#39;t apply yet)
  • Fixed crash in rule dialog (checkbox cleanup when the field wasn&#39;t initialized yet)
Hotfix#2 (0.201.339): 
  • Fixed error when spawning ships from blueprint items.
 
Hotfix#1 (0.201.338): 
  • Fixed missing icons for new blocks
  • Fixed rail logic so only adjacent activation and basic button activate (still any logic block can be connected with c+v)
  • Fixed manual turret aim to be off by default to fix AI mobs not firing their turrets
 



Hello players,

A new update is out. This will be the last major update before going into the heavy codebase changes of the Universe update. This will include updating lwjgl, java, and a lot of other things to their latest stable major releases, so a lot of refactoring has to be done. During this period until the universe update there will still be updates for the current versions along the way, but they will be mostly minor features, fixes and balance changes, as we will fully focus on the universe update from here.


 
Rule System
As said in the latest dev build, chasing a balance that would satisfy all types of players is nearly impossible, so the vanilla game is going to focus on the game as I envision it, while at the same time creating features so players can play the game like they want it to. Not only does this save a lot of time in development in the long run it also removes a lot of issues with balance since in the end it is subjective to the type of player.

 

The rule system is essentially the beginning of an in-game modding system. It is built very general from the ground up and will be able to support any type of condition/action imaginable in the game. It comes with a full GUI in the main menu and in-game, which is capable of uploading and applying changes automatically while in-game.

 

You can also import and export any amount of rules. This enables server admins to quickly setup a certain type of server without having to do all the configuration themselves. They can download and import anything they need.

 

This update focused on getting the rule system to run. It also focused on making rules as performant as possible, which means that a rule is only checked if any parameter of a condition for the targeted object changes. It has a fair number of conditions and actions already present but there will be a LOT more to add along the way.

 

Eventually the rules system will possibly also be used to create quests and other gameplay elements, so it can already be considered a very small part of the universe update in a way.


Tracking & Marking

With rules there is now also a way for admins to track ships. Conditions can be used to place a tracker on ships. Admins can also now mark ships. This is mainly for admins to manually check ships that trigger their conditions.

 

New Admin commands:
  • player_get_block_amount (fixed target inventory)
  • entity_set_check_flag
  • entity_is_check_flag
  • entity_track
(all commands also work with *_UID)

 
New 3D Assets
 

[i.imgur.com]

 

Saber and Kupu finished some beautiful new 3D assets. There have been slight tweaks to existing model unwraps and their textures, and many new additions. New models include (from left to right):
  • Grate Wedge (previous Grate Wedge has been renamed to Grate Slope)
  • Metal Corner and Metal Bar
  • Beacon and Colored Light Corners and Light Bars
  • Light Rods
  • Paint Cans and Resource Capsules
  • Small Button and Small Activator
  • Red, Orange, Green Consoles and Console Inner and Outer Corners
 

We also improved the block editor to make it a lot easier to import and create new 3D assets.

 

Additionally, some 3D assets now have different states when they are activated. We will expand that eventually to full animations on blocks for actions or just them being in idle state. This means you will be able to place animated modules on your ship.

 

*Paint Cans and Resource Capsules have had their default orientation rotated 90 degrees so they place vertically like the Pipe model. These will need to be replaced in old builds.*


3D Collision Meshes

3D assets now have full detail collision detection for astronauts as well as small enough projectiles/beams. This means you can now even shoot between the bars of grates.


 
Balance
Two major changes to balance are:
  • Stabilization beam between reactor and stabilizers is removed
  • Integrity is removed
However, with the rules system both of these functions can be restored.

 

We’re currently working with community members on the Quickfire discord (a community driven initiative to help balance StarMade) to bring the games balance into a good state. The first step of doing that was to fix some essential bugs as well as provide more config capabilities and mechanics.

 

Here are a few major and some minor changes to the balance already:
  • Removed integrity (can be re-added by rules)
  • Remove reactor stabilization beam (can be re-added by rules)
  • increased cannon speed from 25x to 40x server max speed
  • Increased armor bonus from 0.1 to 0.5 (bonus added on armor thickness)
  • Halved vertical cursor recoil
  • Beam damage reduction based on armor value of the block hit. 20% of armor value of block reduced per tick. (config option)
  • 2.5% flat cannon damage reduced if armor if penetrated (config option)
  • Config Option to add additional damage reduction based on armor thickness (currently unused)
 

There will likely be a lot more once the balance proposal is worked through. I have to disclaim though that I can’t promise that everything proposed will make it in.

 
Full Changelog
  • Rule System 
    • Full rule system with condition and actions to affect entities
    • Cascading Condition groups
    • Global rule assignment
    • Individual rule assignment
    • Full config export/import
    • Export/import of individual rulesets
    • Full GUI in ‘tools’ main menu
    • Full GUI ingame with live synch feature
    • New ingame file browser
    • Added basic conditions (more to come)
    • Added basic actions (more to come)
    • Tracking feature
  • fixed advanced build mode raytrace bug where an imprecise physics test would sometimes select the wrong blocks
  • fixed physics bug where cannon shots would sometimes skip a chunk and do damage inside a structure
  • 3D assets can now use any existing shape to be represented
  • 3D assets can now use any arbitrary meshes as physics mesh to be represented
  • 3D assets can now have activated state meshes
  • Improved pipeline for mesh import with the block editor
  • turrets will no longer be able to shoot through other docked entities (they won’t do damage to their docks)
  • improved fleet formation by refreshing ship sizes more frequently and taking ship size more into account for spacing between ships
  • Fixed Fleet not slowing down after move order (edited)
  • Added delay between weapon switches of AI. delay only applies to within type (from a cannon computer to another cannon computer etc.)
  • Added ai_weapon_switch_delay server config and admin command. 
  • added effect SHIELD_HOTSPOT_RECHARGE_MODE  to set to rely on recharge instead of capacity
  • added and exposed formula switching for power reactor
  • player_get_block_amount fixed target inventory
  • entity_set_check_flag
  • entity_is_check_flag
  • entity_track
  • all commands with *_UID
  • docked pull/push permission now saved in blueprint (edited)
  • server.cfg option to allow factories on ships (ALLOW_FACTORY_ON_SHIPS)
  • beacon light now is a flag in the block config
  • logic block is now a flag in the block config
  • updated loading screen tips to reflect game changes
  • Refactoring work
  • Increase missile tickrate to be more precise
  • Added and adapted server config missile target prediction value to prevent missiles from going after a target’s previous position. Added admin command /missile_target_prediction <ticks>. Make sure no missiles are spawned when using or those missiles might get confused.
  • Fixed race gates power usage
  • Fixed ‘draw beams’ game option
  • Self cleaning “waiting for for entities to dock” message for the case that the object isn’t in the db anymore. Reduced frequency of message for all other cases
  • Can now load blueprints directly onto docks
  • Server.cfg option to remove need to build shipyard structure (SHIPYARD_IGNORE_STRUCTURE)
  • Reduced roll speed to balance between rotational axis (more turn speed balance will come)
  • Orange and Blue Light Block color adjusted to differentiate from Yellow and Teal
  • AI ships now auto charge stealth drive (should fix fleet cloak/uncloak/jam)
Balance (all points are non final and might still change)
  • Removed integrity (can be re-added by rules)
  • Remove reactor stabilization beam (can be re-added by rules)
  • Balance: increased cannon speed from 25x to 40x server max speed
  • Balance: Increased armor bonus from 0.1 to 0.5 (bonus added on armor thickness)
  • Balance: Halved vertical cursor recoil
  • Balance: Beam damage reduction based on armor value of the block hit. 20% of armor value of block reduced per tick. (config option)
  • Balance: 2.5% flat cannon damage reduced if armor if penetrated (config option)
  • Balance: Config Option to add additional damage reduction based on armor thickness (currently unused)
If you find any issue please let us know in our discord and we will get get right into hotfixing.


 

We wish you an awesome holidays and a very happy new year,

Thank you for playing StarMade,

​- The Schine Team
]]>
StarMade v0.201.200 Cleanup, Fixes & Enhancements https://starmade-servers.com/blog/67/starmade-v0201200-cleanup-fixes/ https://starmade-servers.com/blog/67/starmade-v0201200-cleanup-fixes/ Sat, 29 Sep 2018 18:54 CEST
Since the weapon update there have been a lot of smaller updates along the way which fixed several issues and added smaller features. For this one, we wanted to make a seperate release announcement for some bigger features as well as more bug fixes.

 
Entity Sidebar
You now have have another tab on the left side of your advanced build mode. This can be used for quickly building up and managing a ship. It has all the previously missing information for weapons and other modules. There is a quick overview of what blocks you need and how many you have for each ship system. The build button will automatically put the block in your hotbar and select it to build. You can also choose to add blocks for an existing weapon, which selects the computer and puts the module into your hotbar.

 

In the future, this mode is going to be enhanced to be a non-intrusive tutorial for new players. When placing a ship core the buttons will light up to lead the players on what modules to build and how to build them. This eliminates the need to watch lengthy non-interactive videos or having to check on the wiki.

 
Build Mode Camera Drones
A long requested feature. Players can now be seen when in build mode. They will each fly in a small camera drone (made by Saber). These drones can also be seen if watching outside of build mode.

 

The drones come equipped with a flashlight (toggles on ‘P’ by default or in the display setting in adv. Build mode), as well as the option to display the name of the player below the drone.

 

 
Adjustable Cockpit view
Another long requested feature. It is now possible to adjust the view of your cockpit blocks individually. Just press ‘P’ while in a cockpit in flight mode to unlock the camera and freely move it. Press ‘P’ again to lock the new view in place. This mode is fully persistent, meaning it will not only save between sessions and apply for other players that fly your ship, it will also save within the blueprint.

 

Keep in mind that this mode is currently still a bit experimental, as there are some minor issues and more features coming for this. One of those features will be delayed camera movement to make flying a lot more fun all around, as well as HUD updates. There will be fixes to handle differently orientated cockpit blocks better as well as other fixes for the “aim at” check.

 
Block Editor Model Tab
The block editor has been cleaned up to make block editing a lot faster and easier.

An all new tab has been added for the Block Editor. This tab contains all information and management for the models in the game. This will speed up development and integration of models considerably in the future, especially for the universe update.

 
Textures
Kupu completed specular mapping, made a unique texture for the Area Trigger and the Cargo Space, Green Forcefield, as well as the Green Cascade deco block.

 
Logic Changes
Logic will now only transmit the end state of the blocks. Fast logic clocks caused over 500 state changes per update, which was not only a performance drain but also bandwidth.

 

To compensate for the necessity of having fast clocks, modules now stay active when a logic block is connected that was switched to active. Currently the activity will reset if the entity unloads, in which case the logic block would have to be turned off and on again. Persistence for that will be added in the next update.

 
Pin AI Targets
Pilots can now specify (pin) targets for AI targeting. When having a target selected, press ‘x’ in flight mode to specify this target for AI fire, while the pilot can select a different entity.


Bugfixes
The more important bugfixes will be listed first.

 
  • Possible Fix for missing/reverted chunks
    This bug seems to be finally fixed (can’t call it 100% fixed yet without long term experience on production, since we had no way of reproducing it). The bug was possibly caused by save events marking chunks as not validated on the server, but at the same time not queuing them for validation cause of another event at the same time. This caused those chunks to not be saved in that session.
  • Fixed all crashes due to malformed translation Strings
    If there was an error in a translation string format (e.g. using malformed arguments), the game would previously crash. These bugs would be fairly hard to track down since they would only happen in that specific language. The system has now been updated to compensate for those bugs and automatically replace the string with an error.
  • Fixed pirate/tg spawning when attacking a station
  • Fix for missing Area Trigger icon, + icons for new blocks.
  • Custom texture for cargo block in build mode
  • Fix for cargo draw issues (on transparent blocks)
  • Torch beam damage upped from 1 to 4
  • Fixed nullpointer on UI when active reactor changes
  • Fixed bug that would prevent newly spawned planets and asteroids from being saved when edited (existing ones had no problem).
  • Removed popup when opening storage
  • Added more info in the build mode entity info
  • Temporary shield disable now affects whole structure incl. all docks, instead of just the entity it was triggered on.
  • Fixed crash after setting the "Pull up to" value of Cargo to 0.
  • Turn rate config values exposed and explained in blockBehaviorConfig
  • Fixed custom block texture handling
  • Fixes map drawing
  • Fixes crash when changing certain graphics settings ingame.
  • Fixes shield message spam
  • Fixed client crash when shipyard anchor was removed when a design was loaded
 

 

 

We will release further fix and cleanup updates while we are working on the universe update. If you have an issue a request, please join the discord. We’re always ready to add smaller features as well as handle bugs when I get the necessary information.

 

Thank you for playing StarMade,
  • The Schine Team
]]>
StarMade v0.201.126 - Weapon Update https://starmade-servers.com/blog/57/starmade-v0201126-weapon-update/ https://starmade-servers.com/blog/57/starmade-v0201126-weapon-update/ Wed, 11 Jul 2018 01:58 CEST
As always, make sure to do a full backup on your world and blueprints. We tested both fresh installation and upgrade multiple times, and couldn’t find any problem, but there is always a rest risk in updates this big.

The weapon handling, projectile, and block processing code has been completely rewritten, as well as parts of the missile system, and a lot of other backend systems to improve performance and stability. This also allows for a lot faster development for these systems from here on out.

In context of the main focus of this update we also improved combat stability and performance a lot, as well as hopefully fixed most of the nasty bugs that were affecting ship combat in the last release.

There might still be some issues with some systems losing server synch temporarily under load, but those will be addressed in a follow-up cleanup update.
Features
We set out to do this update mainly to make combat and ship battles more interesting and fun. On the backend, this also gave us a chance to completely redesign the code of weapons and other usable modules in the game. A new code design was already partly set up with the power update, and this updates completes it.

To make a more complete package, new features and improvements have been added all across the board.
Weapon & Tool redesign
The goal is to make weapons and their combination a lot more unique, while still being a viable option. Some weapons might be easier to use than most, but others could have a much higher pay off when used properly. As each weapon combination has clear positives and negatives, it is up to you to decide what weapons to make.

We also wanted to give weapons and combat in general a better feeling. This incorporates a broad spectrum of features including the HUD, recoil, explosions, physical force, damage, armor, and many more.

While we changed and added on existing weapons, we did remove the damage pulse entirely as it had no real purpose. It also reduced the amount of combinations possible which allows us to concentrate more on the remaining ones.

 
Acid Damage model
Acid Damage is the new damage model used by Cannons and Beams to increase block damage without affecting performance. In our tests, this system allowed us to get 90-95% of the original damage to be applied as block damage, giving us the possibility of one projectile destroying thousands of blocks without running into performance problems.

 

This is achieved by propagating damage outwards, block by block, starting from an origin block.

The propagation speed can be adjusted to move faster or slower depending on the processing power and bandwidth of the server. Several bandwidth optimizations have been made to make the information on removed blocks as small as possible. As a result, even large amounts of blocks get processed quickly without any hiccups.

We can change its behavior while this is propagating as well, allowing for unique damage patterns to be implemented.

 
Cannons
Cannons are now mainly a high penetration weapon, capable of punching through thin armor and leaving a lot of damage in its wake.

 

Like before, each projectile has a penetration depth based on its damage. This can range from 1 to 200+ blocks. Each block in this penetration line, acts as the starting point for Acid Damage to start from. The damage of the entire projectile is then distributed accordingly to end up with the appropriate damage shape.

 

A general change to cannons is that all projectiles are now considerably faster, which will make battles at higher speeds a lot easier.
Over Penetration
Using cannons with too much damage can cause the projectiles to overpenetrate. This happens only when targets have little to no armor, compared to your shot. If this happens, then the penetration depth is stretched before the original damage is distributed on it. This may result in even more system damage...or it may come out of the back of the target and end up wasting most of its damage.

 
Projectile Width
By putting down blocks next to your weapon’s output, you can increases its projectile width. On impact, this will cause more damage to be redirected towards the front, basically shrinking your damage pattern and increasing its width. This can be used to counter any over penetration, or to destroy more superficial blocks if needed.

 
Recoil + Impact force
Every Cannon projectile applies a force on both the shooter and the target. The force and amount of movement created, solely depends on the weapon damage.

The physical recoil on your ship is in the opposite way of the firing direction, the impact force on your target is in line with the firing direction as you would expect.

There is also something we call ‘cursor’ recoil, meant to give a better feeling to cannons and reduce its accuracy slightly when fired manually. It’s kept at a manageable level, and scales properly with your fire rate and damage. There’s also a maximum cursor recoil threshold in place to make sure even the biggest of weapons don’t throw your aim around too much.
Cannon Combinations
The core idea of each combination is mostly unchanged, but they behave in different ways. It’s possible we still add or change parts of them depending on feedback, but the overall role of each support should stay the same.


 

  • Default: An all-around decent cannon, doesn’t excel at anything

  • Cannon + Cannon: Fast firing machine gun with fast projectiles. It uses the Cone: Wide-> Narrow damage shape.

  • Cannon + Missile: Charge cannon with left click to charge, release to fire. The longer it is charged, the better the efficiency and damage of that shot. It also uses the Cone: Wide-> Narrow damage shape.

  • Cannon + Beam: A slow firing artillery cannon with a narrow -> wide cone damage shape. Even when over penetrating, it will be relatively efficient, but it is hard to hit.

 

We’ve changed the Damage <-> Power consumed ratio to be different for each combination. It allows us to balance the high risk weapons to reliable damage dealing ones. A slow firing cannon is always more efficient, as a miss or a bad hit is a huge waste of time and power.


 

Each combination also has a default sniper zoom mode, toggled with right click. It ranges from 2x to 4x and greatly enhances accuracy on long range targets.


 

Some examples of the damage left by only a few projectiles:

~ High damage projectile: 



~ Multiple medium damage projectiles:

<iframe height="500" scrolling="no" src="https://i.imgur.com/UUjJZ5X.gifv" style="border:none;" width="888"></iframe>


Damage Beams
Damage Beams are mostly about doing surface damage and being easier to use. Beams only apply Acid damage on the block they’re hitting, damage will most likely not reach deep within the target unless you focus fire on a particular spot. The only exception to this rule is the Beam support version, where it does penetrate all the way.


 

We’ve improved the functionality of Beams to allow for that. Some versions are capable of traveling along its target without you firing or aiming it again, they’ll deal decent damage as well but may not necessarily stay where you want them to be.


 
Damage over Distance
Unlike Missiles or Cannons, beams lose damage with the distance from target. At maximum range, it goes down to only 40% of its original damage. This increases the closer you get, till it reaches the original value at about 400 meters or less. This can vary depending on the combination and allows us to better balance a hitscan weapon.
Combinations

  • Default: Latch on beam that breaks off when it has no direct line of sight with the current block.

  • Beam + Cannon: Aimable beam with short burst time and cooldown

  • Beam + Missile: Arc beam with a shorter range but doesn’t break when there is no direct line of sight anymore. Has a long burst time.

  • Beam + Beam: Penetrating beam that can’t be aimed with your cursor. The damage of the beam is distributed equally over the blocks in the penetration line. Requires to be charged before firing and stops your shields from blocking damage while you are charging.

 
Repair Beam
The repair beam or astrotech beam is now capable of repairing and replacing killed blocks. The reason this has taken longer is several problems to optimize this system for large scale, as well as handling the logic of connections. At the moment, you can only replace the blocks in order (as if you pressed “undo”), but out of order repairing will be added as a follow up.

If you connect any amount of storages to your beam computer, it will be using those for repairs. If there is no storage attached, the blocks will be taken out of the pilot’s personal inventory (if possible).


 

Keep in mind that for balance reasons you currently cannot repair during battle.


 
Tractor Beam
The new tractor beam replaces the push and pull beam of the previous release. This weapon is able to hold another entity in place. It can also move with you as you either rotate or move yourself while still firing the beam. It comes with a built-in mode change so you can push the target further out or pull it in. You can change the firing mode by pressing left alt (also now indicated in the context help).
Armor
Armor has been completely redesigned as well. There is no longer an abstract “Armor HP”. Armor now will count where it is and how thick it is, you can see this in build mode as well when looking at any armor block. Here is how it works:


 

  • When a bullet hits armor it checks how many armor blocks come behind that block in its path.

  • The count of armor will stop at any non armor block or air. That count defined the “armor depth”

  • Each armor block now has an armor rating that will get added up (with possible additional bonuses on thicker armor)

  • The resulting total armor value along the armor depth is then compared with the bullet’s damage

    • Is the armor value lower than the bullet’s damage, the bullet will travel on as normal and destroy the armor blocks along its way

    • Is the armor value higher than the bullet’s damage, the bullet will only do acid damage on the first block and stops completely

    • Is the armor value much higher than the bullet’s damage, acid damage is not even applied and only a single block gets normal damage and stops completely

  • This will be repeated for every continuous plate of armor the bullet goes through in a ship, so inner armor a very viable option

 

This means, that a sufficient armor depth can stop any shot, and it also means that it depends on the angle of the shot, where that armor is, and what type of armor was used. These values mainly affect the penetration of cannon projectiles although beam acid damage gets affected by the armor rating as well.


 

In addition, the HP of Armor has been increased to make it capable to absorb more damage.


 

You can check your armor rating in build mode by just looking at your armor while having any armor block selected on your hotbar. It will tell you exactly how deep and how much armor the ship has from the angle you are looking from. Note that the armor rating does not scale linear with thickness but has increased values for every added layer in addition to the flat amount of the block itself..


 
Missiles
Missile Capacity
To add another layer to using missiles, we added a Missile Capacity system that will also prevent you from spamming them. By placing missile capacity blocks on your entity, you increase the maximum amount of missiles to be stored. The missiles are reloaded in bulk, as soon as you fire a missile, the reload starts. When the timer runs out, all the missing missiles are filled up again.


 

For AI controlled ships, the reload only starts when they run out of missiles, this helps control the amount of missiles flying around.


 

In addition, you require additional power for the missile capacity blocks. This should normally not be a concern unless you’re deliberately trying to store too many missiles for your ship’s size.


 
Missile Shield + Point Defense Prioritization
Each missile has its own its shield, protecting it from Point Defence turrets. The strength of this shield scales with the missile’s damage and should also encourage firing more high damage missiles than trying to flood the field with low damage decoys.


 

We’ve also implemented proper anti-missile prioritization. You can set any of your AI to fire at a certain category first:

  • High damage missiles

  • Low damage missiles

  • Random (Closest First (old system))

 
Missile Combinations

  • Default: Fast non tracking missiles

  • Missile + Cannons: Heat-seeking swarming missiles

  • Missile + Beam: Lock-On Missiles

  • Missile + Missile: A bomb with no self-propulsion and uses the ship’s velocity as its own. The bomb will ignore shields and does friendly fire as well. It will arm itself after several seconds, it won’t detonate (dud) if it isn’t armed yet, so you can’t fire it at point-blank range of your target.

 
Volley Fire
Changing firing mode from focused to unfocused has been changed to a keyboard toggle for all weapons (default: left alt). We added an additional mode for cannons and missiles as well: Volley fire. This mode will take the time to reload the weapon, and divide it by the amount of groups connected to that computer. When firing, the groups will fire one after another.

Volley fire can also be set in the Bobby-AI module for turrets and drones to use.
New HUD graphics
The HUD graphics have been improved to improve usability and distinction between objects and improve the general look.

All indicators now also have been moved to the center of mass of entities. They will still be on the core if you are aligned or in gravity of an entity.


 
Undocking
Entities will no longer undock when their rail or rail docker is destroyed. However, until those are replaced at the exact position, or manually undocked and docked on a different one, the dock will not receive any power from the mothership.

This will greatly help with lag in larger ship battles, where the undocking of turrets and other docks was one of the biggest parts of lag-causing elements.
Improved graphical effects
The graphical effects for cannons, beams and missiles have been improved. Also more and better explosions have been added.

Also an all new LoD system has been implemented which is currently in use for the mines to be able to have a lot of them in one sector without problems. The system is written in a way that it can be used for a lot of other things in the future.


 
New Textures
Kupu has done an exceptional job in upgrading the texture to be more crisp than ever before, fixing many previous tiling issues and colour inconsistencies.
Lead indicator
Cannons and missiles now also have a lead indicator based on the selected weapon’s projectile speed. Currently the indicator is based on the target’s center of mass.
Effects
The old effect computers have all been removed as most don’t have a purpose anymore. We’ve replaced it with a 3 damage type system with base values for each weapon type:

  • Kinetic (Cannons)

  • Electromagnetic (Missiles)

  • Heat (Beams)

 

You can adjust the basic damage distribution of each weapon by linking it to the specific effect computer you want it to have.

There are also defensive reactor chambers to strengthen your ship/structure against these damage types respectively.

Any damage in the game is now a composition out of these three effects. For example, a sun will now do heat damage. We plan to further expand on this system for the universe update.
Sector Size Weapon Range independency
To make it easier to customize the game for bigger sectors, we added a seperate value in the ServerConfig to set the base range for weapons independently from the sector size. This value will be used as reference for all range config values in the block behavior config. This value can also be set on the fly with an admin command (/set_weapon_range_reference).

If the value is set to 1, all config values will be interpreted as fixed block units (meters).
Mines
The ability to place down stationary mines was added. This feature comes with an all new LoD system that will be reused for other model based things in the future. The Minelayer works like a tiny mobile shipyard, with the Minelayer connected to a Mine core and a storage chest to pull the mine blocks from.

Next to the mine core you can place up to 6 mine-specific block modifications. The mine core block plus its modifications are used as a “blueprint” for the mine’s capabilities, while the constructed and deployed mine itself is not a block but a small 3D model.

Constructing and laying a mine requires blocks from either the pilot’s inventory, or its linked storage. All newly deployed mines are inactive. You can activate them by right clicking, or via the radial ship menu for more options.

Mines can be destroyed by being shot, or simply physically running into them (which may not always be the best idea).

Mines can also be laid via logic by connecting a logic block to the mine layer.

The following mine-types are available:

  • Cannon Mine: This mine fires cannon projectiles when in range

  • Missile Mine: This mine fires heat-seeking missiles when in range.

  • Proximity Mine: The classic mine. Once a targets gets within range, it activates the mine and will follow the entity that triggered it, explodes on impact. Once triggered, it is used up.
The following Mine Modifications are available:

  • Cannon Mine Mod: turns mine into cannon mine

  • Missile Mine Mod: turns mine into missile mine

  • Proximity Mine Mod: turns mine into proximity mine

  • Strength Mod: increases mine damage

  • Personal AI Mod: mine will not attack the one that laid it down

  • Friend AI Mod: mine will only attack the enemies of the person who laid it down

  • Stealth Mod: with each additional mod the mine will gain one point in stealth. Depending on recon strength while scanning the mine will be invisible at distance (distance depends on the difference of stealth vs recon)

 
Cargo Damage
Storage chest blocks (the controllers) don’t get physically destroyed anymore unless they’re empty or have no linked used volume remaining.

This block (or group of blocks) is destroyed on passthrough if the connected storage has no remaining items. If the storage has remaining items, the damage is done to the stored items themselves, meaning that items are being destroying emptying the storage. HP are irrelevant to these blocks as every shot will do passthrough damage. The shot will not lose any strength and continue. The storage will lose items on every storage block the shot passes through.

The storage block has the same mechanics as the cargo blocks.

 
Integrity changes

Warpgate, racegate, activation-gate, doors, factories, cargo, logic connections, all rail connections, mass enhancer)  transporter, sensors and shop will now completely ignore integrity.

Integrity will no longer lower while a ship is in battle. When a system block is destroyed, integrity will not update for 5 minutes and only then update itself to the new correct value. This timer resets every time a system block gets taken out.

This means any ship is equally viable in terms of integrity, as long as its integrity is positive when going into battle. It will also help with lag from explosions and the snowball effect once a ship dips into negative integrity.

 
AI
The AI now uses a better system to gauge their weapon range. Also their aiming has been fixed and improved.
Shield changes
Shields now always regenerate over time again and when under fire only lose regeneration when the shield HP goes down. When not under fire, shields will always regenerate at full speed. Any shield starts in its strongest configuration and can be weakened through high damage weapons if it is a recharge focused shield. Or by a steady stream of small weapon fire if it is a capacity focused shield. The config was changed to allow for that and you may end up with a disportionate amount of regeneration vs capacity with your current builds. Make sure to double check if your regeneration is still positive

 
New Isanth
Lancake has updated the old Isanths’ systems to use new power and the new weapons. Be aware that these ships pack quite a punch now.

The new model will automatically replace the blueprints of the old ones upon start, so if you have modified and overwritten those blueprints (with the exact same name), be sure to make a backup before running the new version.

 
Block Hitpoints
All block HP are being migrated to a new system that supports any amount of HP. While at the same time not increasing amount of data used for HP for memory reasons, the only difference would be that a block with max HP higher than 127 will needs a minimum damage dealt to it for its HP to decrease.

The minimum amount of damage is x/127. This means that you need at least ~8 damage to hurt a block with 1000 Max Hitpoints.
New Admin Commands

  • /kick_players_out_of_entity_uid [entityUID]

  • /kick_player_from_entity [PlayerName]

  • /bp_info [BluePrintName]  (populates information about a specific blueprint)

  • /delete_bp [BluePrintName] (deletes a specific blueprint)

  • /bp_setOwner [BluePrintName] [PlayerName] (sets a blueprint to be owned by a specific person)

  • /clear_mines_here (clears mines in current sector)

  • /clear_mines_sector [X] [Y] [Z] (clears mines in specific sector)

  • /reset_repair_delay (Resets repair delay on selected/entered vessel)

  • /reset_integrity_delay (Resets integrity battle delay on selected/entered vessel)

  • /rail_reset (Resets rail (undock/redock) rail of only the selected or entered entity)

  • /rail_reset_all (Resets rail (undock/redock) rail of all (sub)entities of selected or entered entity)

  • /set_weapon_range_reference (Sets the weapon reference range distance in meters, which the config values are multiplied with (default is sector distance))

  • /faction_set_entity_uid [UID] [FactionID] (sets faction of an entity by UID)

 

All entity info commands have been updated with more info. Also the sector_chmod command has been updated for all sector mods.

The rail commands can be used in case there is still some sort of misalignment or to fix old blueprints quickly.


 

The list in https://starmadedock.net/threads/admin-commands.1283/ has been updated accordingly
Optimizations
Several optimizations have been made to the game.

  • The rewrite of the weapon and general usable module system made the amount of steps involved in pretty much everything weapon and module related a lot less. Not only does this result in much cleaner code, but also a general speed up.

  • The update system for modules is now on-demand, which means the system will not bother to even check if the blocks of a group changed as long as there hasn’t been an actual notification for that. This means that the general idle time for all entities has been cut down significantly. This is very noticable in sectors with a lot of entities and docks.

  • Block processing has been optimized to minimize the amount of lookups by grouping all changes by chunk. This also cuts down on synchronization time between threads and cleans up the code considerably in that section. This makes block processing in general a lot quicker, especially during battles.

  • Block change recording has been completely rewritten to minimize memory usage and serialization size.

  • Beams have been optimized to work a lot faster.

  • Removed some bottlenecks that were occurring in big fights.

  • Thread spool up to remove short freezes after starting the game, e.g. in build mode.

  • A ton of smaller optimizations across the board.

  • Memory optimizations for the particle systems.

  • Log cleanup during ship battles
 
Config Changes
Blocks:

  • Advanced Armor

    • (Effective) HP: 1000 → 2000

    • Armor Rating: 1000

  • Standard Armor

    • (Effective) HP: 250 → 800

    • Armor Rating: 750

  • Basic Armor (previously Hull)

    • (Effective) HP: 75 → 250

    • Armor Rating: 500

    • Recipe:

      • 1 Metal Mesh

      • 1 Crystal Composite

      • 1 Fertikeen Capsule
Systems:

  • Shields

    • Shield Capacity / Block: 400 → 250

    • Shield Recharge / Block: 20 → 25

    • Default Capacity: 200 → 0

    • Default Radius: 25 → 10

    • Shield Local Radius Multiplier: 10 → 7.5

    • Shield Upkeep % of HP / sec: 0.5% → 2%

    • Shield Power consumption resting / Block: 1 → 0.4

    • Shield Power consumption charging / Block: 1 → 0.8

    • Shield Under Fire Time: 30 seconds since last shot

    • Shield Minimum Recharge: 20%

    • Shield Minimum Recharged reached at: 50% Capacity

  • Overheat Timer

    • Minimum Time: 60 seconds

    • Maximum Time: 600 seconds

    • Time added / Block: 0.001 seconds

  • Stabilization Stream

    • Max Cooldown when hit: 60 → 15 seconds

    • Power Regen in Cooldown:  20% → 25%

  • Reactor

    • Chamber blocks needed per reactor block:  0.5 → 0.25

  • Integrity

    • Start Value: 200 → 400

    • Collection Integrity Update delay under fire: 300 seconds

  • MineLayer

    • Layable Mine Distance: 10 meters

    • Cannon Damage per Strength: 1 000

    • Cannon reload: 0.5 seconds

    • Cannon speed: 2 x universe speed

    • Missile Damage per Strength: 10 000

    • Missile Reload: 10 seconds

    • Missile Speed: 1.5 x universe speed

    • Proximity Damage per Strength: 10 000 (bypasses shields)

    • Proximity Speed: 0.5 x universe speed

  • Tractor Beam

    • Moveable mass per module: 5 mass

    • Maximum Force : 10 x Target mass

    • Power Consumption resting / Block: 10

    • Power Consumption charging / Block: 50

    • Distance: 400 meters

  • Salvage Beam

    • Salvage ‘damage’ / Tick: 10 → 25

    • Power Consumption resting / Block: 3 →  5

    • Power Consumption charging / Block: 15 → 25

    • Ticks / second: 40 → 16

  • Repair Beam

    • Blocks / Tick / Module: 1

    • Power Consumption resting / Block: 5

    • Power Consumption charging / Block: 25

    • Ticks / second: 20

    • Repair out of Combat delay: 60 seconds
 
Bug Fixes
Bug Fixes
T1496: Fixed visual glitches for some block icons

T2392: Fixed missiles not targeting systems

T2796: Fixed tooltip displaying on block preview rotation arrows

T2838: Fixed beam texture staying after the shooter overheats

T2849: Fixed shields not always providing protection against weapons

T2941: Fixed stabilizers dropping to 0.0 - 0.1% during block placement/removal

T2942: Fixed crash caused by undoing a large amount of blocks

T2973: Fixed issue where thrust does not consume the right amount of power

T2997: Fixed crash caused by linking mass linking logic or other similar blocks with Shift + V

T3032: Fixed Warp gate distance not displaying correctly

T3037: Fixed stealth strength not increasing with chamber strength lvl 3

Several fixes related to weapon config values

Fixed shipyards (several issues) and added shipyard logs

Fixed turret aim and rotation not working correctly/stopping after a while

Fixed sudden rail misalignment

Fixed horizontal turrets

Fixed chunk corruption (couldn’t confirm 100%. If there is still a case of that, please report)

Fixed missiles not working on sector borders

Fixed slot desync causing players to see wrong weapons being fired at them

Fixed lag compensation causing entities to not rotate correctly for clients (hitting a ship with damage appearing elsewhere & desync)

Stalling missiles now timeout to not cause performance hit (will be fully fixed in follow up)
 
What’s next
Next is going to be a bug-fixing and cleanup round. We will be trying to make the game as stable as possible for the period of the universe update development. Other changes might include reactor chamber balance changes and small changes to weapons based on feedback.

We already started with some aspects of the universe update in the background, and we will now focus more and more on that.

We can’t promise a universe related dev build for a while, but there might be a few highly experimental test builds before that.

 

Thank you for playing StarMade,

  • The Schine Team
]]>
StarMade Weapons Update - Prebuild https://starmade-servers.com/blog/58/starmade-weapons-update-prebuild/ https://starmade-servers.com/blog/58/starmade-weapons-update-prebuild/ Sun, 24 Jun 2018 09:43 CEST
The weapon update just entered the pre-release state. All the features we wanted to add are now implemented.

In terms of content it is probably as big if not bigger than the previous Power update. It completely overhauls all weapon, adds a lot of new features, graphics, optimizations, fixes and other improvements.

Some parts such as updating the block icons, textures and finalizing the config files, are still in the works but everything else should be there for you to test. We already went through a lot of bug fixing and this version should be playable. We strongly advise to backup your universe or use a completely separate installation. You cannot revert your world to the current release version without a backup.

The current pre-release version can be downloaded and installed from the Pre branch.

With more exposure, it will be easier to find those less critical issues and ensure stability before we can release it to everyone to use.
If you come across anything new that doesn’t work or you believe you’ve located a new bug, report that here to help us out: Report a Bug (Release Candidate)
In case you’re not too sure about it, feel free to leave a comment on this thread.


Features
We set out to do this update mainly to make combat and ship battles more interesting and fun. On the backend, this also gave us a chance to completely redesign the code of weapons and other usable modules in the game. A new code design was already partly set up with the power update, and this updates completes it.

To make a more complete package, new features and improvements have been added all across the board.


Weapon & Tool redesign
The goal is to make weapons and their combination a lot more unique, while still being a viable option. Some weapons might be easier to use than most, but others could have a much higher pay off when used properly. As each weapon combination has clear positives and negatives, it is up to you to decide what weapons to make.

We also wanted to give weapons and combat in general a better feeling. This incorporates a broad spectrum of features including the HUD, recoil, explosions, physical force, damage, armor, and many more.

While we changed and added on existing weapons, we did remove the damage pulse entirely as it had no real purpose. It also reduced the amount of combinations possible which allows us to concentrate more on the remaining ones.


Acid Damage model
Acid Damage is the new damage model used by Cannons and Beams to increase block damage without affecting performance. In our tests, this system allowed us to get 90-95% of the original damage to be applied as block damage, giving us the possibility of one projectile destroying thousands of blocks without running into performance problems.

This is achieved by propagating damage outwards, block by block, starting from an origin block.

The propagation speed can be adjusted to move faster or slower depending on the processing power and bandwidth of the server. Several bandwidth optimizations have been made to make the information on removed blocks as small as possible. As a result, even large amounts of blocks get processed quickly without any hiccups.

We can change its behavior while this is propagating as well, allowing for unique damage patterns to be implemented.


Cannons
Cannons are now mainly a high penetration weapon, capable of punching through thin armor and leaving a lot of damage in its wake.

Like before, each projectile has a penetration depth based on its damage. This can range from 1 to 200+ blocks. Each block in this penetration line, acts as the starting point for Acid Damage to start from. The damage of the entire projectile is then distributed accordingly to end up with the appropriate damage shape.

A general change to cannons is that all projectiles are now considerably faster, which will make battles at higher speeds a lot easier.


Over Penetration
Using cannons with too much damage can cause the projectiles to overpenetrate. This happens only when targets have little to no armor, compared to your shot. If this happens, then the penetration depth is stretched before the original damage is distributed on it. This may result in even more system damage...or it may come out of the back of the target and end up wasting most of its damage.


Projectile Width + Bullet Customization
By putting down blocks next to your weapon’s output, you can increases its projectile width. On impact, this will cause more damage to be redirected towards the front, basically shrinking your damage pattern and increasing its width. This can be used to counter any over penetration, or to destroy more superficial blocks if needed.


Recoil + Impact force
Every Cannon projectile applies a force on both the shooter and the target. The force and amount of movement created, solely depends on the weapon damage.

The physical recoil on your ship is in the opposite way of the firing direction, the impact force on your target is in line with the firing direction as you would expect.

There is also something we call &#39;cursor recoil&#39;, meant to give a better feeling to cannons and reduce its accuracy slightly when fired manually. This represents a similar tequnique as shooting a gun in most first person shooters. It’s kept at a manageable level, and scales properly with your fire rate and damage. There’s also a maximum cursor recoil threshold in place to make sure even the biggest of weapons don’t throw your aim around too much.


Cannon Combinations
The core idea of each combination is mostly unchanged, but they behave in different ways. It’s possible we still add or change parts of them depending on feedback, but the overall role of each support should stay the same.


  • Default: An all-around decent cannon, doesn’t excel at anything
  • Cannon + Cannon: Fast firing machine gun with fast projectiles. It uses the Cone: Wide-> Narrow damage shape.
  • Cannon + Missile: Charge cannon with left click to charge, release to fire. The longer it is charged, the better the efficiency and damage of that shot. It also uses the Cone: Wide-> Narrow damage shape.
  • Cannon + Beam: A slow firing artillery cannon with a narrow -> wide cone damage shape. Even when over penetrating, it will be relatively efficient, but it is hard to hit.

We’ve changed the Damage <-> Power consumed ratio to be different for each combination. It allows us to balance the high risk weapons to reliable damage dealing ones. A slow firing cannon is always more efficient, as a miss or a bad hit is a huge waste of time and power.

Each combination also has a default sniper zoom mode, toggled with right click. It ranges from 2x to 4x and greatly enhances accuracy on long range targets.

Some examples of the damage left by only a few projectiles:

~ High damage projectile: https://i.imgur.com/JR213Wr.png

~ Multiple medium damage projectiles: https://i.imgur.com/UUjJZ5X.gifv


Damage Beams
Damage Beams are mostly about doing surface damage and being easier to use. Beams only apply Acid damage on the block they’re hitting, damage will most likely not reach deep within the target unless you focus fire on a particular spot. The only exception to this rule is the Beam support version, where it does penetrate all the way.

We’ve improved the functionality of Beams to allow for that. Some versions are capable of traveling along its target without you firing or aiming it again, they’ll deal decent damage as well but may not necessarily stay where you want them to be.


Damage over Distance
Unlike Missiles or Cannons, beams lose damage with the distance from target. At maximum range, it goes down to only 40% of its original damage. This increases the closer you get, till it reaches the original value at about 400 meters or less. This can vary depending on the combination and allows us to better balance a hitscan weapon.


Combinations
  • Default: Latch on beam that breaks off when it has no direct line of sight with the current block.
  • Beam + Cannon: Aimable beam with short burst time and cooldown
  • Beam + Missile: Arc beam with a shorter range but doesn’t break when there is no direct line of sight anymore. Has a long burst time.
  • Beam + Beam: Penetrating beam that can’t be aimed with your cursor. The damage of the beam is distributed equally over the blocks in the penetration line. Requires to be charged before firing and stops your shields from blocking damage while you are charging.


Repair Beam
The repair beam or astrotech beam is now capable of repairing and replacing killed blocks. The reason this has taken longer is several problems to optimize this system for large scale, as well as handling the logic of connections. At the moment, you can only replace the blocks in order (as if you pressed “undo”), but out of order repairing will be added as a follow up. This method of repairing will use the blocks in your linked storage chest but is using ‘creative’ mode in the dev build for now.


Tractor Beam
The new tractor beam replaces the push and pull beam of the previous release. This weapon is able to hold another entity in place. It can also move with you as you either rotate or move yourself while still firing the beam. It comes with a built-in mode change so you can push the target further out or pull it in. You can change the firing mode by pressing left alt (also now indicated in the context help). The tractor beam mode can also be set via logic by connecting logic blocks to the tractor beam computer:

  • No active logic block connected: hold
  • One active logic block connected: pull
  • Two active logic blocks connected: push

Keep in mind that the mode set by logic is only used when the beam itself is also fired by logic, otherwise it will use what the player set.


Armor
Armor has been completely redesigned as well. There is no longer an abstract “Armor HP”. Armor now will count where it is and how thick it is, you can see this in build mode as well when looking at any armor block. Here is how it works:

  • When a bullet hits armor it checks how many armor blocks come behind that block in its path.
  • The count of armor will stop at any non armor block or air. That count defined the “armor depth”
  • Each armor block now has an armor rating that will get added up (with possible additional bonuses on thicker armor)
  • The resulting total armor value along the armor depth is then compared with the bullet’s damage
    • Is the armor value lower than the bullet’s damage, the bullet will travel on as normal and destroy the armor blocks along its way
    • Is the armor value higher than the bullet’s damage, the bullet will only do acid damage on the first block and stops completely
    • Is the armor value much higher than the bullet’s damage, acid damage is not even applied and only a single block gets normal damage and stops completely
  • This will be repeated for every continuous plate of armor the bullet goes through in a ship, so inner armor a very viable option
This means, that a sufficient armor depth can stop any shot, and it also means that it depends on the angle of the shot, where that armor is, and what type of armor was used. These values mainly affect the penetration of cannon projectiles.

In addition, the HP of Armor has been increased to make it capable to absorb more damage.


Missiles
Missile Capacity
To add another layer to using missiles, we added a Missile Capacity system that will also prevent you from spamming them. By placing missile capacity blocks on your entity, you increase the maximum amount of missiles to be stored. The missiles are reloaded in bulk, as soon as you fire a missile, the reload starts. When the timer runs out, all the missing missiles are filled up again.

For AI controlled ships, the reload only starts when they run out of missiles, this helps control the amount of missiles flying around.

In addition, you require additional power for the missile capacity blocks. This should normally not be a concern unless you’re deliberately trying to store too many missiles for your ship’s size.


Missile Shield + Point Defense Prioritization
Each missile has its own its shield, protecting it from Point Defence turrets. The strength of this shield scales with the missile’s damage and should also encourage firing more high damage missiles than trying to flood the field with low damage decoys.

We’ve also implemented proper anti-missile prioritization. You can set any of your AI to fire at a certain category first:
  • High damage missiles
  • Low damage missiles
  • Random
Missile Combinations
  • Default: Fast non tracking missiles
  • Missile + Cannons: Heat-seeking swarming missiles
  • Missile + Beam: Lock-On Missiles
  • Missile + Missile: A bomb with no self-propulsion and uses the ship’s velocity as its own. The bomb will ignore shields and does friendly fire as well. It will arm itself after several seconds, it won’t detonate if you fire it at point-blank range of your target.


Volley Fire
Changing firing mode from focused to unfocused has been changed to a keyboard toggle for all weapons (default: left alt). We added an additional firing mode for cannons and missiles as well (can also be switched to by using left alt): Volley fire. This mode will take the time to reload the weapon, and divide it by the amount of groups connected to that computer. When firing, the groups will fire one after another.

Volley fire can also be set in the Bobby-AI module for turrets and drones to use.


New HUD graphics
The HUD graphics have been improved to improve usability and distinction between objects and improve the general look.

All indicators now also have been moved to the center of mass of entities. They will still be on the core if you are aligned or in gravity of an entity.


Undocking
Entities will no longer undock when their rail or rail docker is destroyed. However, until those are replaced at the exact position, or manually undocked and docked on a different one, the dock will not receive any power from the mothership.

This will greatly help with lag in larger ship battles, where the undocking of turrets and other docks was one of the biggest parts of lag-causing elements.


Improved graphical effects
The graphical effects for cannons, beams and missiles have been improved. Also more and better explosions have been added.

Also an all new LoD system has been implemented which is currently in use for the mines to be able to have a lot of them in one sector without problems. The system is written in a way that it can be used for a lot of other things in the future.


Lead indicator
Cannons and missiles now also have a lead indicator based on the selected weapon’s projectile speed. Currently the indicator is based on the target’s center of mass.


Effects
The old effect computers have all been removed as most don’t have a purpose anymore. We’ve replaced it with a 3 damage type system with base values for each weapon type:
  • Kinetic (Cannons)
  • Electromagnetic (Missiles)
  • Heat (Beams)

Any damage in the game is now a composition of these effects and they are aplified depending if what they hit is stong or weak against that effect. Even environmental damage like sun damage (heat) is now part of this system. This will be further expended upon in the universe update.

You can adjust the basic damage distribution of each weapon by linking it to the specific effect computer you want it to have.

There are also defensive reactor chambers to strengthen your ship/structure against these damage types respectively.


Sector Size Weapon Range independency
To make it easier to customize the game for bigger sectors, we added a seperate value in the ServerConfig to set the base range for weapons independently from the sector size. This value will be used as reference for all range config values in the block behavior config. This value can also be set on the fly with an admin command (/set_weapon_range_reference).

If the value is set to 1, all config values will be interpreted as fixed block units (meters).


Mines
The ability to place down stationary mines was added. This feature comes with an all new LoD system that will be reused for other model based things in the future. The Minelayer works like a tiny mobile shipyard, with the Minelayer connected to a Mine core and a storage chest to pull the mine blocks from.

Next to the mine core you can place up to 6 mine-specific block modifications. The mine core block plus its modifications are used as a “blueprint” for the mine’s capabilities, while the constructed and deployed mine itself is not a block but a small 3D model.

Constructing and laying a mine requires blocks from either the pilot’s inventory, or its linked storage. All newly deployed mines are inactive. You can activate them by right clicking, or via the radial ship menu for more options.

Mines can be destroyed by being shot, or simply physically running into them (which may not always be the best idea).

Mines can also be laid via logic by connecting a logic block to the mine layer.

The following mine-types are available:
  • Cannon Mine: This mine fires cannon projectiles when in range
  • Missile Mine: This mine fires heat-seeking missiles when in range.
  • Proximity Mine: The classic mine. Once a targets gets within range, it activates the mine and will follow the entity that triggered it, explodes on impact. Once triggered, it is used up.
The following Mine Modifications are available:
  • Cannon Mine Mod: turns mine into cannon mine
  • Missile Mine Mod: turns mine into missile mine
  • Proximity Mine Mod: turns mine into proximity mine
  • Strength Mod: increases mine damage
  • Personal AI Mod: mine will not attack the one that laid it down
  • Friend AI Mod: mine will only attack the enemies of the person who laid it down
  • Stealth Mod: with each additional mod the mine will gain one point in stealth. Depending on recon strength while scanning the mine will be invisible at distance (distance depends on the difference of stealth vs recon)


Cargo Damage
Storage chest blocks (the controllers) don’t get physically destroyed anymore unless they’re empty or have no linked used volume remaining.

This block (or group of blocks) is destroyed on passthrough if the connected storage has no remaining items. If the storage has remaining items, the damage is done to the stored items themselves, meaning that items are being destroying emptying the storage. HP are irrelevant to these blocks as every shot will do passthrough damage. The shot will not lose any strength and continue. The storage will lose items on every storage block the shot passes through.

The storage block has the same mechanics as the cargo blocks.


Integrity changes
Warpgate, racegate, activationgate, doors, factories, cargo, logic connections, all rail connections, mass enhancer) transporter, sensors and shop will now completely ignore integrity.


Integrity in Battle
Also, integrity will no longer lower while a ship is in battle. When a system block is destroyed, integrity will not update for 5 minutes and then set the new correct value. This timer resets every time a system block gets taken out.

This means any ship is equally viable in terms of integrity, as long as its integrity is positive when going into battle. It will also help with lag from explosions and the snowball effect once a ship dips into negative integrity.


Shield changes
Shields now always regenerate over time again and when under fire only lose some regeneration when the shield HP goes down. When not under fire, shields will always regenerate at full speed. Any shield starts in its strongest configuration and can be weakened through high damage weapons if it is a recharge focused shield. Or by a steady stream of small weapon fire if it is a capacity focused shield. The config was changed to allow for that and you may end up with a disportionate amount of regeneration vs capacity with your current builds.


AI changes
AI will now have a better orbiting range based on their lowest weapon range. This can be further customized in the server.cfg

AI should be able to use all weapons with the exception of mines and charged shots currently (will be fixed for release).


Optimizations
Several optimizations have been made to the game.
  • The rewrite of the weapon and general usable module system made the amount of steps involved in pretty much everything weapon and module related a lot less. Not only does this result in much cleaner code, but also a general speed up.
  • The update system for modules is now on-demand, which means the system will not bother to even check if the blocks of a group changed as long as there hasn’t been an actual notification for that. This means that the general idle time for all entities has been cut down significantly. This is very noticable in sectors with a lot of entities and docks.
  • Block processing has been optimized to minimize the amount of lookups by grouping all changes by chunk. This also cuts down on synchronization time between threads and cleans up the code considerably in that section.
  • Block change recording has been completely rewritten to minimize memory usage and serialization size.
  • Removed some bottlenecks that were occurring in big fights.
  • Thread spool up to remove short freezes after starting the game, e.g. in build mode.
  • A ton of smaller optimizations across the board.
  • Memory optimizations for the particle systems.
  • Log cleanup during ship battles
  • Gif recording performance has been improved (quality setting in settings.cfg)


Major Fixes
Besides a lot of smaller fixes, some fixes have been made for more major and annoying bugs that were plaguing the last releases:

  • Shipyards have been fixed. Additionally, shipyards now have a seperate logs to catch any future problems
  • Docked entities (turret or not) being surrenly misaligned has been fixed
  • Fixed hp problem for ships becoming 0 and then not taking damage after that, making a ship effetively unkillable.
  • Fixed shields (fix came with rewriting the system)
  • Fixed bug that would spam the log with exception during battles causing major lag
  • Fixed bug on chunks not drawing correctly (wrong lighting)
  • Fixed warp gates
  • Fixed turret AI not being able to shoot at a target after a while
There are a lot of other bug fixes which we will list in the release news post.


This post contains mostly the features. We will go more into the technical aspects and all the new backend systems that have been created, and the existing ones that have been completely rewritten for this update in the release news post.

Thank you for playing StarMade,

- The Schine Team]]>
StarMade Dev Blog - The Weapons Update https://starmade-servers.com/blog/59/starmade-dev-blog-the-weapons-update/ https://starmade-servers.com/blog/59/starmade-dev-blog-the-weapons-update/ Wed, 18 Apr 2018 02:09 CEST
The first dev build is now available. There is a lot to cover in this update. The primary focus of this update is to make weapons more unique and give them a better feeling, as well as improving the overall combat experience.

This is the first dev build of many, and there are other features to come still like the ability to zoom with weapons, weapon graphical updates and PD missile priority.

Not all combat related aspects will be addressed in this update, ship movement might still receive some minor (but important) changes in the far future and the AI itself will definitely get the attention it needs in other releases.

Also, there will be graphical updates to the weapons still. Most important, however, is to first ensure good functionality.


Weapon Combinations
Weapon combinations use the same mechanic still, but each combination and base weapon has been completely overhauled.

We removed the Damage Pulse weapon (push pulse is still available), so there will be a total of three normal weapons plus nine combinations. All other weapons and support tools are handled separately and will no longer have any combinations. However, the default state of support weapons like the salvage beam will be upgraded to what people usually went for when there were still combinations for it.


Recoil
A new recoil system has been implemented. Not only will cannons and possibly other weapons now cause recoil on your cursor aiming, but there is now also physical recoil on your ship depending on your weapon. This means that you could technically propel your ship by shooting weapons. There is also impact force, which means that you will experience a physical force when weapons hit your ship. The force will scale with the damage of your weapon, but this can vary even more depending on the combination type where we can tweak it even more.


Cannon
The cannons have probably received the biggest update. To make them more viable, we completely changed their damage model to allow for an accurate damage to block destruction representation, while at the same time also interact better with the target’s armor for balancing.

A cannon projectile now does explosive damage that, in theory, can reach the end of any structure. On impact, part of the damage will be expanded to the surrounding blocks and creep outwards till it runs out of damage. To keep the game running smoothly, a scaling algorithm was implemented to limit the number of operations per update. This means that in high load situations, it would not slow down the server. Instead, it would simply take a little longer for the same amount of damage to apply. We call this the “Acid” model since it, in a way, behaves like acid burning through a material but at a much faster pace.

A cannon projectile has extra characteristics too now, such as type and width. The type is determined by the weapon combination and specifies the formula used for the Acid Damage to propagate. For example, one type of cannon could leave a cone-shaped hole in your target, and another type could have this one flipped around. The width of a projectile could then be used to limit how wide its damage can creep outwards.

By putting blocks next to your cannon output, you increase the perpendicular size of it. The width is based on this. The more width a weapon has, the broader the “punch” will be, but the bullet will of course not penetrate as far, since it’s using up a lot more damage for Acid Damage. The weapon itself still needs the damage to do this though and it’s entirely possible that your wide projectile does not even destroy a single layer, or that a too thin projectile over penetrates.


Armor
Armor has also been completely redesigned. The old armor rating values that reduced incoming damage, and armor HP have been taken out completely to be replaced with a system that makes the armor and its thickness matter at the point of impact and does not over generalize the entire ship’s armor.

When a shot hits armor, the system will test how many blocks in the line of fire are also armor. The armor value of those blocks is then summed up and compared with the damage.

This is done every time a shot encounters a new set of touching armor, so you can absolutely have inner armor to protect your reactor.

A projectile can have 3 states in total: Stopped, Normal, or over-penetrating.

If the damage is lower than the combined armor value, the shot is considered ‘stopped’ by that armor. A stopped shot will only do damage to the first block. This means that you will only lose at most one block per shot if you have great armor relative to the weapon that hit you.

If the damage is good but not too good for what it is hitting, you get a normal shot and acid damage will apply like you expect it work.

A shot with overwhelming damage however, will be considered over penetrating against most armor plates. The acid damage model will still apply, but gets adjusted in such a way that less damage will be spent in acid damage, and you’re more likely to shoot right through your target with little damage done.

As an example, if you shoot a relatively small ship with a huge cannon, the shot might just go straight through the complete ship, leaving only a 1-2 wide hole. This means that sometimes, using less powerful weapons against smaller targets might be more destructive.

The next few dev builds will have us applying these acid damage formulas to each of the cannon combinations and you should start seeing a noticable difference between each type.


Combinations
The combinations of cannons are as follows:
  • Default: An all-around decent cannon
  • Cannon + Cannon: Fast firing machine gun with accuracy problems at higher damage values (recoil)
  • Cannon + Missile: Charge cannon with left click to charge, release to fire. Will have different shape for acid damage (most likely a cone. The amount charged on fire will change its damage, acid damage spread and other variables to change its efficiency.
  • Cannon + Beam: A slow firing, sniper/artillery cannon that will have a different shaped acid damage model once again. It will still be relatively efficient when over penetrating its target, but is hard to hit.


Beams
Beams have also been updated considerably. They now possess the ability to latch onto targets. This makes them a lot easier to use. Most beams won’t penetrate, as it simply jumps from one destroyed block to next closest block of the initial hit, preferring blocks that are on the surface over blocks that are deeper. Those beams are perfect for burning off the outer shell of ships and against shields.

An entity can break a latch if it turns away from the firing entity. This will only be possible for the mother ship to prevent exploitations like rotating armor. Alternatively, a non-latch on beam can and will still be used with combinations.

Tools like the salvage beam will not latch on and can be used normally.


Combinations
  • Default: A latch on beam
  • Beam + Cannon: A beam that doesn’t latch on with some acid damage. The latch can break by turning away, but the beam will try to latch onto the next block that has a sight line to the beam output.
  • Beam + Missile: An arc beam with shorter range but doesn’t break from target turning away. This is useful when trying to do focused damage on one spot.
  • Beam + Beam: A doom beam that penetrates the complete length of the beam, and adds acid damage. This would represent an actual death star weapon. Very overpowered right now and can easily be used for performance tests! The acid damage will be adjusted later on, and this beam will get other penalties to account for its high penetration and damage values. This could be the inability to aim with your cursor, having to drop your shield, require additional charging time, having to stop to fire, can not be used on turrets, etc. Stations are especially vulnerable to this type of weapon so we’ll make sure there are mechanics in place to balance it properly.

Once we’ve established a baseline config, we’ll also be using a mechanic to reduce the damage of beams with distance.


Repair Beam
The repair beam has been completely overhauled as well and is now capable of repairing and replacing killed blocks. The reason this has taken longer is several problems to optimize this system for large scale, as well as handling the logic of connections. In the dev build, you can only replace the blocks in order (as if you pressed “undo”), however in release, you will be able to repair blocks that don’t have any connection (like hull) at any time, and only systems would have to be done in order. This method of repairing will use the blocks in your linked storage chest but is using ‘creative’ mode in the dev build for now.


Tractor Beam
The new tractor beam replaces the push and pull beam of the previous release. This weapon is able to hold another entity in place. It can also move with you as you either rotate or move yourself while still firing the beam. It comes with a built-in mode change so you can push the target further out or pull it in. In the dev build, you can change modes by right clicking. This function will be refined further in the GUI. There will also be a way to set the mode by connecting logic blocks to it.


Missiles
While the basic missile has not changed, there are some major changes to how they behave and fire.


Missile Capacity
To prevent missile spam, a ship will now have a shipwide missile capacity. This capacity reloads overtime at a fixed rate, and requires some additional power to do so. You can place extra missile capacity blocks on your entity to increase the base capacity. This means that there is a finite number of missiles you can use in a battle. To counteract that restriction, missiles will be made stronger and less will be more. Firing a missile should be a real decision rather than a no-brainer.

This not only will help with performance during battle, but also will make missiles feel a lot more impactful.


Combinations
  • Default: Very fast non tracking missiles
  • Missile + Cannons: Heat-seeking swarming missiles
  • Missile + Beam: Lock-On Missiles
  • Missile + Missile: A bomb with no self-propulsion and uses the ship’s velocity as its own. The bomb will ignore shields, but it is extremely hard to aim and use (almost impossible to fire effectively from large ships). The bomb does friendly fire and will arm itself after several seconds, which means you should clear away after firing one.

We’re going to add proper missile prioritization for your Point Defense turrets in the next few dev builds, this will also include missile HP that would scale with the missile’s damage. This will allow for high damage missiles to get prioritized, but they will also require big enough PD weapons to take it down before it reaches the target.


Effect types
All damage will now be a combination of 3 damage types:
  • Kinetic
  • Electromagnetic
  • Heat

When a cannon/missile/beam hits, damage is reduced or increased depending on what the target is weak or strong against. This reduction is only applied once for a projectile and missile but is applied every time when a beam does damage.

The existing damage effect blocks have been removed for three new ones. These three are used to change a weapon’s default damage type composition (e.g. cannons are mostly kinetic damage).

On the opposite side, you can use reactor chambers to strengthen your ship/structure against the damage types respectively. You won’t be able to get full protection against weapons, but it is possible against environmental damage. In the universe update, this will be used to add more variation and danger to your universe and with the right setup, allow you to live and build in an otherwise hostile environment.

With armor thickness and these effects, we will be able to provide you in-game information to help with building and analyzing your structure’s armor. By just looking at your armor from any angle, you will see information to show the statistics of that particular spot and what is behind it, showing you potential weak spots, and how much damage your toughest armor can withstand without having to take apart your ship layer by layer.


Mines
With the removal of damage pulse, we decided to add something that is standalone from the weapon combination system to compensate, the minelayer.

With this, you can lay down mines permanently in sectors, with a ton of possible configurations for each to determine what type it is.

The mines could be seen as tiny mobile shipyards, with a Mine computer connecting to a Mine core.

Next to the mine core you can place up to 6 mine-specific block modifications. The mine core block plus its modifications are used as a “blueprint” for the mine’s capabilities, while the constructed and deployed mine itself is not a block but a small 3D model.

Constructing and laying a mine requires blocks from either the pilot’s inventory, or the storage that is connected to the Mine computer. The strength of the mine will be configurable through block consumption in the following dev builds.

Newly laid mines are unarmed and remain so until armed via the Radial Ship Menu.

To destroy any armed mine, simply shoot at it or ram into them.

A mine has a detection radius and will activate based on what it is looking for.

The following mine-types are available (for now):
  • Cannon Mine: This mine fires a cannon projectile towards entities in range
  • Missile Mine: This mine fires heat-seeking missiles as long as an entity is in range
  • Proximity Mine: The classic mine. Once activated the mine will follow the entity that triggered it and do massive explosion damage on impact. Once activated, the mine is used up.


The following Mine Modifications are available:
  • Cannon Mine Mod: turns mine into cannon mine
  • Missile Mine Mod: turns mine into missile mine
  • Proximity Mine Mod: turns mine into proximity mine
  • Strength Mod: increases mine strength 10 fold but also increases cost 10 fold
  • Personal AI Mod: mine will not attack the one that laid it but everyone else
  • Friend AI Mod: mine will attack only enemies of the player
  • Stealth Mod: with each additional mod the mine will gain one point in stealth. Depending on recon strength while scanning the mine will be invisible at distance (distance depends on the difference of stealth vs recon)


Raw Feature List
Here’s a list to indicate all the items that went into this specific build.

  • Completely Rewritten weapon handling and processing
  • Effect damage
    • Effect damage block config capability
    • Effect damage block behavior config capability
    • Effect damage effect config
    • Effect damage attack and defense processing
  • Effect armor
    • Global effect defense
    • Per block category effect defense
    • Per block type effect defense
    • Armor chamber effects
    • Environmental Armor effect
  • Cannon width architecture system
  • Cannon width pipeline
  • Acid damage
    • Acid damage formula
    • Armor depth
  • Cumulative optimized projectile block handling
  • Beam optimized penetrate handling
  • Beam latch-on functionality
    • Beam latch-on synchronization
    • Beam latch-on connection broken handling
    • Beam latch-on progression handling
  • Repair beam
  • Tractor beam
    • Tractor beam pull
    • Tractor beam push
  • Cargo damage
  • Mines
    • Minelayer blocks
    • Minelayer structure
    • Minelayer connection
    • mine graphics
    • mine network and db infrastructure
    • mine proximity checks
    • Mine hitbox checks
    • Minelayer inventory consumption
    • Minelayer mine composition calculations
    • Mine Stealth
    • Mine placement distance checks
    • Basic mine clearing admin commands
  • LoD system
    • LoD abstraction
    • LoD mixed mode
    • LoD activation
  • bBock change handle optimization
  • Wep combination rewrite
  • Missile capacity
    • Missile capacity handling/reloading
    • Missile capacity synchronization
  • Thread instancing optimization
  • HP data update (always making use of all available bits)
  • Block Config parser rewrite
  • Bomb missile
  • Death beam functionality (penetrating/acid)
  • Meta effect capability
  • Raycast fixes and optimizations
  • Beam optimizations
  • Extended user controller pipeline in weapon usage
  • Optimized repair storage
  • Repair storage serialization
  • Smaller fixes in between
  • Inventory block-search reset when dragging from hotbar
  • Mini freeze when building/starting game fix
  • Major memory optimizations for handling damage and block changes in general
  • Recoil
    • Physical Weapon Recoil
    • Physical Weapon Impact
    • Cursor Recoil


Thank you for playing StarMade,

The Schine Team]]>
Schine Q&A Answers - 31st of March https://starmade-servers.com/blog/60/-schine-q/ https://starmade-servers.com/blog/60/-schine-q/ Sun, 15 Apr 2018 02:10 CEST https://starmadedock.net/threads/31st-of-march-schine-q-a-answers.30541/

We're now taking questions for the Q&A opened on the 14th of April, submit your questions here: https://starmadedock.net/threads/14th-of-april-schine-bi-weekly-q-a.30542/#post-366607

A dev blog will be available soon :)


Thanks for playing StarMade,

- The Schine Team]]>
Schine Q&A Answers - 15th of March https://starmade-servers.com/blog/61/schine-q/ https://starmade-servers.com/blog/61/schine-q/ Sun, 01 Apr 2018 01:22 CEST https://starmadedock.net/threads/schine-q-a-answers-15th-of-march.30493/

We're now taking questions for the Q&A opened on the 31st of March, submit your questions here: https://starmadedock.net/threads/31st-of-march-schine-bi-weekly-q-a.30492/


Thanks for playing StarMade,

- The Schine Team]]>
StarMade Patch - SSL Update https://starmade-servers.com/blog/62/starmade-patch-ssl-update/ https://starmade-servers.com/blog/62/starmade-patch-ssl-update/ Tue, 27 Mar 2018 04:39 CEST
We've just released an update to fix SSL certification caching issues, this patch is required for both clients and servers.

We're currently looking into fixing this issue for previous versions.

First dev build for Weapons Update should be out soon, Answers for the first Q&A session[starmadedock.net] will be released in the next week.

Apologies for the inconvenience,

- The Schine Team]]>
StarMade Dev Blog 15 March 2018 https://starmade-servers.com/blog/63/starmade-dev-blog-15-march-2018/ https://starmade-servers.com/blog/63/starmade-dev-blog-15-march-2018/ Thu, 15 Mar 2018 22:23 CET
Development

Weapons Update
The first prototype is about 1-2 weeks away. We will going to do a full news blog for all the changes and additions when it hits to give players something to explore and test for themselves, since trying it out is always better than just reading about it. The goal in the weapon update is to make ship battles more interesting and give armor, weapons, effects, as well as all combinations a valid purpose. For that, all weapon types, as well as armor and effects have undergone some major changes while still keeping their basic principles. As an example, we increased the destructive power of cannons immensely by adding an effect that would emulate explosive damage. In other words: cannon now make big holes. Also, the new minelayer support weapon will be introduced.

Stay tuned.


HUD Improvements

Now that the base functionality of Power 2.0 is in, we're actively working on improving the flight HUD to represent all ship vitals better and integrate newly required information (consumptions/efficiencies). The changes may not be mechanically or thematically drastic, but a concerted effort is being made to improve the legibility above all.


Bi-weekly Development Q&A

We answer a lot of questions in our weekly Twitch stream as well as in other locations such as the forum, tester slack and private conversations with some of our members. Feedback from this has been invaluable, however, one concern has been that these conversations are not easily accessible. To address this, we’ll be creating a thread on SMD every two weeks to gather questions for a bi-weekly development Q&A. Our answers will be posted in a news thread on SMD, Steam and potentially other locations. Hopefully this will provide a central location for further information, without having to go through stream recordings or spread out conversations.

We’ll still be interacting over the board in all different locations, as well as this development Q&A

Our first Bi-weekly Q&A can be found here: Schine Bi-weekly Q&A - 15th of March[starmadedock.net]


Community Translations

With the release of Power 2.0, over 3K translations strings have been modified and 1K new strings added into the game. With only 5.4K strings in pre Power 2.0 StarMade (now sitting at 8.4K), over half of all strings have been changed in some way. Our community translation project has been hard at work since the release of Power 2.0. We’d like to mention a couple of our standout translators in these last few weeks.

@oasisdog (Japanese) has been translating StarMade into Japanese since November of 2015, during his translation time he’s translated a total 7659 strings (64,439 words), almost solely translating all of StarMade’s text into Japanese. He’s been diligently keeping Japanese up to date with all our updates. Since the release of Power 2.0 he’s brought Japanese back up to 100% translated (42 percentage point increase).

@ua2hk (Chinese Simplified & Traditional) has been translating StarMade into Chinese Simplified & Traditional since November of 2017. In total he’s translated 6889 strings (64,439 words) and made significant contributions to both language projects. He’s brought Chinese Traditional and Chinese Simplified up 40 and 20 percentage points respectively since the release of Power 2.0.

Both have made amazing contributions to StarMade, allowing many more people to experience our game in their own language. We’d like to thank everyone who has contributed to our translation project, it’s sometimes tough work translating schema’s English ;)

Thanks for playing StarMade,


~ The Schine Team]]>
StarMade v0.200.332 - Reactor System https://starmade-servers.com/blog/64/starmade-v0200332-reactor-system/ https://starmade-servers.com/blog/64/starmade-v0200332-reactor-system/ Sat, 03 Feb 2018 10:50 CET
This update contains some fixes for problems with the last update, as well as a new advanced system for reactor design.

Reactor Dimension

Our goal with this system is to make every entity shape equally viable. Stabilizer care about the distance between themselves and their reactor, which encourages you to build in one dimension. We worked on a method to allow this distance to be influenced indirectly by the size and placement of additional stabilizer groups. This mechanic does not change your existing ships but it allows you to now put the reactor in different positions with multiple stabilizers closer to it.

How it works

A reactor has 6 relative sides (Front, Back, Right Left, Top, Bottom) and we simply provide a bonus to your overall stabilization for every additional side that contains a stabilization group.

The maximum bonus provided by a side, is set in the config so we can balance it if needed. You don’t immediately get the maximum bonus though, as that would be exploitable.

To calculate the bonus of 1 of the 6 sides, we take the stabilizer group with the most efficient of that side and compare it with the most efficient group on the entire ship. If they’re equal sized, then you get the full bonus, else only a fraction.

The bonuses add up where the maximum one would be used if you use all sides with equal stabilizer groups.


Max bonuses:

1 stabilizer side used: -> normal efficiency at 100% of regular distance

2 stabilizer sides used: -> normal efficiency at 50% of regular distance

3 stabilizer sides used: -> normal efficiency at 33% of regular distance

4 stabilizer sides used: -> normal efficiency at 26% of regular distance

5 stabilizer sides used: -> normal efficiency at 22% of regular distance

6 stabilizer sides used: -> normal efficiency at 20% of regular distance

This will not mean that a cube ship will be able to place stabilizers at 1/6th of the distance when using all 6 sides for bonus, but you will be able to place them a lot closer to make that shape comparable with a long ship in terms of efficiency, and therefore viable. The same goes for any other basic shape.


The examples below normally require 100 meters distance between the reactor and the stabilizers. All 3 examples have the same stabilization and regeneration.


1 group of 200 stabilizers at 100 meters.




2 groups of 100 stabilizers at 50 meters.




4 groups of 50 stabilizers at ~25 meters.




Stabilization Axis

The bonus system works on fixed axis for simplicity. However, it is possible to modify this axis freely. There is a new tab “Reactor” in the advanced build mode, which lets you do that. These are also applied and saved by individual reactor.

You are only required to modify it if your stabilizer groups are in the “corners”, as then the game can’t really decide to which dimension it belongs to.


Fixes and Additions
  • Fixed a bug that would fill up VRAM slowly (causing fps drops)
  • Added a system to search an entity by block type. Select a block in the dropdown in “Selection” in advanced build mode and hit the “highlight” button. All blocks of that type will be highlighted, which will help a lot when refitting ships
  • Turret aiming left click will now focus fire (like beams) if your cursor is on a structure. Right click will be unfocused fire.
  • AI now prefers to aim on reactors, chambers and stabilizers (will use the scanning system in the future)
  • Fixed several crashes
  • Fixed some chunks not being editable anymore
  • Fixed some ships not loading due to memory optimization using compressed chunks
  • Fixed warp-gates not loading due to data discrepancy
  • Fixed sector import failing with certain entities
  • Fixed reactor HP removal on block destruction issue
  • Fixed reactor overcapacity issue
  • Fixed energy stream not always disappearing
  • Fixed old blocks still appearing in factories (set deprecated to false to bring those back)
  • Fixed RHP not deducting correctly on integrity explosions
  • Overdrive, Ion, Piercing and EMP Effects are disabled now as they don’t work fully and will be replaced in the weapons update.


Work is continuing on the weapon update. There will be some news soon amongst other things on new mechanics making armor a lot more viable.


Thanks for playing StarMade,

~ The Schine Team]]>
StarMade v0.200.311 - Power 2.0 https://starmade-servers.com/blog/65/starmade-v0200311-power-20/ https://starmade-servers.com/blog/65/starmade-v0200311-power-20/ Sun, 21 Jan 2018 00:44 CET
The power update has been finally released.

Features

Power 2.0
If you kept track with our last few dev blogs, you will already know how the majority of it works. We did change some features along the way to resolve the issues that were brought up and it might not be a bad idea to go through it once again.

There is an all new power system in this build. Old ships are still loadable and fully usable but the old power and its related blocks are disabled in shops, creative mode and factories. They can be re-enabled in the block editor if needed (set inShop to true) or you can still access them through the admin command /give “player_name” “block_name” if you’re an admin or in single player.

There is an option in the ServerConfig to completely disable the old power system should a server admin want that. It’s advised to not switch from allowed to disallowed and back again constantly though.

If old power is allowed, the system will detect which version to use based on the structure’s root entity (mothership, station or planet) and check if that has any old power blocks. All structures will be counted as “new” power until you place down an old power block at which point they will convert to the old system.

Anything that still uses the old power blocks, will stay like that till the very last old power block is removed. Make sure to clean out your old power before adding the new power components to your ship.

Motivation
The main motivation to update the power system comes from a few basic issues that the old power system has.

  • Scaling of power versus the surface area of ships
  • Filling ships with power and systems is almost impossible to change afterwards without tearing it down completely

  • Additions of bigger features was hard on existing system
  • Consumption model was not consistent and didn’t scale well in terms of balance.
  • Implementation based on partly outdated code
  • Exploits to abuse power system mechanics

There is a lot more in this update than just the power system itself. Additionally, a change of this system allowed for a massive code overhaul of some very fundamental systems. Not only will that reduce bugs, it will also speed up the process of finding any remaining issues, as well as adding new features a lot faster, easier and streamlined.

Consider this update as a way to prepare the game to enter a phase of rapid development. A lot of foundation had to be made so that adding new stuff wouldn’t cause a problem in the end. While we could have skipped this step, it would have probably cost more time after just adding new features, so we went for the option to fix the foundations first, and then add new stuff, as well as finish other incomplete features.


Power Basics
The new power system is relatively simple but has a lot of depth if you are going for optimal building. However, it can be difficult if you build ships with the old power system in mind and expect similar results. Ships will perform similar as before, yet power regeneration and consumption values were changed drastically and simply can’t be compared easily with the old power system.

Our main goal was to make the power reactor components smaller, making sure that anything that uses power is also kept at a relatively small size.

The only way that this is possible, is if there isn’t a reason to fill up a ship with it. We went through a lot of iterations like restrictions compared to dimensions as well as mass, but all of these had major problems that would enable players to just circumvent the restrictions and fill a ship with systems regardless. Our system should be working with as few special cases as possible.

Reactor <-> Stabilizer
The system we went for is a combination of two blocks:
  • The Main reactor block
  • The Stabilizer block

The idea is that a reactor needs to be stabilized beyond a certain value to function properly and that the stabilizer blocks have to be a sufficient enough distance away of the main reactor to be effective. That distance is measured from the stabilizer block to the approximate shape of the main reactor.

The bigger the reactor, the more stabilizers you need and the further away from the reactor they need to be. This puts a minimum span on each reactor size, ensuring that a ship cannot be filled up with reactors entirely.

You get 10 blocks worth of free stabilization for any reactor, so that really small reactors don’t need any stabilization blocks to function. Small ships can be a little bit more compact, as you also need to protect 1 less vital component on your ship.

A reactor is fully operational with a stabilization of 25%, however there is a risk to that. A stabilization below 100% will cause the reactor to suffer from damage penalties. From very little at around 99% up to three times damage taken from all weapons at 0%. The concept of building with low stability is very risky but can of course have high rewards.

Energy Stream
Additionally, there is a non-physical connection between your stabilizers and your reactor. A stream can be hit by any weapon projectile, and apply a temporary power regeneration nerf to the reactor. The duration of this nerf depends on the amount of damage that passes through the stream. Protecting these streams is just as important as protecting your reactor and stabilizer components, not only from enemy ship fire, but also from boarding parties.

A stream’s path can be bent and redirected with one or more Stream Node blocks. These blocks can be connected to each other to build a custom path by linking with C + V. Any stabilizer group will connect to the closest Stream Node and follow its path back to the active reactor.



Consumption
Another important goal was to update and make power consumption more consistent. All power consumers now consume power over time and not instantly on use. This means that there is no instant power drop, and significantly reduces the need to have large amounts of power in storage.

All weapons now consume power when reloading. They also require a lower amount of power per second to keep themselves loaded, as they lose charge over time. If you can’t provide enough power to reload, the weapon will just reload a bit slower. It will only appear discharging if you cannot provide the lower “resting charge”. This means that you can now build weapons far bigger than your reactor technically supports, which will make for some interesting gameplay decisions.

Usable modules like thrusters will, like the old system, only consume power when in use. Some modules that are only active for a certain duration, only require power to charge it up and none when it’s active.

Power Consumption Priority
Additionally to this new consumption system, you can now also customize the priority in which power is consumed. You prefer being able to fly and having shields over your weapons recharging? You can set that now by just dragging your preferred priorities in the new power reactor panel.

Rail Power
One major problem of the old system was the way it handled rails and system inheritance. This is now streamlined and pretty straight forward: Only the mother ship’s reactor can be active. Its docks and turrets are also part of the priority list so you can make sure that your turrets always get power if you want, or you can prevent them to consume so much power that you cannot maneuver anymore. A docked ship’s reactor will go back online once it undocks.

Chamber Tree
Chambers are an all new feature that will help specialize your ship for certain tasks. All stand-alone effects, all “one-block” functionality and some “one-group” systems have been incorporated into this system. Effect blocks can still be used as-is in combination with weapons, however it would be advisable to not use them too much as they will change within the weapons update. (more information will follow shortly)

The chamber system can be understood as a physical skill tree that is on your ship or station. As an example, while a weak version of the jump drive is now available by default, you can use the chamber system to make it possibly stronger and suit your needs. You can reduce its power consumption, increase its recharge speed, change functionality such as allowing it to hold multiple charges at the same time, etc. Each change, represents a node in the tree and which parts you want is up to you.

Other chambers now include cloaking and jamming. There is also now a way to set artificial gravity, as well as set warp gates to an arbitrary position in reach, that doesn’t even have to have a warp gate on the other end.

To build chambers, you have to place down the basic chamber type and connect it to your main reactor through a chain of touching Reactor Conduit blocks. After that you can select a specification in the Reactor panel or simply press ‘R’ on any reactor component to bring you to that menu. In there you can see how your chambers are currently connected with each other. You can specify what each chamber does.

Adding additional blocks to an already specified chamber will automatically increase that chamber’s size. The minimum size requirement for chambers to function, depends on the size of the reactor.

All of this system is based on a new feature we call the “Effect Config System”. The ECS was implemented to allow for any effect on an entity from any source. At the moment, the only source used is a ship’s own chamber tree, but in the future this system will be used for several other things, including changing sector/system/region conditions depending on where you are in the galaxy (for example nebulae disabling all sensors, etc).

We also implemented an easy to use GUI to mod it, as well as insured that it is very scalable as it syncs between client and server with only a few parameters.



Multiple reactors
Multiple reactors are possible and encouraged as not only do they provide a fail safe system, they also enable ships to carry multiple sets of chamber trees and of different sizes. Stabilizers can be reused for multiple reactors, but keep in mind that the stabilization distance is calculated based on the biggest reactor.

Switching reactors can be done in the reactor panel. A switch is instantaneous but there is a cooldown to switch again afterwards.

One major advantage of multiple reactors is also, that only an active reactor can be scanned.

Reactor HP
A ship’s HP is now determined by the active reactor and its chambers. Reactor HP is tracked for each reactor separately, but only the active one applies for your ship’s health. The reactor tree is consistent and keeps tracks of which blocks have been damaged. If your Reactor HP ends up too low (<20%). Reactor HP will affect more of your ship in the near future with the weapons update.

You can chose the reset the HP to their new maximum to stop overheating, but you only do that out of battle as any damage will reset the timer. This consistency will also eventually lead to a repair mechanism that can replace destroyed reactor blocks.

Local Shields
Shields were always a big pain to balance out especially when rails came out, as they always covered the whole ship, no matter where the shields were placed or where the ship parts were located. This, paired with no extra power cost with capacity increases, not only encouraged players to excessively use shield capacity blocks, but it also enabled far away “islands” to be fully shielded, something that has much more of an impact with the new power system. Shield sharing within rails also was the cause of major exploits and confusion when building ships.

Shields no longer apply on your entire ship through inheriting. Now each shield recharger group has its own radius that it will shield blocks from damage. Any shield capacity group within this shield bubble, will auto link to that recharger group and provide it shield HP.

The radius of a shield recharger group, depends on its size.

You’re able to have more than one of these shield groups on your ship as each one has its own recharge and shield HP, allowing you distribute its strength to different parts of your ship and in different proportions. These spheres can overlap partially, but as soon as the recharge group (the center of a sphere) is placed within the influence of another sphere, it will disable itself. If a block that is within the radius of multiple shields is taking damage, each shield will receive the damage.



Stealth vs Recon System

This new system is incorporated in the chamber system. You can setup your chambers to gain stealth/recon strength. When your scanner or stealth drive is active, this strength is applied to your ship or structure.

The system compares your current scan strength with all nearby entities (and vice versa for stealth strength -> scan strength). Depending on the difference between you and a target, you’ll get different results. If your scan strength vastly outweighs the target’s stealth strength, you see every bit of information possible and also counter all of the target’s active stealth drive effects. Cloaker and jammer are now addons for the stealth drive, so these can be countered by scanners still provided your scan strength is high enough.
  • To counter Jamming, your ship needs an equal amount of recon strength than the other ship’s stealth strength
  • To counter Cloak, your ship needs 1 recon strength less than the other ship’s stealth strength.
  • For scanning weapons, your ship needs 1 recon strength more than the other ship’s stealth strength
  • For scanning chambers, your ship needs 1 recon strength more than the other ship’s stealth strength
  • For scanning reactors, your ship needs 2 recon strength more than the other ship’s stealth strength



System Integrity
Unrelated to power, to combat general exploitation of shapes of systems, a new mechanic has been introduced: integrity.

Essentially, if a group of modules is below a certain density, it will receive additional damage when being hit. Generally this will not affect most builds, as long as there are no overly long lines or giant plates of systems being built.

For each group of systems, there’s a starting value of 200 integrity which will go up or down depending on how many blocks each block touches within that group. The penalty only applies if your integrity goes below 0, so small ships generally don’t have to worry about it at all.
  • Touches 0 blocks: - 10 integrity
  • Touches 1 blocks: - 8.5 integrity
  • Touches 2 blocks: - 7 integrity
  • Touches 3 blocks: - 4 integrity
  • Touches 4 blocks: - 2 integrity
  • Touches 5 blocks: + 0.5 integrity
  • Touches 6 blocks: + 2 integrity

The integrity mechanic applies to all usable systems, but not hull.

There are a few special groups worth mentioning:
  • Thrusters will be considered as the same group, they all share the same integrity value.
  • Stabilizers group if close enough, get combined into a single group. This can easily be seen when looking at their outline in build mode with a stabilizer block selected in the hotbar.
  • Shield integrity will take the lowest integrity of both rechargers and capacitors within a shield radius. A shield with low integrity will also receive damage on a shield hit, which means that this is the only module where integrity is an absolute necessity.



User Interface Changes
There was a large amount of GUI items to add for the new power system, along the way we’ve changed other ones too:

  • All new build information panel
  • New power reactor panel
  • Font sizes have been adapted to be more readable at higher resolutions
  • GUI drawing optimizations
  • Effect Config System GUI
  • Several help and information bits based on context
  • Updates to chat (more to come in weapons update)
  • Several message popup fixes
  • Right click on brush size scrollbar resets it
  • A faction member’s position can now be set as waypoint in the faction member list
  • C+V on remote logic (was already in but we missed mentioning it)
  • The infographics you see in this post are available in the game as a quick reference in the top left corner when building a ship.

Ship Information Panel
The information panel you see in build mode has been updated to be more dynamic, and to be less in your way. Each section gives you information of a specific system and can be minimized, allowing you to customize the amount of info you see on screen. The entire panel can be minimized too if needed.

Any large value that doesn’t fit will display as a tooltip if you hover over it.

This panel also has more functionality tied to it, such as faction module options and AI options.

HUD Context
Even if set to “none”, you will still a few power related ones in build mode as they are need to know information and doesn’t get in the way either as it depends on the block you’re looking at, and the one you have selected on your hotbar.

Manual Turret Aiming
Turrets have now the option to be manually controlled. To do that, just set the checkbox in the bobby AI panel. Then you can assign the control for all manually controlled turrets on the hotbar of your mothership. As long as the icon isn’t selected on the hotbar, the turret will be using normal AI targeting. If it is selected it will switch to manual aiming. Additionally, using right shift to look around when manual turret aiming is selected will enable you to aim in all directions (right shift will be the old normal behavior if manual turret aiming isn’t selected).

Repulsor Block
A new block has been added that enables you to build hovercrafts and other contraptions. This block essentially works like a directional magnet that always pushes yourself away. This block is based on the physics system, so you will have to find the right balance for your ship. There are some options in the Thruster configuration for it, too.


Storage/factory pull/push limits
You can now put individual limits on how much a storage can pull of each item and how much a factory can produce. This should make managing factories and inventories a lot easier. Keep in mind that factories will also pull enough resources for one extra production step.


Graphics Config Presets
Since StarMade’s graphics config in its development state is a bit hard to manage, we added simple config presets for all kind of systems. All old options have been moved into an advanced config tab and can be accessed and set as they could before.


Config additions
A large amount of config values were added to the blockBehaviorConfg and effectConfig, giving you the ability to modify and change system values completely. This is not only to enable basic modding, but also for us to explore and experiment with different setups in the game.

Optimizations
Several optimization have been made to different parts of the game.
  • Sped up general chunk loading by streamlining client requests
  • Sped up module group calculations by avoiding unnecessary runs
  • Reduced general RAM usage of ships, stations and asteroids by using dynamic chunk compression.
  • Fixed several memory leaks
  • Optimized RAM usage in several other places
  • General drawing optimizations
  • Several bottlenecks removed
  • Reduced VRAM being used considerably by overhauling frame buffers.
  • Fixed and reduced VRAM usage for antialiasing.
  • Fixes for 4k resolutions
  • Beam drawing optimizations
  • Several block editing optimizations
  • Networking optimization
  • Use of advanced graphics card functions for cards that support it
  • Faster debris handling

Planets have been made smaller by default to not have them impact performance until they are replaced completely.

Bug fixes
  • Fixed building while flying at high speed
  • Fixed normal mapping tangent space
  • Fixed many small fixes for textures
  • Fixed several crashes (without issue attached)
  • : Weapon output added to HUD context
  • : Added safety checks for removal of an in-use inventory, warpgate with set destination, faction module and shop module
  • : Fixed sounds not playing after 5 plays.


Known issues
  • Tutorial videos are not up to date yet. Update video will follow shortly.
  • NPC Assets are not using power 2.0 yet, will be converted along the way.
  • Lighting bug on some sprites and girder
  • Long range scanner not functional yet (placeholder for universe update, will be temporarily serving as the scanning module of the old version)
  • Sensor block currently doesn’t function with the reactor. To fix it will probably be sensing the current consumption versus recharge percentage.

Exploits or any other method of abusing mechanics can also be reported here, as bug tasks are private on creation.


What’s next
Now that everyone is able to use Power 2.0 in a state that it’s supposed to be, we’ll continue to tweak it when balance or mechanical issues arise.

While the QA team keeps a watchful eye, the rest of us will work on the next update to revamp Weapons and possibly some support tools.

Thanks for playing StarMade,
~ The Schine Team

Information on our weapons update can be found near the bottom of our news post here: http://www.star-made.org/news/starmade-v0-200-311-power-2-0
]]>
[Pre-build] StarMade v200.250 https://starmade-servers.com/blog/66/-pre-build-starmade-v200250/ https://starmade-servers.com/blog/66/-pre-build-starmade-v200250/ Sun, 10 Dec 2017 11:27 CET This is not a full release, this is a release we believe to be ready, but still needs public exposure for testing. Pre-builds are after development builds, but before a release build. You can learn more about our release cycles here: https://starmadedock.net/threads/starmade-release-cycle-news-posts.28895/

Greetings citizens, ~

Finally, we’ve reached the point where we enter a pre-release state. This means that all the needed features are in, and preliminary bug fixing is done. There will still be issues, and while it should run fine, we strongly advise to backup your universe or try it out on a separate installation. It can be downloaded and installed from the Pre branch.

With more exposure, it will be easier to find those less critical issues and ensure stability before we can release it to everyone to use.

If you come across anything new that doesn’t work or you believe you’ve located a new bug, report that here to help us out: Report a Bug (Release Candidate)[phab.starma.de]

If you’re not too sure about it, feel free to contact @Lancake in a private conversation, or leave a comment on this thread.

While we wait for people to try it out and report issues, we’ll continue building on features for the update after this.

---

What follows, is a quick overview of what’s new compared to release. We’ll make a more in-depth version for the actual release.


A quick overview of major features and changes:


  • adapted font size to be readable
  • new structure build info panel
  • more context based information
  • HUD context filters: all, most, some, crucial only, none. Crucial only is advised for experienced players.
  • right click reset brush size
  • removal prompt for storage/faction/shops/shipyards/warp gates in use
  • setting waypoint to faction members from within members list
  • shift click hotbar remove for creative mode + keybinding creative mode (if allowed)
  • catalog blocks menu has a toggle to show resource cost
  • chat GUI update (more coming in next update)
  • reactor GUI, graphics and block textures

  • new module use system (faster and a lot less error prone)
  • new power consumption model (faster and less error prone)
  • fixed major memory leak for servers
  • fixed framebuffer VRAM usage
  • reduced general VRAM usage (by more than half depending on Anti-Aliasing)
  • network optimizations
  • gui drawing optimization
  • beam optimizations (more than double performance)
  • several memory allocation optimizations
  • normal mapping tangent space fix
  • general chunk loading and validation optimizations (vastly reduced amount of calls)
  • several block editing optimizations
  • several group speed calculation optimizations
  • optimization for chunk request queuing
  • grouping calculation cancelling to increase performance and responsiveness during battle
  • combined-module power consumption processing optimization
  • usage of some more advanced shader functions for graphics cards that support it
  • faster debris handling

  • new power system
  • new power balance
  • chamber system
  • effect system
  • effect functionality (~130 effects for entities)
  • structural integrity
  • new shield system
  • recon vs stealth system
  • factory production cap
  • storage pull limits
  • manual turret aiming
  • graphic presets for simpler option management
  • repulsors
  • new HP system
  • reworked overheating conditions

  • several menu fixes
  • server message fixes
  • fixed placing blocks when the ship is moving
  • several other bugfixes

As you can see, a lot of optimization was done so make sure keep your eye out for graphical glitches, block grouping bugs and block destruction issues. In case you’re interested to see which issues occurred in the past, this task https://phab.starma.de/T2720 holds a link to many of them. It can give you clues about any other issues that were missed.

Also, keep in mind that we’re working on the weapon update too, the current offensive effects are not fully supported as some will be changed or removed only a few weeks after. The combination system will stay, but the combinations themselves can change drastically.

We’ll make sure to post a dev blog about weapons specifically after the next public release.


Power System
Please keep in mind that all config values are not 100% final yet. In case you encounter any oddities where specific mechanics are too strong or weak, please mention those and make sure to include a blueprint of the ship or structure where that is clearly the case.

There is an all new power system in this build. Old ships are still loadable and fully usable, but the old power and its related blocks are disabled in shops, creative mode and factories. They can be re-enabled in the block editor if needed (set inShop to true) or you can still access them through the admin command /give “player_name” “block_name” if you’re an admin, or in single player.

There is an option in the ServerConfig to completely disable the old power system should a server admin want that. However, once a universe is started with the old power disabled, this option cannot be reverted, as that would lead to incompatibilities with the Structure and Reactor HP system and can lead to overheating of many structures.

If old power is allowed, the system will detect which version to use based on the structure’s root entity (mothership, station or planet) and check if that has any old power blocks. All structures will be counted as “new” power until you place down an old power block at which point they will convert to the old system.

This is mainly for game worlds to be fully functional and for players to get accustomed to the new system without rendering all their creations suddenly completely non-functional.


How to use the new system
This system makes ships work a lot differently. All ships made in the old power system, will not translate well into the new system. Simply swapping out the old power blocks with new ones does not make that ship functional again. Instead, we advise you to remove all power blocks, shields, thrusters and usables to start from a clean slate.

The best way to keep track of your power is to check the detailed power consumption in your reactor panel frequently (‘insert key’ by default, or use the radial menu with tab, or press ‘activate’ key when looking at a reactor block)

On the surface, the new system is really simple. You have your main reactor blocks which add power recharge to your ship; only a single reactor group is active at any given time. Power capacity itself is fixed and low, as all weapons and systems use power over time.

Weapons need a minimal amount of power to function, and require a lot more while they’re reloading. If you don’t have enough recharge, it will simply charge it slower.

Other systems such as thrusters and jump drives, only use power when they’re in use.

If your reactor group is small enough ( < 10 blocks), they work just fine on their own. You don’t need any additional blocks to make them function.
However, larger reactors have deteriorating stability. They will not gain power recharge unless you fix their stability. For that, you need to place down stabilizer blocks. These blocks will work at most ranges, but to be efficient, they need to be placed a certain distance or further from your reactor. This distance increases with your reactor size, so make sure to keep an eye out for your stabilization when adjusting its size. The hud context in build mode will tell you exactly what that distance is and indicate the efficiency of your stabilizers; it also shows additional information based on what you’re using.
While reactors have to be built grouped, stabilizers can be built distributed anywhere on your ship. If you have other inactive reactor groups, then all stabilizers look to the biggest reactor, and their resulting stabilization will be used.

You can also build multiple reactors and switch between them. A reactor switch is instantaneous, but there is a cooldown to switch again, and it also takes time for chambers to become active.


Power Consumption
As said, all modules now consume power over time. Additionally. You now have full control over what is going to be consumed first. Open the reactor panel (‘insert key’ default, or use the radial menu with tab), and you can prioritize certain systems. This means that they will get power first in case your total power consumption is above 100%. So if you prefer your shields and thrusters to work over your giant cannon, you can do that now. It also regulates power that goes into your docks or turrets, giving you more control over their power consumption.

Most systems have a linear power consumption increase that depends on the group size. The few systems that have no group size, instead of scale with the mass of your ship.


Docks
Docked reactors will switch off on docking and all power needed is drawn from the mothership. This means that turrets cannot have any power reactors on their own when docked. We will change the behavior a bit more in the weapon update to increase performance in battle and to add more versatility to docks and turrets.
Structure HP -> Reactor HP
Ships now use reactor HP, which is based on the active reactor and the chambers connected to it. If you use multiple reactors, you can switch to a backup before your current reactor ends up overheating. As for the overheat mechanics, they’re similar to what you’ve known with structure HP, but each reactor tracks its own HP.
Reactors can only be scanned when they are active, so having a backup in another part of the ship can greatly increase survivability.


Chambers
Chambers are an all new feature to customize your ship with. We added over 100 different effects that you can activate with chambers. For this, an all new effect system was implemented to enable fast and save management over network.

Chambers can be imagined as a skill tree. Each reactor only has a limited chamber capacity which chambers consume based on their type and level.

The difference to other skill trees is that here, you are physically building the tree yourself. You need to connect groups of chamber blocks with reactor conduits to the main reactor or each other. Then you can open the reactor panel (‘insert key’ default, or use the radial menu with tab) and specify what exactly you want in your tree. The possible options will adapt based on what you build.

There are eight general chambers currently:

  • Defense
  • FTL
  • Logistics
  • Mass
  • Mobility
  • Power
  • Recon
  • Stealth

Some functionality is now available by default, like the jump drive and the scanner. Chambers can be used to make these a lot more powerful.


Stealth and Recon
Each ship now has a recon strength and stealth strength only if the respective scan/stealth drives are active. The more recon you have over an enemy ship’s stealth strength, the more information you get about that ship. This ranges from simply seeing a cloaked ship to being able to see a ship’s reactor and weapons fully outlined. For the weapon update we plan to add more to it and tweak it were needed.

Respectively, to cloak or radar jam you need a higher stealth strength than the other ship’s recon strength.


Shields
Shields have been reworked into local shields. They now have a radius and only cover the blocks within. This includes docks. Only shields on the mothership will work to prevent abuse and maximize performance. The radius and recharge is based on the main recharger group, and so is its power consumption. The origin of the radius is the center of mass of that group and its capacity is determined from all shield capacity groups that are within the radius (up to 20 groups max). If a local shield radius falls into another recharger group, only the bigger recharger group will stay active. Shield damage that falls into blocks covered by multiple local shields will do damage to all of them.

While adding an interesting mechanic, this system is mainly to avoid building ships in ‘islands’ that are very far apart as you would need multiple groups to cover them, making it more expensive and power intensive to maintain the same shield HP for each of them than you would get if it was a single more concentrated shield group.


Integrity
This is a measure to prevent exploiting certain system shapes without constricting free building too much.

This mechanic will likely not be relevant for most builders. It is to prevent building ships that are too spaced out, mainly abusing line patterns. Most systems will now have an integrity value. This values starts fairly high and is modified based on how the group is built. If any block does not touch enough other blocks of that group, it will lose integrity. If it touches enough (up to 6 max), it will gain integrity. It can be set to scale differently in the config, allowing us to make sure normal builds do not get affected. This means while single lines are now impossible to build while maintaining a positive integrity rating, anything “dense” enough is still ok.

Thrusters count their integrity all in one, meaning that a checkerboard pattern will be the fastest way to lose it.

Shield integrity is based on the lowest integrity of the rechargers and capacity groups within that local shield.

For weapons and other computer + modules, it’s a separate integrity value for each group although this will be tweaked in the weapons update.

If integrity of a system is below zero, hitting that system will cause additional explosions across all groups of that same system. If a shielded ship with negative shield integrity is hit within its shield radius, the same will apply to the shield recharge groups and its capacity banks.


Repulsors
This new block enables you to hover a certain distance away from anything physical. They act as an output for your onboard thrust, and require you to distribute an amount of thrust to them in the thrust configuration menu. They work well in any gravity field and when balanced right, allows you to hover any entity.


Manual Turret aiming
Turrets can now be set to manual aiming. They will then automatically try to align themselves with where the pilot of the mothership is looking at. This includes looking around while using right shift (or double tapping right shift to make it sticky). You can of course also fire your turrets in this mode with the new usable in your .


Factory/Storage upgrade
Factories can now be set to limit production. The factory will also stop pulling resources when that happens, only keeping enough in storage for one extra production step.

Additionally, storage blocks can now be set to limit the amount of blocks to store per type, to stop pulling once that is reached.

We will continue work on refining the GUI and fix issues/exploits that come up that need fixing for an actual release. Some content such as the tutorial videos and block descriptions are still being worked on, but will be available on the actual release.

The weapon update is next and is going to bring more balance and exciting additions to the system. We’ll be making a dev blog about most of its content


Thanks to everyone helping us and thanks for playing StarMade,

- The Schine Team]]>
StarMade v0.19590 - Fleets and Carriers https://starmade-servers.com/blog/56/starmade-v019590-fleets-and-carriers/ https://starmade-servers.com/blog/56/starmade-v019590-fleets-and-carriers/ Fri, 04 Mar 2016 23:30 CET



Fleets

This is an entirely new system within the game’s backend. It is basically a cached virtual layer that can quickly operate on the main database of a server without the need to load in ships. We had to make some significant modifications to the database’s tables to allow for this, so it took some effort to set up just right. 

But enough of the technical details. Here’s an overview of how fleets work in-game: A player can create a fleet in the new fleet panel (default key ‘k’) and add multiple ships to it. There are several other management options for fleets in that panel as well. The first ship in the list is always the flagship (the ordering is easy to change later), and a ship can only belong to one fleet at a time. The flagship of every owned fleet will also always appear in the galaxy map. Ships don’t require Bobby-AI blocks to be part of a fleet. 


Fleets can currently perform the following actions: 
  • Idle: This is the default state. Ships in this fleet will neither move on their own nor attack. In the event of a server restart, fleets will automatically revert to this order. (In the future, the last fleet order will be saved.)
  • Move: The Move command sends the fleet to a sector, whether or not that sector is loaded. Currently, the fleet’s movement speed while in an unloaded state is fixed, and the fleet is also unable to use jump drives as of yet. These will be added in the future.
  • Attack: A fleet will go to a particular sector and attack. Currently, attacks will only commence on loaded sectors; if a sector is unloaded, the fleet will wait on the sector’s edge until it is loaded.
  • Defend: Similar to Attack, the fleet will go to a sector and attack any (loaded) enemies. However, the fleet will not pursue any enemies beyond 2 sectors of the target sector.
  • Sentry: The fleet will attack any enemy in proximity.
  • Formation Idle: the fleet will assemble into a formation, but will not attack anything. The flagship can be manually controlled.
  • Formation sentry: The fleet will assemble into formation. Additionally, ships will break off and attack any enemy in proximity.
  • Carrier Callback: This order is explained further below.


Important: Formation orders are currently experimental and may lead to strange AI behavior or fleet pile-ups. 


Carriers

Carriers are now supported in-game thanks to the new fleet system. For this purpose, we’ve added three additional blocks: the Pickup Rail, the Pickup Point block, and the Shootout Rail. All of these blocks are non-physical and only visible while in build mode. This means that, while the two new rail blocks still function as rails and allow you to change them using existing logic systems, you can not collide with them even if you’re on the rail itself. They also do not provide any armor or hp to the ship. 


New Blocks

  • Pickup Rail: You can use it to lead your ship inside your carrier safely. It works exactly like a normal rail.
  • Pickup Point: These go on the entry points of your ship. They are kind of an expansion to contact docking. Each block you place has a 3 meter radius. If any ship flies in that radius with its rail docker, it will automatically dock that ship to any rail block adjacent to the pickup area block. You can use the pickup area and the pickup point to make pickup points outside of your ship. Then, as the ship gets reeled in, you can use normal logic to open doors and store the ship inside your carrier. Keep in mind that the last pickup point used will be saved in the ship that used it. That will enable the carrier to call ships to the last pickup point they used. In the future you will also be able to control whether a pickup area is active or not via logic. Flying a ship manually into a pickup area will also result in it docking and it can be used to allow touch docking of flat surface which wasn’t possible before. 
    If you have your rail docker selected in flight mode, you’ll be able to see all pickup areas on your display.
  • Shootout Rail: The shootout rail is a way for docked ships to leave your carriers in a safe and non-obstructed way. Any ship reaching this rail will accelerate and shoot out the rails direction with some speed. To prevent misuse, ships will always undock on the end of a shootout rail even if you place a normal rail at the end of it.

Carrier Configuration

To make a carrier, all you have to do is use the pickup areas on your flagship with your drones once. Your drones have to be fleet members. Then you can use the “Recall to Carrier” order on your fleet to order all drones back to their pickup points from anywhere in the universe. Keep in mind that currently only one carrier (the flagship) per fleet is possible, but as long as a ship has no pickup point, it won’t try to dock, so you can mix drones and other fleet ships. You can also wipe a pickup point in the fleet menu if you click on a member. 


Fleet server options

Option to only allow factioned ships (of your own faction) to be added to your fleet, servers probably want to put this on true to prevent ship theft. 
  • ONLY_ALLOW_FACTION_SHIPS_ADDED_TO_FLEET = false

Option to allow fleet formations or not, it’s an experimental feature that could cause collisions and performance drops. 
  • ALLOW_FLEET_FORMATION = true

Art Assets

There is now a unique model for the healing beam, and minor adjustments have been made to the UI and other art assets as well. Furthermore, some sprites (missile/shield effects) have been updated.

Source]]>
StarMade v0.19361 - Flash Light, Ship Scores, On-Ship Spawning & Bugfixes https://starmade-servers.com/blog/55/starmade-v019361-flash-light-ship-scores-on-ship-spawning/ https://starmade-servers.com/blog/55/starmade-v019361-flash-light-ship-scores-on-ship-spawning/ Tue, 04 Aug 2015 15:58 CEST

Spawn on ships


Another feature is also the functionality that you can now spawn on moving ships. Even if the ship is moved after you logged out, and then in a sector that is currently not loaded, you will still spawn on your ship. This will work as long as you are in any way aligned to the ship while logging out: Pilot, in gravity, or simple spacebar alignment. 


This currently is limited to spawn after logout, but mechanics will come for respawning on ships after death. There still have to be some gameplay aspects discussed, as you wouldn't want a player to spawn on a ship you just stole. 

Ship Scores


Another larger feature which is still in the making is ship score. This is basically a way to automatically classify ships. Ship scores are aggregated from multiple simpler scores. As for example weapons generate scores from: 

  • damage per second
  • hit probability (projectile speed, reload, spread)
  • distance
  • power consumption

These scores are then aggregated with the power score, and other scores to generate 4 main scores: 

  • Offensive Score
  • Defensive Score
  • Mobility Score
  • Support Score

Since it's fairly obvious that these values have to be balanced, the main scoring process has been externalized to a LUA script to change it on the fly. 


After a few iterations of initial balance not only will they make it easier to classify ships in the blueprint/website, we can also then use the scores to determine pirate spawning by difficulty, and adapt it depending on how powerful the combined scores of the players in an area are, which should lead to a lot better scaling difficulty and therefore more fun. 


Exploit Fixes and Optimizations


There also have been lots of small optimizations in various parts of the game. For example, framerates on very large structures should go up a bit when higher max-segments are set in the options. 


There also have been some fixes to exploitations of game mechanics like the shield drain/supply being overpowered. Also cloaking/jamming now has a reload sequence when switched off. 

Balance


The block behavior config received some minor changes: 

  • Power consumption per second was changed to power consumption per tick, all related values were changed accordingly.
  • EMP power damage was doubled, the power damage dealt to a ship is 2 times higher than the power consumed to fire that weapon.
  • Shield drain, supply and power drain received some value changes, it should be balanced: 
    Shield drain has the same shield DPS and power use as any other basic weapon but it gives you 50% of the drained HP. 
    Shield supply is set to power supply levels, its power consumption is 10 times lower though since a supply transfers 100% of your own shield. 
    Power drain, drains 50% less power than an equal EMP weapon but you gain 50% of the drained power.
  • Shield drain and supply now allow supports.

Bugfixes


A list of fixed bugs can be found in the original post[star-made.org]. 

Source : http://steamcommunity.com/games/244770/announcements/detail/795235381328507148]]>
Ping Feature https://starmade-servers.com/blog/54/ping-feature/ https://starmade-servers.com/blog/54/ping-feature/ Sun, 28 Jun 2015 23:31 CEST
We are the only web server list for offer such feature and be sure that in the future we will do our best to continue to add original features.

There are lot of criteria to select a good StarMade server. Among all of them, the latency is very important: no one wants to play on a server that is lagging like hell.

That's why StarMade-Servers.com will help you finding a server with the best ping in a location close to you.

Currently our "Ping" feature has 12 locations:

  • Australia
  • Brazil
  • China
  • Chicago, US
  • Dallas, US
  • Los Angeles, US
  • North America
  • Germany
  • Eastern Europe
  • Western Europe
  • Sweden
  • Russia

 

Discover our Ping Feature

]]>
StarMade 0.19282 - More Fun Into Battles https://starmade-servers.com/blog/53/starmade-019282-more-fun-into-battles/ https://starmade-servers.com/blog/53/starmade-019282-more-fun-into-battles/ Sun, 21 Jun 2015 14:28 CEST
We redesigned how ship battles work, adding a completely new system, called the “HP-System”. There are also a lot of other enhancements and fixes in the update. 

Here is a video that explains the new features:

https://www.youtube.com/watch?v=iF0fe6EBMuA

 

Hitpoints

 

System-HP

 

One of the biggest constructive criticisms we get for the game is that ship battles are basically a race on who can take out the core of the other ship. Which makes it a single focus point for everything. We long wanted to fix this problem, but first had to solve a lot of other problems along the way, ensuring that the new system is not more boring or broken than the old one, but intuitive and fun.

 

A Hit Point System was the goal, but while it sounds easy on paper, it actually required a lot of problems to be solved for integration.

Here are some of the problems that came up along the way:

 

HP is always represented by two values: Maximal HP which indicates how many Hit Points an entity has, and current HP which indicates how many Hit Points the entity currently has left.
 

The first problem was with determining how to keep track of HP.

 

One idea that seems natural was to keep a copy of the ship in the status of full hp. This however would cause a lot of problems, as it would essentially double the size of ships in RAM, on disk, and cause problems managing it, as every change that modifies max HP would also modify that copy. All that for just two values seemed a very bad deal in cost-value.

 

To combat that problem we are using a block count system, which has existed anyway. This however means that HP is based on the blocks, so if a block is damaged it still provides HP as long as it’s not destroyed.

 

This means we can have a very small and fast way of keeping track of maxHP vs currentHP.

 

Now, what is the max HP based on? If you would add a block to a ship, you would want your maximumHP to go up based on what you have placed. The same would have to happen if you removed a block.

 

This all works fine, but what happens if you lose a block due to damage. Naturally you wouldn’t lose maximumHP, but only current HP of course. However, what happens then if you place a block? Would you get the HP back? Would that mean if you place another you would have more HP than maximumHP, would both HP and maximumHP go up? What is the actual ship’s state that the max HP is based on?

 

  • If your HP is at 100% adding and removing blocks will instantly update your HP keeping your HP at 100%.

  • If you are below 100% placing a block will NOT give you any HP, but still increase your maxHP.

  • If you are below 100% removing a block will deduct from your current HP, but not decrease your max HP. This means you will lose percentage when removing blocks from a damaged ship.

  • If you reach certain damage below 100% you will get negative effects like power/shield regeneration loss, loss of thrust, control, and at the end the “overheating” state. This means that you don’t have to kill every single block to kill a ship, but only a certain percentage.

 

So, what can you do to get back to 100% once you have lost blocks? The solution was to add a mechanism called “Reboot”.

A reboot takes your max HP to what the ship’s blocks currently represent, and also brings your current HP to 100%.

You probably already saw the potential problem that brings: Just quickly reboot in battle and you will be at 100% again. However, rebooting actually takes time. The time is based on the damage taken, as well as the overall mass of the ship. You also can neither modify or fly a ship that is currently being rebooted, and power and shields go down to 0. It is also canceled if more damage is done. All these things make it relatively silly to try to reboot in combat.

 

The most Hit Points are provided by system blocks like power, weapons, support, etc. So ships now have actual weakpoints.

 

Furthermore on overheating you will no longer die instantly. You will get thrown out of your ship (it is now implemented that you automatically align to a ship when exiting it) and you can get to your escape pod, or stay and fend off a possible boarding party. You can’t enter your ship while it is overheating, and your only way to stop it is to reboot by pressing ‘r’ on the core. When a core is rebooting from overheating, you will not be able to enter it until it is done overheating.

 

Armor-HP

 

To further add more depth to ship battles, armor HP has also been introduced. Armor HP is the complement to System HP. The only blocks providing armor HP are actual armor blocks like hulls.

 

Armor HP provides a damage reduction to all damage taken to an armor block. Upon damage, 50% (config value) of the damage is going to Armor HP and the other half will be the damage on the ship, as long as there are any Armor Hit Points left.

 

Armor HP does NOT reset with a reboot, and can only be repaired at ships (or future ship yards) for credits. Ships can also reboot instantly at shops for credits.

 

Losing armor HP will not give you any negative effects, but they are a vital resource to have on a good ship.

 

Both System-HP and Armor-HP give a whole new feeling to ship battles, making them a lot more fun and exciting. All values of course are not final, because as always we took care that all essential values are available in the blockBehaviorConfig.xml. You can also go back to ship core based combat from the serverConfig if you would like to do so.

 

Center of Mass

 

Center of Mass is also no longer the core. It will now calculate the center of mass of a ship precisely on any mass placed anywhere.

This doesn’t yet include docked entities, but it will soon. Also, in the future there will be options to have a more realistic physical model based on the shape of the ship in terms of being able to turn the ship.

Implementation wise, the new Center of Mass system doesn’t cost any performance and is updated immediately (best to try it out on a planet)

AI has also been updated to now aim at the Center of Mass which gives them a much better chance to hit something vital.

You can also switch on an indicator for center of mass in the advanced build mode.

 

Individual Block Mass

 

With the new center of mass implementation it was also time to integrate individual block masses. This means, decorative elements will now barely add any mass to the ship, while armor and other blocks will add more than usual. Of course the center of mass will also reflect individual masses.

 

Cannon and Beam damage rework

 

Since now every block counts in terms of a ship taking damage, the missile seemed really superior as while it has similar total damage, it just takes out blocks a lot faster.

 

Cannons now do damage to multiple blocks by default. The more damage a projectile has, the more blocks will be affected. Starting at 100 - 900 damage goes one block deeper per 100, from 1000, every 1000, and so forth.

The damage is then distributed so that the first block hit will take the most and the last one the least damage. Accurate numbers can be looked up in the structure panel.

 

A beam will do the exact damage no matter if the block got taken out or not (what in the past the piercing effect did), but it is stopped by any block that provides armor HP.

The cannons has to take out a block to get to the next one, so if the damage of 1 block deep is not enough, the damage that would go in the second block will be used on the first until it is taken out. Any damage more that it took to take out a block is however still lost. Overall this still means a lot less damage is lost from cannons and more blocks are taken out per shot.

 

All values are of course still not in a final state and are available in the config.

 

New tools and boarding mechanics

 

Two new tools have been added and are now available from the shop keeps. These keeps can now also be respawned in the middle of the glass area of Shops that had them.

 

Grapple Beam

 

This beam aligns you to an object on a very far range. It doesn’t automatically reel you in (yet), but you will have time to get to the object before the grapple expires. This makes it possible to get on objects from a good distance and board them.

 

Torch

 

This useful tool does little damage but has a very distinct advantage: It bypasses armor and shields and throws the pilot out of the core if the core was brought down to 0 HP with it.

This means you can use the torch to take over enemy ships. Be warned though: The pilot will receive a warning if a torch is being used on his ship.

 

New Turret AI option

 

Since with the new mechanics, you not only have to defend your ship from the outside, but also from the inside. This new AI option makes turrets only target astronauts.

 

Ship info window now customizable

 

It is now possible to resize and move the ship info while holding control in build mode. You can now also change the size of the text so it is much easier to read on higher resolutions. A general size option will also come later for all menus.

Multiple weapon hot bars

 

Another requested feature was the addition of more places to put weapons, especially with inner ship logic now being a thing, so we added 9 more hotbars. There are multiple ways to switch through them.

 

  • Pure mouse scroll: upon going to the end of a hotbar you will switch to the next one. This can be disabled in the ingame options.

  • Control+Mousewheel switches through hotbars

  • Control+number selects a hotbar directly (with ‘0’ being the 10th)

 

Additional Chat Controls

 

More chat options have been added to enhance the experience.

 

• Client-side ability to ignore other players

• Admin Mute Command

 

They are usable via the right click context menu.

 

New bug tracker

 

We switched to a new bug tracker, which will make tracking a lot easier and streamlined with the development process.

 

Colored Missile Trails

 

The trailed of colored missiles are now also colored.

 

Bug Fixes

 

A lot has been done since the last update. Thanks to all the testers!

One thing to note is that missile turrets have been upgraded to now being able to hit missiles a lot better. Turret rotation is now mass based, so smaller missile turrets are better in aiming and leading a target. Also the “aim at selected” AI option has been fixed.

  1. T255 can't load old templates
  2. T253 Old docking system makes astronauts stop moving
  3. T213 Numpad Enter causes newline in dialog, instead of "submitting" the value
  4. T196 Blocks dropped on death do not spawn properly
  5. T184 Diaply.Hide Help Screen typo
  6. T160 TAB + F8 nullpointer
  7. T155 texture faces are rotated
  8. T139 Damage Pulse modules listed as "beam unit" in Weapons menu
  9. T132 Hotbar indicators are missing
  10. T131 Selected waypoint sometimes wrong color after closing Navigation menu
  11. T130 Cannot access ship storage after removing named chest
  12. T127 "Killing" the ship core kicks pilot out
  13. T125 removing blocks as astronaut doesn't update ship or armor HP
  14. T123 Destroyed entity will cause you to go back to where you got in.
  15. T114 blocks discarded on deletion as astronaut when not enough inventory space
  16. T112 HP System - tiny ships and cores cannot be killed
  17. T110 shooting factioned planet with missiles crashes all players not in that sector
  18. T88 Area triggers are invisible
  19. T77 escape key does not close options menu
  20. T60 Inner Ship Remote labels don't work until weapons menu is opened
  21. T58 Joining a faction when not being in one causes all factionless players to recieve a "<playername> has left your faction" notice
  22. T49 Crash when holding weapon menu items in your cursor and opening inventory
  23. T48 rail basic acts like turret axis block
  24. T38 Faction systems do not work for all 12 planet segments
  25. T35 Scan history nullpointer
  26. T31 Oculus Rift DK2 Error
  27. T30 Anti-missile turrets ineffective
  28. T23 Station not saving
  29. T21 /explode_planet_sector explodes planets in all loaded sectors
  30. T15 Serverlist ping-check only trying TCP
  31. T13 Ship HP damaged systems does not change anything
  32. T12 Rail turret blueprint and nullpointer issue
  33. T10 Rail entities are not properly synced across clients
  34. T7 Ship always inherits faction after reloading sector
  35. T5 local rail blueprint errors with multiple chains
  36. T3 Require auth + not uplinked does not show a clear enough error-message on connecting

 

Music

We're currently looking to create SFX and a soundtrack for the game, if you're interested and have the skills, please send an email to duke@star-made.org with some samples and info about yourself. We're aiming for orchestral, classical and ambient elements, however any sample you think will impress us is fine.

Coming up

 

There is a completely new launcher nearly done. It will be built to make the installation of java for the game absolutely obsolete. It will also eliminate any java version problems, as well as add a lot of other features. It will also be the starting point for finally having an ingame menu, as well as ingame server switching (which are easy to do but held off for solving other problems around the game). Also, work on the creature system will now switch into full focus.


Thanks for playing StarMade,

- schema and the Schine Team

Source : http://star-made.org/news/starmade-v0-19282-putting-more-fun-into-battles-also-boarding

]]>
StarMade 0.19226 Released With Rail System https://starmade-servers.com/blog/52/starmade-019226-released-with-rail-system/ https://starmade-servers.com/blog/52/starmade-019226-released-with-rail-system/ Tue, 12 May 2015 11:14 CEST
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 ton 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 fixing bugs. They’re getting more and more familiar with the huge codebase, so bugfixing and work on new features will continue to speed up. 


Here is the news in youtube form: 



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

http://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 on our site.[star-made.org] 

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 ground up. The new design is far more suited for all the current demands, as well as things to come. 

The old system is still functional so ships, blueprints, or other structures will not break. The only restriction is that the docking beam is replaced with a pure activation beam, but if needed, 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 are also completely integrated 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. The most common example of 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 joined on a 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 will 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 removed. 

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 does 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 that were caused by the rail system itself are not listed) 


Rail Docking Explained

Please go to our website to get an in-depth explanation and reference for all new systems.[star-made.org] 


Use of the rail system, Crimson-Artist 
 

That’s all for now, 
Thanks for playing StarMade, 

- schema and the Schine Team

Source : http://steamcommunity.com/games/244770/announcements/detail/249166030719835294]]>
API Documentation Updated https://starmade-servers.com/blog/51/api-documentation-updated/ https://starmade-servers.com/blog/51/api-documentation-updated/ Tue, 17 Feb 2015 15:42 CET
You can download it or find other wrappers/scripts that use our API here : https://starmade-servers.com/help/api/]]>