Progress on the walk cycles moved along quickly.
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3486351898
The bounce on the chest didn't quite align with the perspective of the rest of the body, so that got fixed next. A male torso was also introduced at this stage.
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3486357942
I also spent some time prototyping a flag here for a change in pace. The flag eventually went through several iterations, too. The design is supposed to resemble a mouse footprint, and making it symmetrical kind of gave it an alien, winged appearance which looked unique and interesting so I decided to keep it like that.
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3486359356
8 iterations later, it looked like this:
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3486360212
The design ended up looking a little bit stiffer on the flag than I'd prefer, but deforming it too much to follow the flapping contour of the flag mangles the design and creates a lot of blinking single-frame pixels which look much worse. I may go back and touch it up some more later.

Not bad for day 1.

Over the coming days, I started setting up the actual .species config files for nicemice.
Testing stuff like the sitting and crouching animations was... interesting.
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3486363410

It is worth taking a moment in this thread to very briefly describe some of the items in the .species config files that were confusing to me :
(many of these ended up being problems later)

Setting up the character customization screen for nicemice was a weird and involved process. This community forum post helped a lot:
https://community.playstarbound.com/threads/a-guide-on-implementing-character-customization-for-custom-races.136565/
(thanks INVADA)

I wanted the two-tone color palette for nicemice to match two colors for their entire body. The main fur color was intended to cover the hair, the exterior of the ears, and most of the torso and legs. The secondary fur color was intended to cover accents on the hair, the interior of the ears, and ventral fluff near the navel.

Starbound applies color instructions called "directives" to the player to change the colors of your skin. There are a handful of different combinations that the game uses in order to customize races like Florans, Hylotl, and Apex, but none of them did what I wanted. It turns out all of the races have single-tone hairstyles, except for Florans, which have single-tone skin coloration. None of the vanilla races support two-tone setups for their entire body, and it was curious and frustrating for me to go through all of the Hylotl hairstyles just to realize that all of them relied on the head acting as the second tone for contrast.

The only way to make this two-tone coloration work correctly was to put all of the recoloring instructions in at the same time, which means that instead of having palettes for:

• black
  
• white
  
• yellow

I needed to set up palettes for:

• black + black
  
• black + white
  
• black + yellow
  
• white + black
  
• white + white
  
• white + yellow
  
• yellow + black
  
• yellow + white
  
• yellow + yellow

Every color that the player could choose would increase the number of color options to the next-largest square number. WIth a planned color option set of between 16 and 24 colors, this was not something that was reasonable to do manually, so I opened up Visual Studio and threw together a very quick-and-dirty C# project to read color palettes, combine them together, and spit out a text file with all the color directives formatted for me.

This new program allowed me to just edit an image with the color palettes I wanted, click a button, then copy and paste the result into the species config file.
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3486372363
The source code for this program is included in the .zip file in the mod's workbench folder if anyone is interested.

Some of the config options for species in Starbound are named very unintuitively.

I was expecting sitOffset to change where your character sits relative to an object lounging position, but what it actually affects is the offset applied to your armor while sitting.

Several of the other species config options are similarly stupid to work with. Going through the motions of testing each thing and having to /reload the game's assets prettymuch forced me to uninstall all of my mods except the ones I absolutely needed to test nicemice.

The walking animation looked good so far, but at this stage, nicemice didn't have running animations, jumping animations, falling animations, etc. I had brought their idling poses (mostly) into parity with the vanilla idles, but for the sake of player customization, I added each permutation of idle stand and idle arm together into its own preset.

The first time I encountered a species that did similar things, it was actually the Viera mod. I thought it was weird and stupid! Why do I have to click 500 times to get the ear variation and ear color I want? Why does it have so many idle pose options? These aren't the mod creator's fault. It's just Starbound's UI being primitive and stupid. Clicking through all the different idle pose options felt really weird to me when I first saw them in the Viera character creator, but I understand why they were included now, and I ended up doing the exact same thing with player idle poses to give the player as many options as possible.

Better control over what the character creation spinners do would have been a massive improvement to the character creation UI. There are a small number of flags we can turn on or off to get highly-specific behavior from particular spinners, but it's not flexible enough to scale into weird species mods effectively.

The "hairColor" options ended up going completely unused for nicemice. When you change your eye color, you're actually modifying your underwear color. Everything else is in the "bodyColor" slot because the directives for hair didn't apply to the body the way I needed them to.

While we're on the topic of hair, the nicemice ear styles go in their "hair" slot and their actual hairstyles go in the "facialHair" slot. Why? Because the rendering order for the character forced me to do it that way. Also your head renders BEHIND your body, but your hair renders IN FRONT of your body. Also also, if you wear a helmet, that renders IN FRONT of the body, but BEHIND your arm, regardless of whether or not you're wearing anything on your chest. The render order is extremely weird and I don't think they really put much thought into how the order would make stuff awkward for customization down the road. A better system would have been to assign a z-layer value to every drawable in the species configuration that was easy to edit.

