I ended up deviating a bit from my work on the lunar base mission today, as I’m waiting on further developments on the new enemy before I go too in-depth with careful placement and setting up the loot distribution. We have some other cool stuff for it in the works, but I’d really like to keep those elements a surprise if I can help it.

Instead I primarily spent my time getting the Novakid armors that George showed off last week actually craftable in-game. We’ve got all their tiered weapons designed and ready to go too, they just need to be implemented and balanced.

The Novakids feel so at home in our universe, they could well usurp the Glitch as my favorite race!

I’ve also begun work on rebalancing all the armors that fall into the separator, accelerator and manipulator classes. I expect to spend most of tomorrow continuing on this task, so I’d like to get it to a good place. That said, I have no doubt we’ll need to do some fine-tuning down the line as we continue our playtesting.

Until next time!

Recently, we’ve been discussing adding some more capabilities to the Status and Status Effect system in Starbound.  There are a lot of interesting things we want to do, but as of right now the Status system is a bit of a pain point in the Starbound codebase.

Every Status equipped entity has around 20 stats, all defined directly in c++, and they can be affected by about *45* status effect primitives, also specified in c++.  Status primitives are everything from ForceField to FlawedProtection to ClumsyProtection to ExplosiveDefense to ExplosiveDefensePower to.. you get the idea.  Extending the status system right now involves doing things like extending this enum and adding to this set of fields.

Now, don’t get me wrong, simple and hard-coded sometimes works great.  Usually, it’s what you want to try *first*, and you stick with that until it’s clear that it needs to be replaced by something more powerful.  Well, for the Status system, that time is NOW.

Omni and I have been working on a replacement for the Status system that should hit (fingers crossed) master in a few days.  Stats are generic String -> Float mappings, there’s a system for adding temporary modifiers to the String -> Float set, there is a resource system that is closely tied to the stats system for things like health / energy / warmth, and, the most exciting part is, it will be driven by lua scripts!

Not only will this allow us to have, well.. sort of more “interesting” status effects like brain reboot and things like that driven by an isolated script and with way more interesting graphical effects, it will allow modders to add additional status effects and, as a side effect, will give modders a place to add persistent client-side data and scripts that affect the player without having to tie into the tech system.

Also, as either part of this update or soon thereafter, I’m trying to work it so that status graphical effects like cold and hunger that affect the screen can actually modify the shader used by the world renderer for some more interesting graphical effects than what we have now.

It’s exciting!

The new JSON patching system discussed way back on June 25 has landed. There might be a few edge cases that aren’t implemented correctly, but it’s passed all of the tests I threw at it. Let me know if you find an edge case I missed.

“__merge” style patches no longer work. You can override files fully, or you can use the patch system. To use a patch, name the file “whatever.config.patch” where “whatever.config” is the file you want to patch. It should support the entirety of RFC6902 and RFC6901.

Q: Can you give us an example?

A: Sure:

Here’s a short example.
Let’s say you have a file named… oh I don’t know, “player.config” And let’s say you want to change the hitbox of the player by changing around the standing poly.
You would create a file called “player.config.patch” and it could contain, for example, the following:


[
  { "op" : "replace", "path" : "/techControllerSettings/baseMovementParameters/standingPoly/2", "value" : [ 1.35, -2.5] },
  { "op" : "replace", "path" : "/techControllerSettings/baseMovementParameters/standingPoly/3", "value" : [ 1.75, -2.0] },
  { "op" : "replace", "path" : "/techControllerSettings/baseMovementParameters/standingPoly/4", "value" : [ 1.75, 0.65] },
  { "op" : "replace", "path" : "/techControllerSettings/baseMovementParameters/standingPoly/5", "value" : [ 1.35, 1.22] }
]


What that will do is change the values in the file from:


  "techControllerSettings" : {
    "baseMovementParameters" : {
       "standingPoly" : [ [-0.75, -2.0], [-0.35, -2.5], [0.35, -2.5], [0.75, -2.0], [0.75, 0.65], [0.35, 1.22], [-0.35, 1.22], [-0.75, 0.65] ],
       "crouchingPoly" : [ [-0.75, -2.0], [-0.35, -2.5], [0.35, -2.5], [0.75, -2.0], [0.75, -1], [0.35, -0.5], [-0.35, -0.5], [-0.75, -1] ],
       "airFriction" : 0.2,
       "mass" : 0.6,
       // should keep the player from teleporting through walls
       "maximumCorrection" : 1,
       "maxMovementPerStep" : 0.4
     }
   },


to


   "techControllerSettings" : {
     "baseMovementParameters" : {
       "standingPoly" : [ [-0.75, -2.0], [-0.35, -2.5], [1.35, -2.5], [1.75, -2.0], [1.75, 0.65], [1.35, 1.22], [-0.35, 1.22], [-0.75, 0.65] ],
       "crouchingPoly" : [ [-0.75, -2.0], [-0.35, -2.5], [0.35, -2.5], [0.75, -2.0], [0.75, -1], [0.35, -0.5], [-0.35, -0.5], [-0.75, -1] ],
       "airFriction" : 0.2,
       "mass" : 0.6,
       // should keep the player from teleporting through walls
       "maximumCorrection" : 1,
       "maxMovementPerStep" : 0.4
     }
   },


Possible values for “op” are: “test”, “add”, “remove”, “move”, “copy”, and “replace”. They do what it says on the tin. The only one potentially confusing is “test” which simply tests the path for some value, and if it’s not correct it aborts the patch.

“test”, “add”, and “replace” take “path” and “value”
“remove” just takes “path”
“move” and “copy” take “from” and “path”

There’s other stuff like “-” for end of list and using ~1 and ~0 to reference “/” and “~” respectively. But that’s pretty much it.