Commit Graph

9 Commits

Author SHA1 Message Date
Joshua Kidder 7a3ad79506 All camelCase (Brute|Burn|Fire|Tox|Oxy|Organ|Stamina)(Loss) procs now use snake_case. UNDERSCORES RULE! (#94111)
## About The Pull Request
It's just a partial cleanup of
anti-[STYLE](https://github.com/tgstation/tgstation/blob/master/.github/guides/STYLE.md)
code from /tg/'s ancient history. I compiled & tested with my helpful
assistant and damage is still working.

<img width="1920" height="1040" alt="image"
src="https://github.com/user-attachments/assets/26dabc17-088f-4008-b299-3ff4c27142c3"
/>


I'll upload the .cs script I used to do it shortly.

## Why It's Good For The Game
Just minor code cleanup.

Script used is located at https://metek.tech/camelTo-Snake.7z

EDIT 11/23/25: Updated the script to use multithreading and sequential
scan so it works a hell of a lot faster
```
/*
//
Copyright 2025 Joshua 'Joan Metekillot' Kidder

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.
//
*/
using System.Text.RegularExpressions;
class Program
{
    static async Task Main(string[] args)
    {
        var readFile = new FileStreamOptions
        {
            Access = FileAccess.Read,
            Share = FileShare.ReadWrite,
            Options = FileOptions.Asynchronous | FileOptions.SequentialScan
        };
        FileStreamOptions writeFile = new FileStreamOptions
        {
            Share = FileShare.ReadWrite,
            Access = FileAccess.ReadWrite,
            Mode = FileMode.Truncate,
            Options = FileOptions.Asynchronous
        };
        RegexOptions regexOptions = RegexOptions.Multiline | RegexOptions.Compiled;
        Dictionary<string, int> changedProcs = new();
        string regexPattern = @"(?<=\P{L})([a-z]+)([A-Z]{1,2}[a-z]+)*(Brute|Burn|Fire|Tox|Oxy|Organ|Stamina)(Loss)([A-Z]{1,2}[a-z]+)*";
        Regex camelCaseProcRegex = new(regexPattern, regexOptions);

        string snakeify(Match matchingRegex)
        {
            var vals =
            matchingRegex.Groups.Cast<Group>().SelectMany(_ => _.Captures).Select(_ => _.Value).ToArray();
            var newVal = string.Join("_", vals.Skip(1).ToArray()).ToLower();
            string logString = $"{vals[0]} => {newVal}";
            if (changedProcs.TryGetValue(logString, out int value))
            {
                changedProcs[logString] = value + 1;
            }
            else
            {
                changedProcs.Add(logString, 1);
            }
            return newVal;
        }
        var dmFiles = Directory.EnumerateFiles(".", "*.dm", SearchOption.AllDirectories).ToAsyncEnumerable<string>();

        // uses default ParallelOptions
        // https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.paralleloptions?view=net-10.0#main
        await Parallel.ForEachAsync(dmFiles, async (filePath, UnusedCancellationToken) =>
        {
            var reader = new StreamReader(filePath, readFile);
            string oldContent = await reader.ReadToEndAsync();
            string newContent = camelCaseProcRegex.Replace(oldContent, new MatchEvaluator((Func<Match, string>)snakeify));
            if (oldContent != newContent)
            {
                var writer = new StreamWriter(filePath, writeFile);
                await writer.WriteAsync(newContent);
                await writer.DisposeAsync();
            }
            reader.Dispose();
        });
        var logToList = changedProcs.Cast<KeyValuePair<string, int>>().ToList();
        foreach (var pair in logToList)
        {
            Console.WriteLine($"{pair.Key}: {pair.Value} locations");
        }
    }
}

```

## Changelog
🆑 Bisar
code: All (Brute|Burn|Fire|Tox|Oxy|Organ|Stamina)(Loss) procs now use
snake_case, in-line with the STYLE guide. Underscores rule!
/🆑
2025-11-27 15:50:23 -05:00
RikuTheKiller 337ab7f2c3 Refactors status effects to be based on subsystem ticks, among a few other minor status effect fixes/refactors (#93694)
## 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.
/🆑
2025-11-07 15:25:16 +01:00
Bloop a66c6a7191 Adds damage getter procs with a required_bodytype arg (#92417)
## About The Pull Request

There is a way to specify bodytypes and organ flags when dealing damage,
but no such thing exists when checking the damage for _some reason_.

This means you can't do easily something like check how much damage is
done specifically to nonrobotic limbs.

No more! This PR just adds an arg that probably should have been there
for a while now. Should not have any noticeable effects in-game.

## Why It's Good For The Game

Better procs for coders mean less of a need to do janky things.
2025-08-09 19:29:53 -05:00
SmArtKar f40bb684b1 Fixes an old simplemob damage bug (#89759)
## About The Pull Request

Literally every single bit of our code assumes that adjustXLoss returns
the total health delta (old_damage - new_damage), so negative values
when damage was taken and positive when it was healed, ***except***
simplemobs had this inverted for (supposedly) two years. Yeah. This
broke crushers, mending touch and slime feeding - not sure if anything
else was screwed due to this.

Closes #87550

## Why It's Good For The Game


![despair-suffer](https://github.com/user-attachments/assets/cc18bc20-2fd5-48fc-833e-046433185ec5)

## Changelog
🆑
fix: Fixed inconsistent crusher trophy droprates
/🆑
2025-03-03 20:26:52 +11:00
Ghom 5409570e01 Upgrades GODMODE from a flag to a trait. (#86596)
## About The Pull Request
GODMODE has a lot of sources that toggle it. From admin-stuff to status
effects, components, actions and mobs which are supposed to be
invincible. It's better off as a trait than a flag, so we can manage
these sources.

## Why It's Good For The Game
See above.

## Changelog

🆑
admin: godmode is now a datum trait instead of a bitflag. This means the
process for toggling it is a little different now.
/🆑
2024-09-15 13:40:19 +00:00
MrMelbert 249df48116 Deletes handle_random_events, saving us from 1 whole proc call in Life (#83421)
## About The Pull Request

Dumps `handle_random_events` in the bin, giving us one less proc in
`Life`, that's a free proc call optimization baby.

Replaces its only implementation with a status effect conditionally
applied when gaining / losing tox dam.

## Changelog

🆑 Melbert
refactor: Refactored the way high toxins cause you to vomit.
/🆑
2024-05-26 11:58:16 -07:00
distributivgesetz 274eb2a52e Removes Clone Damage (#80109)
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->

## About The Pull Request

Does what it says on the tin. We don't have any "special" sources of
clone damage left in the game, most of them are rather trivial so I
bunched them together into this PR.

Notable things removed:
- Clonexadone, because its entire thing was centered around clone damage
- Decloner gun, it's also centered around cloning damage, I couldn't
think of a replacement mechanic and nobody uses it anyways
- Everything else already dealt clone damage as a side (rainbow knife
deals a random damage type for example), so these sources were removed

<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->

## Why It's Good For The Game

Consider the four sources of normal damage that you can get: Brute,
Burn, Toxins and Oxygen. These four horsemen of the apocalypse are very
well put together and it's no surprise that they are in the game, as you
can fit any way of damaging a mob into them. Getting beaten to death by
a security officer? Brute damage. Running around on fire? Burn damage.
Poisoned or irradiated? Toxin damage. Suffocating in space? Brute, burn
and oxygen damage. Technically there's also stamina damage but that's
its own ballpark and it also makes sense why we have a damage number for
it.

Picture this now: We have this cool mechanic called "clone pods" where
you can magically revive dead people with absolute ease. We don't want
it to be for free though, it comes at a cost. This cost is clone damage,
and it serves to restrain people from abusing cloning.

Fast forward time a bit and cloning is now removed from the game. What
stays with us is a damage number that is intrinsically tied to the
context of a removed feature. It was a good idea that we had it for that
feature at the time, but now it just sits there. It's the odd one out
from all the other damage types. You can easily explain why your blade
dealt brute damage, but how are you going to fit clone damage into any
context without also becoming extremely specific?

My point is: **clone damage is conceptually a flawed mechanic because it
is too specific**. That is the major issue why no one uses it, and why
that makes it unworthy of being a damage stat.
Don't take my word for it though, because a while ago we only had a
handful of sources for this damage type in the game. And in most of the
rounds where you saw this damage, it came from only one department. It's
not worthwhile to keep it around as a damage number. People also didn't
know what to do with this damage type, so we currently have two ways of
healing clone damage: Cryotubes as a roundstart way of healing clone
damage and Rezadone, which instantly sets your clone damage to 0 on the
first tick. As a medical doctor, when was the last time you saw someone
come in with clone damage and thought to yourself, "Oh, this person has
clone damage, I cannot wait to heal them!" ?

Now we have replacements for these clone damage sources. Slimes? Slime
status effect that deals brute instead of clone. Cosmic heretics? Random
organ damage, because their mechanics are already pretty fleshed out.
Decloning virus? The virus operated as a "ticking timebomb" which used
cloning damage as the timer, so it has been reworked to not use clone
damage. What remains after all this is now a basically unused damage
type. Every specific situation that used clone damage is now relying on
another damage type. Now it's time to put clone damage to rest once and
for all.

Sure, you can technically add some form of cellular degradation in the
future, but it shouldn't be a damage number. The idea of your cells
being degraded is a cool concept, don't get me wrong, but make it a
status effect or maybe even a wound for that matter.

<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->

## Changelog

<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->

🆑
del: Removed clone damage.
del: Removed the decloner gun.
del: Removed clonexadone.
/🆑

<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
2023-12-04 14:42:43 -08:00
Bloop 0359da29bc QoL improvements to the mob damage unit tests (#78748)
## About The Pull Request

This is something that I meant to do because it was a minor annoyance as
I was creating the tests but I never got around to it.

Because many of the failures occurred in procs it could be difficult to
pinpoint the exact line of the test where they were failing. It would
just be the line within the proc, and not the line where the proc was
called. So you'd have to sort of infer which one it was from the values
of `x` and `y` in `Expected x to be equal to y`.

Now each test failure will have a brief description and a line number
where `apply_damage()` / `verify_damage()` actually got called to make
it clearer. Like shown below.


![Code_r6N3XSAb3m](https://github.com/tgstation/tgstation/assets/13398309/92ac5a91-3c3f-4b3b-90de-09fe0d9891f1)

## Why It's Good For The Game

Just a small QoL update for coders. Some typos fixed, too. 

## Changelog

Nothing player facing though.
2023-10-06 13:29:19 +01:00
Bloop 68b798efa0 A thorough audit of damage procs and specifically their use in on_mob_life() (with unit tests!) (#78657) 2023-10-03 04:01:32 -04:00