## 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.
/🆑
## About The Pull Request
We probably shouldn't be doing all of this work for all the stacking
status effects without visuals considering only a single status effect
uses the overlay system as of now.
## Changelog
🆑
code: Stacking status effects without visual overlays will no longer try
to create them and fail to do so.
/🆑
## About The Pull Request
516 requires float layered overlays to be using pixel_w and pixel_z
instead of pixel_x and pixel_y respectively, unless we want
visual/layering errors. This makes sense, as w,z are for visual effects
only. Sadly seems we were not entirely consistent in this, and many
things seem to have been using x,y incorrectly.
This hopefully fixes that, and thus also fixes layering issues. Complete
1:1 compatibility not guaranteed.
I did the lazy way suggested to me by SmArtKar to speed it up (Runtiming
inside apply_overlays), and this is still included in the PR to flash
out possible issues in a TM (Plus I will need someone to grep the
runtimes for me after the TM period to make sure nothing was missed).
After this is done I'll remove all these extra checks.
Lints will probably be failing for a bit, got to wait for [this
update](https://github.com/SpaceManiac/SpacemanDMM/commit/4b77cd487d0a7b6a069df20356b701af5b20489d)
to them to make it into release. Or just unlint the lines, though that's
probably gonna produce code debt
## Why It's Good For The Game
Fixes this massive 516 mess, hopefully.
closes#90281
## Changelog
🆑
refactor: Changed many of our use cases for pixel_x and pixel_y
correctly into pixel_w and pixel_z, fixing layering issues in the
process.
/🆑
---------
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
Co-authored-by: SmArtKar <master.of.bagets@gmail.com>
## About The Pull Request
Technically an improved port of
https://github.com/DaedalusDock/daedalusdock/pull/651, instead of only
storing height over 32 pixels for HUDs we store both pure height and
width for the sake of cutting down on icon operation spam (which is
pretty costly). Should save us a significant amount of time, cuts down
update_health_hud times by 45% and total update_health by 30% which is
pretty good for a somewhat hot proc.
## Why It's Good For The Game
Our health HUDs constantly fetch icons ***twice*** every update_health,
jesus.
## Changelog
🆑 SmArtKar, Kapu
code: Implemented caching for icon sizes which should significantly
improve mob health performance due to HUDs constantly fetching icons
/🆑
## About The Pull Request
Fixes a lot of status effects having the default alert, adds a unit test
to check that status effects don't forget to change it
I chose a test rather than just making the default "no alert" because I
think people making status effects should think about whether it should
have an alert
Also I added a test for effects which did not set an ID because that's
kind of important, I applied the same mindset here to account for
abstract types but admittedly less sold on this one.
## Changelog
🆑 Melbert
fix: You should be afflicted by the "Curse of Mundanity" far, far less
/🆑
## About The Pull Request
1. Deletes `INFINTIE`, it is misleading and not at all a big number and
causes bugs
2. Adds `STATUS_EFFECT_PERMANENT` and `STATUS_EFFECT_NO_TICK` to make it
clearer what infinite status effects are
## About The Pull Request
All usages of world.icon_size in code have been replaced with new
`ICONSIZE_X`, `ICONSIZE_Y` and `ICONSIZE_ALL` defines depending on
context
Replaces some "32" magic numbers with the defines
A few bits of code have been modified to split up x/y math as well
## Why It's Good For The Game
Magic number bad, code more readable, code more flexible and I'm told
there's an access cost to doing world.icon_size so minor performance
gains
## Changelog
🆑 tonty
code: made some code relating to the world's icon size more readable
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Fixes several errors to spelling, grammar, and punctuation.
## Why It's Good For The Game
## Changelog
🆑
spellcheck: fixed a few typos
/🆑
## 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).
/🆑
* Code improvements for status effects in general
* Does this for now
* Throws in a qdeleted check
* A return
* comment tweak
* Missed some ref()s
* Wrong var
* Comment clarifications
* Some more comment clarifications
RikuTheKiller