mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-30 08:37:43 +01:00
RikuTheKillerandGitHub
337ab7f2c3
## About The Pull Request Refactors status effects to track their durations and tick intervals using counters. In effect, [var/duration] now directly refers to how many deciseconds are left on the status effect. I've also moved the old [var/tick_interval] [world.time] implementation to a tick-based [var/time_until_next_tick] counter. There are a couple, less noteworthy changes in here as well. The main one is that there was an unused bit of bloat code for setting tick intervals based on a random lower and upper threshold, but that can be done in tick() now so it's completely redundant, and I thus removed it entirely. That makes parts of [proc/process] much easier to read. I added/modified some unit tests (which I expect to fail) to verify that [var/duration] and [var/tick_interval] are both multiples of the subsystem wait assigned to the status effect. If the programmer wants a duration of 2.5 seconds, they expect it to work that way, but it won't because SSfastprocess only ticks once every 0.2 seconds, which 2.5 is not a multiple of. This becomes way more apparent when a status effect is set to use SSprocessing. The final, perhaps most important unit test I've added, is one that verifies that the overall tick count and overall accumulated [seconds_between_ticks] are equal to "[var/duration] / [var/tick_interval]" and "[var/duration]" respectively. ## Why It's Good For The Game The main thing this PR fixes is timing inconsistencies. Before this PR, durations and tick intervals were tracked using world.time, while the [proc/tick] call timing was dependent on the wait time of the subsystem the status effect was processing on. Thing is, SSfastprocess and SSprocessing rarely run completely in one tick during real gameplay. This led to a continuous desync where status effects were consistently inconsistent in their overall tick count. This is a big problem as [seconds_between_ticks] is constant and thus doesn't account for this difference in tick count. As an example, Changeling's Fleshmend has a duration of 10 seconds, a tick interval of 1 second and a healing rate of 4 brute per tick. Previously, if the server was lagging even slightly and it only ticked 8 times over the course of 10 seconds, you would heal 32 health rather than the 40 that a full Fleshmend would give you. The total effect potency of a status effect being reliant on server lag is incredibly stupid, especially for status effects that have an associated cost. (like the aforementioned Fleshmend) As for the refactors, they make status effect code easier to read and debug. Unit tests also make verifying things are working as intended much easier. ## Changelog 🆑 fix: Status effects now tick consistently, with Fleshmend and such giving a consistent total healing amount. Report any oddities. refactor: Status effect code is now easier to read and makes more sense. Again, report any oddities, the changes are major. /🆑
61 lines
2.2 KiB
Plaintext
61 lines
2.2 KiB
Plaintext
/datum/status_effect/jitter
|
|
id = "jitter"
|
|
tick_interval = 2 SECONDS
|
|
alert_type = null
|
|
remove_on_fullheal = TRUE
|
|
|
|
/datum/status_effect/jitter/on_creation(mob/living/new_owner, duration = 10 SECONDS)
|
|
src.duration = duration
|
|
return ..()
|
|
|
|
/datum/status_effect/jitter/on_apply()
|
|
// If we're being applied to a dead person, don't make the status effect.
|
|
// Just do a bit of jitter animation and be done.
|
|
if(owner.stat == DEAD)
|
|
owner.do_jitter_animation(duration / 10)
|
|
return FALSE
|
|
|
|
RegisterSignal(owner, COMSIG_LIVING_DEATH, PROC_REF(remove_jitter))
|
|
owner.add_mood_event(id, /datum/mood_event/jittery)
|
|
return TRUE
|
|
|
|
/datum/status_effect/jitter/on_remove()
|
|
UnregisterSignal(owner, COMSIG_LIVING_DEATH)
|
|
owner.clear_mood_event(id)
|
|
owner.update_offsets()
|
|
|
|
/datum/status_effect/jitter/get_examine_text()
|
|
switch(duration)
|
|
if(5 MINUTES to INFINITY)
|
|
return span_boldwarning("[owner.p_They()] [owner.p_are()] convulsing violently!")
|
|
if(3 MINUTES to 5 MINUTES)
|
|
return span_warning("[owner.p_They()] [owner.p_are()] extremely jittery.")
|
|
if(1 MINUTES to 3 MINUTES)
|
|
return span_warning("[owner.p_They()] [owner.p_are()] twitching ever so slightly.")
|
|
|
|
return null
|
|
|
|
/// Removes all of our jitteriness on a signal
|
|
/datum/status_effect/jitter/proc/remove_jitter(datum/source)
|
|
SIGNAL_HANDLER
|
|
|
|
qdel(src)
|
|
|
|
/datum/status_effect/jitter/tick(seconds_between_ticks)
|
|
// Resting helps against jitter
|
|
// While resting, we lose 8 seconds of duration (4 additional ticks) per tick
|
|
if(owner.resting && remove_duration(4 * seconds_between_ticks))
|
|
return
|
|
|
|
var/time_left_in_seconds = duration / 10
|
|
owner.do_jitter_animation(time_left_in_seconds)
|
|
|
|
/// Helper proc that causes the mob to do a jittering animation by jitter_amount.
|
|
/// jitter_amount will only apply up to 300 (maximum jitter effect).
|
|
/mob/living/proc/do_jitter_animation(jitter_amount = 100)
|
|
var/amplitude = min(4, (jitter_amount / 100) + 1)
|
|
var/pixel_w_diff = rand(-amplitude, amplitude)
|
|
var/pixel_z_diff = rand(-amplitude / 3, amplitude / 3)
|
|
animate(src, pixel_w = pixel_w_diff, pixel_z = pixel_z_diff , time = 0.2 SECONDS, loop = 6, flags = ANIMATION_RELATIVE|ANIMATION_PARALLEL)
|
|
animate(pixel_w = -pixel_w_diff , pixel_z = -pixel_z_diff , time = 0.2 SECONDS, flags = ANIMATION_RELATIVE)
|