Starmade
Small Update with fixes for modlauncher
this is a small update, that fixes some issues with mods as well as balane:
- Fixed customBlockConfig being ignored when mods are enabled
- Fixed weapons dealing 1/3rd of their intended damage
- Added notification dialog when joining a server that has mods enabled
We have gotten some new contributors on the repository of the code. Since it's not a small project, it will take a little until things take off. If you would like to contribute, please send me a quick DM on discord https://discord.gg/6r9KGmJWbn
We're also getting the bug tracker back up, and will likely make a fresh start to clean up and to not overwhelm newcomers.
Thanks for playing the game,
- schema & the Schine Team, the mod-launcher team, and contributers.
StarMade 0.203.101
as announced this is a minor update by the community, already using the opened codebase.
It fixes a few bugs, as well adds a mod-loader.
Bug fixes:
- Fixed AI leading beam shots
- Fixed the "Require authentication" being enabled by default, making people unable to log into single player without uplink.
- Made factory progress bars not factoring in the Factory Bake Time chamber
- New UI for the blueprint manager
- Effects and defenses now use a more straightforward formula, where the defense rating subtracts a percentage of incoming damage in the corresponding offensive effect type
- Fixed an issue where all defense ratings were multiplied by zero. Defensive effects (such as armor chambers and innate defenses from the BlockBehaviorConfig) are now functional.
There is also an addition of an in-development mod loader. Note that there may be some bugs, please report these to the StarLoader discord
Joining modded servers will automatically download the mods needed to join. Servers may still experience a few bugs, however, but hopefully not many.
The modding API is a work in progress and subject to change, but many of the core systems are in place. Check the StarLoader discord for tutorials.
The code is currently open on an invite-based system until we made sure that everything is in order. If you like to contribute, please feel free to send me (schema) a PM in the StarMade discord.
(special thanks to all the people working on the code already, enabling new updates. Special thanks to the StarLoader Team & Community as well.)
Thanks for playing the game,
- schema, the Schine crew, and the StarLoader Team & Community.
Fixed Launcher Login
The update should fix that.
There will be an actual game update and more news within the next few days.
The summery of that:
- StarMade will go Open Source for the community. (since I can't work on it until I have enough money to not have to work on other projects for a while)
- Community mod launcher
- Balance updates and bugfixes
Sorry for the long wait without update. I'm still alive and want to finish the game, but I'll leave the source for the community for now.
- schema
STARMADE V0.202.86 - BALANCE CHANGES
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
Big performance increases (I/O) - Universe update dev dump 4 [30 OCT - 7 NOV]
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.
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:
--- 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]
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:
What's coming up:
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]
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:
What's coming up:
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]
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:
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:
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:
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.
Modding + QuickFire balance (dev build v0.202.0)
We've released a dev build that introduces two things:
[LIST]<*>Implemented QuickFire balancing project configs as default.
[/LIST]
AND:
[LIST]<*>This build has been (mostly) unobfuscated, to reduce the barrier for our community to mod StarMade.
[/LIST]
See image below for how to install the dev build.
[IMG]https://i.imgur.com/1rVul5i.png[/IMG]
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.
[B]
Modding[/B]
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:
[LIST]<*>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. ([URL="https://github.com/Schine/StarMade-Launcher"]Schine/StarMade-Launcher[/URL])
<*>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 ([URL="https://www.spongepowered.org/"]Sponge - Minecraft: Java Edition Modding API[/URL]) who has expressed interest in helping StarMade modders.
[/LIST]
A modding proposal based on the input we received from modders has been created by Zidane and Gabizou from the Minecraft [URL="https://www.spongepowered.org"]Sponge Team[/URL]. [URL="https://docs.google.com/document/d/1-p_OzQ0I0fhmfkjX_Q3CJ2d15zUjtTuGhllnhm5p-Fw/edit?usp=sharing"]You can check that out here[/URL].
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: [URL="https://docs.google.com/document/d/1Fm7BbsT5VvH5RNZ30QnmWjA1EYDwkQYUjIziZYqrxzw/edit?usp=sharing"]modpack format[/URL]
The input we've received has been keeping in mind the following:
[LIST]<*>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.
[/LIST]
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: [URL="https://discord.gg/UvgYcP8"]Join the StarMade Discord Server![/URL]
Alternatively, you can email DukeofRealms here: tai@schine.games
[B]Thanks to all the modders who helped us[/B]
We received a lot of useful feedback and input from modders, we'd like to thank those that helped us so far here:
[URL="https://fabricmc.net/"]The Fabric team[/URL] ([URL="https://github.com/asiekierka"]asie[/URL], [URL="https://github.com/sfPlayer1"]sfPlayer1[/URL], [URL="https://github.com/Prospector"]Prospector[/URL], [URL="https://github.com/grondag"]Grondag[/URL] and [URL="https://github.com/modmuss50"]modmuss50[/URL]) 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.
[URL="https://www.spongepowered.org"]The Sponge team[/URL] ([URL="https://github.com/Zidane"]Zidane[/URL], [URL="https://github.com/gabizou"]gabizou[/URL], [URL="https://github.com/progwml6"]progwml6[/URL], [URL="https://github.com/jamierocks"]jamierocks/jmansfield[/URL], [URL="https://github.com/Katrix"]Katrix[/URL] and [URL="https://github.com/d4rkfly3r"]Snowie[/URL]). 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 [URL="https://github.com/kashike"]kashike[/URL], [URL="https://github.com/DemonWav"]DemonWav[/URL], [URL="https://github.com/madmaxoft"]madmaxoft[/URL], [URL="https://github.com/darkhax"]darkhax [/URL]and [URL="https://github.com/clienthax"]Clienthax[/URL] for joining our Discord modding channel and giving their input on StarMade modding.
Thanks to [URL="https://github.com/Benevolent27"]Benevolent27[/URL], [URL="https://github.com/Alendon1"]Alendon[/URL] and [URL="https://github.com/BlueStriderX"]TheDerpGamerX[/URL], 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:
[LIST]<*>[URL="https://github.com/asiekierka"]asie[/URL] - tons of feedback about modding and considerations we should take about our policies.
<*>[URL="https://github.com/jamierocks"]jamierocks/jmansfield[/URL] - 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.
<*>[URL="https://github.com/gabizou"]gabizou[/URL] - Gave a ton of input in Discord DMs and our Discord channel. Went through an unobfuscated build, giving feedback and input.
<*>[URL="https://github.com/Zidane"]Zidane[/URL] - Gave a ton of input in Discord DMs and our Discord channel. Started the mod proposal google doc, which is very comprehensive.
<*>[URL="https://github.com/progwml6"]progwml6[/URL] - 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.
<*>[URL="https://github.com/jaredlll08"]jaredlll08[/URL] - Gave a ton of input in Discord DMs and our Discord channel.
[/LIST]
Finally, [URL="https://github.com/NZSmartie"]NZSmartie[/URL] for starting the [URL="https://github.com/distortsm"]DistortSM[/URL] 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]I’ve tried to include everyone if I missed you, I’m very sorry, we’ll rectify it ASAP :)[/I]
[B]QuickFire project[/B]
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:[URL="https://starmadedock.net/threads/cs-quickfire-initiative-rebalancing-starmade.31361/"] https://starmadedock.net/threads/cs-quickfire-initiative-rebalancing-starmade.31361/[/URL]
Important details:
[LIST]<*>"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
<*>The config is not completed. "Beware that with the current dev build config, small-ship combat is broken. Armor is simply too powerful at those scales against both beams and cannons. We have revamped the values, but until beams switch to the proper formula, we are not releasing the new config version." - 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 ([URL="https://discordapp.com/invite/45zmQBe"]Join the Starmade Quickfire Initiative Discord Server![/URL]) or forum thread ([URL]https://starmadedock.net/threads/the-quickfire-initiative-rebalancing-starmade.31326/[/URL]).
<*>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 :)
[/LIST]
Check out our news post about QuickFire from last week here:[URL="https://starmadedock.net/threads/cs-quickfire-initiative-rebalancing-starmade.31361/"] https://starmadedock.net/threads/cs-quickfire-initiative-rebalancing-starmade.31361/[/URL]
Important links:
[LIST]<*>Latest config files (GitHub) -[URL="https://github.com/alterintel/Quickfire"] https://github.com/alterintel/Quickfire[/URL]
<*>Overview of QF changes - [URL="https://docs.google.com/document/u/1/d/e/2PACX-1vRgkpoMYG6YJEHZjWQ7_jjDSRJfU-p8FfMR-vykhe7Q30vmTzS5F7xGLzsrUcB9_LLcGgToeNICsOaA/pub"]Quickfire Initiative - Config v0.1 Changelog/Overview[/URL]
<*>A more detailed document of changes and their reasons - [URL="https://docs.google.com/document/d/e/2PACX-1vT4o3-6V-bwjWPbzwrLE2XqplRZsF4ExsF65BR_4dkuHFa5Lx8wIDKDdgxYJmTwuILhS4_sHIpS86dy/pub"]Quickfire Initiative - Config v0.1 Full Change Overview + reasons.[/URL]
<*>QF forum thread - [URL]https://starmadedock.net/threads/the-quickfire-initiative-rebalancing-starmade.31326/[/URL]
<*>QF discord - [URL="https://discord.gg/CBJ5rV4"]Join the Starmade Quickfire Initiative Discord Server![/URL]
[/LIST]
Thanks to the QuickFire team and all those who have/will contribute to the project.
Ithirahad Ivrar'kiim : Lead Tester and Config. Forum thread manager, document writer, and generally unofficial chief keyboard jockey.
Scypio : Lead Tester and Config. Created several tools and utilities to make rapid config changes and publish information to the Discord, and does a lot of testing too.
SchnellBier : Lead promoter, he keeps this discord active and encourages constructive conversation.
Morphix : Founding member. Setup the QuickFire Discord Server.
Benevolent27 : Server and Bot admin and Consultant
Zoolimar : Primary Armor Mechanic and consultant.
ManhattenProject: Primary PVP consultant
IKindaCrashAlot : PVP consultant
Lord_Latterous : PVP consultant
alterintel : QuickFire Sponsor. He pays the bills and provides some technical know-how on the server-side.
Thanks for playing StarMade,
~ The Schine Team
CS: Quickfire Initiative: Rebalancing StarMade
Check out the "Discuss with the Devs" that happened in our official Discord last month here: [URL]https://starmadedock.net/threads/discuss-with-the-devs-july-18-2019-sis-shortform.31343/[/I]
---
[B]Quickfire Team[/B]:
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, [B]we need the community[/B]! 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 (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. A longer, more complete list of changes and the explanations behind them is available here.
If you have feedback, suggestions, questions, issues, or other comments about our config set, please post them in the project thread. You can also join the Quickfire Initiative Discord server.
---
[B]Schine[/B]:
We'll be adding the Quickfire config changes in a dev build in the next week or so. Please make sure to try these changes out and give your feedback. This will help us (and the Quickfire team) to decide what changes we should or shouldn't adopt into the default configs. The purpose of the dev build and news post is to draw attention to the QF project to help us receive feedback. [B]We will not[/B] officially adopt any changes into release until we feel a good solution for our community has been reached.
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!) 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