Since you're open to having these included, could you create a quick PR for any part(s) you consider reasonably complete and ready? She at least tries to go through those every so often.
That's the plan.
The SpEL changes are the closest to completion, though there are still a couple of aspects that I need to change before it's ready for prime time (pretty much just protecting the game state variables, which I don't see being too difficult given how the parser works), as well as doing a test run of the game.
Why the fuck would she set it up that way. The game actually presents character changes as happening on the update increments. I could *MAYBE* see doing it this way if she was updating the character body consistently, but the game explicitly tells you that's not what is happening.
It's a simple, naïve approach. Basically, everything is set up as a child of AbstractStatusEffect and handled the same way. It wouldn't surprise me if most of those AbstractStatusEffect implementations also included a call to the scripting engine, as status effects can be modded into the game.
This approach is clean and flexible, as the endTurn routine doesn't have to know any of the details about each status effect: it just processes them all at once. The problem is that this simplicity also leads to the game having to update a ton of stuff that the player has no way of observing.
Put it on the scheduler. There should be a way to specify if buffs are on the scheduler or on the player's turn. Both would be useful, but handling all buffs in one way or the other is dumb as hell. But this might be a bit too hard for modding purposes.
Yeah, my main concern are those situations where the timeline can move forward, such as with Mother's Milk and pregnancy. Pregnancy is pretty predictable, being a core gameplay mechanic, but with the game's modability increasing I'm not sure that the status effect system will be able to completely escape iteration, especially if it's possible for status effects to change the game world behind the scenes like a resolved pregnancy does. Still, I think there are some things that could be done to nudge things into a better place.
And doesn't your fork require changing out which version of Java the games using and all that? Somehow I doubt it'd be accepted.
Everything I did should still work with JDK 8. I might have let a couple of var's slip in (I believe that was introduced in JDK 10), but that's easy enough to deal with.
I think the main issue is that the SpEL fork isn't really required if JDK 8 continues to be targeted. That's more of a future proofing branch which has the side-effect of replacing a heavy JavaScript engine with a lighter expression parser. I think the bigger issues in this case would be that it breaks existing XML scripting (though I've gone through and corrected those) and that its practical improvements are dubious.
Honestly, at this point it isn't entirely clear how much of an impact, if any, it has on actual performance, due to the weight of the status effect system. eval() did come up pretty hot in the CPU profiler's heat map, but with my stress test save the game feels pretty similar between both the official release and my fork.
