Fill count and inflation inconsistencies

[XspeedPL]

Since part of the drip logic has been moved to the climax plugin, we now have two separate counters for preg chance bonus and the drip mechanics.
The original idea has that the sperm amount was directly tied to the bonus, but since both counters now have separate decay config values it can produce odd results, like showing inflation when fill count is 0.

Wouldn't it make more sense to merge the counters into one?

On a related note, should there be logic of sperm from different sources killing each other?

[ErinaSugino]

I agree that it is a weird concept in the long run to separate the two this much. Atleast they should be using the same config value and calculation formular. Why the inflation mechanic has been outsourced to the climax plugin I already explained to you back when you first introduced it.

As for the second suggestions: Yes Probably not. I'm all for complexity and pseudo-realism, but especially in the current context that would just be too much for too little of an effect. If one day we'll make the sperm side of things it's own tracked mechanic as a whole (basically just like the persistent ovulation cycle, there is temporarily persistent cum and stuff) we can talk about the more detailed aspects of it. But not for now.

[XspeedPL]

Then, would moving the stat and it's tracking higher up to Actor instead make sense?
I was also thinking about making the fill value persistent outside of sexnodes/scenes, so the drip could happen when naked.

Having it persistent could allow mods to utilize it outside of scenes as a resource (e.g. magic charms, summonable tentacles, custom NPC interactions).

Also afterwards then, impregnation logic could be fully moved outside the scenes as well, though I guess some people like it happening instantaneously.

[ErinaSugino]

For managing, probably. The tracking of the fill state and stuff could go there. The mechanics and their handling should still remain in their modules though, as they are tied to it. And since plugins in theory can be disabled entirely, the corresponding mechanic should also be diabled. So if you for example disable pregnancies alltogether, there is no need to do any tracking of fertility bonuses based on climax state. And if climaxing is disabled... well, there is nothing to begin with xD

As for having it persistent, that is a whole lot more work. It requires adding a resource to the entities that is tracked, communication that syncs these values (preferably integrated into the current syncing loop, though that is only for pregnancies, or only during unloading to safe data traffic) and managing on the entity side. I'm not saying it's impossible or a bad idea (it actually ties well into the whole "lingering cum can impregnate you even after sex" kinda mechanic, but that needs serious balancing), just that it's no simple change. And if you want drip outside of sexnodes - well, that's where things get really funky. We already have tracking of clothing, so that can easily be edited to have a nude state. (Assuming people only play with nude-patched characters, otherwise they drip into their undies, at which point it could be fully independant of clothing) But adding the dripping itself; I know that players have a local animator that allows adding effects at runtime, used by e.g. status effects. That could potentially be used, but I have no idea if and how it all works yet.

As for completely outsourcing the pregnancy logic to the entity - that would in theory also be a good step, but then the question about data consistency remains. Currently, the actor knows everything they need to know for everything. They just sync the created pregnancies to be stored on the entity, whereas players then trigger notifications and stuff after a delay ticked down. If the entire pregnancy logic it put onto the entity, then the actor would have to sync every event that affects pregnancy (like every climax), while the entity needs to send back pregnancy related data like "is visibly pregnant". I'm sure there can be a lot of optimization done in this regard, but for now it seems like leaving it on the actor and just send the data that needs to be persistently stored is the better solution.

Also talking about "it happening instantaneously" - that's already not happening (for players) anymore, and it's nothing you can disable in the config. As a player mother, the pregnancy triggers 60-180 seconds after climax. Period. So that wouldn't be a change either way. The only change would be adding this for NPCs too, but that bring alot of other complications with their fickle, temporary existence.