## About The Pull Request
There's a few of these that conflict, mostly relating to timing. This
conflicting won't actually break anything but it does muddy "what is
this doing" somewhat and it's good to be clear so here we go
## Why It's Good For The Game
Makes the MC very slightly harder to confuse yourself with
## About The Pull Request
Continuation of https://github.com/tgstation/tgstation/pull/78857
FOR TOOO LONG WE HAVE SUFF-
Ok yeah so like, we made them overlays to save on maptick, but with
threaded maptick that is potentially not an issue anymore.
I'm opening this pr so I can tm it and see. If it works, it'll save
about 50% of lighting object update costs, which is pretty damn good.
I'm also removing the fullbright light icon state, since it is barely
ever used (it was added as a clientside op, but we don't hit fullbright
very much at all so it does nothing but eat my cpu time)
Also also changing how SSlighting does its resolution. Rather then
waiting for all sources to process, then working on corners and objects,
instead we will do all the sources we had at the start, then all the
sources after, and so on.
The goal is to avoid churn causing the system to constantly choke. it is
better to potentially double operate then it is for things to feel
horrifically slow.
## Why It's Good For The Game
Faster. Also you won't be able to see lights through walls anymore, so
mesons will be less dumb. Can maybe bump their nightvision a bit idk
we'll see.
## Current Issues
to be found
## Changelog
🆑 Absolucy, LemonInTheDark
fix: You can no longer see lights through walls when using mesons or
when ventcrawling.
/🆑
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
This adds experimental read-only support for `/alist`s in VV.
I'm not quite sure how to add support for properly changing alists, but
this is better than nothing at least.
### Before
<img width="474" height="262" alt="image"
src="https://github.com/user-attachments/assets/8701fc64-855b-429e-88d1-f6607000b2c8"
/>
### After
<img width="943" height="539" alt="2026-03-23 (1774313721) ~
dreamseeker"
src="https://github.com/user-attachments/assets/cb6caf2a-19fd-49a9-b228-1bccb2c315f3"
/>
## Why It's Good For The Game
Should be able to at least view alists with VV.
## Changelog
🆑
admin: View Variables can now properly view alists, altho it cannot edit
them.
/🆑
## About The Pull Request
Port of "fast" reftracking from
https://github.com/Monkestation/Monkestation2.0/pull/6893
This adds a `FAST_REFERENCE_TRACKING` define, which makes it so the
reftracker will completely skip over specific types - if my math is
right, on icebox, it will need to scan **1.1+ million fewer items**
compared to normally (stats based on me using Count Atoms/Datums on an
icebox manuel round)
it's still the reftracker, so it's still not magically super speedy now
- it's only enabled by default when `REFERENCE_DOING_IT_LIVE` is set,
you shouldn't really use this locally or in CI.
## Why It's Good For The Game
hopefully makes running reftracker on live less hellish of an experience
## Changelog
No player-facing changes.
## About The Pull Request
This is the most efficent way of doing it (I think), typeid checking is
actually worse (it's 55 btw). I've also added alists to all the find
reference unit tests.
This is a good step in making these things actually work in our
codebase. The next thing to look into will be VV (or SDQL though I
suspect that's just a matter of being able to use a stable version)
which is gonna require playing around with IS_NORMAL_LIST's uses a good
bit
## 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!
/🆑
## About The Pull Request
Allows users to edit color matrix filters and layered filters'
transforms through Filterrific, which were the two last unsupported
filter fields. The menus are pretty minimal, but you shouldn't be
touching them if you don't know what you're doing anyways.
https://github.com/user-attachments/assets/e87447f3-e5d6-4f6c-a8e4-bf50a1d5fa79
## Why It's Good For The Game
Makes our tooling actually work
## Changelog
🆑
admin: Implemented color matrix and transform modification support for
Filterrific
/🆑
## About The Pull Request
Non-smooth modification and renaming didn't work, and mass application
broke a lot of things (always, did actually)
## Changelog
🆑
fix: Fixed some Filterrific functions not working
/🆑
## About The Pull Request
update_filters() is more expensive than it should be due to running
timSort every time a filter is added or removed, plus we wipe
re-initialize the entire atom filter list every time we call it. I
swapped it to use binary insertion into the main list, and we can cut
down on the amount of filter churn by storing filters in a separate list
which we can use Insert on, which allows us to stop constantly deleting
and recreating filters completely.
## Why It's Good For The Game
Server CPU consumption go down
## Changelog
🆑
refactor: Refactored filters to utilize binary insertion instead of
timSort. The server should run somewhat faster now, hopefully.
/🆑
## About The Pull Request
Make `VV` verb Context Menu only.
As it's very annoing when clicked on, because it's forming the list of
all atoms in world which causes nasty client freeze.
## Why It's Good For The Game
No more accidentally clicking VV when trying to click View Runtimes 😠
## Changelog
🆑
admin: VV verb is removed from Debug tab. Who is even using it?
/🆑
## About The Pull Request
Make `VV` verb Context Menu only.
As it's very annoing when clicked on, because it's forming the list of
all atoms in world which causes nasty client freeze.
## Why It's Good For The Game
No more accidentally clicking VV when trying to click View Runtimes 😠
## Changelog
🆑
admin: VV verb is removed from Debug tab. Who is even using it?
/🆑
This is a big one so please bear with me, wounds are complicated
We've decreased the max contributed damage to wound rolls from 35 to 25.
This results, after the exponent, a max possible wound roll of 1 to 91
before any modifiers (assuming the attack, after armor, is 25 or above).
The minimum value to wound is still 5.
Most wounds were contributing significant numbers per wound type to the
potential for a new wound to occur. Getting wounded once meant you were
getting wound a lot, but actually getting past that first wounding may
be the tricky part.
We have significantly reigned in the wound penalty that having a wound
contributes, and instead utilize the series wound penalty to allow same
type wounds to escalate themselves faster as a priority. Having wounds
still makes you more wound vulnerable, just not to such an extreme
degree.
The priority here for what wounds matter most for contributing to
overall wounding vulnerability is ``Infected BURNS > BURNS >
SLASH|PIERCE > BLUNT.``
Wound armor, unlike all other kinds of armor, was used as a additive
value to the wound roll modifiers rather than a multiplicative value.
We have reworked how wound armor is determined by changing how wound
modifiers are calculated.
Firstly, we're passing our entire injury roll into the
``check_woundings_mod()`` proc, as we're not treating this as a proc
that just adds values anymore.
Secondly, bare wound bonus only applies if there is no potential wound
protection from any source, as expected. But it comes last in the
calculations.
Thirdly, wound protection is applied to the injury roll last, after
wound bonuses from the attack, wound bonuses from other wounds and wound
bonuses from a disabled limb are applied. This does not include serial
wound bonuses, which are determined outside of this proc.
Wound protection comes from two sources. Clothing and limb wound
resistance. Your chest and head have an amount of wound resistance so
long as they are not mangled in any fashion. Being mangled means having
either a hairline fracture or a weeping avulsion wound.
Wound protection reduces the final injury roll by a percentage. Say our
roll is 50, and we have effectively 50% wound protection. The final roll
would be 25.
~~Most clothing have had their wound armor values changed. As a loose
rule, I used the highest of melee or bomb armor, except where that value
was 100, in which case I used the lowest instead. I'm basing this
decision on how embeds are calculated, which is attack type agnostic.~~
~~Some armor have inconsistent values because they are alternative
armors to an existing armor type or are hyperspecialized armor.
Ablative, bulletproof and security vests all share a value of 35,
despite the former two not having decent melee or bomb armor.~~
~~Some clothing missing wound armor that should have had them now have
wound armor.~~
~~This may need a bit of scrutiny in case one or two seem weirdly high.
Some have maybe become too low. Its a bit hard to say.~~
I changed it to ``exposed_wound_bonus`` to better represent when it
applies. You can be naked and still not be affected by this bonus if the
limb has wound resistance.
I'm not promising anything with this PR, but this is an attempt to
sanity check the values on wounds so that we're not seeing what the data
that determined the removal of beheading presented. An extreme
over-representation of tier 3 wounds. ~~And, from that, maybe I can
argue for beheadings coming back. That's my goal. I think beheadings
happened so much because the numbers were in need of work.~~ Well okay I
just wanna make wounds a bit more workable actually more than I want
beheadings.
Why is it that tier 3 wounds were so over-represented? Because wounds
will often force more severe wounds of other types by merit of any
wounds existing at all on a limb. Having **_a_** wound makes you more
wound prone for any kind of wound, and not just making you more likely
to suffer a more severe type of the same wound.
The threshold mechanic was intended to simulate making a wound worse,
but oddly just made a limb broadly more prone to getting worse from any
kind of attack to such a degree that future wound rolls of different
types were often going to start at the threshold necessary to be a tier
3 wound.
Dismemberment, mind you, requires you to suffer a flesh wound while you
have a bone wound of tier 2 or higher (with tier 3 giving a bonus to
this). You can do this readily via just a sharp weapon, because having a
mangled limb causes the wound to turn into a bone wound. Technically,
this is meant to be less likely as the effective damage for this wound
is halved. But the wound bonus from having a flesh wound was almost
always significant enough to kick your new bone wound up to a tier 3.
In other words; its not surprising that you saw so many beheadings,
because the system wanted to behead you as fast as it possibly can
thanks to all these escalating values.
Wound armor was only applied as a flat reduction on the roll. The
average for wound armor was 10. After receiving a single wound, you can
expect wound rolls to reach upwards of 100, even if the actual damage
roll was not particularly high, due to wound stacking bonuses form being
wounded.
This meant that wounds, if they happened, came thick and fast after the
first, regardless of what your protection might be to wounds. It was
just a matter of getting past the initial bump.
This is why effects that forced wounds were so powerful. They basically
made a given limb more prone to taking a wound without having to deal
with the protection problem first.
Finally, this is just a broad flaw with the system that is not its
fault. It is actually a problem that isn't a problem. Most people in the
game are not wearing helmets that protect their head. So most people are
going to suffer from a higher proclivity of being wounded if people are
aiming for the head. There is this...kind of cargo cult belief that
aiming for the head means you do more damage, or can stun someone if
you're lucky or what have you. It's entirely nonsense, but it has a
grain of truth in that people rarely wear, or even have access too,
headwear that provides wound protection or any protection at all. People
have jumpsuits, which are universally wound protected, but that isn't
true of the head. Look, the point is, they're not aiming at the head
because it is usually less armored, its for other reasons but it just so
happens to become true due to wounds and how wounds roll their type.
To soften this issue, I've decided to treat wound resistance as armor
until the limb suffers a tier 3 wound. This way, hits to the head MAY
not necessarily escalate to tier 3 instantly as they would on live even
from relatively low power weapons. Some weapons have very low force, but
have extreme bare wound bonuses. This should be less likely after this
change. I doubt this will necessarily make high damage high wound
weapons like energy swords any less prone to cutting you clean open, but
it might thanks to the reduction to contributed damage to the injury
roll. The system is now _a bit more random_.
🆑
balance: Wounds do not make you as vulnerable to suffering wounds of all
types as before. Instead, wounds make you more vulnerable to suffering
worse versions of themselves as a priority.
balance: Wound armor is now more impactful when protecting you from
wounds when you have already been wounded.
balance: Your head and chest are more difficult to wound until they have
been mangled; either from suffering from a weeping avulsion or a
hairline fracture.
code: Changed the variable for bare_wound_bonus to exposed_wound_bonus
to better explain what that variable is doing.
/🆑
---------
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
## About The Pull Request
This is a big one so please bear with me, wounds are complicated
### Max Potential Wound Rolls
We've decreased the max contributed damage to wound rolls from 35 to 25.
This results, after the exponent, a max possible wound roll of 1 to 91
before any modifiers (assuming the attack, after armor, is 25 or above).
The minimum value to wound is still 5.
### Wound Escalation Penalties
Most wounds were contributing significant numbers per wound type to the
potential for a new wound to occur. Getting wounded once meant you were
getting wound a lot, but actually getting past that first wounding may
be the tricky part.
We have significantly reigned in the wound penalty that having a wound
contributes, and instead utilize the series wound penalty to allow same
type wounds to escalate themselves faster as a priority. Having wounds
still makes you more wound vulnerable, just not to such an extreme
degree.
The priority here for what wounds matter most for contributing to
overall wounding vulnerability is ``Infected BURNS > BURNS >
SLASH|PIERCE > BLUNT.``
### Wound Armor
Wound armor, unlike all other kinds of armor, was used as a additive
value to the wound roll modifiers rather than a multiplicative value.
We have reworked how wound armor is determined by changing how wound
modifiers are calculated.
Firstly, we're passing our entire injury roll into the
``check_woundings_mod()`` proc, as we're not treating this as a proc
that just adds values anymore.
Secondly, bare wound bonus only applies if there is no potential wound
protection from any source, as expected. But it comes last in the
calculations.
Thirdly, wound protection is applied to the injury roll last, after
wound bonuses from the attack, wound bonuses from other wounds and wound
bonuses from a disabled limb are applied. This does not include serial
wound bonuses, which are determined outside of this proc.
Wound protection comes from two sources. Clothing and limb wound
resistance. Your chest and head have an amount of wound resistance so
long as they are not mangled in any fashion. Being mangled means having
either a hairline fracture or a weeping avulsion wound.
Wound protection reduces the final injury roll by a percentage. Say our
roll is 50, and we have effectively 50% wound protection. The final roll
would be 25.
### ~~Wound Armor on Clothing~~ Reverted
~~Most clothing have had their wound armor values changed. As a loose
rule, I used the highest of melee or bomb armor, except where that value
was 100, in which case I used the lowest instead. I'm basing this
decision on how embeds are calculated, which is attack type agnostic.~~
~~Some armor have inconsistent values because they are alternative
armors to an existing armor type or are hyperspecialized armor.
Ablative, bulletproof and security vests all share a value of 35,
despite the former two not having decent melee or bomb armor.~~
~~Some clothing missing wound armor that should have had them now have
wound armor.~~
~~This may need a bit of scrutiny in case one or two seem weirdly high.
Some have maybe become too low. Its a bit hard to say.~~
### The ``bare_wound_bonus`` variable
I changed it to ``exposed_wound_bonus`` to better represent when it
applies. You can be naked and still not be affected by this bonus if the
limb has wound resistance.
## Why It's Good For The Game
I'm not promising anything with this PR, but this is an attempt to
sanity check the values on wounds so that we're not seeing what the data
that determined the removal of beheading presented. An extreme
over-representation of tier 3 wounds. ~~And, from that, maybe I can
argue for beheadings coming back. That's my goal. I think beheadings
happened so much because the numbers were in need of work.~~ Well okay I
just wanna make wounds a bit more workable actually more than I want
beheadings.
Why is it that tier 3 wounds were so over-represented? Because wounds
will often force more severe wounds of other types by merit of any
wounds existing at all on a limb. Having **_a_** wound makes you more
wound prone for any kind of wound, and not just making you more likely
to suffer a more severe type of the same wound.
The threshold mechanic was intended to simulate making a wound worse,
but oddly just made a limb broadly more prone to getting worse from any
kind of attack to such a degree that future wound rolls of different
types were often going to start at the threshold necessary to be a tier
3 wound.
Dismemberment, mind you, requires you to suffer a flesh wound while you
have a bone wound of tier 2 or higher (with tier 3 giving a bonus to
this). You can do this readily via just a sharp weapon, because having a
mangled limb causes the wound to turn into a bone wound. Technically,
this is meant to be less likely as the effective damage for this wound
is halved. But the wound bonus from having a flesh wound was almost
always significant enough to kick your new bone wound up to a tier 3.
In other words; its not surprising that you saw so many beheadings,
because the system wanted to behead you as fast as it possibly can
thanks to all these escalating values.
Wound armor was only applied as a flat reduction on the roll. The
average for wound armor was 10. After receiving a single wound, you can
expect wound rolls to reach upwards of 100, even if the actual damage
roll was not particularly high, due to wound stacking bonuses form being
wounded.
This meant that wounds, if they happened, came thick and fast after the
first, regardless of what your protection might be to wounds. It was
just a matter of getting past the initial bump.
This is why effects that forced wounds were so powerful. They basically
made a given limb more prone to taking a wound without having to deal
with the protection problem first.
Finally, this is just a broad flaw with the system that is not its
fault. It is actually a problem that isn't a problem. Most people in the
game are not wearing helmets that protect their head. So most people are
going to suffer from a higher proclivity of being wounded if people are
aiming for the head. There is this...kind of cargo cult belief that
aiming for the head means you do more damage, or can stun someone if
you're lucky or what have you. It's entirely nonsense, but it has a
grain of truth in that people rarely wear, or even have access too,
headwear that provides wound protection or any protection at all. People
have jumpsuits, which are universally wound protected, but that isn't
true of the head. Look, the point is, they're not aiming at the head
because it is usually less armored, its for other reasons but it just so
happens to become true due to wounds and how wounds roll their type.
To soften this issue, I've decided to treat wound resistance as armor
until the limb suffers a tier 3 wound. This way, hits to the head MAY
not necessarily escalate to tier 3 instantly as they would on live even
from relatively low power weapons. Some weapons have very low force, but
have extreme bare wound bonuses. This should be less likely after this
change. I doubt this will necessarily make high damage high wound
weapons like energy swords any less prone to cutting you clean open, but
it might thanks to the reduction to contributed damage to the injury
roll. The system is now _a bit more random_.
## Changelog
🆑
balance: Wounds do not make you as vulnerable to suffering wounds of all
types as before. Instead, wounds make you more vulnerable to suffering
worse versions of themselves as a priority.
balance: Wound armor is now more impactful when protecting you from
wounds when you have already been wounded.
balance: Your head and chest are more difficult to wound until they have
been mangled; either from suffering from a weeping avulsion or a
hairline fracture.
code: Changed the variable for bare_wound_bonus to exposed_wound_bonus
to better explain what that variable is doing.
/🆑
---------
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
## About The Pull Request
So
A) Modifying traits pretty self explanatory was a missing check
B) imo given the type of data that can be seen in vv this shouldnt be
exposed to literally anyone with an admin datum especially considering
actually showing it to someone else and editing it is R_admin and
r_varedit
the giant diff is just indentation change
Showing vv to other players is unaffected by this
## Changelog
🆑
fix: fixed some vv issues
/🆑
---------
Co-authored-by: TiviPlus <572233640+TiviPlus@users.noreply.com>
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
## About The Pull Request
So
A) Modifying traits pretty self explanatory was a missing check
B) imo given the type of data that can be seen in vv this shouldnt be
exposed to literally anyone with an admin datum especially considering
actually showing it to someone else and editing it is R_admin and
r_varedit
the giant diff is just indentation change
Showing vv to other players is unaffected by this
## Changelog
🆑
fix: fixed some vv issues
/🆑
---------
Co-authored-by: TiviPlus <572233640+TiviPlus@users.noreply.com>
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
## About The Pull Request
Title. If compiled on 515 the game screen will be black
## Why It's Good For The Game
There is no reason for it to exist if connecting from 515 is not allowed
## About The Pull Request
various uis (tgui-say, vv, player panel, anything using
`/datum/browser`) would not correct for dpi. they now do
we also have a preference to allow you to have smaller windows that are
zoomed out, instead of larger windows that are not zoomed
#### of note, this does require a small change to the usage of css
viewport units, like `vh` and `vw`. they need to be fed through the
`vp(100vw)` function first. there was only one such unit in the codebase
on 4k monitor with 200% scaling:
fixed (pref on default)
pref disabled
## Why It's Good For The Game
516 fucked with uis again and this unfucks them a bit
## Changelog
🆑
qol: there's a new UI preference called UI scale which allows people
that use windows scaling to have their UIs original size with the
contents zoomed out, instead of the default, which is the UIs being
larger with the contents "normal" size
fix: various UIs did not respect windows scaling, they now do
/🆑
---------
Co-authored-by: harryob <55142896+harryob@users.noreply.github.com>
## About The Pull Request
As the title says.
`init_order` is no more, subsystems ordering now depends on their
declared dependencies.
Subsystems can now declare which other subsystems need to init before
them using a list and the subsystem's typepath
I.e.
```dm
dependencies = list(
/datum/controller/subsystem/atoms,
/datum/controller/subsystem/mapping
)
```
The reverse can also be done, if a subsystem must initialize after your
own:
```dm
dependents = list(
/datum/controller/subsystem/atoms
)
```
Cyclical dependencies are not allowed and will throw an error on
initialization if one is found.
There's also a debug tool to visualize the dependency graph, although
it's a bit basic:
Subsystem load ordering can still be controlled using `init_stage`, some
subsystems use this in cases where they must initialize first or last
regardless of dependencies. An error will be thrown if a subsystem has
an `init_stage` before one of their dependencies.
## Why It's Good For The Game
Makes dealing with subsystem dependencies easier, and reduces the chance
of making a dependency error when needing to shift around subsystem
inits.
## Changelog
🆑
refactor: Refactored subsystem initialization
/🆑
## About The Pull Request
Title. If compiled on 515 the game screen will be black
## Why It's Good For The Game
There is no reason for it to exist if connecting from 515 is not allowed
## About The Pull Request
various uis (tgui-say, vv, player panel, anything using
`/datum/browser`) would not correct for dpi. they now do
we also have a preference to allow you to have smaller windows that are
zoomed out, instead of larger windows that are not zoomed
#### of note, this does require a small change to the usage of css
viewport units, like `vh` and `vw`. they need to be fed through the
`vp(100vw)` function first. there was only one such unit in the codebase
on 4k monitor with 200% scaling:
fixed (pref on default)
pref disabled
## Why It's Good For The Game
516 fucked with uis again and this unfucks them a bit
## Changelog
🆑
qol: there's a new UI preference called UI scale which allows people
that use windows scaling to have their UIs original size with the
contents zoomed out, instead of the default, which is the UIs being
larger with the contents "normal" size
fix: various UIs did not respect windows scaling, they now do
/🆑
---------
Co-authored-by: harryob <55142896+harryob@users.noreply.github.com>
## About The Pull Request
As the title says.
`init_order` is no more, subsystems ordering now depends on their
declared dependencies.
Subsystems can now declare which other subsystems need to init before
them using a list and the subsystem's typepath
I.e.
```dm
dependencies = list(
/datum/controller/subsystem/atoms,
/datum/controller/subsystem/mapping
)
```
The reverse can also be done, if a subsystem must initialize after your
own:
```dm
dependents = list(
/datum/controller/subsystem/atoms
)
```
Cyclical dependencies are not allowed and will throw an error on
initialization if one is found.
There's also a debug tool to visualize the dependency graph, although
it's a bit basic:
Subsystem load ordering can still be controlled using `init_stage`, some
subsystems use this in cases where they must initialize first or last
regardless of dependencies. An error will be thrown if a subsystem has
an `init_stage` before one of their dependencies.
## Why It's Good For The Game
Makes dealing with subsystem dependencies easier, and reduces the chance
of making a dependency error when needing to shift around subsystem
inits.
## Changelog
🆑
refactor: Refactored subsystem initialization
/🆑
## About The Pull Request
This PR should fix the problem of small previews in TGUI once and for
all (I hope).
What was causing it? Because TGUI takes a long time to open, that's why
previews were generated broken (small).
On Byond 515 this problem was not so noticeable as the interfaces opened
faster, but with the release of 516 it became much worse.
Previews were generated inside a window that was not yet open, so the
scale was broken, sometimes the window would open before the preview was
done and sent, usually with small interfaces, or when reopening.
I'm not very good at working with signals, and to tell the truth this is
my second experience with them, so I hope I did it right.
## Why It's Good For The Game
No more small map previews
<details> <summary> Video </summary>
https://github.com/user-attachments/assets/834f3820-cc6a-4f65-90e5-d6bb2a118bcf
</details>
## Changelog
🆑
fix: Fixed small character preview, color matrix preview, mech preview,
and other previews with uses ByondUI map
/🆑
---------
Co-authored-by: Gaxeer <44334376+Gaxeer@users.noreply.github.com>
## About The Pull Request
This PR should fix the problem of small previews in TGUI once and for
all (I hope).
What was causing it? Because TGUI takes a long time to open, that's why
previews were generated broken (small).
On Byond 515 this problem was not so noticeable as the interfaces opened
faster, but with the release of 516 it became much worse.
Previews were generated inside a window that was not yet open, so the
scale was broken, sometimes the window would open before the preview was
done and sent, usually with small interfaces, or when reopening.
I'm not very good at working with signals, and to tell the truth this is
my second experience with them, so I hope I did it right.
## Why It's Good For The Game
No more small map previews
<details> <summary> Video </summary>
https://github.com/user-attachments/assets/834f3820-cc6a-4f65-90e5-d6bb2a118bcf
</details>
## Changelog
🆑
fix: Fixed small character preview, color matrix preview, mech preview,
and other previews with uses ByondUI map
/🆑
---------
Co-authored-by: Gaxeer <44334376+Gaxeer@users.noreply.github.com>
## About The Pull Request
Makes wrapper procs to support working with bitflags as defined "things"
rather then EXCLUSIVELY numbers, mostly for getting random flags.
I've ~~also added a unit test to prevent bitfields from being double
defined~~ stolen some code form moth to make double definitions here a
compile error.
This does rely on people actually using the bitfield lists, essentially
upgrading them from breaking just admin debug to POTENTIALLY breaking
game logic (slightly). Would like input on this @tgstation/commit-access
## Why It's Good For The Game
More tools for feature coders to play with, more sane code
## About The Pull Request
just cleaning out the cobwebs
Mixed usr/src, using set on a proc /datum/o
casting atom but taking datums
## Changelog
🆑
code: cleaned up some mass var edit code
/🆑
---------
Co-authored-by: TiviPlus <572233640+TiviPlus@users.noreply.com>
## About The Pull Request
So, some admin verbs/tools that used tguis, i.e edit/debug planes, were
available to admins with +DEBUG... but the ui_state used
`GLOB.admin_state`, which checks for +ADMIN - meaning that if they
_only_ had +DEBUG, they would have the verb... but it would do nothing
when they used it.
I've refactored `GLOB.admin_state`, `GLOB.debug_state`, and
`GLOB.fun_state` into a merged `/datum/ui_state/admin_state`, with a var
for which specific permissions are being checked for.
You now use the `ADMIN_STATE(perms)` macro to get the UI state for those
specific perms, i.e `admin_state(R_ADMIN)` or `admin_state(R_DEBUG)`,
and the resulting UI state will check for _those specific perms_.
These are initialized and cached in `GLOB.admin_states` (which should
never be directly accessed).
So, I've went thru every single usage of `GLOB.admin_state`,
`GLOB.fun_state`, and `GLOB.debug_state`, and made them all use
`ADMIN_STATE()` with the actual permission flags needed to use said UI
in the first place.
## Why It's Good For The Game
Kinda dumb for specific admin permissions to be granted verbs that don't
let them use it anyways.
## Changelog
🆑
admin: Certain UI-based tools (plane debugger, filter editor, etc) that
were given to admins with only +VAREDIT or +DEBUG, but refused to open
without +ADMIN, now actually work for admins that have the needed
permission.
/🆑
## About The Pull Request
fix color picket problems introduced by the upstream, specifically the
blooper and mutantparts color picker
## Why It's Good For The Game
bug fix gud
## Proof Of Testing
yes
<details>
<summary>Screenshots/Videos</summary>
</details>
## Changelog
🆑
fix: fix color picket problems introduced by the upstream, specifically
the blooper and mutantparts color picker
/🆑
---------
Co-authored-by: Waterpig <49160555+Majkl-J@users.noreply.github.com>
## About The Pull Request
just cleaning out the cobwebs
Mixed usr/src, using set on a proc /datum/o
casting atom but taking datums
## Changelog
🆑
code: cleaned up some mass var edit code
/🆑
---------
Co-authored-by: TiviPlus <572233640+TiviPlus@users.noreply.com>
## About The Pull Request
So, some admin verbs/tools that used tguis, i.e edit/debug planes, were
available to admins with +DEBUG... but the ui_state used
`GLOB.admin_state`, which checks for +ADMIN - meaning that if they
_only_ had +DEBUG, they would have the verb... but it would do nothing
when they used it.
I've refactored `GLOB.admin_state`, `GLOB.debug_state`, and
`GLOB.fun_state` into a merged `/datum/ui_state/admin_state`, with a var
for which specific permissions are being checked for.
You now use the `ADMIN_STATE(perms)` macro to get the UI state for those
specific perms, i.e `admin_state(R_ADMIN)` or `admin_state(R_DEBUG)`,
and the resulting UI state will check for _those specific perms_.
These are initialized and cached in `GLOB.admin_states` (which should
never be directly accessed).
So, I've went thru every single usage of `GLOB.admin_state`,
`GLOB.fun_state`, and `GLOB.debug_state`, and made them all use
`ADMIN_STATE()` with the actual permission flags needed to use said UI
in the first place.
## Why It's Good For The Game
Kinda dumb for specific admin permissions to be granted verbs that don't
let them use it anyways.
## Changelog
🆑
admin: Certain UI-based tools (plane debugger, filter editor, etc) that
were given to admins with only +VAREDIT or +DEBUG, but refused to open
without +ADMIN, now actually work for admins that have the needed
permission.
/🆑
## About The Pull Request
This PR reimplements https://github.com/tgstation/tgstation/pull/71538
atop `master`. Quoting the original PR:
> Every `icon_exists()` call will cache the entire file. Past me didn't
realise _why_ file opts were so expensive, but I do now. This is
immeasurably slower on a single call, and _significantly_ faster on
subsequent calls to the same file.
I attempted to handle some of the review comments that were posted
there, by splitting screaming functionality into its own proc.
* `if(icon_state in icon_states(file))` and `if(!(icon_state in
icon_states(file)))` were refactored to use `icon_exists(file,
icon_state)`.
* Where screaming was seemingly wanted (and where there wasn't a more
descriptive error inside the `if` block), I refactored them to use
`icon_exists_or_scream(file, icon_state)`
* The exception to the above was under
`/datum/unit_test/turf_icons/Run()` and
`/datum/unit_test/worn_icons/Run()`, where `icon_states()` was being
passed a mode flag. Given that this is only used in unit tests (where
performance isn't a priority), I opted to leave these be.
Additionally, I revised the documentation comment for
`/proc/icon_exists()`, as I felt it was a bit vague currently.
## Why It's Good For The Game
https://youtu.be/Z9G1Mf6TZRs
## Changelog
No player-facing changes (hopefully).
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
## About The Pull Request
Was just scrolling through the Paradise github since they seem to have
more work done for 516 to see if there's anything I can port over, found
this and thought why not.
Ports parts of https://github.com/ParadiseSS13/Paradise/pull/25105
Specifically, updaing all hrefs to use the internal ``byond://``, and
adding it to grep.
## Why It's Good For The Game
More work towards 516.
## Changelog
Nothing player-facing.
## About The Pull Request
Adds VV header for items, letting quick modification of a few of an
item's combat values..
## Why It's Good For The Game
In testing, I find I tweak these values commonly, to test how effective
an item is vs armor, or how strong a new item should be, etc etc. So
having quick access to these might be cool
I thought about adding a few more like throwforce but I didn't want to
clutter it too much
## Changelog
🆑 Melbert
admin: Items now have a header in VV allowing for quicker editing of
combat properties
/🆑
shayoki