Clothing was next on the list.
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3486388549
The first clothing that nicemice had available was a resprite of the HAZMAT suit. It's one of my favorite cosmetic sets in the game and is unfortunately underrated for a lot of reasons.

Once I had this prototype outfit set up, my next goal was to make templates for generic clothing that I could use to create starter outfits and armor for nicemice. This ended up being the hardest part of the mod so far.

Each time I would make changes to the shading or the position on the sleeves or the arms, those changes would need to be propagated to the male and female body base layers. Working within the constraints of the absolutely tiny character size created a lot of situations where I had to compromise with the option that looked "least bad" instead of an option that looked correct.

Testing each frame for the front and back arms while naked also created situations where the palettes for the skin matching on the body and arm hid overlap problems that became issues when editing the sleeves later.

Making an edit to which pixels were visible on the sleeve required editing it on the arms too to prevent parts of the arm from sticking out behind the sleeves, and because the body shapes of the male and female chests are different, there are different shaded bits on the back arm that are visible at different frames in the walking, running, etc animations that needed to be ironed out too.

I spent SEVERAL AGONIZING DAYS just getting the sleeves to behave correctly. It was painful and awful and I hope I never have to do that again. You're welcome.

I also had to make changes to the way that the chest bounces on the female torso in order to maintain a defined outline shape while wearing armor, because armor isn't animated on the chest. I was expecting to be able to animate a chestpiece the same way you can animate pants or capes, and didn't discover that this was not possible until I had already committed to the body shape for nicemice.

I ended up having to make a ton of adjustments to the shoulders and torso - not only to make it look consistent with the behavior of sleeves, but in order to have armor effectively hide the male and female bodies while also looking like clothing or armor. This process was just as frustrating as configuring the sleeves and took a couple of days, too. Overall, I probably spent just shy of a week editing the arms and chests to make clothing work - and after all that effort, the templates still kinda' looked like crap with most color palettes.

I limited the starter jumpsuit to a single color palette because the randomized colors for the jumpsuit in the character creation interface looked extremely garish. Not being able to choose which colors are available (apart from limiting them in the clothing item itself) felt like a terrible compromise situation to be in, but I decided to use the option that I felt would make the best first impression on a new player seeing a nicemice character pop up for the first time - which means the jumpsuits have one color, for now.

With the torsos and sleeves defeated, making pants was a lot easier. However, I ended up having to adjust the position of the hips over to the left a few pixels to make the positioning consistent for pants, leg armor, jumping, running, walking, and idling. It turns out that these things have to have specific relative offsets to one another to work correctly ingame when all the pieces come together.

Animating tails was mercifully easy though. I am glad that I can properly animate stuff in the back slot. I will be adding more tails soon.

Tiered armor wasn't hard to add once I had clothing templates set up.

Some stuff that I ran into that might be useful for other modders:

If you typo the item name in the species default blueprints, the recipe will show up in the crafting table in admin mode, but not in normal gameplay.

All vanilla armor has the same stats. The only things that change are the "level" of the armor, the "leveling function" (for T5+), and the price/rarity/name of the item. And the recipe I guess, whatever.

When I was working on tails, I wanted them to match the player's skin color. I ended up using this code to do it:
https://community.playstarbound.com/threads/anyway-to-get-a-player-npcs-bodycolor-color-mapping.126403/
(thanks again, INVADA)

This is used to apply a status effect to the player that replaces tail cosmetic colors with their skin colors. I wanted to apply this to npcs, too - but discovered that npcs do not, by default, actually get any bonuses or status effects from their worn armor.

In the base npc type, it looks like all npcs have the flag "disableWornArmor" set to true. I think if you set this to false, their armor will work correctly - but I did not know this existed, so I did something else entirely - I hooked my npc types up for scripts!

Okay cool so it turns out you can just put arbitrary scripts on your npcs and monsters if you hook them up to a behavior.

What you'll need to do this:

• Behavior node
  
• Behavior
  
• A script to hook into

This sounds pretty shrimple, but it's a pain in the ass because if you typo anything it'll crash your game or not work correctly. Here is an example of the nodes that nicemice use:
There are two nodes here. One is a generic hook for npcs in case I need to send them commands, and the other one is specifically for the villagers.

It's worth noting that the npcs folder has an s, but the behavior npc folder does not. This caused some hiccups while I was testing because I wasn't paying attention when looking at folder names for script locations.

These nodes hook into a behavior file:
...and then these scripts are used to apply status effects to nicemice villagers:
It's important that the appropriate scripts are linked in the behavior file, nodes file, and npctype file, or things won't work.

If it's all hooked up correctly you should be able to change the behavior in the .npctype file's scriptConfig field:

