## About The Pull Request
It was possible for explosions to process throwing FIRST, then the
actual explosion. That's dumb, let's not do that.
Fixes a bug with SS explosions, it used SSair defines for its currentrun
default, which because of misordered defines lead to it running throwing
first for ONLY the first explosion. DUMB.
Changed how objects pick where they land. instead of using get_dir we
get the angle to the center, then invert it. Should lead to a nicer
picture
Unanchors broken disposal pipes so they'll get flung around Ups the
throw range for explosions. This needs more tweaking someday, but this
is ok for now
## Why It's Good For The Game
Throwing will happen consistently now, less fuckin floating shit sitting
in spac
## About The Pull Request
I literally can't focus on anything nowadays, so I just did this to
break a never-ending chain of distress. Anyways, regal rats! These
fellas are mostly player controlled, but did have _some_ AI capabilities
(mainly tied to their actions), so that was incorporated too. Everything
should work as-expected (as well as look a shitload cleaner).
Instead of doing weird and awful conditional signals being sent out, I
made the `COMSIG_REGAL_RAT_INTERACT` (not the actual name) have a return
value so we can always rely on that working whenever we have that signal
registered on something we attack. I also cleaned up pretty much every
proc related to regal rats, gave them AIs to reflect their kingly nature
(and action capabilities (as well as move the action to
`mob_cooldown`)).
Since I thought they needed it, Regal Rats now get a special moniker!
This is stuff like "the Big Cheese" and what-not, like actual regents in
history. That's nice.
## Why It's Good For The Game
Two more off the list. Much better code to read. Way smarter rats with
spawning their army as part of a retaliatory assault (war). More sovl
with better regal rat names. The list goes on.
## Changelog
🆑
refactor: Regal Rats have been refactored into basic mobs. They should
be a bit smarter and retain their docility (until attacked, in which
case you should prepare to get rekt by summoned rats), and properly flee
when they can instead of just sit there as you beat them to death. The
framework for them interacting with stuff (i.e. opening doors while
slobbering on food) is a bit more unified too, now. They also have
cooler names too!
/🆑
FYI: Beyond a few code touchups, I haven't touched the actions at all. I
do not believe myself to be enthusiastic about fixing anything involving
the actions code as of this moment so that this PR is more overbloated
unless it's unbelievably stupid or easy to fix.
Whatever you do, if it warrants the use of something like
`handle_atom_del`, chances are `Exited` can do it better, as most of
these cases involve movables that shouldn't be moved out of their loc
(`Destroy` forcefully moves movables to nullspace) without calling
specific procs, and for the remaining few, `handle_atom_del` doesn't
even cover the eventuality of a movable being deleted outside the source
atom, so it's quite garbage.
Beside, I feel confident in saying `handle_atom_del()` is older than the
DCS, an echo on the workarounds done at the time.
## About The Pull Request
Replaces a ton of `turn(dir, 180)` calls with the aforementioned macro.
## Why It's Good For The Game
Afaik, `REVERSE_DIR` was coded to be faster than the classic `turn(dir,
180)` call, being a simple set of binary operations. To sum it up, micro
optimization.
## Changelog
N/A
## About The Pull Request
New malf AI upgrade
Remote safety overrides: Mid-cost, Mid-supply. Allows the AI to remotely
emag things it can see and can access.
1. Very useful for psychological warfare (Emagging APCs to throw the
crew off their trail)
2. Logically makes sense - why, of all things, can the AI not emag
anything when it's fundumentally integrated with the station's
electronics?
3. Generally speaking can only access things that make sense for it to
access - it cannot emag ethereals, sadly
In order for this to work, emag_act now returns a boolean, designating
if the emag had any effect.
While I was in there, I also added args to every single emag_act I could
find and added far more feedback/converted a lot of things to balloon
alerts to allow the AI to see if its emag had any effect.
## Why It's Good For The Game
It just makes sense that the AI, the most electronically-sensitive
entity in the game, would be able to emag things. Plus, more options
given to malf that aren't strictly MURDER KILL MURDER are always a plus,
especially if they allow for fancier plays.
## Changelog
🆑
add: New malf ability: Remote safety overrides. Allows the AI to
remotely emag things it has access to.
code: emag_act() now returns a boolean designating it's success in
emagging
code: All instances of emag_act() now have the proper arguments
qol: Most usecases of emagging now have some kind of feedback, and
existing feedback has been sanity checked and converted to balloon
alerts.
/🆑
## About The Pull Request
Further continous organizing and cleaning the Icons folder. There are
still some minior nitpicks left to do, but I reached my daily sanity
expenses limit again, and the faster these get in the less issues for
both me and others later. Also cleans some mess I caused by my blindness
last PR.
## Why It's Good For The Game
Saner spriters = better sprites
## About The Pull Request
This adds a new element for movables that grants turfs they're in
traits, changes lava and the chasm component to check for traits
instead, ditto for turf slowdown. It also implements another trait that
prevents wet floor from slipping people, as well as some other changes
(feel free to opine on them really):
- Tables and conveyor belts now stop turf slowdown, much like catwalks,
as I imagine people walking on them are not really touching the floor.
(I'd include protection against lava too... until they melt, but that'd
mean finding a way to have these objects burn in the first place, and
lava code is still stupid despite a years old refactor I did)
- Tables also stop slippery turfs from slipping (bananas, soaps etc.
still apply). I wish there were a way to make some objects slippery by
coating them in water vapor or splashing water/lube, but that's outside
the scope of this PR.
- Fixed an edge case in which a mob standing on a lava turf would be
left permanently visually on fire if the lava is changed to another kind
of turf.
- Removed unused code from stone tiles.
I'm going to include these traits in that global list for admin-added
traits... tomorrow perhaps. 💤
## Why It's Good For The Game
Replacing some hard-coded mechanics with easier to use traits and an
element, which I also need for the submerge element PR.
## Changelog
🆑
refactor: Replaced hardcoded "safeties" for lava, chasms and ignoring
turf slowdowns on catwalks with traits.
balance: much like catwalks, tables and conveyors also disable turf
slowdowns.
balance: slippery turfs won't slip you when walking on a table.
fix: Fixed an edge case in which a mob standing on a lava turf would be
left visually but permanently on fire if the lava is changed to another
kind of turf.
/🆑
## About The Pull Request
[Removes the pretense of relative multiz
levels](0293fdc2bd)
Our multiz system does not support having a z level that is only
connected one way, or which goes down backwards or anything like that.
That's a fiction of the trait system, the actual backend has never
really supported this.
This pr removes the assumptions we were making backend around this, and
uses that to save cpu time.
I am also converting multiz_levels from an assoc list to a pure one,
which saves significantly on access times and cleans up the code
somewhat.
Also I'm making the get_below/get_above procs into macros, for the sake
of cpu time.
[Converts the starlight disease to use BYOND's directional defines
instead of our
own](7d698f02d9)
To some extent spurred on by
https://github.com/DaedalusDock/daedalusdock/pull/298, tho it was known
before
## Why It's Good For The Game
Faster multiz code, faster init, etc etc etc
## About The Pull Request
Adds a footstep_override element to the game, that allows object to do
what it reads on the tin.
Only conveyor belts, catwalks and tables use it for now.
## Why It's Good For The Game
Consistency. If you're walking on a table or catwalk, the sound of shoes
trudging on snow or lava shouldn't be played. Tested.
## Changelog
🆑
sound: Walking on conveyors, catwalks and tables no longer plays the
footstep sound of the turf. They have theirs.
/🆑
Remove welder fuel usage from all actions except attacking and leaving
it on
most welder tasks require a minimum of 1u of fuel, some longer tasks
require a minimum of 2 or 3u welders now drain 1u every 5 seconds
they're active
## About The Pull Request
Prior to this PR welder fuel usage was random, a lot of tasks didn't use
any welder fuel and welders were basically near infinite so long as you
didn't use them for combat, it took 26 seconds of activity to drain 1u
of fuel, that means an emergency welder alone could run for 5 minutes
straight before needing a refuel
After this PR all welders will drain 1u every 5 seconds instead of every
26 seconds, but welding objects won't require extra fuel anymore, making
the fuel usage much more consistent.
resolves#55018
## Why It's Good For The Game
Actually makes fuel tanks useful and relevant without making it
obnoxious to do repetitive quick tasks like turn rods into plates,
there's actually a reason to upgrade off the emergency welder now since
it lasts 50 seconds rather than 5 minutes
## Changelog
🆑
qol: Welders now have a more consistent fuel usage
/🆑
## About The Pull Request
[A common problem with explosions is an overabundance of
sleeping](6499077a09)
In an attempt to solve this issue, let's not continue to sleep and do
work in door closing if the door is already deleted
(This is caused by firelocks activating due to other adjacent objects
deleting, triggering an atmos update, and closing the firelocks before
they get bombed. I don't have a elegant way of resolving that core
problem, so let's just minimize the impact)
[Nukes a stupid sleep loop in airlock
code](5b16360520)
When an airlock was depowered, it would enter a sleep loop, decrementing
its delay by 1 second every well, one second, so long as it had the
right wires flipped
This is very stupid
Instead, let's use signals off wire changes and a combo of timer and
remaining time var to do this with JUST a timer
Most of the changes here are just swapping over wires to a setter to
make signal registration work\
## Why It's Good For The Game
Less sleeping around explosions means less dropped ticks after a bomb
goes off. Good just in general
Also this excises dumb boomer code and adds some hooks for other devs to
use (we should use wires more man)
## About The Pull Request
Removes some boilerplate from transforming component, uses traits in a
similar way to the two-handed component
Also fixes#74955 (If it's still broken?)
## Why It's Good For The Game
Makes it a bit cleaner to work with. Cause I wanna do something with
this in the future maybe.
## Changelog
🆑 Melbert
fix: Fixed e-cutlasses and bananium swords having invisible inhands
code: Removed boilerplate from transforming component
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
fixes#69837
## Why It's Good For The Game
accurate combat logs
## Changelog
🆑
admin: fix combat logs for tabling and disposal shoving
/🆑
## About The Pull Request
Signals were initially only usable with component listeners, which while
no longer the case has lead to outdated documentation, names, and a
similar location in code.
This pr pulls the two apart. Partially because mso thinks we should, but
also because they really aren't directly linked anymore, and having them
in this midstate just confuses people.
[Renames comp_lookup to listen_lookup, since that's what it
does](102b79694f)
[Moves signal procs over to their own
file](33d07d01fd)
[Renames the PREQDELETING and QDELETING comsigs to drop the parent bit
since they can hook to more then just comps
now](335ea4ad08)
[Does something similar to the attackby comsigs (PARENT ->
ATOM)](210e57051d)
[And finally passes over the examine
signals](65917658fb)
## Why It's Good For The Game
Code makes more sense, things are better teased apart, s just good imo
## Changelog
🆑
refactor: Pulled apart the last vestiges of names/docs directly linking
signals to components
/🆑
## About The Pull Request
Re-read the title. I had to add a dcs signal to do this.
## Why It's Good For The Game
Empowering trash bins for the sake of consistency.
## Changelog
🆑
balance: You can now sweep garbage into open trash bins (the crate
subtype).
/🆑
## About The Pull Request
Adds range per setting on disposals outlets, meaning packages (or
weapons) can be launched further and, at it's highest settings,
embed/hurt or break bones. Also, makes the emag effect automatically
switch to the highest speed/range and doesn't allow it to go below it.
## Why It's Good For The Game
Cargo techs have very few antaggy things under their jurisdiction and
leaves few options. With disposals becoming more commonly used as a
fantastic option for delivery, adding more meaningful ways to sabotage
it would offer more options. Also, this opens up lots of opportunities
for traps.
## Changelog
🆑
add: Made disposals outlets launch with more range depending on the
setting used
add: Made disposals outlets emag effect irreversible without
reconstruction
/🆑
---------
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
Ladies, Gentlemen, Gamers. You're probably wondering why I've called you
all here (through the automatic reviewer request system). So, mineral
balance! Mineral balance is less a balance and more of a nervous white
dude juggling spinning plates on a high-wire on his first day. The fact
it hasn't failed after going on this long is a miracle in and of itself.
This PR does not change mineral balance. What this does is moves over
every individual cost, both in crafting recipes attached to an object
over to a define based system. We have 3 defines:
`sheet_material_amount=2000` . Stock standard mineral sheet. This being
our central mineral unit, this is used for all costs 2000+.
`half_sheet_material_amount=1000` . Same as above, but using iron rods
as our inbetween for costs of 1000-1999.
`small_material_amount=100` . This hits 1-999. This covers... a
startlingly large amount of the codebase. It's feast or famine out here
in terms of mineral costs as a result, items are either sheets upon
sheets, or some fraction of small mats.
Shout out to riot darts for being the worst material cost in the game. I
will not elaborate.
Regardless, this has no functional change, but it sets the groundwork
for making future changes to material costs much, MUCH easier, and moves
over to a single, standardized set of units to help enforce coding
standards on new items, and will bring up lots of uncomfortable balance
questions down the line.
For now though, this serves as some rough boundaries on how items costs
are related, and will make adjusting these values easier going forward.
Except for foam darts.
I did round up foam darts.
Adjusting mineral balance on the macro scale will be as simple as
changing the aforementioned mineral defines, where the alternative is a
rats nest of magic number defines. ~~No seriously, 11.25 iron for a foam
dart are you kidding me what is the POINT WHY NOT JUST MAKE IT 11~~
Items individual numbers have not been adjusted yet, but we can
standardize how the conversation can be held and actually GET SOMEWHERE
on material balance as opposed to throwing our hands up or ignoring it
for another 10 years.
This tracks the seconds per tick of a subsystem, however note that it is
not completely accurate, as subsystems can be delayed, however it's
useful to have this number as a multiplier or ratio, so that if in
future someone changes the subsystem wait time code correctly adjusts
how fast it applies effects
regexes used
git grep --files-with-matches --name-only 'DT_PROB' | xargs -l sed -i
's/DT_PROB/SPT_PROB/g'
git grep --files-with-matches --name-only 'delta_time' | xargs -l sed -i
's/delta_time/seconds_per_tick/g'
# MAINTAINER - USE THE BUTTON THAT SAYS "MERGE MASTER" THEN SET THE PR
TO AUTO-MERGE! IT'S MUCH EASIER FOR ME TO FIX THINGS BEFORE THEY SKEW
RATHER THAN AFTER THE FACT.
## About The Pull Request
Hey there,
This took a while to do, but here's the gist:
Python file now regexes every file in `/code` except for those that have
some valid reason to be tacking on more global defines. Some of those
reasons are simply just that I don't have the time right now (doing what
you see in this PR took a few hours) to refactor and parse what should
belong and what should be thrown out. For the time being though, this PR
will at least _halt_ people making the mistake of not `#undef`ing any
files they `#define` "locally", or within the scope of a file.
Most people forget to do this and this leads to a lot of mess later on
due to how many variables can be unmanaged on the global level. I've
made this mistake, you've made this mistake, it's a common thing. Let's
automatically check for it so it can be fixed no-stress.
Scenarios this PR corrects:
* Forgetting to undef a define but undeffing others.
* Not undeffing any defines in your file.
* Earmarking a define as a "file local" define, but not defining it.
* Having a define be a "file local" define, but having it be used
elsewhere.
* Having a "local" define not even be in the file that it only shows up
in.
* Having a completely unused define*
(* I kept some of these because they seemed important... Others were
junked.)
## Why It's Good For The Game
If you wanna use it across multiple files, no reason to not make it a
global define (maybe there's a few reasons but let's assume that this is
the 95% case).
Let me know if you don't like how I re-arranged some of the defines and
how you'd rather see it be implemented, and I'd be happy to do that.
This was mostly just "eh does it need it or not" sorta stuff.
I used a pretty cool way to detect if we should use the standardized
GitHub "error" output, you can see the results of that here
https://github.com/san7890/bruhstation/actions/runs/4549766579/jobs/8022186846#step:7:792
## Changelog
Nothing that really concerns players.
(I fixed up all this stuff using vscode, no regexes beyond what you see
in the python script. sorry downstreams)
## About The Pull Request
I'm a bit sad about the state of trashbags.
They're very clunky to use, so they almost never get touched. S
depressing. Let's try and fix that.
Let's make em fit in the belt slot (again), but as a tradeoff we'll make
it harder to pull one thing from your bag.
We'll give it a say, 1.5 second delay, so you can't quickdraw from em.
If you try and dump them out into something else, we'll throw any
spillover on the ground below you
I'm also doing some general code cleanup here. Making procs more
readable, vars more direct, removing some old legacy stuff.
I've added a remove_single proc to hook into via subtype, which takes a
mob as input. this has required placing extra requirement on some helper
procs, but fortunately it's not something they're unable to meet.
My hope is this will make garbage bags usable without being stupid.
## Why It's Good For The Game
I don't see these get used at all, cause they're a pain to carry around.
They got gimped because people were using them as infinite storage for
shotgun shells and other small items.
I've made using them for this sort of thing hard and slow, so I think we
oughta be fine. If not I'll do some more touching, maybe give the
autodrop a delay.
## Changelog
🆑
balance: The janitor's trashbag now fits on his belt. In exchange,
taking something out of it sends a visible message, and has a delay.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
This, as the title suggests, fixes some wrapping paper bugs.
First, wrapping paper coloration has been rebound to Alt+click, so the
control doesn't conflict with extracting wrapping paper from a roll,
which is right click. Originally, both of them were on right click,
which caused problems.
Second, it fixes a problem with the greyscale icons on the gifts
themselves. They were showing up as the default gift icon, no matter
what color you selected, because the automatic path generation wasn't
set up properly. This fixes that.
Fixes#73800.
## Why It's Good For The Game
Bugs are bad, and we should try to fix them.
## Changelog
🆑
fix: Gifts you wrap will now display their greyscale colors as they're
supposed to.
fix: Wrapping paper color selection has been rebound to Alt+click, to
fix a bug where both wrapping paper color selection, and extracting
wrapping paper from a roll were both bound to right click.
/🆑
## About The Pull Request
Fixes#73562
Adds ignore spam and forced tag to the regal rat forcesay
## Why It's Good For The Game
Bugfix
## Changelog
🆑
fix: fixed regal rat rummaging lines sometimes getting you muted!
/🆑
This builds on what #69790 did and improved the code even further.
Notable things:
- `Topic()` is a deprecated proc in our codebase (replaced with
Javascript tgui) so it makes sense to rename `canUseTopic` to
`can_perform_action` which is more straightforward in what it does.
- Positional and named arguments have been converted into a easier to
use `action_bitflag`
- The bitflags adds some new checks you can use like: `NEED_GRAVITY |
NEED_LITERACY | NEED_LIGHT` when you want to perform an action.
- Redundant, duplicate, or dead code has been removed.
- Fixes several runtimes where `canUseTopic` was being called without a
proper target (IV drips, gibber, food processor)
- Better documentation for the proc and bitflags with examples
## About The Pull Request
This PR makes some changes to how JPS is used in movement loops, as it
was causing a variety of issues:
- Fixed some code where JPS would fail because the path is still being
made. Instead, the movement loop will now wait.
- Reduced the subsystem wait for the pathfinder subsystem from 2 seconds
to 0.1 seconds. @LemonInTheDark told me that this is better, I'll update
this with a better explanation once I squeeze it out of him :D
- Allows you to provide an initial path to the movement loop, in case
you pre-calculated one while making a plan.
## Why It's Good For The Game
Makes working with JPS a bit easier when making AI.
---------
Co-authored-by: Capybara <Capybara@CapybaraMailingServices.com>
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
This is a remake of #70242
Replaces all instances of ``do_mob`` and ``do_after_mob`` with
``do_after``.
## Why It's Good For The Game
All 3 of these are just copy pastes of eachother but some miss some
features (like do_after not checking for target loc change, which helps
towards fixing https://github.com/tgstation/tgstation/issues/66874
though it doesn't because mechs are setting ``do_after`` on the mob in
the mech) and signals only being used on ``do_after``.
## Changelog
🆑
fix: Mechs should now cancel out of drilling when they move.
/🆑
## About The Pull Request
I added a few quirks to a downstream that I feel fit well with tg so
here they are.
First up is Poster Boy, a quirk that gives you three mood altering
posters, similar to the traitor objective to hang up demoralizing
posters. You spawn with a box that has one poster that will uplift the
entire crews spirits and 2 that are unique to your department. Captain
counts for security and assistants get only neutral posters. Finally,
with a crayon or spraycan, if you are any antagonist you can make your
poster into one of the ones from the traitor objective.
example of quirk posters
Costs 4.
Finally, the characterful Throwing Arm quirk, which lets you throw
objects further (but not harder) and means you will never miss shots
into the disposals bin.
Costs 7.
previously i had a food subscription quirk here as well but i pulled it
out and plan to re-add it as a separate PR in march, where it will now
give you ingredients to cook a meal with occasionally.
## Why It's Good For The Game
Positive quirk variety is good and fun, I think that these positive
quirks are reasonable ones that offer unique things that the current
positive quirks do not.
Poster boy gives people a reason to run around and claim wall real
estate for their department and hopefully can build more solidarity in
departments, the hidden antag feature probably has uses but is just for
styling on people.
Throwing arm offers a fun character trait that probably can have some
slight uses and encourages the use of throwing weapons and tools more.
Also it is good to have a way to never miss the disposals bin. It's so
embarrassing.
## Changelog
🆑
add: Poster boy and Throwing arm positive quirks.
imageadd: added posters for poster boy quirk
/🆑
## About The Pull Request
On some maps, there is a special disposal sorting pipe, which checks if
the `tomail` var of a disposal holder. However, this has been only be
set on the parent disposal object. The delivery chute and the disposal
bin overrode this behaviour without a parent call. I have elected to
remove the two identical overrides, and move their contents to the
parent, while also swapping out the `1` to the correct sorting define of
the same value. I have also updated the disposal holder object merging
proc.
I have also autodocced proc and var definiton in the files I have
touched.
## Why It's Good For The Game
Now once again, the wrapper sorter objects will detect wrapped packages,
and on maps that support them, will be redirected to the mail outlet
chute (along with any other item in the same holder object as usual),
instead of the trash outlet chute.
## Changelog
🆑
fix: Bundles of disposal packages that contain a wrapped parcel will be
now successfully redirected by the wrapping sorters
/🆑
## About The Pull Request
closes#72348
Title
## Why It's Good For The Game
My bad
## Changelog
Heres the script I used this time if you want to
```cs
var baseDir = Environment.CurrentDirectory;
var allFiles = Directory.EnumerateFiles($@"{baseDir}\code", "*.dm", SearchOption.AllDirectories).ToList();
var known = new Dictionary<string, List<KeyValuePair<string, int>>>();
foreach (var file in allFiles)
{
var fileLines = File.ReadAllLines(file);
for (var i = 0; i < fileLines.Length; i++)
{
var line = fileLines[i];
if (line.StartsWith("/datum/armor/"))
{
var armorName = line.Replace("/datum/armor/", "").Trim();
if (!known.ContainsKey(armorName))
known[armorName] = new List<KeyValuePair<string, int>>();
var knownList = known[armorName];
knownList.Add(new KeyValuePair<string, int>(file, i));
}
}
}
Console.WriteLine($"There are {known.Sum(d => d.Value.Count)} duplicate armor datums.");
var duplicates = new Dictionary<string, List<int>>();
foreach (var (_, entries) in known)
{
var actuals = entries.Skip(1).ToList();
foreach (var actual in actuals)
{
if (!duplicates.ContainsKey(actual.Key))
duplicates[actual.Key] = new List<int>();
duplicates[actual.Key].Add(actual.Value);
}
}
Console.WriteLine($"There are {duplicates.Count} files to update.");
foreach (var (file, idxes) in duplicates)
{
var fileContents = File.ReadAllLines(file).ToList();
foreach (var idx in idxes.OrderByDescending(i => i))
{
string line;
do
{
line = fileContents[idx];
fileContents.RemoveAt(idx);
}
while (!String.IsNullOrWhiteSpace(line));
}
File.WriteAllLines(file, fileContents);
}
```
## About The Pull Request
[Saves 0.2 seconds of init time. 50% of emissive
blockers](8318b648f6)
Emissive blockers are a decent expense during init, even these, which
are the ones that update outside of initialize.
I've inlined them, removed some redundant vars and checks, reduced the
arg count, and shifted some things around. This ends up saving 200ms, or
50% of its total cost.
I also shifted mutable_appearance about a bit. it's not a massive
saving, but it is technically faster
[Prevents a few redundant appearance_updates, saves 0.8 seconds of
init](5475cd778b)
Prequisit info: update_appearance is decently expensive
It's good then to only do it if we have a reason to, right?
Me and moth were shooting the shit about just general init time, and we
came up with the idea of tracking which update_appearances actually
"worked" and which didn't.
That bit comes later, let's enjoy the fruits of that work first
First, holograms were calling update_appearance on process, for almost
no reason.
I patched the one event they don't already "react" to, and then locked
it behind a change decection if.
good for live, doesn't impact init.
Next, decals. If you add a decal to something before it inits, it'll
react to the after successful init signal.
The trouble is the same atom could have its appearance updated from this
MORE then once, since decals can be stacked on tiles, and signal
unregisters don't work once the signal is sent.
So we add a flag to track if we've had this happen to us or not, so it
only happens once.
saves 80 ms
Power! lots of things call power_change on init, often more then once.
We'll update appearance for each of those calls, even if only one is an
actual change.
That's silly, better to track what sort of power we're using for our
appearance and go off that changing
This was taking about 300ms. Really stupid
Icon smoothing. After emissive blockers were added, any change to
something's icon smoothing would lead to an update_appearance call.
Nasty shit, specially cause of walls, which don't even use emissive
blockers.
Ok then, so we'll always update appearance for movables, and will allow
turfs that are interested to hook it manually.
Not many of those anyhow
This is slightly a dev ux thing, but it saves 600ms so I think it's
worth it. Rare case anyway
Telecomms:
telecomm machines were updating appearance on process. This is to cover
for them turning on/off on process.
Better then to just check if on actually changed.
This cost adds up midgame, doesn't impact init tho
Materials:
There's this update_appearance call in material on_apply. it doesn't do
anything.
The logs will lie to you and say it does, but it's just like reapplying
emissives. It doesn't need to exist
Saves like 50ms
Canisters:
Live thing, lots of time wasted updating appearance for no reason, lets
see if we change anything first yes?
[Uses defines to wrap update_appearance for
tracking](4fa82e1c9d)
[Undoes _update_appearance changes, instead reccomends 2 regexes to
use](a8c8fec57a)
I need file and line number for my tracking, so I need to override
update_appearance calls, and also preferably not require every override
of update_appearance to handle dummy file + line args.
So instead, I created a wrapper proc that checks to see if appearanaces
match (they're unique remember, the two of the same visual appearance
will be equivalent)
The trouble is I can't intercept JUST proc calls, or JUST function
definitions with defines. it needs to be both.
So I renamed the /update_appearance proc to /_update_appearance
this way I can capture old uses, and don't need to worry about merge/dev
brain skew
~~It does mean that all update_appearance proc definitions now look
weird tho.
My profiling is leaking into dev ux. I wish I had better templating.~~
**The above is no longer being pr'd**, it's instead just recommended via
a few regexes adjacent to the define.
Smelled wrong anyhow
[Adds a setter for panel_open, so I can update_appearance on
it](cf1df8a69f)
## Why It's Good For The Game
Speed
<!-- 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
Missed putting the icon for lockboxes on the base type. Same for wrapped
crates.
<!-- 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
Seeing items is good.
Fixes#71912Fixes#71909Fixes#71905
<!-- 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. -->
🆑 Tattle
fix: lockboxes' and wrapped crates' invisibility spell has worn off
/🆑
<!-- 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. -->
Co-authored-by: tattle <article.disaster@gmail.com>
- Makes QDELETED use isnull(x) instead of !x, giving about 0.2 to 0.25s
of speed.
- Make disposal constructs only update icon state rather than go through
expensive overlay code. Unfortunately did not have much effect, but is
something they should've been doing nonetheless.
- Makes RegisterSignal only take signals directly as opposed to
allocating a fresh list of signals. Very few consumers actually used
this and it costs about 0.4s. Also I think this is just a bad API anyway
and that separate procs are important
`\bRegisterSignal\((.*)list\(` replaced with `RegisterSignals($1list(`
## About The Pull Request
Disposals pipes didn't correctly release their contents when they were
destroyed by damage, causing anything inside to be deleted. That has
been fixed.
Fixes#71252.
## Why It's Good For The Game
Bugfix
## Changelog
🆑
fix: Fixed disposals pipes qdel-ing their contents when their integrity
hits zero.
/🆑
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
Fixes a simple text input bug. Earlier you couldn't type in 0.2 for
example because it would get rounded while this is the original speed.
Now it will not get rounded.
## Why It's Good For The Game
## Changelog
🆑
fix: Fixes conveyor speed input.
/🆑
<!-- 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. -->
This is a re-opening of #69960, after addressing all prior reviews
(except one, see below).
## About The Pull Request
- A mob inside a disposalpipe holder object that has stopped can use the
"resist" action (hotkey: B by default) to struggle out. This will take
20 seconds (on top of the time spent waiting for their holder to stop),
and will play a sound. The pipe they are in will burst (taking the tile
with it if applicable), and deal a random 5 to 15 brute damage to all
mobs in the holder.
- When merging a moving holder with a stopped holder, pipes will now
check if the stopped holder has a mob, and if so, will merge the moving
holder into the stopped holder rather than the reverse. Thus, all new
mobs will become stuck on a stopped mob.
- When deleted, holders will now drop their contents to the floor first.
This is to prevent a very rare bug deleting all holder contents
(including mobs) if the holder attempts to move through a pipe currently
being destroyed.
<!-- 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
Disposal traps are fun, but there shouldn't be a scenario where a player
is trapped indefinitely, with no ability to use tools or other items to
escape, that can be made for free using round-start items. If you want
to make a trap, the disposals pipes should be the delivery system, not
the destination.
<!-- 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. -->
🆑
add: You can now resist out of disposals pipes once you have stopped, at
the cost of some brute damage.
/🆑
<!-- 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. -->
About The Pull Request
The Export Scanner, Sales Tagger, and Price Tagger are all niche, cargo adjacent items that each perform a different minor task and if using one, requires usually one of the three extremely rarely. Each one requires printing a new item at the lathe, all for maybe one or two uses before it needs to be replaced.
This PR merges the three into a singular, modular item. Existing export scanners have been reflavored the "universal scanner". When used in-hand, it produces a radial to swap between the three modes, Each mode has identical function to their previous scanner, with the only functional difference being that the sales tagger now prints new tags on secondary attack as opposed to primary.
The other two items lathe recipes have been removed, as their functionality has been fully moved to the universal scanner.
Also flips the export scanner icon state to match the other 2 scanner items that have been lumped together.
Why It's Good For The Game
Cargo now only needs to swap between 1 of three nearly identical barcode scanner looking items at a time, as opposed to having to print an item that sees functional use once every thousand rounds. By increasing the ease of use, it will also make it easier to use custom vendors, as well as print sales tags on regular rounds, as the universal scanner can still be found in shipping boxes located around the station and in tool storages.
Arguably not a balance change, as the three tools are extremely cheap to print, and don't have a formal impact on cargo balance except for tedium.
* canUseTopic now uses TRUE/FALSE instead of defines that just say TRUE
The most idiotic thing I've seen is canUseTopic's defines, they literally just define TRUE, you can use it however you want, it doesn't matter, it just means TRUE. You can mix and match the args and it will set that arg to true, despite the name.
It's so idiotic I decided to remove it, so now I can reclaim a little bit of my sanity.
