## About The Pull Request
"If GAGS is such a good system, why isn't there GAGS 2?" - Sun Tzu
GAGS is very neat but it has one glaring issue: it needs sprites to be
greyscaled in advance to be used. On the other hand we have color
matrices, but they're hard to use and even harder to get good results
from. The logical solution grew out of a discord argument about colors
this morning after @LemonInTheDark decided to toy around with HSL
matrices using filters on live servers.
This PR implements Color Transition Filters as an additional option for
atom colors - passing a transition filter matrix into
``add_atom_colour`` will "recolor" the atom into the passed color by
using an HSL filter (since color only supports RGB values and matrices).
Normal color matrices are now also supported in atom colors, in case
anyone needs to use them there. ``color_transition_filter`` has 2 modes:
``SATURATION_MULTIPLY`` which only changes the hue and shifts saturation
of the original icon, and ``SATURATION_OVERRIDE`` which changes
saturation and light values to more correctly fit the passed color.
Multiply mode does a far better job at recoloring clothing or objects
with obvious highlights, but fails to color pale or white objects, while
Override mode is closer to what we have right now (just doesn't produce
rancid blobs of color nearly as much)
Here are some examples of colored clothes, mechs, items and tiles using
the new system.
Green RD? Sure.
Atmos MODsuit colored with a speed potion
Why override mode exists in the first place
Aftermath of a colorful reagent grenade.
As you can see, the colors are far brighter and significantly less
acidic, since they're no longer just used as multipliers for existing
colors but instead shift the palette of the sprite towards themselves.
In order to bypass the main downside of "default" Multiply mode,
spraycans have received a new right click function "coat with paint",
which will color the item using the Override mode. Left Click mode lost
its coloring restrictions (RMB still has them), and color
sampling/prosthetic recoloring has been moved to Ctrl Click instead.
Here's the full list of all systems/items that now use color transition
filters:
* Drying items
* Deep frying items
* Slime blueprints/potions/coloring crossbreeds
* Colorful reagent
* Spraycans
* Paint buckets
## Why It's Good For The Game
Our coloring system is ***really*** bad, to the point where we're
preventing players from using any dark colors because item icons become
unintelligible when colored into them.
## Changelog
🆑 SmArtKar, LemonInTheDark
add: Changed how spraycans color items - "old" mode is still availible
via right click.
refactor: Refactored how some items and effects color things so that
they look prettier.
/🆑
## About The Pull Request
this is a revival of #82635 . i got permission from potato to reopen
this, he did almost all the work. i only just solved the conflicts and
fixed all the bugs that were preventing the original from being merged
(but it should be TMed first)
## Why It's Good For The Game
slightly improves the performance of basic mob AI
## Changelog
🆑
LemonInTheDark
refactor: able_to_run and incapacitated have been refactored to be event
based
/🆑
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: ZephyrTFA <matthew@tfaluc.com>
## About The Pull Request
- Afterattack is a very simple proc now: All it does is this, and all
it's used for is for having a convenient place to put effects an item
does after a successful attack (IE, the attack was not blocked)
- An overwhelming majority of afterattack implementations have been
moved to `interact_with_atom` or the new `ranged_interact_with_atom`
I have manually tested many of the refactored procs but there was 200+
so it's kinda hard
## Why It's Good For The Game
Afterattack is one of the worst parts of the attack chain, as it
simultaneously serves as a way of doing random interactions NOT AT ALL
related to attacks (despite the name) while ALSO serving as the defacto
way to do a ranged interaction with an item
This means careless coders (most of them) may throw stuff in afterattack
without realizing how wide reaching it is, which causes bugs. By making
two well defined, separate procs for handing adjacent vs ranged
interactions, it becomes WAY WAY WAY more easy to develop for.
If you want to do something when you click on something else and you're
adjacent, use `interact_with_atom`
If you want to do something when you click on something else and you're
not adjacent, use 'ranged_interact_with_atom`
This does result in some instances of boilerplate as shown here:
But I think it's acceptable, feel free to oppose if you don't I'm sure
we can think of another solution
~~Additionally it makes it easier to implement swing combat. That's a
bonus I guess~~
## Changelog
🆑 Melbert
refactor: Over 200 item interactions have been refactored to use a
newer, easier-to-use system. Report any oddities with using items on
other objects you may see (such as surgery, reagent containers like cups
and spray bottles, or construction devices), especially using something
at range (such as guns or chisels)
refactor: Item-On-Modsuit interactions have changed slightly. While on
combat mode, you will attempt to "use" the item on the suit instead of
inserting it into the suit's storage. This means being on combat mode
while the suit's panel is open will block you from inserting items
entirely via click (but other methods such as hotkey, clicking on the
storage boxes, and mousedrop will still work).
refactor: The detective's scanner will now be inserted into storage
items if clicked normally, and will scan the storage item if on combat
mode
/🆑
## About The Pull Request
Paint can total uses 10 => 200
## Why It's Good For The Game
Paint cans used to be infinite until it was discovered that was actually
a bug and it was fixed back in May
What wasn't actually changed was how much paint is supposed to be in the
can.
Cans only hold 10 charges of paint, and lack an apparent way to refill
them (as far as I know), which is enough paint to do almost nothing
with.
Given crayons and spraycans hold 30 charges, 200 seems a lot more
reasonable for a big old can of paint that can only colour things and is
generally a lot bigger than spraycans (much less crayons)
## Changelog
🆑
balance: Paint cans hold 20x more paint than before, painters rejoice!
(Janitors cry more)
/🆑
## About The Pull Request
Apparently paint cans were never decrementing their `paintleft`
variable. They do this now, plus an error message for the funny
multicolor paint can when you try changing the color while it's empty.
Fixes#75110 by decrementing the variable.
This also makes sure clown borgs aren't hampered by their inability to
just get a new paint can by making their specifically infinite use.
## Why It's Good For The Game
Apparently paint cans were supposed to be limited use in the first
place, considering they had a `paintleft` variable that was never
decremented. We could also look at a few different options for refilling
these cans in the future that could further the creativity available
with them.
## Changelog
🆑
fix: Paint cans have become limited use as intended by the gods of code
fix: Clown borgs get unlimited paint, as a treat.
/🆑
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
This sprite file had been a dumping ground for miscellaneous sprites for
the past decade. It's bloated and full of random kinds of icons and even
has a few unused ones. It's time to reorganize them into their own
separate dmi's based on theme.
## Why It's Good For The Game
Better organization and easier access when looking for stuff.
## Changelog
🆑
imageadd: Split all icons in weapons_and_items.dmi to their own
categories
imagedel: Removed some unused icons
/🆑
Necessary for #72292 to work effectively, and probably not very useful
out of that context. Split out of its own PR because this is long and
boring.
I want to make sure that we're catching actual mistakes there, and not
just experiencing side effects of how shitty the attack chain is.
## About The Pull Request
https://user-images.githubusercontent.com/82386923/199180691-6605c8cc-e8aa-490e-ab65-909d45d12ca0.mp4
Do note that the damage in this video is extremely exaggerated compared
to what the normal value is.
## Why It's Good For The Game
All these signs about engineers needing to wear their hardhat, and for
what? For the assistant dropping toolboxes onto them from above, that's
what! Also allows people to do as god intended by allowing them to drop
pianos on people.
## Changelog
🆑
add: A variety of items, mainly tools, around the station might hurt if
they fall on your head, remember to wear your hardhat and to avoid
standing under large red X marks on the ground with a piano hanging
above them.
/🆑
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
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>
Moves singulo and supermatter dmis into obj/engine, renamed from obj/tesla_engine
Moves Halloween, Christmas, and misc holiday items to obj/holiday
Moves lollipops to obj/food
Moves crates, closets, and storage to obj/storage
Moves assemblies to obj/assemblies
Renames decals.dmi to signs.dmi ...because they're signs and not decals
Moves statues, cutouts, instruments, art supplies, and crayons to obj/art
Moves balloons, plushes, toys, cards, dice, the hourglass, and TCG to obj/toys
Moves guns, swords, shields to obj/weapons
Done using this command sed -Ei 's/(\s*\S+)\s*\t+/\1 /g' code/**/*.dm
We have countless examples in the codebase with this style gone wrong, and defines and such being on hideously different levels of indentation. Fixing this to keep the alignment involves tainting the blames of code your PR doesn't need to be touching at all. And ultimately, it's hideous.
There are some files that this sed makes uglier. I can fix these when they are pointed out, but I believe this is ultimately for the greater good of readability. I'm more concerned with if any strings relied on this.
Hi codeowners!
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
Splits the restrained() proc into component traits: TRAIT_HANDS_BLOCKED for the general inability to use hands and TRAIT_RESTRAINED for the more specific condition that permits arrests.
Code moved away from the update_mobility() proc so it doesn't have to wait for an update, instead changing based on events. The idea is to eventually kill that proc.
Wrapper proc added for setting the handcuffed value so we can react to the event of it changing.
Kills the RestrainedClickOn() proc. That is now just an UnarmedAttack(), in where the ability to use hands can be checked. Monkeys keep their bite attack and humans their self-examine.
* Renames a few variables. Also reorders fallback order again.
Renames item_state to inhand_icon_state
Renames mob_overlay_icon to worn_icon
Renames mob_overlay_state to worn_icon_state
worn_icon_state/mob_overlay_state now never gets used for inhands.
* Fixes some comments
* Fixes map issue
* Restart lints
* Properly resolves conflicts
* Adds sorting to most input() lists.
* Sorted some global lists, added more input sorting
* Should now use correct sort everywhere.
* compiles
* Last fixes.
About The Pull Request
Completely removes item_color and the clusterfuck of bad programming it caused.
In places where item_color was used for entirely unique purposes it was split off and renamed to a new var on that typepath only, or refactored so it wasn't needed
In places where item_color was used as a dye color, it was converted to the new dye_color var
In places where item_color was used as the worn overlay it was removed and instead now icon_state is always used as the clothing overlay.
A new mob_overlay_icon var was added for manually setting where the mob overlay icon path is for specific items.
Moved some mob overlay files relating to clothing to their own directory as well for organization purposes.
Totally refactors washing machines, instead of the horrible abortion that was iterating through the typepath it now uses a registry of dye results.
Some bonus functionality to come out of this:
the washing machine now supports arbitrary dye colors.
Why It's Good For The Game
It's been 4 years since the "this should be deprecated soonish" comment was added, and this var is a shitpile of confusion if you just trace the usage of it.
Changelog
cl
add: Washing machines now support arbitrary dye color
add: Washing machines now dye nearly every item.
refactor: lots of backend changes to clothing overlays, report any issues
/cl
* adds signal and modifies each call of afterattack to call it's inherited proc
* uses new macro for sendsignal()
* map fuck
* skip precommithooks
* combine and negate 2 ifs
SmArtKar