The result of all of this is that I was able to apply a scripted status effect to nicemice villager npcs which makes their tail cosmetic match their skin.

Pain in my ass, honestly. I really hate how often the ship pets get in the way of the boxes I'm trying to open, or sit in front of the Captain's Chair, etc, so I removed ship pets from the nicemice SAIL. I wanted to make sure that removing the ship pet wouldn't cause issues, so I loaded into a new ship and gave myself a few copies of the modified SAIL station.

Ok so in vanilla SAIL has an object property called "uniqueId" and if two objects have the same uniqueId on the same planet/world/instance/etc, the game will explode.

While I was testing the ship, I crashed the game trying to place a new SAIL, which led me to research why that was happening. The wiki said it was because SAIL can't spawn 2 ship pets at a time, which was both untrue and unhelpful - because I had removed the ship pet from SAIL like two seconds ago.

It was not intended for the player to ever have more than one SAIL station and it was also not intended for the player to be able to pick it up and move it, but I wanted the T8 nicemice ship to be as flexible as possible for player customization- which includes moving SAIL to a different spot if you want to.

Once I figured out what the real issue was, I took a short break from nicemice to fix all the SAIL stations for vanilla, then submitted a pull request to Starbound Patch Project so that people can have more than one SAIL on their ship. You're welcome.

I would like to eventually add a ship pet spawner item as its own object. SAIL should never have been responsible for spawning ship pets and it's really annoying that Chucklefish decided to keep it that way. Using a dedicated ship pet spawner object will allow ship pets to be swapped and customized, and I plan on making them available as rare loot later on.

Some mods already exist that allow you to customize the ship pet for your ship, but all of them just patch SAIL which is stupid. SAIL should not be spawning pets. We have pet tethers, which do the same thing, but better. I hope that more modders adopt my style of ship pets when they are ready for release.

I've also received a request to make the nicemice SAIL compatible with the SAIL chip customization mod. I would like to make it compatible, but I don't want to make users install 2 mods just to have their SAIL work with their modded race - so I will probably be dissecting the SAIL chip customization mod to integrate some of their features into the nicemice SAIL.

More importantly - I don't want users to brick their ship if they decide to uninstall custom sail chips later. This is the primary reason I'm not just patching it the way Neki did.

There's also the issue of residual vs non-residual items. See below for more details on that.

So, ships use their own format for stuff. You aren't able to just pop them open in Tiled like everything else, which is annoying, and it's also not exactly the same format as the old dungeons, which is also annoying, but it's still reasonable to edit ships if you're willing to be patient about it.

Ships use blockKey files, which is just a big map that turns colored pixels into foreground blocks, background blocks, and objects. As far as I'm aware, surface mods aren't supported in this format, which means pre-painting ships or placing things like grass aren't available.

Most of the blockKey format is very self-explanatory. I feel that it was simple enough to just kinda' pick up and run with, but it was still a lot less intuitive than using Tiled would have been.

Ship layers are set up with the background assets for ships rendering behind everything else. Every ship has a fullbright bg layer and a non-fullbright fg layer, both of which render behind any placed blocks or objects. This means if you place sand in your ship's background, the outermost pixels of the sand will overlap the floor of your ship. If you think that's bad, do the same thing in the sloped areas of your cockpit. Hate it? Me too. You're welcome.

All of the vanilla ships avoid 45-degree ramps (except in the cockpits). I think the main reason for this is that ships were created before sloped blocks were available, and the background blocks overlap sloped areas in aesthetically unpleasing ways. I'll add some sloped ship blocks in a later update to make sure the player has some tools to fill those gaps.

The greebling on the outside of each ship is kinda' impressive when you're dissecting it. It looks like the detailing was done in Tiled, and I wonder if the adoption of Tiled into Starbound's developer workflow was the result of successful field testing to make ship bg assets.

I haven't decided on a final aesthetic for nicemice ships yet. The apex-esque look is a placeholder, but I am leaning toward black and red for the eventual fleet designs.

I'm also not sure if I want to keep the sloped ball tunnel areas on the T6+ ships. There's some charm to having little tunnels to roll around in, but the diagonal ones feel kinda' forced. I might redo those sections of the ship in coming updates, and I've put warning labels on those areas so people hopefully won't build there. If they do end up building in those spots, I tried to warn them - womp womp.

It's easy to take for granted how many ship lights the player's ship actually has. Running around with the entire ship completely dark really hammers home how important those starter lights actually are.

In terms of usable ship size, the nicemice T8 ship is about 20% larger than the Apex T8 ship- but a lot of that extra space is more confined, so I think it evens out.

The design of the nicemice ship doesn't block the player from visiting the cockpit. In the vanilla ships, the door to your Captain's Chair is locked until you repair your ship. There wasn't a good place to put that door in the nicemice ship, so players will just have to deal with sitting in their chair and seeing the big NAVIGATION OFFLINE text that pops up in the star navigation console.

