* makes cursed katana combos into a generic component (#74543)
## About The Pull Request
what the title says
also the katana's dark cloak move now has some vfx cause i figured why
not
## Why It's Good For The Game
this means anyone can give any weapon combos :D
## Changelog
* makes cursed katana combos into a generic component
---------
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
* Reagent soup / Soup rework / Stoves - A kitchen expansion
* fixes that stuff
* puts the range stove on maps that sohuld have it
* fixes some paths that don't exist anymore
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Paxilmaniac <paxilmaniac@gmail.com>
* Rebalances a vast oversight with one of the game's weapons (#74283)
## About The Pull Request
Makes sure the game is fairly balanced again.
## Why It's Good For The Game
Honestly I'm surprised this weapon went unchanged for so long with no
downsides.
## Changelog
🆑 Wallem
balance: Fixes a glaring oversight with the entrenching tool's
balancing.
/🆑
* Rebalances a vast oversight with one of the game's weapons
---------
Co-authored-by: Wallem <66052067+Wallemations@users.noreply.github.com>
* fixes heck suit hiding boots and gloves (#74131)
the armor's worn icon doesnt cover boots or gloves so when you wear it
over them you look all messed up
* fixes heck suit hiding boots and gloves
---------
Co-authored-by: SMOSMOSMOSMOSMO <95004236+SmoSmoSmoSmok@users.noreply.github.com>
* Audits usage of isanimal() vs isanimal_or_basic_mob() (#74029)
## About The Pull Request
There's a couple of open issues which fix places where only simple
animals were considered, but they are doing it piecemeal.
I decided to just go through every instance of `isanimal` or
`subtypesof(mob/living/simple_animal)` I could find, identify which
should also affect basic mobs, and fix them.
I left out the two others which are already in PR, I'm not stealing your
GBP.
Fixes https://github.com/tgstation/tgstation/issues/68881
## Why It's Good For The Game
Consistency, mostly.
As far as I can tell all of these things _should_ have effected basic
mobs, but didn't.
This fixes a fair number of bugs but also they're bugs that nobody
noticed or reported.
There are a couple of places I did not update which will need updating
in future. These are:
- Dextrousness checks, because basic mobs don't have that yet.
- The Charge cooldown action, because frankly I couldn't tell what it
was trying to do.
alright here goes
## Changelog
🆑
fix: Carp will once again be healed from being near carp rifts
fix: Sepia slime cores and the rewind camera now work on Ian
fix: Sapient ridden carp (or cows) can throw off their riders by shoving
them, or by performing the spin emote.
fix: Giant Spider AI will be disabled by the timestop spell
fix: Ian can eat envirochow
fix: Mice, Frogs, and Cockroaches will no longer set off bear traps
fix: You can put a macrobomb implant into Cayenne (or Ian)
fix: Ian will now recognise that being squeezed by a cyborg is a nice
hug
fix: The player panel will tell admins if you're currently a corgi
fix: The staff of storms deals massive damage to Bileworms and Giant
Spiders
fix: Ian will whimper if forced to scream
fix: Slimes can consume space carp
fix: Mice can be captured in xenoballs
fix: You can use pacifying potions on Giant Spiders
fix: Sgt Araneus can be fitted with a xenobiological radio implant
fix: Sapient corgis no longer count as living players for the purpose of
highlander escape objectives
fix: The random sentience event can now target corgis and sergeant
araneus
add: The random sentience event can target a wider array of farm animals
fix: Petsplosion wizard event can target corgis
add: Petsplosion wizard event will now target farm animals and
mothroaches
fix: The colossus possession crystal can now actually possess the
cockroach it spawns, does not kill you instantly upon ending possession
/🆑
* Audits usage of isanimal() vs isanimal_or_basic_mob()
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Splits mutant_bodyparts.dmi into several subfiles. (#71408)
Splits the `mutant_bodyparts.dmi` file up, as was suggested, but not
implemented, in #69302.
The following new files were created in the `icons\mob\species` folder,
containing the listed sprites:
- `lizard\lizard_misc.dmi`: Snouts, horns, frills, and body markings.
Anything I didn't feel needed an entire file to itself.
- `lizard\lizard_spines.dmi`: Lizard spines, both animated and not.
- `lizard\lizard_tails.dmi`: Lizard tails, both animated and not.
- `human\cat_features.dmi`: Felinid ears and tails.
- `monkey\monkey_tail.dmi`: The monkey tail.
- `mush_cap.dmi`: The lone mushperson cap, so easily forgotten.
Additionally, I moved `wings.dmi` from `mob\clothing` to `mob\species`.
I'm not sure what it was doing there.
`mutant_bodyparts.dmi` was something of a mess, with parts from four
different species thrown together haphazardly. It probably made sense in
earlier days when "mutant humans" were few and far between, but
splitting it up makes it more intuitive to find these sprites, and
brings it in line with other species - namely, moths. It also means that
any future sprites of these types added will not bloat an oversized file
even more.
Moving the wings file to the species folder just makes sense, because
wings are not a type of clothing.
🆑
refactor: Removed mutant_bodyparts.dmi and distributed its sprites in a
more sensible and granular manner.
/🆑
* External Organ Rework: new bodypart_overlay system (#72734)
Bodypart overlays are now drawn by the new /datum/bodypart_overlay
datum.
External organs no longer draw anything and instead add a special
/datum/bodypart_overlay/mutant to the bodypart, which draws everything
Makes it way easier to add custom overlays to limbs, since the whole
system is now modularized and external organs are just one
implementation of it
I haven't moved anything but external organs to this new system, I'll
move eyes, bodymarkings, hair, lipstick etc to this later
New pipeline is as follows:
- External organ added to limb
- External organ adds /datum/bodypart_overlay/mutant to limb to
bodypart_overlays
- Limb updates its icon, looks for all /datum/bodypart_overlay in
bodypart_overlays
- Very cool new overlay on your limb!
closes#71820🆑
refactor: External organs have been near-completely refactored.
admin: Admin-spawned external organs will load with a random icon and
color
fix: fixes angel wings not working for non-humans (it was so fucking
broken)
fix: fixes external organs being invisible if they werent initialized
with a human
/🆑
External organs are cool but are pretty limited in some ways. Making
stuff like synthetic organs is kinda fucked. I tried and it was dogshit.
Now you can just give an icon state and icon and you're good (using
/datum/bodypart_accessory/simple)
Stuff like eyes, cat ears and hair seem like good choices for extorgans,
but don't quite work for it because their icons work a lot differently.
This solves for it completely since any organ (or object or whatever)
can add it's own icon to a bodypart.
Want to add an iron plate to someones head? Go ahead. Want a heart to
stick out of someones chest? No problem.
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Makes the whole thing compile, although it most likely doesn't work
* Whoopsie daisy
* Now it's starting to work
* ok monkey
* Fixes tails some more
* Moth wings should be wings not moth wings
* Podpeople hair, yeah.
* Okay no more handle_mutant_bodyparts()
* Removed an useless variable from is_hidden()
* Fixes some more can_draw_on_bodypart (I'm gonna have to fix it upstream too)
* Removes the second useless argument of is_hidden()
* No, cat tails are no longer allowed to be snowflake
* Removes some useless variables from humans
* Whoops I forgot to commit this one
* How did I miss this one?
* Okay, yeah, tails and some other stuff show up now. Pod people hair too. Just many of them don't. Good enough for today.
* Okay so after a lot of pain and suffering, many mutant_bodyparts are now functional
* Everything works, except for ears, some of the taur layering, and moth markings (which never worked it seems)
* Alright skintones seem to work rather well now(?)
* Okay, my bad, now they do
* Moth markings can't be selected and won't be added anymore (since they're broken and integrated into the regular markings system anyway)
* Spines are no longer just matching the color of the limb they're attached to
* Moves taur organ and bodypart_overlay out of the sprite_accessory file for taurs, and fixes the taur rendering
* Linters moment
* Alright, spines are working and overlaying properly now
They just need to have a FRONT overlay for the /tg/ ones if we want them to display above the lizard tails, we already have that for vox spines thankfully.
* Disables moth_markings for good
* Fixes some rendering bugs
* Makes ears work (almost, rest of the code has MODsuit stuff in it too :( )
* Made the MODsuit overlays work :)
* Fixed horns and spines
* Fixes all of the screenshot tests
* Removes the Body Markings option from Appearances, use Augments+ instead (because that one works and is just better)
* Bye bye handle_mutant_bodyparts(), I won't miss you :)
* Forgot to take this out, whoops
* Fixes the moth antennae being unticked
* Removes some commented code in a modular file
* Fixes part of the create_and_destroy unit test
* Fixes a pretty big issue that caused some sprite_accessories to be removed from the global list because of the alter_form action (deep copies ftw)
* Fixes the runtimes related to pod_hair
* Gives the vox a better look in the prefs menu
* Fixes the appearance of functional wings
* Makes synths able to access their robotic wings
* Podpeople don't cause runtimes during CI anymore
* Fixes the random appearance of locked functional wings
* Fixed cat and lizard tails using the /tg/ sprites (we have slightly modified ones)
* Fixes the coloring on multi-colored sprites
* Fixes the code for the screenshot of the mammal screenshots and preview, so it has a tail
* Fixes the screenshot tests for a few species
* Fixes tails going invisible when wagging
* Fixes a runtime with horns
* Fixes showing/hiding mutant bodyparts not working at all
* (Hopefully) fully fixes all the issues related to extra and extra2-related icon_states.
* Fixes synth stuff and starts working on pod hair again
* I DID IT PODPEOPLE HAVE HAIR AGAIN
* Fixes the podpeople hair showing up on more than just podpeople
* Fixes the IPC screens showing up on species outside of synthetics
* Fixes a runtime in the pod_hair and the synth_screen's apply_to_human
* Updates the screenshots for podpeople and synths
* Fixes an issue with a certain type of organs
* Fixes another runtime, whoops
* Fixes the markings from /tg/'s Body Markings not being available in our markings system
* Re-adds support for taur-variants of certain mutant bodyparts
* Hopefully fixes a few more runtimes
* Adds some debug variable in the code for now, likely to be removed later if really necessary. This will make my life easier.
* Whoops, that needed to be backwards. :clown:
* Fixes the top snouts not rendering at all
* Fixes the issues where bodytypes weren't handled properly, and thus snouts were getting squished
* Fixes the weird placement of the Xeno Head Emissives in the prefs menu
* Removes a no-longer-necessary override of post_set_preference() in the limbs_and_markings middleware
* Reverts an unnecessary SKYRAT EDIT inside of commented out code
* No longer creates a new body every time we change prefs in the prefs menu, we reusing now lads
I know there's commented out code but I'm going to remove that in another commit
* Removed some more dead code.
* Fixes jellyfish ears being all white
* Fixes plasmaman limbs not displaying because I accidentally hardcoded the limb_id for all augments to "robotic"
---------
Co-authored-by: lizardqueenlexi <105025397+lizardqueenlexi@users.noreply.github.com>
Co-authored-by: Time-Green <timkoster1@hotmail.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Reworks sabotage progression traitor objective (#73750)
## About The Pull Request
This one is a little bit of a more abstract change than my last traitor
objective rebalancing PR.
The idea here is that I think that the objectives which have you
sabotage a frequently used machine (lathes or the ORM, but we can maybe
expand it to others following this?) are potentially pretty good but
limitations in how the objective are tracked mean that people go about
them in a boring way which rarely inconveniences anyone.
I have reworked these objectives so that you can choose to apply a
provided item to the machine over 10 seconds. The next interaction
following this (clicking on it, or in the case of the ORM loading any
ore into it) will cause the machine to explode, destroying itself and
lightly damaging people nearby (explosion damage is... variable, but
it's a light explosion so it won't instantly kill anyone).
There is a 0.5 second grace period between the bomb triggering and the
explosion actually happening, which players can use to perform some kind
of tactical reaction or simply to feel regret.
Here's a video:
https://www.youtube.com/watch?v=xNIaHsA9YFE
Trapped machines will intermittently beep, though at a volume which is
hard to detect from more than two tiles away, and can be defused by
using a screwdriver on the machine.
If you choose to do this then you will get a little bonus to TC and
reputation, but only if the trap is successfully sprung. This means that
sabotaging a machine in an empty department is unlikely to lead to quick
success.
You can also still do it with screwdriver and crowbar way if you are
boring but this means you will only get reputation and not any
telecrystals.
The two objectives to destroy a radio server or the research machine
remain as they were.
Also I refactored how we set which machines are targets for these
objectives so it doesn't iterate over every machine in the world every
time.
## Why It's Good For The Game
Traitor objectives (and antagonist objectives in general) should:
- Present you with a somewhat engaging task
- Encourage you to interact with at least one other player (at least by
"attempting to sneak past them")
- Move the state of the round forward in some way, usually by creating
inconvenience for at least one other person
Prior to this change you could, and people often did, complete this
objective by accessing a machine that you already _have_ access to,
using a screwdriver and crowbar on it, and then reassembling it.
This prompts interaction with nobody, and inconveniences nobody.
Following this change people will be encouraged to:
- Actually destroy the machine.
- Probably harm somebody.
- Potentially cause some collateral damage.
- Make loud sounds and flashing lights to delight people of all ages.
Even if you opt to set the device in a little-used department and then
blow yourself up, that will prompt you to go and interact with someone
in medbay and will also look pretty suspicious in a way that's much
harder to track with the previous objective.
Also I might reuse this component again in the future, you never know.
## Changelog
🆑 Jacquerel, sprite by J(Clearly Lying)
balance: Traitor objectives which ask you to destroy lathes or the ORM
provide an optional bonus if you _booby trap_ the machine using a
provided tool. This causes the machine to explode the next time it is
interacted with.
balance: Performing the objective without rigging the machine to explode
awards no TC, using it awards more TC than it did previously.
/🆑
* Reworks sabotage progression traitor objective
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Adds a stack_trace for emissives with invalid icon_states, fixes all that appeared roundstart (#73678)
## About The Pull Request
So, this spiraled from one missing icon being fixed to an entire check
for said icons.
Several icon files no longer use error icons because its assumed that
the checks will handle any missing ones, but the checks don't apply to
emissives nor overlays at all. This led to the radsuit having an
emissive but no icon_state for it - a relic of the old radsuit. This was
only noticed because of a downstream with an error icon appearing for
it...
I was curious how many were actually having the same issue, so I made a
small little stack_trace in the mutable_appearance proc.
There were like, 2k. Lots of them were icons named, like, "transparent"
or "blank" too...
I moved that check to the emissives proc because I semi-understand that
system so could actually fix it, and it moved to around fourty
roundstart. Much more achievable.
(The error usually has more info if you click on it, including the item
that caused it. I dunno how to add that to the check itself because of
where it's located, though.)
This fixes all the ones I could find, including...
Nonexistant icons that shouldn't be adding emissives on:
- Empty Barsign
- Radsuit
- Mass Driver Controllers
- Telescreens
- Aux Base Consoles
- PanDEMIC
- Kobayashi computer (holodeck)
- Abductor camera console
- Syndie drop pod
- BSA controller
Entirely missing icons on:
- Pwr Game Vendor (this was just misnamed)
- Generic Soda Vendor
- Engivend
- Security Laptop (proud of this one.,.,)
There are no doubt more of them hidden about, but I don't really know
what I'm doing... If there's a check that'd be better than this, please
review telling me what to change <3
## Why It's Good For The Game
Fixes missing icons, fixes attempts to add icons where we don't need
them, and adds a check to help fix more of the two issues as they occur.
## Changelog
🆑
fix: fixed missing emissives on the Engivend, Pwr-Game Soda, and generic
Soda vendors. Also fixed the seclaptop having no valid screen icon!
fix: fixed a few items trying to apply emissives when they shouldn't.
code: added a stack_trace for emissives with missing icon states.
/🆑
* Adds a stack_trace for emissives with invalid icon_states, fixes all that appeared roundstart
* Update cryopod.dm
---------
Co-authored-by: OrionTheFox <76465278+OrionTheFox@users.noreply.github.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Nightvision Rework (In the name of color) (#73094)
Relies on #72886 for some render relay expansion I use for light_mask
stuff.
Hello bestie! Night vision pissed me off, so I've come to burn this
place to the ground.
Two sections to discuss here. First we'll talk about see_in_dark and why
I hate it, second we'll discuss the lighting plane and how we brighten
it, plus introducing color to the party.
https://www.byond.com/docs/ref/#/mob/var/see_in_dark
See in dark lets us control how far away from us a turf can be before we
hide it/its contents if it's dark (not got luminosity set)
We currently set it semi inconsistently to provide nightvision to mobs.
The trouble is stuff that produces light != stuff that sets luminosity.
The worst case of this can be seen by walking out of escape on icebox,
where you'll see this
Snow draws above the lighting plane, so the snow will intermittently
draw, depending on see_in_dark and the luminosity from tracking lights.
This would in theory be solvable by modifying the area, but the same
problem applies across many things in the codebase.
As things currently stand, to be emissive you NEED to have a light on
your tile. People are bad at this, and honestly it's a bit much to
expect of them. An emissive overlay on a canister shouldn't need an
element or something and a list on turfs to manage it.
This gets worse when you factor in the patterns I'm using to avoid
drawing lights above nothing, which leads to lights that should show,
but are misoffset because their parent pixel offsets.
It's silly. We do it so we can have things like mesons without just
handing out night vision, but even there the effect of just hiding
objects and mobs looks baddddddd when moving. It's always bothered me.
I'll complain about mesons more later, but really just like, they're too
bright as it is.
I'm proposing here that rather then manually hiding stuff based off
distance from the player, we can instead show/hide using just the
lighting plane. This means things like mesons are gonna get dimmer, but
that's fine because they suck.
It does have some side effects, things like view() on mobs won't hide
stuff in darkness, but that's fine because none actually thinks about
view like that, I think.
Oh and I added a case to prevent examining stuff that's in darkness, and
not right next to you when you don't have enough nightvision, to match
the old behavior `see_in_dark` gave us.
Now I'd like to go on a mild tangent about color, please bare with me
You ever walk around with mesons on when there's a fire going, or an
ethereal or firelocks down.
You notice how there isn't really much color to our lights? Doesn't that
suck?
It's because the way we go about brighting lighting is by making
everything on the lighting plane transparent.
This is fine for brightening things, but it ends up looking kinda crummy
in the end and leads to really washed out colors that should be bright.
Playing engineer or miner gets fucking depressing.
The central idea of this pr, that everything else falls out of, is
instead of making the plane more transparent, we can use color matrixes
to make things AT LEAST x bright.
https://www.byond.com/docs/ref/#/{notes}/color-matrix
Brief recap for color matrixes, fully expanded they're a set of 20
different values in a list
Units generally scale 0-1 as multipliers, though since it's
multiplication in order to make an rgb(1,1,1) pixel fullbright you would
need to use 255s.
A "unit matrix" for color looks like this:
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
0, 0, 0, 0
)
```
The first four rows are how much each r, g, b and a impact r, g, b and
well a.
So a first row of `(1, 0, 0, 0)` means 1 unit of r results in 1 unit of
r. and 0 units of green, blue and alpha, and so on.
A first row of `(0, 1, 0, 0)` would make 1 red component into 1 green
component, and leave red, blue and alpha alone, shifting any red of
whatever it's applied to a green.
Using these we can essentially color transform our world. It's a fun
tool. But there's more.
That last row there doesn't take a variable input like the others.
Instead, it ADDS some fraction of 255 to red, green, blue and alpha.
So a fifth row of `(1, 0, 0, 0)` would make every pixel as red as it
could possibly be.
This is what we're going to exploit here. You see all these values
accept negative multipliers, so we can lower colors down instead of
raising them up!
The key idea is using color matrix filters
https://www.byond.com/docs/ref/#/{notes}/filters/color to chain these
operations together.
Pulling alllll the way back, we want to brighten darkness without
affecting brighter colors.
Lower rgb values are darker, higher ones are brighter. This relationship
isn't really linear because of suffering reasons, but it's good enough
for this.
Let's try chaining some matrixes on the lighting plane, which is bright
where fullbright, and dark where dark.
Take a list like this
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
-0.2, -0.2, -0.2, 0
)
```
That would darken the lighting a bit, but negative values will get
rounded to 0
A subsequent raising by the same amount
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
0.2, 0.2, 0.2, 0
)
```
Will essentially threshold our brightness at that value.
This ensures we aren't washing out colors when we make things brighter,
while leaving higher values unaffected since they basically just had a
constant subtracted and then readded.
You may have noticed, we gain access to individual color components
here.
This means not only can we darken and lighten by thresholds, we can
COLOR those thresholds.
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
0.1, 0.2, 0.1, 0
)
```
Something like the above, if applied with its inverse, would tint the
darkness green.
The delta between the different scalars will determine how vivid the
color is, and the actual value will impact the brightness.
Something that's always bothered me about nightvision is it's just
greyscale for the most part, there isn't any color to it.
There was an old idea of coloring the game plane to match their lenses,
but if you've ever played with the colorblind quirk you know that gets
headachey really fast.
So instead of that, lets color just the darkness that these glasses
produce.
It provides some reminder that you're wearing them, instead of just
being something you forget about while playing, and provides a reason to
use flashlights and such since they can give you a clearer, less tinted
view of things while retaining the ability to look around things.
I've so far applied this pattern to JUST headwear for humans (also those
mining wisps)
I'm planning on furthering it to mobs that use nightvision, but I wanted
to get this up cause I don't wanna pr it the day before the freeze.
Mesons are green, sec night vision is red, thermals orange, etc.
I think the effect this gives is really really nice.
I've tuned most things to work for the station, though mesons works for
lavaland for obvious reasons.
I've tuned things significantly darker then we have them set currently,
since I really hate flat lighting and this system suffers when
interacting with it.
My goal with these is to give you a rough idea of what's around you,
without a good eye for detail.
That's the difference between say, mesons, and night vision. One helps
you see outlines, the other gives you detail and prevents missing
someone in the darkness.
It's hard to balance this precisely because of different colored
backgrounds (looking at you icebox)
More can be done on this front in future but I'm quite happy with things
as of now
I have since expanded to all uses of nightvision, coloring most all of
them.
Along the way I turned some toggleable nightvision into just one level.
Fullbright sucks, and I'd rather just have one "good" value.
I've kept it for a few cases, mostly eyes you rip out of mobs.
Impacted mobs are nightmares, aliens, zombies, revenants, states and
sort of stands.
I've done a pass on all mobs and items that impact nightvision and added
what I thought was the right level of color to them. This includes stuff
like blobs and shuttle control consoles
As with glasses much of this was around reducing vision, though I kept
it stronger here, since many of these mobs rely on it for engaging with
the game
<details>
<summary>
Technical Changes
</summary>
filter transitions.
Found this when testing this pr, seemed silly.
This avoids dumbass overlay lighting lighting up wallmounts.
We switch modes if some turfflags are set, to accomplish the same thing
with more overhead, and support showing things through the darkness.
Also fixes a bug where you'd only get one fullscreen object per mob, so
opening and closing a submap would take it away
Also also fixes the lighting backdrop not actually spanning the screen.
It doesn't actually do anything anymore because of the fullscreen light
we have, but just in case that's unsued.
Needs cleanup in future.
color with a sprite
This is to support the above
We relay this plane to lighting mask so openspace can like, have
lighting
vision goggles and such
Side affect of removing see_in_dark. This logic is a bit weak atm, needs
some work.
It's a dupe of the nightvision action button, and newly redundant since
I've removed all uses of it
trasnparent won't render
These sucked
Also transparent stuff should never render, if it does you'll get white
blobs which suck
</details>
Videos! (Github doesn't like using a summary here I'm sorry)
<details>
Demonstration of ghost lighting, and color
https://user-images.githubusercontent.com/58055496/215693983-99e00f9e-7214-4cf4-a76a-6e669a8a1103.mp4
Engi-glass mesons and walking in maint (Potentially overtuned, yellow is
hard)
https://user-images.githubusercontent.com/58055496/215695978-26e7dc45-28aa-4285-ae95-62ea3d79860f.mp4
Diagnostic nightvision goggles and see_in_dark not hiding emissives
https://user-images.githubusercontent.com/58055496/215692233-115b4094-1099-4393-9e94-db2088d834f3.mp4
Sec nightvision (I just think it looks neat)
https://user-images.githubusercontent.com/58055496/215692269-bc08335e-0223-49c3-9faf-d2d7b22fe2d2.mp4
Medical nightvision goggles and other colors
https://user-images.githubusercontent.com/58055496/215692286-0ba3de6a-b1d5-4aed-a6eb-c32794ea45da.mp4
Miner mesons and mobs hiding in lavaland (This is basically the darkest
possible environment)
https://user-images.githubusercontent.com/58055496/215696327-26958b69-0e1c-4412-9298-4e9e68b3df68.mp4
Thermal goggles and coloring displayed mobs
https://user-images.githubusercontent.com/58055496/215692710-d2b101f3-7922-498c-918c-9b528d181430.mp4
</details>
I think it's pretty, and see_in_dark sucks butt.
<!-- 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: The darkness that glasses and hud goggles that impact your
nightvision (think mesons, nightvision goggles, etc) lighten is now
tinted to match the glasses. S pretty IMO, and hopefully it helps with
forgetting you're wearing X.
balance: Nightvision is darker. I think bright looks bad, and things
like mesons do way too much
balance: Mesons (and mobs in general) no longer have a static distance
you can see stuff in the dark. If a tile is lit, you can now see it.
fix: Nightvision no longer dims colored lights, instead simply
thresholding off bits of darkness that are dimmer then some level.
/🆑
* modular edits
* see_in_dark
* [MIRROR] Adds a unit test to detect double stacked lights [MDB IGNORE] (#19564)
* Adds a unit test to detect double stacked lights
* we really need to get that night vision pr done
* lints fixes
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Paxilmaniac <paxilmaniac@gmail.com>
* Update augments_eyes.dm
* Update augments_eyes.dm
* eeee
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: SkyratBot <59378654+SkyratBot@users.noreply.github.com>
Co-authored-by: Paxilmaniac <paxilmaniac@gmail.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* [no gbp] orm correctly displays borg id data (#73808)
## About The Pull Request
this is a minor thing i forgot to add in my last PR, now the borg's name
will be displayed as well when interacting with the ORM rather than
displaying "no id detected"
## Why It's Good For The Game
## Changelog
🆑
qol: Borgs are now acknowledged by the orm
/🆑
* [no gbp] orm correctly displays borg id data
---------
Co-authored-by: SMOSMOSMOSMOSMO <95004236+SmoSmoSmoSmok@users.noreply.github.com>
* Removes Cult perms from Survival pods (#73757)
## About The Pull Request
Removes Cult permitted from survival pods, as it's very uninteresting to
have cult bases in places no one will check.
This doesn't affect the mining base itself.
## Why It's Good For The Game
One of the drawbacks of Cult is that they get stronger at the cost of
being more easy to spot, so being to completely bypass the negative part
makes it unfair to fight cult if there's a single shaft miner, or
literally anyone if it's icebox.
## Changelog
🆑
balance: Cult can no longer draw runes in survival pods.
/🆑
* Removes Cult perms from Survival pods
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
Buff scythes, goats, and plantbgone vs PLANT biotypes (#72889)
This buffs scythes, goats, and plantbgone vs PLANT biotypes:
- Scythes now deal x1.5 damage to venus flytraps (3 hits to kill)
- Scythes now target the flower bud vines
- Goats now target flower bud vines and deal 15 damage to PLANT biotypes
- Goats have a eating sound whenever they bite PLANT biotypes
- Plantbgone now does 2 dmg per unit to PLANT biotypes (10 dmg per
spray)
- Plantbgone now has a 75% chance to remove weeds and deals large damage
to flower buds
- Weed control crates now come with a pair of leather gloves
- Golems are immune to thorn effects
- Any kind of thick glove material will prevent thorn effects when
attacking
- Flower buds will now take x4 damage from fire and sharp weapons
(unless they have fire trait)
- Regular scythes are now a sharp object
Also this fixes a few runtimes with spacevines and nulls. The bane
element now accepts `mob_biotypes` bitflags as an argument.
Before my changes:
- Plant-b-gone was doing 0.4 dmg per unit to PLANT biotypes (2 dmg per
spray)
- Scythes took 5 hits to kill venus flytraps
- Goats only affected podpeople
- Flower bud vines were being ignored by weed killing code
- Plantbgone only had a 50% chance to remove weeds (and this was very
inconsistent due to RNG)
- Botanical gloves and thick gloves didn't protect from thorns
- Golems were getting pierced by thorns despite having pierce immunity
- Flower buds were not taking the x4 damage like they should have been
- Regular scythes were not a sharp object, but other scythes
(chaplain's, megafauna loot) were sharp
This makes the weed killer crate more effective since people were
complaining about it being worthless vs vines and flower buds. These
changes give people more options to respond to threats vs plants.
🆑
add: Add a pair of leather gloves to weed control crate
balance: Mobs with the PLANT biotypes (venus flytraps, pod people,
killer tomatoes) are now much weaker vs scythes, goats, and plantbgone.
balance: Plantbgone is now more effective at destroying weeds.
balance: Regular scythes are now a sharp object
fix: Fixed scythes, goats, and plantbgone not affecting flower bud
vines.
fix: Thick and botanical gloves not protecting from thorns
fix: Golems not having pierce immunity from thorns
fix: Runtime where vines tried to spread into null turf
fix: Runtime where null vines that were destroyed were trying to spread
to nearby turfs
soundadd: Add eat food sound when goats eat plants
code: Improved goat targeting code
code: The bane element now accepts `mob_biotypes` bitflags as an
argument.
/🆑
Co-authored-by: Tim <timothymtorres@gmail.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Return to Tiny: Reworks heights to use filters, allows spacemen to have varying heights (#72344)
Re-pr of #66644 with some changes to get it working
- [x] ~~Huds get cut off~~ Resolved
- [x] ~~Very tall helmets get cut off~~ Resolved
- [x] Hair gets cut off
- [x] ~~Needs optimization before releasing to the world as a pref~~ jk
lol
Look at that fella so cute
🆑 Melbert, That REALLY Good Soda Flavor, FatFat, AndreyGusev
add: Spacemen can now have varying height. (Admin only for now)
add: Dwarfs are now slightly shorter, but look way better.
/🆑
Co-authored-by: Jack LeCroy <3073035+jacklecroy@users.noreply.github.com>
* fix conflict
* clarity
* update rouny
* update screenshots
* Revert "update screenshots"
This reverts commit a5427a5238e574869fe364568b7f043bbd287c79.
* Fixes the dwarf screenshot.
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Jack LeCroy <3073035+jacklecroy@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Fixes the labor claim console not properly linking in shuttle loads (#73590)
## About The Pull Request
Caused by f88edef0fb
I prevented lighting objects transfering between space turfs and not
space turfs.
This meant if you went from space turf -> non space turf, we had to
spawn you a new lighting object.
This would set your luminosity to 0, then queue you for updates.
This meant that shuttles would go fulldark (To things without
see_in_dark) on move. So when we'd try and do a view check to look for a
stacking machine to feed from, we'd get blocked
Lets swap from a view to a dview() then, and default to lit instead of
unlit turfs
Because mobs use infi see_in_dark this only impacts redundant view()
calls. Lets just be nice to em yeah?
## Why It's Good For The Game
Closes#73324
## Changelog
🆑
fix: The gulag shuttle's point claim console will load in again. Whooops
/🆑
* Fixes the labor claim console not properly linking in shuttle loads
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Dominate & Lazarus Inject basic mobs. Lazarus Injected mobs don't fight each other. (#72440)
Fixes#72404
The Lazarus Injector doesn't currently work on basic mobs, but should.
Problem:
The EMPed state of the Lazarus Injector is intended to make a revived
mob hostile to everyone except you, including other mobs you have
revived wtih an EMPed Lazarus Injector.
This is trivial to achieve for Simple Mobs which essentially all share
the same AI, but I could not think of a single workable solution for
Basic Mobs which don't, or at least any which didn't come with a tedious
requirement to closely consider this niche item when programming any
additional AI.
Solution:
Change the default behaviour of the Lazarus Injector so this is not a
problem.
If all it does it make the mob loyal to you _and_ friendly to other mobs
which are loyal to you, then it's pretty easy because we can just use
the existing faction flags.
This is unambiguously a buff to using the item for nefarious purposes as
now if you revive four ice drakes and fulton them onto the station they
won't kill each other until only one is left, but is the only workable
solution I could really think of.
A lot of the very dangerous mining fauna can't be dragged so
transporting your army to the station still poses a question.
The alternate solution was just to replace the AI controller of any
emp-revived basic mob with a "zombie" AI controller, but this has the
problem that
A- It would now make things like cows and dogs into hostile creatures
when they previously weren't.
B- It loses any interesting behaviour the mob previously had and for
cases like Bileworms doesn't even make any sense (they'd try to walk and
just get stuck in place).
This ultimately leads to needing to make bespoke versions for various
mobs, which doesn't seem desirable from a maintainability standpoint.
As a side note it's still not a great idea to revive Bileworms _anyway_
as, their ability to move is tied to their ability to attack so once
they don't have a target they will just kind of sit there and if they
_do_ get a target their attempts to help you fight are difficult to
distinguish from attempts to kill you... but at least being able to
revive them makes it easier to make one sapient if you really want to
trap a player's mind inside a body which is incapable of leaving
lavaland.
Additional edit:
At Fikou's suggestion I've also added a sentience comparison proc to
`mob/living` and removed some code duplication which dealt with this
problem in the sentience/mind transfer potions, as well as added it to
the Dominate spell.
This device is meant to revive mobs and it shouldn't be required for
players to memorise an arbitrary list of which mobs it does and doesn't
work on.
Especially as the goal is eventually that all simple mobs should be
basic mobs.
This way of working is more intuitive, even if it is also stronger. I
was surprised when I used EMPed injectors and my "new minions" just
killed each other.
🆑
fix: You can now revive 'basic mobs' with a Lazarus Injector, such as
dogs, cows, axolotls, or carp.
fix: The same category of mobs can also now be effected by the Runic
Golem Dominate spell.
fix: Basic Mobs will switch target if they can no longer attack their
current target; meaning that if you become a Bileworm's friend it will
stop attacking you.
balance: Mobs injected with the Lazarus Injector while it is EMPed will
no longer attack other mobs revived by EMPed Lazarus Injectors.
/🆑
* Update code/modules/research/xenobiology/xenobiology.dm
* Update code/modules/research/xenobiology/xenobiology.dm
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
Fixes the ORM I/O lights (#72936)
## About The Pull Request
The ORM's input lights have turned invisible, due to item state names
that have not been updated. This PR fixes that. It also autodocs the
various procs and vars.
## Why It's Good For The Game
Fixes#72923 It is good to see which direction you have to place the
ores.
## Changelog
🆑
fix: The ORM's input and output lights are once again visible
/🆑
Co-authored-by: Profakos <profakos@gmail.com>
Mint can gib obese people again (#72970)
## About The Pull Request
Changes minttoxin(a toxin) to mintextract(a food).
## Why It's Good For The Game
Fixes https://github.com/tgstation/tgstation/issues/72969
The chef's mint is intended to gib fat people. Due to
https://github.com/tgstation/tgstation/pull/70764, liver functionality
was reworked so that instead of being purged rapidly, toxin's in a mobs
system with 3 units or less have no effect. Since the chef's mint only
has 2 units of mint toxin, it's intended functionality is impossible
under normal circumstances.
By changing the reagent type from toxin to consumable, it restores the
ability to gib.
## Changelog
🆑
fix: Mint Toxin(a toxin) has been changed to Mint Extract(a food). The
chef's mint can once again gib, fatties beware.
/🆑
Co-authored-by: the-orange-cow <76538214+the-orange-cow@users.noreply.github.com>
Moves mining points from the ID to the bank account (+credit type shown on order console) (#72726)
## About The Pull Request
Mining points are now stored on the ID's bank accounts instead of the
individual IDs, bringing them on-par with credits. This allows miners to
safely replace their ID and keep their mining points just like they can
for their credits.
I also added the cost type on Produce Consoles, so people using them
will know whether they're using mining points or credits.
Because all IDs have a bank account by default, this won't be a problem
to Golems or the like.
## Why It's Good For The Game
1. It's more clear to the player what type of credit is being used in
the order console
2. Mining points being tied to the ID is no longer needed as all IDs
have a bank account
3. Brings mining points up to the same standard as credits.
## Changelog
🆑
qol: Mining points is now tied to bank accounts instead of individual
IDs, so they transfer over in cases of an ID replacement.
/🆑
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* TGC rulebook added to the card battle arena and fixes a bug with holographic TGC coins (#72595)
## About The Pull Request
The coins spawned by the TGC holodeck arena had monetary value and could
be used as an infinite source of income, they've been replaced with a
worthless subtype.
Also a small QoL change since I've seen people looking for it ICly but
I've added a rulebook to the holodeck so people can access the wiki page
directly.
## Why It's Good For The Game
Infinite money exploit bad and I've watched multiple people go hunting
for a non-existent rulebook.
## Changelog
🆑
qol: Rulebook for TGC has been added to the TGC arena.
fix: Holographic TGC coins are no longer legal tender and cannot be
inserted into your ID.
/🆑
* TGC rulebook added to the card battle arena and fixes a bug with holographic TGC coins
Co-authored-by: NamelessFairy <40036527+NamelessFairy@users.noreply.github.com>
* Autounlock techwebs are shared between machines that use them. (#72515)
## About The Pull Request
Did you know that for every Autolathe, Limbgrower, Biogenerator, ORM,
and Smelter that was built, an entire new techweb was made? The average
round has 2 ORMs (smelters count) if not more from ORM deconstruction
objective, 2 biogenerators, several autolathes and generally 0-1
limbgrower, I think there's more techwebs being created than we need.
Creating a whole techweb was a pretty terrible way to optimize this, so
I made a global list that stores these techwebs. Created on demand,
these autounlocking techwebs now share between the machines that use
them. It also generate all hacked nodes which will be visible if the
machine is hacked, instead of 'researching' them for each hacked
individual machine.
The 'specialized' techweb subtype was removed because its sole purpose
was to allow autounlocking to be a subtype of it. Now autounlocking is
just the direct subtype. I also removed mechfab autounlocking type
because it wasn't used, mechfabs use techwebs directly.
Autolathes and Limbgrowers now locally store 'imported designs' which
are things uploaded from technology disks. Outside of this, the
autounlocking techweb subtype now stores 'hacked designs' which unlocks
when the machine is emagged.
While doing this, I saw ORMs and Biogenerators had disks you can insert
into them, but I did not find anything that can actually be uploaded to
them (I saw Alien Alloys as a possibility, but there's no such disk to
allow uploading this alloy to the machine, and I didn't think an entire
system for 1 single alloy was worth keeping around), so I removed this
unused feature from both machines.
I merged 'Hacked' and 'Emagged' categories because they served the same
purpose, 'hacked' being on hacked autolathes and 'emagged' being on
hacked (emagged) limbgrowers.
Tech disk techwebs (which is created every time a disk is made, however
I hope to change this in the future) into it's own subtype, so admins
understand where its from when looking in VV panel (because I was
confused when I saw them at first).
``autolathe_crafted`` proc was removed because it was entirely unused
too.
Now it looks like this, which I consider an improvement:
## Why It's Good For The Game
We no longer initialize a brand new techweb for no reason whatsoever.
Each techweb made is making entire lists of experiments and research
papers, all of which is never to be seen in-game and is completely
useless to the player. Cutting down on these techwebs is a good first
step to this needless initializing.
## Changelog
🆑
qol: Removed the tech disk part of the ORM's UI as it was entirely
unused, now it's a little more compact with less scrolling needed.
refactor: Autolathes, Limb growers, Biogenerators, ORMs and Smelters now
share techwebs with other machines of their types, rather than all make
new techwebs each time. This means they only build their nodes once,
including hacked ones. Instead of researching nodes on hacking the
machine, they now show hacked ones depending on if it's hacked.
/🆑
Co-authored-by: Zephyr <12817816+ZephyrTFA@ users.noreply.github.com>
* Autounlock techwebs are shared between machines that use them.
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
Co-authored-by: Zephyr <12817816+ZephyrTFA@ users.noreply.github.com>
* Biogen shows default reagent container icons instead of beakers (#72247)
## About The Pull Request
With the new crafting menu some reagents now have default container
assigned.
I applied these to visualize reagents in biogen UI too.
<img alt="060ybChTkI"
src="https://user-images.githubusercontent.com/3625094/209483256-e4159a05-46ae-47b8-bc42-9d003cf6c303.png">
## Why It's Good For The Game
Better representation of a reagent.
## Changelog
🆑
qol: Biogenerator shows default reagent containers instead of beakers
/🆑
* Biogen shows default reagent container icons instead of beakers
Co-authored-by: Andrew <mt.forspam@gmail.com>
Co-authored-by: Zonespace <41448081+Zonespace27@users.noreply.github.com>
* Remove Mining LTSRBT + Change mining vendor costs to be less ass (#72380)
Removes Mining LTSRBTs
Adds a new cargo_cheaper variable to order consoles to make the tooltips
actually imply that express costs 1x
Mining Vendor cargo delivery now costs 0.65x (and rounded)
Express delivery costs 1x, no cooldown.
Costs displayed in the vendor are now multiplied by 0.65 to make them
show the cheaper price of buying by cargo
Encourage people to not fuck over ghost roles for their gamer mining
vendors
Encourage miners to cooperate with cargo techs (best case) to get their
gear cheaper
Encourage miners to talk to their own stationside department for their
gamer gear cheaper, while making miners
who dont do that, have costlier (normal price) gear
* Update interdyne_mining.dm
* SR maps
Co-authored-by: jimmyl <70376633+mc-oofert@users.noreply.github.com>
* [no gbp] removes all duplicate armor datums (#72354)
closes#72348
Title
My bad
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);
}
```
* modular
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Add lints for idiomatic balloon alert usage (#72280)
Adds lints for `balloon_alert(span_xxx(...))` (which is always wrong),
and balloon alert where the first letter is a capital (which is usually
wrong). Fixes everything that failed them. As a reminder, abbreviations
like "AI" and "GPS" shouldn't be capitalized in a balloon alert.
In cases where this is intentional for flavor (there was one case), you
can `UNLINT` like so:
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
* Converts drowsy and eye blur to status effects, striking yet another two carbon level status vars
* merge conflicts
* adjust_eye_blur and set_eye_blur_if_lower
* adjust drowsiness overdoses
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: tastyfish <crazychris32@gmail.com>
* Clean up something else which was failing CI (#72299)
## About The Pull Request
Well my last PR passed the CI but everything else is still failing and I
want a little tick next to my pull requests.
So I guess I'm whacking moles until everything that 515 doesn't know how
to dispose of is disposed of?
I'll be honest I don't know what change makes this a requirement when it
wasn't before but it seems like a logical thing to be doing.
Unfortunately running this test locally doesn't produce a failure for me
so my only solution is to keep getting the CI to do it and hope that it
doesn't report a false positive again.
## Why It's Good For The Game
## Changelog
Not player facing
* Clean up something else which was failing CI
* modular m90
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: tastyfish <crazychris32@gmail.com>
holoparasite types have improved code
admins can now give someone a holoparasite through a new menu in vv
dropdown
alt click holopara abilities were moved to right click (support's beacon
wasn't, but support's heal mode was)
holoparas have less hardcoded stuff so admins can edit them easier
holoparasites now get their light color from their guardian color
holoparasites no longer have the hostile faction, things will attack
them
holoparasites now have a damage overlay, so you can see how much your
summoner is damaged
holoparasite health updating is now event based rather than running on
life, so you'll see health changes everytime they happen, rather than
every 2 seconds
holoparasites fly properly again (they cant spacewalk, but count as
flying for stuff like chasms)
holoparasite creation now uses a radial menu with tooltips for each
subtype. it also shows ghosts which type you picked
holoparasites can no longer be fugu'd
adds support for ownerless holoparasites
fixes mildly related bugs along the way
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
Co-authored-by: Tastyfish <crazychris32@gmail.com>
* Crafting/Cooking menu update
* Yeeted away all of the merge conflicts, time to fix the code
* Okay, now it compiles, and after testing, it seems to work just fine
* Actually, early addition of an upstream fix, so those that don't have hunger can still open the cooking menu
* Fixes the units tests by removing the extra comma in the Stuffed Muli Pod recipe
Co-authored-by: Andrew <mt.forspam@gmail.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
* Basic Mobs can run away (#71963)
## About The Pull Request
That's right I'm still atomising #71421, some day I might even post
something related to carp.
This PR adds various behaviours to basic mobs allowing them to run away,
in a couple of variations.
Mice will flee from anyone who doesn't share their factions, at all
times (so they will scatter from most humans, but not regal rats).
Rabbits and Sheep will flee from anyone who has attacked them.
Pigs will run away from people who have attacked them, but only if
they're below half health.
https://user-images.githubusercontent.com/7483112/207127135-d1737f91-d3f7-468a-ac60-7c7ae5d6623d.mp4
Mice are still plenty catchable because they don't run _very far_ (or
very fast) but I think the chase will be good enrichment.
To achieve this I had to change the signal COMSIG_CARBON_HEALTH_UPDATE
into COMSIG_LIVING_HEALTH_UPDATE but frankly the latter seems more
sensible anyway.
## Why It's Good For The Game
More behaviours to use later when designing mobs, gradually gives mobs
more things to do rather than just sort of moving aimlessly around the
area you left them in.
It'll give people hunting rats in maintenance some exercise.
## Changelog
🆑
add: Mice will now run away from you, you have to catch them if you want
to eat them. Use those traps!
add: Rabbits, Sheep, and Pigs likewise won't just sit there and let you
pulverise them if they can see an escape route.
/🆑
* Basic Mobs can run away
* Modular!
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: Funce <funce.973@gmail.com>
* Smoothing groups optimization, save 265ms with configs, more on production & w/ space ruins (#71989)
This one is fun.
On every /turf/Initialize and /atom/Initialize, we try to set
`smoothing_groups` and `canSmoothWith` to a cached list of bitfields. At
the type level, these are specified as lists of IDs, which are then
`Join`ed in Initialize, and retrieved from the cache (or built from
there).
The problem is that the cache only misses about 60 times, but the cache
hits more than a hundred thousand times. This means we eat the cost of
`Join` (which is very very slow, because strings + BYOND), as well as
the preliminary `length` checks, for every single atom.
Furthermore, as you might remember, if you have any list variable set on
a type, it'll create a hidden `(init)` proc to create the list. On
turfs, that costs us about 60ms.
This PR does a cool trick where we can completely eliminate the `Join`
*and* the lists at the cost of a little more work when building the
cache.
The trick is that we replace the current type definitions with this:
```patch
- smoothing_groups = list(SMOOTH_GROUP_TURF_OPEN, SMOOTH_GROUP_FLOOR_ASH)
- canSmoothWith = list(SMOOTH_GROUP_FLOOR_ASH, SMOOTH_GROUP_CLOSED_TURFS)
+ smoothing_groups = SMOOTH_GROUP_TURF_OPEN + SMOOTH_GROUP_FLOOR_ASH
+ canSmoothWith = SMOOTH_GROUP_FLOOR_ASH + SMOOTH_GROUP_CLOSED_TURFS
```
These defines, instead of being numbers, are now segments of a string,
delimited by commas.
For instance, if ASH used to be 13, and CLOSED_TURFS used to be 37, this
used to equal `list(13, 37)`. Now, it equals `"13,37,"`.
Then, when the cache misses, we take that string, and treat it as part
of a JSON list, and decode it from there. Meaning:
```java
// Starting value
"13,37,"
// We have a trailing comma, so add a dummy value
"13,37,0"
// Make it an array
"[13,37,0]"
// Decode
list(13, 37, 0)
// Chop off the dummy value
list(13, 37) // Done!
```
This on its own eliminates 265ms *without space ruins*, with the
combined savings of turf/Initialize, atom/Initialize, and the hidden
(init) procs that no longer exist.
Furthermore, there's some other fun stuff we gain from this approach
emergently.
We previously had a difference between `S_TURF` and `S_OBJ`. The idea is
that if you have any smoothing groups with `S_OBJ`, then you will gain
the `SMOOTH_OBJ` bitflag (though note to self, I need to check that the
cost of adding this is actually worth it). This is achieved by the fact
that `S_OBJ` simply takes the last turf, and adds onto that, meaning
that if the biggest value in the sorting groups is greater than that,
then we know we're going to be smoothing to objects.
This new method provides a limitation here. BYOND has no way of
converting a number to a string at compile time, meaning that we can't
evaluate `MAX_S_TURF + offset` into a string. Instead, in order to
preserve the nice UX, `S_OBJ` now instead opts to make the numbers
negative. This means that what used to be something like:
```dm
smoothing_groups = list(SMOOTH_GROUP_ALIEN_RESIN, SMOOTH_GROUP_ALIEN_WEEDS)
```
...which may have been represented as
```dm
smoothing_groups = list(15, MAX_S_TURF + 3)
```
...will now become, at compile time:
```dm
smoothing_groups = "15,-3,"
```
Except! Because we guarantee smoothing groups are sorted through unit
testing, this is actually going to look like:
```dm
smoothing_groups = "-3,15,"
```
Meaning that we can now check if we're smoothing with objects just by
checking if `smoothing_groups[1] == "-"`, as that's the only way that is
possible. Neat!
Furthermore, though much simpler, what used to be `if
(length(smoothing_groups))` (and canSmoothWith) on every single
atom/Initialize and turf/Initialize can now be `if (smoothing_groups)`,
since empty strings are falsy. `length` is about 15% slower than doing
nothing, so in procs as hot as this, this gives some nice gains just on
its own.
For developers, very little changes. Instead of using `list`, you now
use `+`. The order might change, as `S_OBJ` now needs to come first, but
unit tests will catch you if you mess up. Also, you will notice that all
`S_OBJ` have been increased by one. This is because we used to have
`S_TURF(0)` and `S_OBJ(0)`, but with this new trick, -0 == 0, and so
they conflicted and needed to be changed.
* Sorting how did I miss it
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: Funce <funce.973@gmail.com>
* Changes the missing food icon test to cover ALL /obj's
* Update implant.dm
* Hopefully fixes all the failing integration tests!
* Fixes more missing icons
* Even more icon fixes
* Hopefully that was all of them
* Okay now SURELY that's all of them
* I'm tired of this shit man
* Hopefully that's all, for real this time!
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
Co-authored-by: Zonespace <41448081+Zonespace27@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
* fixes hollow survival pod window spawners (#72000)
## About The Pull Request
they used fulltile survival pods so it just spawned 4 full windows in
one place
## Why It's Good For The Game
i use them on my map and it upsets me
## Changelog
🆑
fix: fixes hollow survival pod window spawners
/🆑
* fixes hollow survival pod window spawners
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
* 3/4ths-ify some wall mount sprites (by Kryson and Viro) (#71788)
posters are now 24px tall, new sprites for nanomeds, emergency safes, and ticket machines
(by Kryson)
* 3/4ths-ify some wall mount sprites (by Kryson and Viro)
* DON'T INCLUDE FUCKING OVERRIDES IF THEY DON'T DO ANYTHING HHHNGH MY CI IS FAILING CODERS
* FUCK
Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
Co-authored-by: Jolly-66 <70232195+Jolly-66@users.noreply.github.com>
* Stacking machine input, output rotation (#71870)
All stacking machines spawn var edited. You could build one, but you
couldn't select the directions.
Now you can rebuild a stacking machine and rotate input/output as it was
before destruction.
* Stacking machine input, output rotation
Co-authored-by: Andrew <mt.forspam@gmail.com>
