Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Major "Real Time" Processing Causes Issues
#1
Ever since reagent processing was changed to be in "real time" as opposed to BYOND time, there's been a number of weird bugs with reagents.

There seems to be far more instances of rounding errors when reagents deplete. While this has always occurred with reagents, this seems to be happening more often.

That said, the major frustration with this is that reagent damage as defined by the wiki is now meaningless. I dunno if this is intentional or not, but it's impossible to know or tell how much damage a reagent is supposed to do. Sometimes a reagent that's supposed to do 1 TOX will do 1.25. Then next time it'll be 2.32342.

I'm guessing you're doing some weird thing of looking at total elapsed tick useage or measuring when something started versus finished, then taking the time difference and multiplying it by when it should have processed, but this makes things a bit confusing and inconsistent.

Breathing and losebreath have the same problem (8.255962 damage, verus the flat 5, for instance) when you're in an O2 deprived environment or acquire the losebreath status. Also, as an aside, there's some weird conditions where O2 will just not heal from `Breath` at all; it'll stay stuck, forever, when it should be recovering 5 every other atmospherics process (as a personal aside this should probably be changed to process every other `Life`instead of processing based on what the air controller is doing).

I get what's being gone for, but I'm not really sure it's necessary for reagent processing to be so precise that all transparency for what a reagent is doing is effectively destroyed (or anything using this).

It seems that a better solution would be to track the current duration of how long it took `Life` to process (or whatever it is you're doing for this system), and subtract the over time for the next scheduled time for it to run. So, if reagent processing or Life processing was delayed by 0.5 seconds, then the next time it runs, it'll run 1.5 seconds later, instead of the usual 2.

In this way, the damage/healing of reagents/breathing is kept the same, and transparent, but the damage over time is kept consistent and in "real time" of what it should be.
#2
with respect to reagents, the focus has been moved away from per-tick damage consistency. instead the system now has emphasis on doing a reliable amount of damage in a reliable timeframe. (example : X units of toxin will always proc Y units of damage in Z minutes, where in the old system this damage could come faster or slower depending on the server load)

for breath : i know there are some problems (that were also sort of related to realtime stuns), in which some numbers needed to be rebalanced to reflect the new timing. this is an ongoing effort and I've just pushed a handful of adjustments today.
#3
Yeah, I realize that's what you're aiming for, as I surmised in my post, I'm just not sure the reasoning for doing it like ya did, I suppose.

Obviously sleeping until the tick is no longer overrun will have some implications of things being a bit delayed (though are reagents so important that if you miss even 2-3 life loops, that it's going to ruin things? Ehhh, not so sure).

At the same time, dynamically running each mob's `Life` by either sorting the list or allowing for a sort of "run at this time" instead of flat every 2 seconds could easily accomplish the the same thing without having to adjust damage numbers.

Just curious on your approach, really.

Admittedly, I'm not a fan of destroying all transparency for how much damage things deal in favor of something running in "real time".
#4
(04-04-2019, 05:59 PM)Fox McCloud Wrote: Yeah, I realize that's what you're aiming for, as I surmised in my post, I'm just not sure the reasoning for doing it like ya did, I suppose.

Obviously sleeping until the tick is no longer overrun will have some implications of things being a bit delayed (though are reagents so important that if you miss even 2-3 life loops, that it's going to ruin things? Ehhh, not so sure).

At the same time, dynamically running each mob's `Life` by either sorting the list or allowing for a sort of "run at this time" instead of flat every 2 seconds could easily accomplish the the same thing without having to adjust damage numbers.

Just curious on your approach, really.

Admittedly, I'm not a fan of destroying all transparency for how much damage things deal in favor of something running in "real time".

There was no transparency before. Life() tick order or frequency was completely indeterminate before, and that hasn't changed here. Life() ticks were and are not sorted, and never will be. The change here moved damage from a per-tick basis to a per-second basis. Instead of dealing 5 damage per tick, it will now deal 20 damage per second, except ticking once every 2-4 seconds based on server load.

Before, you could take a ton of damage in a short duration if there were catchup ticks, but now it being per second it's easier to determine the end result over a period of time than it was before so if anything it's MORE transparent.

If you miss 2-3 life ticks, reagents will proc at a 2-3x multiplier to play catchup. Numbers obviously need to be tuned, and those numbers themselves should be reported when they come up, but this report in it's current state is currently Not a Bug. Yes, there will be rounding errors, but it should be more accurate now and as a result of this change, the wiki should be changed from per-tick to per-second.
#5
Quote:Before, you could take a ton of damage in a short duration if there were catchup ticks, but now it being per second it's easier to determine the end result over a period of time than it was before so if anything it's MORE transparent.

Not really, no.

As is, it's incredibly transparent how much damage a reagent does, when it runs (or how much damage you take from missing a breath).

As an example, take simple old "toxin", which deals 2 damage every time it processes. It's really easy to determine how much that is. You swallow a pill, take note of what your current tox is, then note when the amount in you changes and take note of how much damage it did each time it updates.

That's now impossible from my experience; even with only 4-10 players on under (presumably) low load, how much damage it deals is all over the place---and this is for a simple chemical like toxin. I'm sure you could hypothetically time an arbitrary duration of, say, 60 seconds, and get an estimate, but even that will be difficult to determine, since you stated things could tick every "2-4 seconds".

Throw in something advanced like Initro, Sarin, histamine, or what have you--things that are RNG based? It's now impossible to even *guess* at thresholds or amounts. You could kinda guess it before, if you were patient and wanted to test on monkeys. But now? Won't really be possible.

Quote:Life() ticks were and are not sorted, and never will be.

Well, when it ticks, and in what order is determined by the order in which human mobs get added to the mobs list, in part; you could definitely do sorting of that list to insert things at the proper ordering to get them to process at specific times; TG's `addtimer` system (which replaces spawn) does something like this.

Another alternative is reworking the Process Scheduler so that it keeps track of how long it takes to run, then fires early if it slept, before; obviously, not all scheduled processes need to do this (I doubt anyone will care if solars is delayed by 10 seconds, nor is it of any impact), but if certain tasks need precise timing, like mobs, then this would allow you to effectively keep reagent processing the same, without funky number adjustments.

I more than understand what you're aiming for; I just find it to be an odd way to go about it, I guess (albeit, it's definitely easier to go about the way you've done it than a more involved list sorting and having dynamic schedule intervals for the Process Scheduler).

Thanks for your time though. I appreciate all the hard work you guys put into Goon to make it better.


Forum Jump:


Users browsing this thread: 1 Guest(s)