It's interesting to me that the non-fullbright versions of each ship's overlays are 75% opacity. This ensures that the ship is never darker than 25%. I haven't applied this to the nicemice ship assets yet but it's a nice little touch that helps separate the playable space from the unplayable space, lit or unlit.

I had to apply some scripting changes to SAIL to make it behave correctly with the nicemice ships. Items can be set to residual or non-residual, and I wanted to eventually be able to get rid of the SAIL console at T8, which means each time the ship is upgraded, the (non-residual) SAIL console is deleted and replaced with a new one (another issue that I need to correct for proper compatibility with the SAIL chips mod). The scripting in MAUS (the nicemice SAIL replacement) should gracefully handle most situations where you upgrade your ship, but I've noticed that it occasionally skips quest dialog if you rush through a new character in multiplayer. I'll look into proper fixes for that when I can.

Nicemice weren't ever part of the Protectorate, and only entered the Starbound scene after the Protectorate (and the Ruin) had been destroyed.

Changing all of the progression lore for the player to reflect this is a monumentally large task which is probably not going to ever actually happen since I'd basically be redoing the entire game's progression and missions and etc. Maybe someday though. We'll see.

Nicemice society has a caste-like structure based on their concept of "niceness".

Species that are considered "nice" are treated as equals, and species that are considered "not nice" are treated as obstacles and threats, or "domesticated" for use in mundane tasks.

In general, Nicemice interactions with other species fall into four categories:

• Nice - Openly friendly
  
• Neutral
  
• Not Nice - Openly hostile
  
• Not Nice - Kill on sight

Nicemice npcs have unique dialog for a wide array of different modded species in addition to vanilla races. A template is used for friendly, neutral, and hostile interactions. The races that are kill-on-sight will eventually trigger scripted hostile reactions from npcs by default.

Most races fall into the "Openly hostile" category. Nicemice are almost entirely uninterested in the drama or affairs of these species and consider them pests to be eliminated.

Nicemice society has achieved a prosperous equilibrium - often at the expense of several other species in the process - and they usually view other races who do things differently (and therefore have not achieved the same kind of prosperity) as being below themselves.

It is notable that Nicemice are on good terms with the Miniknog, whose strict and domineering social policies are similar to those of Nicemice.

Kill-on-sight races include large dragons and avali, both of which have been deemed "Not Nice" by MAUS Fleet Command.

From an outside or metagame perspective, Nicemice behavior is influenced by a lot of different factors. Some of the decisions for whether or not Nicemice are friendly or hostile came down to whether or not a particular race's mod did a good job including various features like dialog or unique items. Sometimes the lore for a particular race was silly, or maybe their spritework is just ugly.

There are lots of different reasons that Nicemice might be friendly or hostile to a particular race - but if you approach them and they pull guns on you, rest assured - it's your fault for not being nice

I wanted to make Spiral Knights Gremlin goggles, so this happened.
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3487620424
Futara's fullbright shader has become pretty ubiquitous in the Starbound modding scene, but Starbound requires you to unpack the mod for it to work properly because it doesn't /reload shaders.

I wanted to give the user fullbright clothing options without requiring them to install other mods. I spent a day trying to accomplish this, and the results are lackluster. I don't think I'm going to keep these experiments in the mod, but I wanted to document the attempt in case someone else wants to take a jab at it later.

So, quick rundown - let's talk about how the fullbright shader works, first.
Futara's fullbright shader is simple. It's only 1 or 2 lines of edited code on top of the default fragment shader, and it basically just checks to see if the alpha value on a pixel is 254. If the alpha value is correct, it changes the resulting "a" value in the shader to be maxed out instead of whatever would have normally been sampled using the lightmap and etc.

The fullbright pixel shader is a good solution. It's simple, it works well, and it bypasses a lot of stupid technical problems that Starbound has by just editing the render pipeline directly.

---

I still wanted to try to make my own thing, though.

In Starbound's source code, drawables added to a humanoid normally only have fullbright applied if the species has the fullbright flag set in its config - this prettymuch means that the only normal way to get a fullbright drawable onto a humanoid body at all is by being a novakid, and even then - it wouldn't be in the armor slots.

This meant that I'd need to render something on top of the player or on top of an npc in order to get fullbright to work the way I wanted. My options for this are particles, projectiles, or drawables through the lua hooks provided by localAnimator.

I tried particles first and quickly decided those weren't the right option. They'e weird to work with and don't behave how I want them to behave for this kind of thing.

Projectiles offered an interesting set of possibilities because they can be anchored to a source entity. This theoretically meant that I could overlay whatever graphics I want, anchored on top of a player or NPC, and those can be fullbright. Projectiles expect to be fired from something to determine their direction though, and what started as simply placing a few lit pixels on top of the player's head turned into a frustrating exercise in dissecting the game's boomerang code and messing with the different options for ignoring terrain, setting up collision polygons, making sure the projectile didn't harm the player or nearby npcs by simply existing, and replacing the projectile as it was getting ready to time out. After a few hours of not really getting any results that looked good, I gave up on projectiles and moved on to trying out drawables.

