StarMade News

Hello players,

Update 0.202.87: Fixed missile speed for AI tracking

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

Greetings,

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:

• Latest config files (GitHub) -https://github.com/alterintel/Quickfire
• Overview of QF changes - Quickfire Initiative - Config v0.1 Changelog/Overview[docs.google.com]
• A more detailed document of changes and their reasons - Quickfire Initiative - Config v0.1 Full Change Overview + reasons.[docs.google.com]
• QF forum thread - https://starmadedock.net/threads/the-quickfire-initiative-rebalancing-starmade.31326/
• QF discord - Join the Starmade Quickfire Initiative Discord Server![discord.gg]

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

Hello players,

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

FixBuild 0.201.374

• Fixed cargo permissions not loading correctly

FixBuild 0.201.373

• Fixed issue for beams that would apply shield effect to damage even if shield is down
• Fixed several crashes
• Added new stabilizer bonus version (currently inactive in blockbehavior) that makes bonus depend on angle between stabilizers instead of dimensions

Hotfix 0.201.370:

• Fixed loading issue that would not let some machines connect to the local server
  (more fixes coming soon)

Hotfix 0.201.364: 

• Logic toggle trigger to activate beams didn't work correctly and timed out on
• Factory on/off switch didn't synch (and several other similar issues)
• Astronaut not mining ore/shards on first beam hit

---

Hello players,

here is a small feature and fix update. There will be several of those along the universe update roadmap. 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

 

 

Hello players,

This will be the first of hopefully many Roadmap updates for the Universe Update.

The universe update requires a lot of groundwork, and while there have been already some things prepared and done over the last year, there is still a lot left as well as fitting the pieces together.

First of all, let me give you a rough outline of the timeline of the Universe update.

The update is going to be comprised of three Phases. Each phase primarily consists of similar types of updates.

 

• Phase #1: Library upgrades, basic system refactoring and basic system enhancements
• Phase #2: Engine upgrades and System optimization
• Phase #3: Universe redesign and content creation

In the following, I will talk about what has already been done, and what the next steps are.

Phase #1:

Upgrade to Java 11

Status: DONE
There are several reasons for this: Java 11 is is not only more optimized on its own, it also provides new functions for cleaner code, game optimizations, as well as better compatibility. Furthermore, it is future proof, especially since a lot of newer versions of 3rd party libraries the game uses rely on a newer version of java. Another nice thing about it is that the runtime provided can be customized, meaning that we can deploy the game with a much smaller customized package that only contains the modules needed to run the game (and of course you would never have to install java to play the game).

 

Upgrade other major libraries

Status: DONE
Major libraries like hlsql (for databases) have been upgraded with new versions and the code had been refactored to support them.

 

Upgrade to Lwjgl 3

Status: DONE
Not only does lwjgl provide a closer interface to the hardware, it also comes with GLFW:
a universal interface, which is an Open Source, multi-platform library for OpenGL, OpenGL ES and Vulkan development on the desktop. It provides a simple API for creating windows, contexts and surfaces, receiving input and events.

GLFW is written in C and has native support for Windows, macOS and many Unix-like systems using the X Window System, such as Linux and FreeBSD.

Most of the upgrade work was already done in the background over the last year, so this major undertaking didn’t take as much time.

One major part of upgrading was also implementing some functionality (like text render management) that the previous version of lwjgl provided, since the new version is a lot less bloated, but instead a lot more modular and slick.

Another major advantage of lwjgl is that it comes with a lot of add-on libraries that can potentially optimize starmade or create new features like a faster compression lib. Also, Vulcan is fully available to us now.
Furthermore, there is a full library for Steamworks, which will make the planned implementation of steam functions (join game, etc) a lot faster and easier.

Redesigning the Input System

Status: DONE <- We are here
Since GLFW uses a whole different way to interface with input (keyboard, mouse, joysticks), I took the opportunity to rewrite StarMade’s input system to make it a lot more versatile, more responsive, and a lot less bug prone. The main advantage from the update, however, is that now every action in the game can be assigned to any device and button (including mouse wheel). This means firing with the keyboard, or switching slots with a joystick is now easily possible. The system can also handle modifier keys (key combinations), as well as any number of alternative inputs for an action.

 

Rest of Phase #1

• Integrate new lwjgl3 libs 
• Steamworks (join game, achievements, etc, workshop support probably later)
• GUI Scaling (100%, 150%, 200%) to cover everything from 1k to 4k
• Sound System (and a sound manager)
• There might be a few steps still in Phase #1. Time wise I hope to be done with this first phase somewhere in February.

 

Phase #2

Phase #2 is comprised of engine upgrades and system optimizations. There are a lot of plan to speed up block loading as well as block drawing by possibly a few magnitudes. This is necessary not only, but especially for the new planets.

This phase will also contain moving more things than ever to c++ code. I’m planning to move the physics to c++ fully, which will also natively support multiprocessor/threading.
Additionally, I’ll put the lighting calculations on c++ to speed up chunk graphics generation. With this, all processor heavy functions will be running in native c++, while maintaining the ease of project management that java provides.

On top of that, the graphics engine will be upgraded with a lot of functionality. Starting with simplifying a lot of block graphics data management, the main upgrade would be a new pipeline containing deferred rendering and dynamic lighting. Since dynamic lighting on its own never really works for voxel games of this scale, it will be built to be used in tandem with the baked lighting. This means that everything up close (or further away depending on the power of the graphics card) will be lit dynamically, meaning that light will look a lot better as well as affect other objects (cross entity lighting), while light in far away areas will be used the baked lighting as an approximation giving us optimal performance mixed with much better-looking visuals.

Another upgrade in phase #2 will be the content loader for sectors. If everything goes to plan, a sector switch will hopefully be virtually undetectable by a player.

This phase will also contain a rewrite of all the AI functions (might be moved to phase 3)

I will talk more in detail about Phase #2 when we get there.

TimeLine: This is in no way certain but I hope to finish with this phase in the first half of 2019.

Phase #3

The actual content phase. After phase #1 and #2, the engine should be in a great state. This phase includes redesigning the whole universe to a more condensed playing field filled with content and gameplay.
I can’t reveal too much about it yet since there are still some uncertain details that depend on the prior phases, but I will talk a lot more about more about these things in the updates during and after phase #2.

I hope that this will give you a nice overview of the current status of development. Everyone at Schine will continue to work at full power to make this the defining update to StarMade worthy of giving it the subtitle: StarMade 2020.

Thanks for playing StarMade,
- The Schine team