1. StarMade
  2. News

StarMade News

STARMADE V0.202.86 - BALANCE CHANGES

Hello players,



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.

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


[h2]Quickfire[/h2]
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




[h3]OVERVIEW[/h3]​


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

Big performance increases (I/O) - Universe update dev dump 4 [30 OCT - 7 NOV]

Screenshot and station build by SkylordLuke.

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!

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]

Image is of USS Endeavor, by Wilavid7. You can check out the progress of his ship here. Background image taken by 12yanogden.


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!

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

More audio work! Universe update dev dump 2 - [11th of October - 20th]

Image is of 116-2 Marksman, by MeRobo.

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!

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.


Universe update discord dev dump - [1st of October - 10th]

Image is of Brimstone-L7 Advanced Salvager by DeepspaceMechanic.

This has been copied (with a couple of corrections) from the semi-daily updates posted by schema in our official Discord server, in the #universe-update-dev-news-dump channel. To receive universe update news as it happens, join our Discord channel here: Join the StarMade Discord Server!

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 (
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 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


1
1

BUTTON
GUI
PRESS
HOVER


ONE_TIME
false
false



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