So! It builds! What now? (Patreon)

I’m posting at 1 AM but this is going to count as my friday post this week, fuck you I’m excited!

I’m still going to wait until I have at the very least the minimum functionality I want before posting anything for people to try.

So, what has been done with the source in the time me and Zy have been fiddling with it, a whole number of things.

Firstly TF is real now

A little history first so people can understand how important that is, if any of you ever heard me ramble about why vore NPCs caused lag or why animations were funky when TFed or in vore mode, it’s because, none of that was real as far as the game was concerned! We achieved it using a workaround, using a status effect to override the player’s animations, I actually got the idea from futaradragon, which is also why they don’t play well together, two different status effects trying to override the animation, regardless! The status effect was meant to imitate how the player normally animates as closely as possible but also add in the additional vore animations, we had to reverse engineer the logic of how the player chooses what animation to play, and we had to have it sending entity messages back and forth from the status effect, the player, and their weapons to get the data so it would know how to animate, because yes! It didn’t just have to imitate the player’s anims, it also had to imitate their weapon’s anims! This meant, if we hadn’t understood everything perfectly, things would look odd, and often they did. And the scripting language allowed in starbound mods, lua, runs relatively slow, and even at that, the game limits how many instructions a lua script can do per cycle before it stops that script! So that workaround was, kinda doomed to have bad performance from the start, but it was, as far as I know, the *only* way to do what we were doing without modifying the game engine, there was a little bit more to it than just the animation, we used some trickery to scripts to effectively trick other scripts into reading the species we wanted it to read, hence why it seemed like FU race abilities worked and such, but, internal to the game, as far as it was concerned, the species never changed, for example, calling player.species() in a context we used our trickery would return the TF species, but calling world.entitySpecies(player.id()) would always return the original internal species value, also I’ve been saying player this whole time but that also applies to NPCs too

But now TF is real, the potion or dart gun now calls a new lua table we’ve added to players and NPCs, which then of course triggers engine side code that will properly actually for real, TF the player into another species, getting that species’ new sprites and colors and properties and all!

We also went ahead and fixed some potential bugs that could have cropped up from TF being real

Your ship will now, always be the same ship, doesn’t matter what species you become, or if you were to transfer your ship to another player file, it will stay as the same ship when upgrading, we’ve also went and made it so your AI matches your ship, not your species, so if you happen to be say, an Avali with a Novakid ship, you’d get Novakid AI on your radio messages

Zygan also made Starbound account for high dpi displays, mostly because when we initially got it to build it was having a rendering bug that made it only render to a quarter of the window it opened, and we had two options, figure out some compiler flag, or go into thr code and make it support high dpi, Zy chose to make it support it, turns out it wasn’t that hard

Also, have you ever heard of the starbound server issue where it requests the full player customization data every frame? yeah, we fixed that, the reason it did that is, when customization data for the player updates, it sets a bool to true, then later checks this bool, if it’s true it sends the data to the server and then sets the bool to false, seems good right? When it recieves the data it sets the bool back to true again, therefore making an infinite loop. The point of thst bool is so it only sends the data when it changes and they just fucked it up, that ONE line setting it back to true on receipt causes endless amounts of lag for everyone.

So now it just doesn’t do that :) it only sends the data when it changes now, as it should.

ANOTHER STUPID THING THE GAME DID THAT INFURIATED ME

perfectly generic items

They are so fucking stupid they had everything they needed to do right fucking there and they just didn’t. Turning modded items that you don’t have the mod installed for into a dummy item? Smart! Not retaining the data in any way? Idiotic. So! Perfectly generic items retain their data now, as long as you don’t place em down, if you unistall and then re-install a mod, the items will turn back into what they were supposed to be :)

Also when using the spawnitem command if you fudge an item ID it won’t create a generic item anymore, you’re welcome.

Also I added a function to the root table to check if an asset exists, because, all over the place I’d check if a file existed using a pcall in lua but it would still report that missing file as an error, that was dumb, now lua can check that without errors

I also added functions to lua to get a species’s file as well, dunno why there wasn’t one originally

Anyway anyway, that status effect I mentioned back at the beginning? the current goal is to do everything it ever did but better, we haven’t quite replaced everything it did yet, I’m working at making the humanoid entities (players and NPCs) use the same networked animator everything else in the game uses, the nice thing about that, is it’s configurable! it’ll let different species support different ways of animating their bodies and it probably won’t fuck up perfomance since the code controlling it will be in the engine rather than lua scripts

Anway, that is the goal for the first wip I distribute using the engine, no more status effect