Using the localAnimator lua hooks to create drawables isn't great. You can't pick and choose which ones you want to keep or discard, so if you want to get rid of one local drawable, you have to dump all of them and then reinstantiate the ones you still care about in whatever states they need to be in. This isn't too awful, but it's definitely very different from the previous approach with projectiles where you can keep track of your individual projectiles and just cull them as neeeded.

Getting a fullbright drawable hovering over the player was pretty simple with localAnimator, but making it actually behave nicely was a much more involved task. Starbound doesn't have any way to reliably determine which frame the player (or an npc) is currently displaying during things like a walk animation or run animation - which means the only way to figure that out is to keep track of how long they've been moving and guess which frame they should probably be playing based on how long it takes to complete a single walk cycle.

And yes, I am aware of how ridiculous that is

The good news is that for the player, this works great. I was actually able to synchronize the player's walking, running, jumping, falling, crouching, and swimming with a fullbright drawable overlay rendered on top of the player. It was usually within 1 pixel of where it needed to be (although there is a little bit of wobbling because of the camera which I partially corrected for) regardless of the zoom level.

Here's a screenshot of this process working correctly for the player. The drawable is rendered in front of the water because at the time I was testing with the "overlay" layer, which is at the top.
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3487623986
NPCs, however, were not as cooperative. Take a deep breath and grab some water (or as in my case above, take a deep breath full of water and embrace it), because this is where things get silly.

The different lua namespaces in Starbound can only be accessed from certain types of scripts. For example, the npc namespace is only available to scripts running directly on an npc. Their status effects don't count - it has to be running on the base npc.

The localAnimator scripts are only available clientside to the player. I wasn't able to attach localAnimator drawables to npcs, which meant that all of the drawables being used to render fullbright parts were parented to the player. Not ideal, but still reasonable to work around.

In order to grab movement controller data for the player, I could simply hook a status effect and push the relevant data to the player's status effects storage, but for npcs, I can't access their status storage from a player script. This meant that I'd need to store their motion controller data, then find a way to send it to the player for processing.

A brief dive into setting up message handlers later, I started working on a system to make these motion controller updates robust and reliable. The result of my tinkering was a subscription service where the player would send an entityMessage to npcs that were nearby asking to subscribe to updates from their motioncontroller, and whenever the npc moved, jumped, etc - those updates would be sent to the player so that the rendering for the fullbright components in an npc's outfit could be updated appropriately.

At this point I was starting to hit snag after snag after snag.

There isn't a way to determine whether or not an npc is dancing. Dances are used for a lot of the interactive things NPCs do, whether it's crouching in front of gravestones to cry or flailing their arms around near Hylotl radios to jam out. Dances offset the character from its normal idle position and the fullbright components have no way to detect that it's happening, so they just hang in the air, desynchronized from their npc, looking very stupid.

Additionally, npcs handle their walking, running, and other animations very slightly differently from the player. It seems like their frame index is never actually reset to 0 when they stop walking or running, which means that when they start moving again, their walk cycle can't be relied upon to actually start at the first frame? At least, that's what I observed. Not an issue for the player, but it makes npcs look dorky as hell when they start moving around.

NPCs also do this really weird tiny little hop thing when they interact with each other and it uses their idle animation even though the motion controller reports them as jumping, which also causes unsightly desyncs between the state of the npc and the state of the fullbright overlay when it detects a jump and adjusts itself. Detection for whether or not a player or npc is sitting on an object is also weird and janky and requires (separate) subscription services. Very annoying.

Although I can place drawables on a particular layer, such as "Npc" or "Player", I don't have control over where in that layer they end up rendering. Placing localAnimator drawables on the "Npc" layer ended up rendering all the fullbright stuff behind the npcs in question, so using "Npc+1" solved that issue, but now all the fullbright stuff for any npc was rendering above all npcs, which meant that two npcs standing close to each other would bleed over each others' fullbright overlays and look really bad.

Handling fullbright stuff on the sleeves was also an issue - mostly because of the dancing thing. Getting the rotation of the arms isn't too hard and in theory I could apply that same rotation to a drawable rendered on top of the humanoid, but I didn't get that far. I am sure that trying to apply fullbright using this method to the backArm layer would have also been trouble.

---

So, a recap of using localAnimator drawables to try to add fullbright decals:

• Putting fullbright stuff on the player's helmet slot is possible and reasonable
  
• Adding stuff to the chest, legs, or back is weird because of layering with the arms
  
• Adding fullbright stuff to npcs is possible but keeping it in sync is not reasonable
  
• Adding fullbright stuff to npcs requires hooking into their motion controllers
  
