Java Lilith's Throne [v0.4.10.7 Hotfix] [Innoxia]

[Cadenboy8]

Hmm seems as though that the save menu button seems to be broken as in when i click it doesn't take me the save menu. Quick save and Quick load work tho.

 

[anon707]

Well... she did warn in the previous post that it could take longer than expected. And did so again in this one. The difference now is that she makes it clear there may be a delay, whereas before it was a whole bunch of guaranteed empty promises.

if inno wants to set these dates as "goal" purely for her own self motivation, she can at least keep it to herself instead of giving everyone else an expectation.

 

[Sarkath]

The general idea I going for in my suggestion was something like:

    if(this.isPlayer() || (this.getCell() == Main.game.getPlayer().getCell() )
    {
        for(AppliedStatusEffect appliedSe : new ArrayList<>(statusEffects))
        {
            [code]
        }
    }

Gotcha! The approach I took was a bit different, but accomplished a similar goal:

for(NPC npc : Main.game.getCharactersPresent()) {
    npc.statusUpdateOnDemand();
}

I put this in endTurn(), in Game.java.

With my branch I introduced status priorities: ALWAYS and ONDEMAND, with priorities of ALWAYS updating regardless of the player's position in the world and ONDEMAND only updating when players share a tile with that NPC (or the lastUpdated field gets close to overflowing). The priority defaults to ONDEMAND, but can be freely overridden both in hardcoded and XML status effects.

One of the main drawbacks is that it's still looping through all of the statuses every. single. turn. but with the main difference being that it doesn't act on the ONDEMAND ones.

There's always going to inevitably be some sort of issue. Like, I just realized that using a scheduler won't necessarily work in all cases, since it's possible that some global (or ALWAYS priority) statuses are going to need to update every turn. Pregnancy doesn't, but that doesn't mean that something won't come along later that does.

Here's kind of what I currently have in mind: a status priority system, a scheduler, and your zone-based system to limit the loaded NPC count. The status priority would allow for ONDEMAND statuses (which only fire off when the player shares a tile with the NPC) and ALWAYS statuses (the NPC remains loaded, with the status event firing off every turn). Statuses like pregnancy would be reimplemented as scheduled events. This would allow the NPC to be unloaded as normal and reloaded on-demand when the event is resolved (if the player impregnates an NPC in Dominion, then travels to Elis, the NPC would be unloaded until their due date). Finally, the zone-based system would ensure that only the NPCs in the same general region as the player were active and in memory, to reduce the overall memory cost.

Rather than storing the amount of time that passed since an NPC was last updated like my current implementation does (that won't be possible if the object is unloaded, after all) we would save the time that they were last updated, then work out what the numeric delta is from that point.

One idea might be to ditch the scheduler system and just use global events for everything. I kind of see the scheduler as being more of a long term goal. I'll also have to see if one already exists (I haven't looked into how the game tracks events like arcane storms, holidays, etc) that could be extended.

 

[ohshitnoo]

just finished it in one sitting, very enjoyable experience, not to complain, ive been looking forward to world map the whole game, and then the only thing you could visit on it was an unfinished city lmao, all good tho

 

[PussyPassAnon]

Here's kind of what I currently have in mind: a status priority system, a scheduler, and your zone-based system to limit the loaded NPC count. The status priority would allow for ONDEMAND statuses (which only fire off when the player shares a tile with the NPC) and ALWAYS statuses (the NPC remains loaded, with the status event firing off every turn). Statuses like pregnancy would be reimplemented as scheduled events. This would allow the NPC to be unloaded as normal and reloaded on-demand when the event is resolved (if the player impregnates an NPC in Dominion, then travels to Elis, the NPC would be unloaded until their due date). Finally, the zone-based system would ensure that only the NPCs in the same general region as the player were active and in memory, to reduce the overall memory cost.

Rather than storing the amount of time that passed since an NPC was last updated like my current implementation does (that won't be possible if the object is unloaded, after all) we would save the time that they were last updated, then work out what the numeric delta is from that point.

I think all of this sounds fantastic. Ideally, we could add classifications. The status system seems to be this weird amalgamation of different types of statuses, rather than a clarified, type-based system of statuses. I think three would be enough: Global (time-based), Localized (map-based), Combative (self-explanatory). Now, the Combative clarification already exists; they are the statuses at only appear during combat and are removed after it ends. So, it's just a matter of differentiating the other two from each other; they're currently bunched together under the same umbrella of being Globally assessed and we would have to go through and filter each individual status into the rewritten code. Adding a classification would be more Object-oriented and abstract, allowing each status to basically just be seen as one of the three and evaluated accordingly (e.g. Global statuses get filtered into code that checks them at time-based instances, Localized statuses get filtered into code that checks them at map-based instances, and so forth).

 

[Sarkath]

Ideally, we could add classifications. The status system seems to be this weird amalgamation of different types of statuses, rather than a clarified, type-based system of statuses. I think three would be enough: Global (time-based), Localized (map-based), Combative (self-explanatory). Now, the Combative clarification already exists; they are the statuses at only appear during combat and are removed after it ends. So, it's just a matter of differentiating the other two from each other; they're currently bunched together under the same umbrella of being Globally assessed and we would have to go through and filter each individual status into the rewritten code.

That should do the trick!

I didn't have to split localized and combative effects in my deferral branch since everything would get updated anyway (when you're in combat you're always sharing a tile with the enemy, after all) but I suspect that distinguishing the two would make it a lot easier and more reliable to have combat effects (bleed and such) fall off after combat. Localized effects could always be applied during combat if such a thing is desired (potion effects and such).

Adding a classification would be more Object-oriented and abstract, allowing each status to basically just be seen as one of the three and evaluated accordingly (e.g. Global statuses get filtered into code that checks them at time-based instances, Localized statuses get filtered into code that checks them at map-based instances, and so forth).

That sounds a lot better than my lazy solution, which was to just make it a dinky enum, lol. I figured that if I were to put in a PR down the road, a simple but impactful patch would be more likely to be accepted, while still opening the door to broader changes down the road.

One potential issue that I see with creating classes for each type of event is that it might make it more tricky to add in modding support. That said, I'm generally of the opinion that it's best for the developer to put in the extra work to both design elegant and make it easier for the end user. XMLs for the proposed status system would have to be handled a bit differently to preserve the current XML format. I think having the effects default to Localized (which should be a safe default, even for combat-focused statuses), then using a factory pattern to switch it based on the value of a new element (say, <classification>) would probably work. That would be a bit friendlier to modders than splitting it into three separate root elements, IMO.

 

[Carl0sDanger]

just finished it in one sitting, very enjoyable experience, not to complain, ive been looking forward to world map the whole game, and then the only thing you could visit on it was an unfinished city lmao, all good tho

Most people here remember that feeling. "Wow, this game really has potential! I can't wait to see what happens in the next update! The whole world's going to open up!"

Most people here also remember the feeling of mounting frustration as (late) update after (late) update contained no progress whatsoever on the main story. The "unfinished city" actually represents the most progress on the main story that we've gotten in around two years (possibly longer). I actually first joined this site to try to find out when work on the main quest would resume. That was May of last year.

 

[PussyPassAnon]

Localized effects could always be applied during combat if such a thing is desired (potion effects and such).

This is actually why I came up with the idea, tbh. There was a problem I had with some of my mod ideas where the current mod system has Combat effects and general effects applied in mutually exclusive scenarios. If it's a combat effect, then I won't see it outside combat. But, if it's a general effect, then I can't use it in combat (the status won't render, rather). I was wanting to suggest something that could make the system more flexible, to even where some combat effects could "linger" after the fight (e.g. "Flash" critical makes sight difficult for a little while, "Arcane Cloud" critical accelerates lust gain for a while, etc). The idea would allow a status to adopt multiple classifications and allow a status to be applied across any combination of the three types (so, if that Flash spell lingered after battle, then it would be labeled both a Combative and Localized Effect).

That sounds a lot better than my lazy solution, which was to just make it a dinky enum, lol. I figured that if I were to put in a PR down the road, a simple but impactful patch would be more likely to be accepted, while still opening the door to broader changes down the road.

One potential issue that I see with creating classes for each type of event is that it might make it more tricky to add in modding support. That said, I'm generally of the opinion that it's best for the developer to put in the extra work to both design elegant and make it easier for the end user. XMLs for the proposed status system would have to be handled a bit differently to preserve the current XML format. I think having the effects default to Localized (which should be a safe default, even for combat-focused statuses), then using a factory pattern to switch it based on the value of a new element (say, <classification>) would probably work. That would be a bit friendlier to modders than splitting it into three separate root elements, IMO.

Yes, I agree. Defaulting to localized would by definition keep status effects contained to regions and maps, thus ensuring optimization of the entire structure. However, I'm not entirely sure what the vision was for Innoxia when coding in status effect support or if this falls in line with it. I could start work on the changes, but I don't want to pick up a project that won't see implementation.

 

[Sarkath]

I was wanting to suggest something that could make the system more flexible, to even where some combat effects could "linger" after the fight (e.g. "Flash" critical makes sight difficult for a little while, "Arcane Cloud" critical accelerates lust gain for a while, etc). The idea would allow a status to adopt multiple classifications and allow a status to be applied across any combination of the three types (so, if that Flash spell lingered after battle, then it would be labeled both a Combative and Localized Effect).

In that case, trying to roll everything out as separate classes would be a bit sticky. Using an EnumSet (flags) might be a better option for keeping track of which effect needs to go where.

Actually, the more I think about it the better that would probably be. Trying to differentiate them by type would either require you to check the type (would would essentially be a less flexible option than using flags) and trying to simply get a list of each status type would require reflection, which would wreck performance if it's done too often. Additionally, it would prove to be more flexible in the long run.

With flags, on the other hand, you could set a combination of flags, such as Combative+Localized, to ensure that the status remains applied. If you're feeling particularly spicy, you could even use that technique to define a long-term post-combat status (Combative+Global).

It's not the most object-oriented approach, but it feels like the most pragmatic and flexible one.

The other option would be to keep them split by type and simply have a combat move apply a Localized/Global effect directly. Those would still continue to receive update ticks during combat.

Yes, I agree. Defaulting to localized would by definition keep status effects contained to regions and maps, thus ensuring optimization of the entire structure. However, I'm not entirely sure what the vision was for Innoxia when coding in status effect support or if this falls in line with it. I could start work on the changes, but I don't want to pick up a project that won't see implementation.

The current system is probably used the way it is because "hey, this updates every turn, has a visible icon/tooltip, and can have a duration." Conceptually it's not bad, it just doesn't scale well in its current inception (and, IIRC, combat effects have to be special cased to ensure that they fall off properly, which this proposal would instantly fix…gonna have to look that up at some point).

As far as gauging interest is concerned, opening a RFC as a GitHub issue would be a good formal approach. I'd probably open up with the former (and then move to Discord if requested), since it's easily possible that it could get lost in the shuffle if the idea is thrown out in a chatroom, to say nothing of the typical signal-to-noise ratio.

 

[PussyPassAnon]

Alright, sounds like a plan. I'll look into it when I finish breaking my current mod.

 

[badbadbadnotgood]

need help cant press start

 

[anon707]

need help cant press start

gonna need a little more than just "PLEASE HELP"

 

[Carl0sDanger]

gonna need a little more than just "PLEASE HELP"

On the plus side, at least they said "please". And the full word even, not just "plz". By the standard of the average drop-in asking for help, BBBNG's manners are impeccable.

@badbadbadnotgood:
By "cant press start", do you mean that the game loads, but nothing happens when you press the "start" button? Please be advised that this game is laggy as fuck (reasons, and possible fixes, for which have been discussed extensively over the last 5-10 pages). Click on the"start" button and wait a while would be my initial advice.

 

[Rukatzu]

Does anyone have any recomendations for mods that expand gameplay? Like more side-quests, unique NPCs, romance quests and maybe even a mod that let's you get your own home/mansion/palace?

And could anyone help explain how to install mods? Because everytime I install a mod, the game doesn't go beyond the title screen, so I must be doing something wrong.

 

[PussyPassAnon]

Does anyone have any recomendations for mods that expand gameplay? Like more side-quests, unique NPCs, romance quests and maybe even a mod that let's you get your own home/mansion/palace?

As far as I know, there's people working on things like that, but they typically get implemented into Innoxia's main build as part of the game.

 

[262177]

need help cant press start

If your problem isn't Innoxia, my money is on your /res/ folder not being there or no write permissions to the game folder. And to Innoxia's defense, this should throw a warning when you start the game.

What does the fox error log say?

 

[e-disfunction]

Is there an easy way to generate a text list of *my* character stats and/or abilities and/or equipment, please?

e-d

 

[PussyPassAnon]

Is there an easy way to generate a text list of *my* character stats and/or abilities and/or equipment, please?

e-d

You can export the character data and view the xml file sitting in the "data" folder that contains all the information.

 

[e-disfunction]

You can export the character data and view the xml file sitting in the "data" folder that contains all the information.

Yeah, that *is* easy, thank you!

... However, those .xml files are a he** of a slog to use as a quick or easy reference. Do you or anyone have other ideas?

e-d

 

[262177]

Is there an easy way to generate a text list of *my* character stats and/or abilities and/or equipment, please?

e-d

In addition to what PussyPassAnon said, a <playerCharacter></playerCharacter> search-and-copy in your current XML savefile will also do the trick though that method is indeed easier unless you want only specific fields to be exported.

Edit: And there goes my bad habit of posting too fast and not waiting for the "New posts" prompt...