Mr. Fixit

Hey Folks! Busy day today, as I shored-up the spark vfx and integrated it with repair actions in-game.

Early in the day, I finished tweaking the spark vfx to use the correct lens flare sprite, increased spark speed, and disabled collisions. The collisions were causing problems any time the AI was too close or turned in such a way that the vfx intersected a nearby object. And for how subtle the bouncing particles was, it wasn't worth fixing.

Once that was done, it was time to add it to the game.

I updated the crew class to have a more reusable AddLight function, which is used for both the headlamp and sparks. Similarly, adding and removing conditions to the crew can enable and disable the sparks. I briefly considered making vfx a part of the item light class, so any object could have vfx added through data. But I decided to put that off until I needed it, since I wasn't sure what params to expose yet.

Finally, I added some bespoke flickering code to the crew, so that when the sparks are alive, the lens flare and shadow-casting light flicker intensity over time. Between that flare sprite and illumination flickering, and the red-hot sparks falling away, it looks pretty good!

I created a special tool animation, as well, since the normal use looks a bit weird with the sparks active. This one, seen in today's screenshot, looks more like the crew is hunched over the sparks, cupping it in their hands. This'll likely be used for any mechanical work activity, including things like drilling. It's not 100% realistic, but it conveys the message really well. (Rimworld does similar with a ratchet and drill anim and sparks flying for every mechanical task.)

There were a few polish issues with getting the sparks and animation to time correctly in this activity. Plus, I had to tweak the LookAt code to also work when the AI is waiting. There was an edge case where the AI would be close enough to start work immediately, but was facing the wrong way, and never got the LookAt triggered.

Finally, I needed a special non-teleporting "Done" action for cases like this. Unlike the nav station and toilet, which have separate sitting and use points, repairs just have the use point. And if the AI gets close enough to the use point to begin, and teleports to the use point when done, it can cause some weird jumping appearances. Instead, this non-teleport "Done" action just leaves them in place, and restores their normal idle animation and such.

Overall, pretty successful week so far! I can now record footage of AI sitting in a nav station for one teaser shot, and footage of one (or more) AIs repairing stuff for the other shots that need it.

Next steps are a bit less certain. Most of the pieces I'll need are already there to do them, but might require some things to be moved around in the AI. Or in some cases, a slightly more polished appearance. The one exception I can think of is some sort of reactor power-up control panel for the start-up sequence. Might make sense to start on that next, and refine the other bits as the needs become clearer.

Tags: Ostranauts