• Adding fullbright stuff to npcs requires adding scripts to query their equipment
  
• Rendering fullbright stuff on top of npcs will render on top of ALL npcs which is weird

In theory, you could use localAnimator stuff to add things to the player, and you can definitely fake animations for things like the chest armor in certain situations where your arms aren't in the way.

Using it for npcs is janky and the results are low-quality for npc applications. It would be faster, easier, and more reliable to just make a monster with fullbright parts that looks like an npc and acts like an npc.

( I might try that for the planned Gremlin-themed npcs instead. )

Overall, I'm not happy with how this experimentation turned out. It feels like I have access to about 75% of the tools I need, and the ones that are missing are important.

For now, I guess I will just add fullbright to things using the FD shader, but I would prefer to not do that. Asking the user to unpack a mod to make it work isn't a good experience for the user, and making my mods rely on other mods which do that is not good practice.

Right now we can combine the FD shader with directives and specify FE as the alpha value which works well, but it's not the same as just being able to properly apply a fullbright layer to clothing the same way we can with activeItems and etc. The 25% opacity fullbright applied to ship overlays, for example, isn't something that's simple to do with the FD shader hack.

Maybe some of this stuff will be fixed in Starbound 1.5.

The mouthOffset parameter in the species config file moves your speech bubble around when you send messages. It doesn't affect the script that checks for whether or not your mouth is in a breathable area.

Instead, mouthPosition in the status controller is the variable that dictates whether or not you can breathe.

By default, mouthPosition is set to +0.75, and this value is relative to the movement controller's position. Nicemice have this value adjusted to -0.17, which allows them to breathe in short tunnels again.

It's weird to me that breath is stored as a resource in the status controller. I guess you could make big bubbles that let players breathe with the way it's set up. I wonder if anyone has ever done that?

It might be the only clock in all of Starbound that has ever actually worked.
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3488472998
I am considering making a mini-mod that patches the 11 clock objects in vanilla to also make those work. We'll see what happens with that in the coming days, I suppose.

