I didn't listen and I regret it. Somehow I missed that javafx got dropped from the official arch repo and compiling it from source nearly killed my computer. Thing has over 4000 C++ objects to compile and my processor tapped out about a quarter of the way through after several hours. Made me apologize to rustc for whining about it's speed. Then I found out there was a prebuilt bin and I got more pissed than a man with a bladder infection trying to have sex. That was before attempting to build and gradle throwing an error for modifying a immutable variable, specifically line 076. I could post an issue with a stack trace if you'd like.
I'd say it still is more buggy as not fully tested and there's mods use problem, but should have all content for Inno's 0.4.9 version - from the user perspective.
From the developer perspective: running java 21 (not the old 8) and is modularized (jpms), can be packaged as installer (no console window) and jlink-ed to not bundle all the jre. i have revorked to use java nio meaning to run fully in jar and not creating `data` folder (my version created it at user home directory, not along executable), but failed, as it being jpackaged cannot access files in jar in module (`jrt:`) I'm workin for now to load mods from archive and data folder (to just drop mods there and they could just work).
I'm planning to rewrite code fully (should reduce by amount), get rid of javafx and webview, and javascript, also both game and mods to rewrite using Kotlin (instead of both JS and XML).
As a result it should be (in the future) a lot(!) faster, smaller, less buggy, extensible (easily extensible) and fully customizable, but having all the features LT has now
(I suspect the dearest Innoxia has some trouble to continue developing not just because of personal issues, but with the whole game inner architecture) So I intervene here
I'd say it still is more buggy as not fully tested and there's mods use problem, but should have all content for Inno's 0.4.9 version - from the user perspective.
From the developer perspective: running java 21 (not the old 8) and is modularized (jpms), can be packaged as installer (no console window) and jlink-ed to not bundle all the jre. i have revorked to use java nio meaning to run fully in jar and not creating `data` folder (my version created it at user home directory, not along executable), but failed, as it being jpackaged cannot access files in jar in module (`jrt:`) I'm workin for now to load mods from archive and data folder (to just drop mods there and they could just work).
In other words, Java finally got features that other platforms like C++ had for years.
I know you said this was buggy but hot damn.
1: Mousing over literally any button returns an null exception error. Seemingly harmless.
2: The context popups stay until another button is moused over or until anywhere else is clicked. This blocks some elements such as the personality options.
3: Using the keyboard did not update the screen until I clicked. Last instance when I tapped the /1/ key repeatedly the next screen my male character "Unknown" was being fingered by Alexandria. The main menu, inventory, phone, and my character profile were all unresponsive. Used escape to return to the main menu and start a new game.
4: The first turn of combat can fail to show the opponent's stats.
5: Got this funky screen when approaching the bank -
I'm guessing that's due to all the non-hardcoded content being removed.
6: Got a similar error when meeting the shady dealer in the alleyway, confirming my suspicions.
And that's all after playing just past the prologue. Still, willing to wait a bit while more pertinent tasks are handled.
So I plan to move to Kotlin but first I should compact all of this spaghetti code.
That's surely not easy when I'm not the original developer, and so i'm many places where the dearest Inno is making presupmtions try{}catch{Syste.err.prinltn} "oh, exception, lets pretend that nothing happened really" I just rethrow an exception so game may be unplayable now but now you can see why and I'll be expecting why. Again, with the original architecture, "if you've fixed that particular bug, please inspect 10 000 more similar places" is killing me.
Again why I'm moving to Kotlin is nullables - then i will have no presume that object anytime will be present - intentionally or not - and correct the game behaviour. Another plus is refactoring - in java i have no trick "we have no such method, but lets add a fake then refactor normally" - so i java i have to run thoroughly run all 1000 places to fix when in Kotlin i just write new fake extension function then make it "inline" refactor everywhere tp get desirable effect.
finally, i have here natural bulk functions instead of handmade java-streams - no 10000 rewrites either.
And the last: data is a code too (take a look on Gradle philosophy) so we don't need (no) JS engines, xml pasrsing and so on - just compile and run codable data.
That's my goal.
, it's my philosophy how the data should look (character generation for now only): the data (even if it is compilable) decides what and when it should be, and a thin client should only nicely present it and give some control over it, that's all.
In other words, all the data should be an DSL data, regarding is it xml, html, css, or business logic. That's a control (java, js or python) or data (xml, html, css or what): one language, one format, no thirdparties (such as embedded languages or browsers)
if possible please find a way to get rid of the whole "js code inside of xml" portion. because that was extremely error prone and had provided no feedback if you mistyped something until you spun up the game and prayed that the error wasnt swallowed.
if possible please find a way to get rid of the whole "js code inside of xml" portion. because that was extremely error prone and had provided no feedback if you mistyped something until you spun up the game and prayed that the error wasnt swallowed.
I will, surely will, when i'm moving from java to kotlin: so there will be no js, no xml, no hardcoded data: anything should be a Kotlin code. The drawback is, that, if you want make a mod, you should PROGRAM it (nothing more scary that writing gradle dsl scripts - it looks like a json, but stiil it's coding) and compile it, and upload as a jar library - but then you could just drop thus jar in a game and it should just recognize it.Aaand - no limitations at all: you can mix json-like dsl and imperial code, such as:
Code:
for (i in (1..100))
if (game.day) {
div {
+"What a nice day!"
}
}
No xml, no js, but all conditional behaviour you need - conditions, loops, html+css which looks like an original one and at zero cost, is it adorable?
edit: and, p.s.: and if you're using JetBrains Idea you will get autocomplete with all properties and functions you can use: and such properties is active, "reactive" - if you change one, all dependent places would properly be updated immediately. So, if you program to change your MC - it's acting now like a new one - no need to call service function and so on. Magnifique!
From everything that's been relayed to me the code is actually fundamentally flawed in how it processes each turn and object in the game. Godspeed to you my friend.
So, as for what's going to be in this next update, the main addition is going to be the completion of the new doll race mechanics. You'll be able to buy dolls from Lovienne's Luxuries, house them in the mansion, and interact with them in a manner similar to slaves. I've also added a new 'command' immobilisation type for dolls, so that you can command them to remain completely immobile during sex.
I'll also have a lot of bugs fixed and some other minor things added (such as a Dalmatian subspecies). I will have this update released by the end of this month at the latest, and I'll make another post to let you know how things are going next Friday.
Thank you all so much for your patience over the past few months. I'll do my best over the next week to flesh out this update and try to get more content added before the release. See you again soon!
Ah yes, adding something to the game that is ALREADY IN THE FUCKING GAME.
Bravo Innoxia. Truly, this update was worth all the time taken for it. Not a single moment of waiting was wasted.
So, as for what's going to be in this next update, the main addition is going to be the completion of the new doll race mechanics. You'll be able to buy dolls from Lovienne's Luxuries, house them in the mansion, and interact with them in a manner similar to slaves. I've also added a new 'command' immobilisation type for dolls, so that you can command them to remain completely immobile during sex.
I'll also have a lot of bugs fixed and some other minor things added (such as a Dalmatian subspecies). I will have this update released by the end of this month at the latest, and I'll make another post to let you know how things are going next Friday.
Thank you all so much for your patience over the past few months. I'll do my best over the next week to flesh out this update and try to get more content added before the release. See you again soon!
LT has ironically reached its "pokemon" state (stagnant, monopoly) without even ever being finished, and we're now waiting for their "palworld" competitors to be born someday
LT has ironically reached its "pokemon" state (stagnant, monopoly) without even ever being finished, and we're now waiting for their "palworld" competitors to be born someday
I think you just need to look a little. There are other text games that focus on fetish diversity and things like that. Two examples... Or even CoC and TiTS.
I think you just need to look a little. There are other text games that focus on fetish diversity and things like that. Two examples... Or even CoC and TiTS.
Ain't that the life. Several games you have been interested in getting finished and all of them end in disappointment. Either development gets abandoned, development suddenly drags out for no reason or the end result is a freaking dumpster fire.
