Before the changelog, a note from Gedan:
If you’re wondering why there seem to be so many issues lurking around every corner, here is a little insight into what has been happening:
Actionscript3 (The language the game was originally built in) and Javascript are very similar – so similar in fact, that the code almost works entirely with some simple find & replace action to remove Type data. The problem is the bits that don’t work look almost like completely normal Javascript work, so it can be difficult to pick them out without executing them and making them blow up. A couple of months ago I dug into building out an actual automated testing system, and I have a couple of tests written and working but they cover virtually none of the game considering its size – and with so much core functionality to still get working right, it’s difficult to justify spending the time on extending these tests to do much of anything right now. I have a couple ideas that maybe I can pull off over the course of a day or two, but they’d be coming after core systems are done no matter.
What doesn’t work though is “Cyclic Dependencies”, essentially when two different files in our codebase reference each other either directly, or through a chain of other files. In AS3 this didn’t matter, and over time, a lot of functionality was built around the fact that it didn’t matter – we have a lot of system manager classes that manage unique descendent processors, but those descedent processors sometimes need to reach back up to the system manager to execute defaults or shared functions. Whilst this would just work under AS3, now we need to fix it, either through dependency injection or removing the cyclic calls, or crushing all of the cyclic calls into the same file.
Fixing cyclic dependencies lead me down the garden path and resulted in me completely reorganizing all of the game content files. Doing this has allowed me to slice up the games content into blocks, called modules, that can be compiled and loaded independently from each other – the idea here is if we don’t make changes to the Tarkus module during an update, then the Tarkus module doesn’t need to be changed at all, then if you browser has a cached version of that module from the last time you played then it’ll be pulled from there…. There are caveats to the caching, but that’s a conversation for another day! What’s important is the fact that we have modules, not all the modules will be available, and we spent a long time implementing things assuming it just ended up as one fat bundle of code. With modules I’ve been able to turn off the ones that aren’t stable enough yet for play, which in turn hides those planets from the Fly menu – but there may be support functions of various types that are in those modules that needs to be moved around. A lot of them have been caught and shifted, but not all of them.
Javascript has moved on a lot from the days when AS3 was first conceived and it’s added some nice features along the way, things we couldn’t code – or would be extremely annoying to code – under AS3. As an example, the way we handled buttons under AS3 looked a lot like this:
addButton(index, "Button Name", functionToExecute, argumentsWeMightWant, "Tooltip Title", "The bulk body of the tooltip we want displayed.");Now, most functions didn’t need an argument passed to them, but if we wanted to specify a tooltip on a button like this, we’d have to remember to stuff a none-value in that position. And if we wanted more arguments, we had to stuff things into an array and pass that, which made remembering where things were in the array an annoying task on the recieving end. The solution would have been to use “closures”, but the syntax for doing it in AS3 was unwieldy at best. The same could be said about Javascript, at least, until the Fat Arrow was added:
addButton(index, "Button Name", () => functionToExecute(arguments, we, want), "Tooltip Title", "The bulk body of the tooltip we want displayed.");A subtle change, but this was a decision I made early. I think in the long run that it’s going to be beneficial to building future content but it means changing EVERY existing addButton call across the entire game, and sometimes the functions on the recieving end to change them from expecting an array stuffed full of arguments to seperate parameters.
The way our map data was structured has bugged me for a long, long time. It was already set in stone pretty much by the time I came on board and I didn’t want to rock the boat without a good reason. The good reasons have been found over time, and whilst the task was going to be monumental to fix the structure that we had used for a couple thousand rooms so far… I bit the bullet and went for it; so much of the games code is already having to be retouched anyway, that throwing the map structure on the pile is just a bit more work again. This has afforded us the ability to performantly display much larger areas of the map – in the past, our little limited 7×5 view was purely constrained by the processing time of updating the display, but now things are fast enough that we could render the whole planet map and use it as an interface to move around if we so desired. I did a little test to satisfy my own curiosity this week and, well…
Made it through all that? Good. This is Fen, and this is the changelog my exhausted brain barfed out.
TiTS-JS Changelog (#1131):
- Several fixes were applied to how child/birth data is stored. As a result, children stored at the nursery previously had to be reset.
- The javascript version now has the ability to override what gender the game uses for you, just like the flash one.
- Work on a “click-to-move” system for the map has been started by Geddy. It’s not available in these releases yet, but a lot of under the hood work was done toward that possible goal.
- Aliss’s sex menu is no longer automatically unlocked. The tooltip for the disabled button now shows a useful hint for how to unlock it. Aliss’s lust gain when trying on outfits will also be displayed (as well as her current lust). Additionally, after unlocking sex with Aliss, she no longer has a minimum lust requirement.
- Corrected the formatting on ~80 of Siegwulfe’s button prompts that could potentially cause crashes, though I am aware more bugs remain…
- Fixed a crash with lapinara pregnancy.
- Various small UI fixes for inventory systems.
- Fixed a crash in Bianca’s fingering the PC scene.
- Fixed a crash in the combat menu with the sense menu.
- Fixed possible goo armor crash.
- Fixed possible Ardia crash.
- Lots of updates and fixes for Amber.
- Lots of updates and fixes for Mitzi.
- Corrected “hasCockSock” having its arguments set up in the wrong order.
- Milk thief crash fixes.
- Zaika hydra crash fix.
- Gastigoth crash fix.
- Two Syri crash fixes.
- Cleaned up bonus menus in Myrellion so they don’t crash when we release it.
- Fixed a crash with Erika.
- A ton of buttons that use the various bodypart routing utility functions have been updated & fixed (58 changed files)
- Starchild crash fix.
- [pc.goin] -> [pc.groin]
- Several fixes for the dong designer.
- Fixed a duplication issue with strange eggs.
- Fixes for the maxOutLust utility function.
- Getting throbb from crew Penny should now unlock the Codex entry for it.
- Fixed many calls to “loadInCunt” having their arguments in the wrong order.
- Fixed an Anno crash.
- Fixed some inventory-related bugs.
- A bunch more fixes.
- Even more fixes for unreleased content (Uveto, Myrellion, etc).
As always, if you like the game and like what we’re doing, you can always support us on Patreon or SubscribeStar! And if not, well, the free builds will still be here (eventually)!
Loading ...