Mimiga-themed items are definitely coming soon. I feel that the main things missing between where Nicemice are currently at and being able to reasonably cosplay as a Mimiga are a proper Mimiga tail, some purpose-built ears and/or hairstyles (maybe add Sue's facial scar via hairstyle as a customization option), and a recolorable sweater.

Spiral Knights' Gremlins are also fun to daydream about. A customized healing staff with the appearance of a Mender's wand could be fun to add. I think for Gremlin support I'd also want to add a few skintones to the player's customization options- and Gremlins would need their own ears to support colored tips and similar cosmetic details.

I feel like I could probably also squeeze a Nanachi outfit into the todo list, too. Narehate are extremely varied in their shapes, sizes, and appearances- there's no way Starbound would ever be able to adequately encompass all of the weird and interesting designs of the Hollows, but it's probably reasonable to staple Nanachi's tail into the back slot and sprite up a helmet and some pants. We'll see what happens

Lots of people have requested goblin options. I don't blame them, nicemice are good base for that. I'd like to add some goblin stuff. Low prio, but it's on the todo list.

A Midna-themed skinsuit could be cool, too, but making the glowy bits fullbright would require edits to the way the species works which would cause problems for most players. It is definitely possible to make an npc version of Midna which has the appropriate glowing parts - but allowing the player to do the same thing is harder and probably not worth the effort.

Palico-themed stuff came up in conversation, too. I like Monster Hunter's aesthetic, so I might try to sneak some monhun outfits in at some point. The todo list continues to grow rapidly!

For now, version 0.2 is out and ready for testing. I'm going to bed. Goodnight nerds.

So, Nicemice has been on the Workshop for a week now.
957 current subscribers is a pretty cool number. 1152 unique subscribers is also a cool number.
I'm gonna' split the difference and assume we hit over 1000 subs in the first week, and some of those people downloaded the mod, unpacked it, then unsubbed from the Steam Workshop.

Lots of good feedback has been gathered so far. Lots of good suggestions have been posted, too!

It is notable that the majority of the feedback I've received so far has been positive. I am glad that the trend isn't people reporting game-breaking bugs or really obvious stupid stuff that I may have missed on accident.

As the length of this discussion thread grows, I'm not sure if this is really the right place to keep doing dev blog posts. It sorts new posts to the bottom instead of the top, which isn't helpful for this format.

The Nicemice Discord server has gained several new faces, and I'm happy to see the community slowly growing! It'll be interesting to see how that develops over the coming weeks as more features get fleshed out.

I want to work on a UI panel that pops up whenever I update the mod, to show the most recent update info. Arcana has something like this but I've only ever seen it pop up when making a new character - I'm not sure if that's simply because my characters have never persisted through an Arcana update or if it just only shows up on new toons, but it's a cool feature nonetheless and I want something like that, too.

This week also saw the release of my working clocks mod, which has gotten a bunch of positive feedback already, too.

Project Irisil has also reached a milestone with the Shizubelle villages being prettymuch ready to release. I need to fix one or two small bugs with the biome tracker before I push Irisil 1.5.12, and I'd also like to finish up the "You don't have any races installed" version of the dynamic villages, so players who don't have Shizubelles installed can still find ruins or other abandoned structures (instead of holes where the Shizubelle stuff is supposed to be).

In other news, I also helped with some stuff for upcoming updates to the Neki mod and submitted another patch to SPP to fix Pinfriend's HP bar being visible at the Outpost.

Also, Gremlin head option.
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3489866154
Sorry everyone, these are gonna' require their own body to not look awful. Their bellies need fur accents which the Nicemice base body doesn't have.

I'll make "Nicemice - Gremlin Variant" a playable species option when the Gremlin stuff is ready.

https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3490512243
After having a chance to play around with the ship for awhile and get feedback from other people, I've started making some changes to the internal layout of the ship.

Changes are coming for T6, T7, and T8 ships.
If you already have your ship upgraded to T6 or higher, don't get too attached to it. The layout is going to change!

The good news is that new layout is pretty cool.

So it turns out you can, in fact, set up a ship to work with Tiled, but there is a lot of technical overhead.

I'm good at technical overhead though. Let's dive in

You'll still need some initial blockKey setup and ship block images. However, once you set these up correctly, you can just use Tiled for everything else.
This blockKey entry instantiates a scripted dungeon spawner object. The world.placeDungeon command is very useful to us here - the backbone of how this setup works is allowing our scripted object to spawn a dungeon inside our ship once we load in, which will fill in any details that are not the bare-minimum required in our ship block image files to make the ship work.

What I used as a starting point for "bare minimum" was a physics boundary for the player to stand on, and open air for the ship's interior.

You can get away with a very simple setup for this. The nicemice setup is very carefully pieced together with a lot of very precise moving parts, but all you really need for your scripted spawner is an object with a script that calls world.placeDungeon then deletes itself.

It is very important that the dungeon you place with the dungeon spawner does not delete the dungeon spawner in the process. This will make your game crash. Your dungeon spawner must wait until after its dungeon finishes spawning to delete itself.

Players love bricking their ships. When this happens, the game will try to rebuild your ship, but the way it handles blocks in ship block files is different from the way it handles objects.

If you delete your shipworld file for a character with a T8 ship, then start the game as that character, the game will start with your T0 ship and then tier it up (very quickly) to T8.

For most species this just means you have a few extra layers of hazard blocks to dig through. However, the way it handles placing objects is a little different, and what will usually happen is that you will only have your T8 ship objects, even though you have your T0-T8 hazard blocks.

The dungeon spawners for nicemice ships have several extra failsafes built in that detect these kinds of abrupt changes in world configuration, and will iteratively rebuild the interior and exterior of your ship in order through each tier up to the current ship tier. This mostly involves daisy-chaining spawners and placeDungeon commands, but a handful of object scans and message callbacks are used to segment the process into chunks to guarantee it runs in the correct order every time.

https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3492321191&fileuploadsuccess=1
Here's a screenshot of what my Tiled setup looks like.

I decided to use a 1x1 dungeon and place all of my tiles using matmods. This is not necessary to do, but it allowed me to quickly and easily position my dungeon spawning anchor in a place that would always be reliably loaded by the player, and created a consistent workflow for all of the ship tiers.

If you're not familiar with placing matmods in Tiled, I'd definitely recommend becoming familiar with them, because they can be placed out of bounds which is extremely useful for this kind of engineering.

Having had some time to reflect on the various technical details of the Nicemice ship improvements, I have a few suggestions for anyone intrepid enough to try similar methods.

The main pain-in-the-ass obstacle with using spawner objects is their placement and constant micromanagement with each tier of the ship. This could be solved by simply injecting a script into the Captain's Chair which spawns stagehands to handle dungeon placement instead of objects.

The player's load distance is pretty small, vertically. Spawning space chunks outside the Nicemice T8 ship struggles when moving directly up due to the topleft placement of the stagehand relative to each new 40x40 space chunk. I suppose you could solve this by just blasting world.loadRegion over and over, but that seems like a bad solution to this particular problem. Perhaps distributing more granular chunks could have been a better approach? The player can't /placedungeon from scripts running on themselves, so stagehands seem to be the only tool available to solve this particular issue.

Using world properties as a storage space for certain ship flags has its upsides and downsides. An upside is that multiple spawners can sync with each other by reading from and writing to the world's properties. The downsides include a lot of code fragmentation across multiple concurrently-running scripts, and a severe lack of easy access to this data for players to reasonably view, edit, or remove it. Without knowing the name of the world property and having enough experience with admin commands, the player is unable to make changes to these things - which is a bad thing for modders in general.

So, to summarize:

• Spawner objects could be replaced with stagehands to improve the setup
  
• Player space exploration on their ship can still be improved
  
• World properties are useful for syncing object scripts, but bad for player editing

I will probably eventually improve these things for Nicemice, but as it currently stands, the ship is working, and it already supports way more features than any other ship I've ever seen, because of its unique setup.

Now that the tech has been pioneered, though, I hope that eventually others can continue to iterate and improve upon it. I think that several parts of this process could be compressed, optimized, or removed for a more streamlined and more effective setup. In theory a single stagehand spawned by the Captain's Chair could be a huge improvement - and a simple tool to reset relevant world properties for a "clean ship install" could be good, too.

I'd also like to make the Nicemice T8 space exploration reset when you visit different planets. This should, in theory, give the player new things to explore within their own shipworld each time they enter orbit around a new planet - like a very casual-difficulty space anomaly.

Upsides: cool new thing
Downsides: players might want to build stuff in the zero-G space outside the ship?

I guess I'll need to make some tool to turn that on-or-off.

I would also like to add support for adding your own gravity/no-gravity zones. I know other mods have created tools for this and I'd like to take a stab at that at some point, too.

Interesting updates are coming, for sure

Starbound has trees.
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3493745053
That's great and everything, but we don't really have very good tools to do dynamic or interesting things with trees. I wanted to make a monster that climbs trees, and it turned into a small engineering experiment.

The first step was "can we even detect trees?" and the answer to that query was "yes, but-"

You can detect trees with world.entityQuery. This can also be used to detect falling trees, and the categories for each entity are plant and plantDrop respectively.

My first iteration on tree detection relied on entityQuery. It fired multiple queries with small radii to shotgun-scan trees in an attempt to determine their size. This method worked very well for determining the size and shape of a tree, but it struggled to determine the trunk width for asymmetrical trees. I think I could have eventually gotten that working, but hitting this particular roadblock gave me a reason to try other methods out.

Most of the scripted functions we have explicitly target objects, npcs, monsters, etc - and there isn't a set of functions targeted for trees. Fortunately, a very small number of functions can target trees (perhaps on accident?) and they are both useful for what I was trying to do:

• world.objectSpaces
  
• world.entityDescription

Using world.objectSpaces on a tree's entityId will return all of the block tiles it occupies, relative to its anchor point, like any object would. The reason I even tried this was because you can see trees when you use the /boxes command. Digging through SB's source code for debugging world tile collisions, I saw that it was one generic handler for turning those boxes on or off which were displayed by both objects and trees, so I tried it and sure enough, it worked. Cool.

Using world.entityDescription on a tree's entityId will return a description in the format of "trunk with foliage", except when it doesn't. Not all of the trees in the game (such as magictree and darkrock and kelp) have foliage, so there are a handful of one-offs, but you can generally detect the type of tree from its description matching the x with y template.

Vines hanging from the ceilings of caves have the same inconsistencies in their descriptions.

Ok, so we can scan for a tree, we can measure how tall and how wide it is, and we can get a description of the trunk type and foliage type. Now what?

Trees are made of 3 parts- a base, a middle, and a crown. The base attaches to the ground, the middle is made up of a set number of configurable segments for each type of tree, and the crown has the tree's primary foliage attached to it.

As long as the name of the tree's asset files matches the name of the lowest directory in its folder structure (or we otherwise know the name of the .modularstem and .modularfoliage files) then we can use root.assetJson to read the contents of the config for any type of tree that we scan to get the xy offset values for each section of the tree.

We can't directly retrieve a list of the parts that any particular tree is using, so what I did instead was averaged all the offsets for the various components of a scanned tree to form a best-guess for what the tree will probably do as it grows upward from the base toward its crown.

Since I don't have a way to tell how many segments a tree has for absolute-sure, I'm currently relying on the number of object spaces that the tree is tall to infer how many segments it actually has in its middle. It's not a perfect system because the tree trunk segments aren't necessarily multiples of 8 pixels tall or wide, so the tile spaces they occupy are only a rough estimate of the size of the tree, rather than a definitive answer.

I wanted my climbing enemy to generally be centered on the trunk of the tree it is attached to while it is climbing. With the knowledge of approximately how many tree segments there are, how tall (on average) a segment is, and how they offset against each other as the tree grows, we can start guesstimating a reasonable climbable area:
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3493744689
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3493744860
My tree climbing enemy prototype is currently a bright yellow rectangle, but it does work. I have a lot of cool ideas for how I want to use this code, and I am sure that both Nicemice and Irisil mods will benefit from it.
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3493746682&fileuploadsuccess=1
I have some stuff I need to take care of before and during the weekend, though, so my breakneck pace with Starbound stuff will need to come to a brief halt for a few days while I get that all figured out.

In the meantime, daydreaming about tree enemies is fun.