mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-24 05:30:05 +01:00
52bd1b6233
* Kills `seconds_per_tick` from status effect `tick`, replaces it with `seconds_between_ticks` to clarify some things (#77219) ## About The Pull Request https://github.com/tgstation/tgstation/pull/66573#discussion_r861157216 `status_effect/proc/tick(seconds_per_tick)` is wildly misleading and I feel like I should address it For a majority of status effects, they process on fast processing but do not tick every fastprocessing tick This means that using `seconds_per_tick` here is not giving you the seconds between status effect ticks, it's giving you seconds between processing ticks (`0.2`) This is how it's misleading - If you have a tick interval of `1 SECONDS`, you'd think `seconds_per_tick` is, well, one. But it's actually one-fifth. So all of your effects are now 80% weaker. I have replaced the use of `seconds_per_tick` in tick with `seconds_between_ticks`. This number is, quite simply, the initial tick interval of the status effect divided by ten. An effect with the tick interval of `1 SECONDS` has a `seconds_between_ticks` of 1. As a consequence, some things which were inadvertently made weaker, such as fire and some heretic things (at a glance), are now a little stronger. ## Why It's Good For The Game See above. Makes it more clear what you're doing when working with effects. ## Changelog 🆑 Melbert code: Updated some status effect tick code to be more clear of how long is elapsing between ticks. Some effects that were inadvertently weakened are now stronger as a result (fire and some heretic effects). /🆑 * Kills `seconds_per_tick` from status effect `tick`, replaces it with `seconds_between_ticks` to clarify some things * Modular updates --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
79 lines
3.2 KiB
Plaintext
79 lines
3.2 KiB
Plaintext
/datum/status_effect/dizziness
|
|
id = "dizziness"
|
|
tick_interval = 2 SECONDS
|
|
alert_type = null
|
|
remove_on_fullheal = TRUE
|
|
|
|
/datum/status_effect/dizziness/on_creation(mob/living/new_owner, duration = 10 SECONDS)
|
|
src.duration = duration
|
|
return ..()
|
|
|
|
/datum/status_effect/dizziness/on_apply()
|
|
RegisterSignal(owner, COMSIG_LIVING_DEATH, PROC_REF(clear_dizziness))
|
|
return TRUE
|
|
|
|
/datum/status_effect/dizziness/on_remove()
|
|
UnregisterSignal(owner, COMSIG_LIVING_DEATH)
|
|
// In case our client's offset is somewhere wacky from the dizziness effect
|
|
owner.client?.pixel_x = initial(owner.client?.pixel_x)
|
|
owner.client?.pixel_y = initial(owner.client?.pixel_y)
|
|
|
|
/// Signal proc that self deletes our dizziness effect
|
|
/datum/status_effect/dizziness/proc/clear_dizziness(datum/source)
|
|
SIGNAL_HANDLER
|
|
|
|
qdel(src)
|
|
|
|
/datum/status_effect/dizziness/tick(seconds_between_ticks)
|
|
// How much time is left, in seconds
|
|
var/amount = (duration - world.time) / 10
|
|
if(amount <= 0)
|
|
return
|
|
|
|
// How strong the dizziness effect is on us.
|
|
// If we're resting, the effect is 5x as strong, but also decays 5x fast.
|
|
// Meaning effectively, 1 tick is actually dizziness_strength ticks of duration
|
|
var/dizziness_strength = owner.resting ? 5 : 1
|
|
|
|
// How much time will be left, in seconds, next tick
|
|
var/next_amount = max((amount - (dizziness_strength * seconds_between_ticks * 0.1)), 0)
|
|
|
|
// If we have a dizziness strength > 1, we will subtract ticks off of the total duration
|
|
if(remove_duration((dizziness_strength - 1) * seconds_between_ticks))
|
|
return
|
|
|
|
// Now we can do the actual dizzy effects.
|
|
// Don't bother animating if they're clientless.
|
|
if(!owner.client)
|
|
return
|
|
|
|
// Want to be able to offset things by the time the animation should be "playing" at
|
|
var/time = world.time
|
|
var/delay = 0
|
|
var/pixel_x_diff = 0
|
|
var/pixel_y_diff = 0
|
|
|
|
// This shit is annoying at high strengthvar/pixel_x_diff = 0
|
|
var/list/view_range_list = getviewsize(owner.client.view)
|
|
var/view_range = view_range_list[1]
|
|
var/amplitude = amount * (sin(amount * (time)) + 1)
|
|
var/x_diff = clamp(amplitude * sin(amount * time), -view_range, view_range)
|
|
var/y_diff = clamp(amplitude * cos(amount * time), -view_range, view_range)
|
|
pixel_x_diff += x_diff
|
|
pixel_y_diff += y_diff
|
|
// Brief explanation. We're basically snapping between different pixel_x/ys instantly, with delays between
|
|
// Doing this with relative changes. This way we don't override any existing pixel_x/y values
|
|
// We use EASE_OUT here for similar reasons, we want to act at the end of the delay, not at its start
|
|
// Relative animations are weird, so we do actually need this
|
|
animate(owner.client, pixel_x = x_diff, pixel_y = y_diff, 3, easing = JUMP_EASING | EASE_OUT, flags = ANIMATION_RELATIVE)
|
|
delay += 0.3 SECONDS // This counts as a 0.3 second wait, so we need to shift the sine wave by that much
|
|
|
|
x_diff = amplitude * sin(next_amount * (time + delay))
|
|
y_diff = amplitude * cos(next_amount * (time + delay))
|
|
pixel_x_diff += x_diff
|
|
pixel_y_diff += y_diff
|
|
animate(pixel_x = x_diff, pixel_y = y_diff, 3, easing = JUMP_EASING | EASE_OUT, flags = ANIMATION_RELATIVE)
|
|
|
|
// Now we reset back to our old pixel_x/y, since these animates are relative
|
|
animate(pixel_x = -pixel_x_diff, pixel_y = -pixel_y_diff, 3, easing = JUMP_EASING | EASE_OUT, flags = ANIMATION_RELATIVE)
|