Stats and Scripts

August 20, 2014 in Dev Blog

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!

August 19 – The day when all your mods died.

August 19, 2014 in Dev Blog

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.

August 19th – Let’s throw a rave!

August 19, 2014 in Dev Blog

It’s pretty much been business as usual for me the last few days. The lunar base mission is getting to a really nice place, and I’ll be able to start populating it with enemies and loot very soon.

Kyren kindly implemented a quick update to our lighting engine that provides far greater control of how a light flickers. Previously the controls were a little vague and it was often difficult to get the precise results desired. It was difficult to get lights doing anything other than dimming and brightening in an largely unpredictable fashion.

Now we have the capacity to make lights pulse, strobe, or flicker erratically as we wish. As a side effect of this update, you may notice in the nightly that any lights that previously flickered currently are not doing so, but I’ll be quickly zipping through them to make them work as intended again in my downtime.

I put a quick video test together with a variation of the spotlights that flickers erratically. I do not advise watching this video if you are sensitive to strobing light effects as I have purposefully used a lot of them in one space simply to demonstrate.

Good night!

August 18th – More Manipulation

August 18, 2014 in Dev Blog

As we’ve been working on the progression of the early game, one awkward point that kept coming up is the Matter Manipulator. You’re given this all-purpose future tool, but then immediately replace it with stone age pickaxes because of their superior digging ability. So, for the past few days, I’ve been prototyping a system of upgrades for the Matter Manipulator that should keep it useful throughout the course of the game and give players something more futuristic than hand tools. This is all WIP, obviously, but so far it seems to make more sense both aesthetically and mechanically. Here’s a quick look at the current range of upgrades we’re testing:

Players will be able to upgrade the area, digging power, and other numerical aspects of the Matter Manipulator as well as enabling new harvesting options such as liquid collection. Hopefully, this should make it a satisfying tool in your character’s arsenal and even offer a bit of customization to suit your play style.

15th of August, 2014: Dev Blog Nova

August 15, 2014 in Dev Blog

Here’s a little something I’ve been working on… The Novakid will be needing their own armor sets.

novakidarmorZZZClick it to enlarge!

Time to go back to my Devcave. K Bye!

August 14th – Steady as she goes!

August 14, 2014 in Dev Blog

Hey guys!

Over the past few days I’ve continued my work on the lunar base mission with a nice steady rate of progress with some feedback from Tiy and George along the way. As I’ve stated previously, I don’t wish to spoil any plot details, but I’m okay with teasing a small piece of the environment. You may also notice a subtle new feature that crept its way into the game. Blocks are now capable of casting light.

Lunar Base Progress

It can be challenging at times; sculpting out a cave environment in such a way that it looks natural while also keeping the player’s ability to traverse it firmly in mind. That said, I think it’s coming along nicely.

On a side note, yesterday’s upload of the nightly build failed, so if you’re interested in trying out Kyren’s new projectile code, the update only went live a couple of hours ago. Personally, I’ve already noticed a huge improvement!

Area-of-effect projectiles like grenades are hitting and damaging multiple enemies far more reliably. The issue of projectiles outright disappearing when shot point blank into an enemy’s face is gone. If you have a bunch of monsters clustered together and you land a melee attack it now damages all of them as it should, rather than just a fraction. The PvE combat is feeling really good right now. Nice work, Kyren!

Anyway, that’s it from me. Stay classy and good night!

It’s Aug 13 now

August 13, 2014 in Dev Blog

Projectile disconnect fix is complete and pushed to master.  It’s less of a fix and more of a.. near total rework.

I promised I would go into more detail but.. it’s late so here’s the very VERY quick version:

Projectiles are now proper synced entities with entity update deltas and everything, and damage is sometimes applied where an entity is not necessarily the master entity.  Our old concept of a disconnected entity is gone, and there has been a lot of simplification with other damage and status related parts of the code.  Self damage no longer routes through the damage manager, and instead entities can produce arbitrary damage notifications themselves.  Damage requests and now also a new thing called *hit requests* can travel over the network before being applied, and there is no longer a need for direct status effect requests over the network.  Total change in lines of code: -120

PvP needs lots more work still, but PvE locally and over network should be MILES better.

Aug 12, yep definitely 12

August 13, 2014 in Dev Blog

Sorry, I was supposed to do the daily update yesterday and I missed it :(

I’ve been working on a ton of things lately, instancing and unique world support, world <-> world warping, new world generation types and general world generation fixes, material light sources.

But right now I’m fixing a loooong standing series of bugs in starbound regarding projectile disconnects between the client and server.  I’m basically done, and with any luck you will see it in tonight’s update.

If I finish and merge today, I’ll do another post later today that goes into how the fix actually works.

August 11 – Documentation again

August 11, 2014 in Dev Blog

Remember the late time I mentioned documentation I said I’d eventually make it automated?

I did that today. It’s now tied to the steam upload so it should update every time Steam does (ie, nightly).

You can find the documentation here: http://doc.playstarbound.com/

You can navigate around by classes or by namespace, but the front page is mostly blank (because it’s the default doxygen setup).

The bits that you lua modders are most interested in are located here: http://doc.playstarbound.com/namespaceStar_1_1LuaBindings.html under the namespaces section (for instance: http://doc.playstarbound.com/namespaceStar_1_1LuaBindings_1_1WorldEnvironmentCallbacks.html )

Hope this helps!

Also did a few things with the Sky today. I’m currently separating the Sky from the Celestial Coordinate system so that we can give fully featured Skies to Outputs and Instances and the like. Nothing too exciting though.

August 8th – Mission to the Moon!

August 9, 2014 in Dev Blog

The last couple of days have been really exciting. As our work on progression continues, we’ve been putting some serious focus into our missions; what they will be, and how they’ll tie into the grand scheme. Those of you who follow the daily updates will likely recall the moon mine George showed a mockup of a little while ago. Well, now you know what it was for!

We sat down and mapped out the overarching goal, structure, events, and enemies for the player’s first mission. Unlike the dungeons where I would generally build a single carefully detailed room at a time, we intend the development of this mission to be a highly iterative process, with feedback and ideas from other members of the team.

For now I’ve got the entire layout boxed out with a loose scale reference, but next week I’m going to really go to town shaping it into an actual environment. Detailed decoration will come later after we’ve got something solid we can actually play through.

I’m honestly really excited. Being able to work on a carefully constructed experience from start to finish will be a refreshing change of pace from having to build dungeons that are inherently dynamic in nature, as I am not bound to the limitations that randomly generated layouts bring with them. In the interest of keeping specific elements a mystery, I won’t be sharing any media of it today, but I’m sure you guys can understand.

In any case, that’s it from me. Take care and good night!

spiele