* Adds IS_TRAITOR macro (#74293)
## About The Pull Request
i was making another PR and found that we have cultist, heretic, and
nuke op IS macros but not one for traitors
this adds one and then replaces it where applicable, mostly in checks
where a traitor device does something different if you are not a traitor
## Why It's Good For The Game
better for people making traitor only devices to have this macro, as it
is more clear and also cleaner in general i think
## Changelog
🆑
code: adds IS_TRAITOR macro
/🆑
* Adds IS_TRAITOR macro
---------
Co-authored-by: Sol N <116288367+flowercuco@users.noreply.github.com>
* Splits Pirates into Two Subgroups, One For Light Midrounds And Another For Heavy (#73881)
## About The Pull Request
This PR splits the Pirate midround antagonists into two separate groups,
normal and dangerous. Normal pirates are the human, silverscale, and
psycker groups, and they are all light antagonists now, meaning they can
show up early in the round, similar to when a revenant or nightmare can
spawn. Dangerous Space Pirates only consist of the Skeleton Crew, and
they will remain as heavy weight antagonists with the same spawning
restrictions as it is currently. I also fudged with the crew required
value some for both, not that it makes a huge difference.
Since pirates were split into two separate groups, both versions have a
reduced dynamic weight of 3, from 4.
Also added a sanity check to the pirate's dynamic ruleset to make sure
there are remaining pirates to be spawned for the ruleset to be allowed.
Also added a check to the pirate event itself to prevent runtimes when
no pirate team is available to be chosen, unless an admin specifies what
pirate team they want to use.
## Why It's Good For The Game
As it is right now, there is a massive difference between the skeleton
pirates and the rest of the pirate types. Skeleton Pirates have cannons,
innate space immunity and other small benefits which make them much more
threatening than the other pirate crews. In our current system,
something like Psycker pirates can spawn in lieu of something like blob
or xenomorphs when they aren't anywhere near the same level of
threatening, so moving the less dangerous pirates off to be light weight
midrounds seems like a good move, especially since we need more
lightweight midrounds to keep the variety up anyway.
Keep in mind these designations are not permanent and may change at the
request of maintainers or as the pirate teams get nerfed/buffed.
## Changelog
🆑
balance: The pirate gangs have been split into two subcategories, one
which can spawn earlier in a shift and one that spawns later as they
currently do. While skeleton pirates will still be only seen later into
the shift, expect to see the other pirate gangs earlier on.
fix: Prevented the pirate event from runtiming when no possible pirate
gangs were available.
fix: Pirates can no longer be selected by Dynamic if there are no more
pirates gangs that can be used.
/🆑
* Splits Pirates into Two Subgroups, One For Light Midrounds And Another For Heavy
---------
Co-authored-by: IndieanaJones <47086570+IndieanaJones@users.noreply.github.com>
* Cult Roundend Report No Longer Lists Post-Summon Cultists (#74255)
## About The Pull Request
Harvesters and any other post-summon cultists aren't shown in the
roundend report
## Why It's Good For The Game
Harvesters are a roundend thing, nobody cares who the harvesters were
since literally everyone becomes one even ghosts who observed since
roundstart
It just clogs up the roundend report
The cultists who contributed to summoning are the ones people are
interested in seeing
## Changelog
🆑
qol: Cult Roundend Report no longer lists post-summon cultists. No more
30 random Harvesters clogging up the roundend report
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@ users.noreply.github.com>
* Cult Roundend Report No Longer Lists Post-Summon Cultists
---------
Co-authored-by: 13spacemen <46101244+13spacemen@users.noreply.github.com>
Co-authored-by: MrMelbert <51863163+MrMelbert@ users.noreply.github.com>
* Kidnapping Alive Bonus TC price Increase: The Fair Kidnapping Wage Act of March 23th 2573 (#74258)
## About The Pull Request
Changes the Prices of TC for kidnapping objectives to more reasonable
prices that fit the challenge and switches some jobs into more fitting
positions for their cost of kidnapping
Common: Now gains +2 TC for alive targets
Uncommon: Now gains +3 TC for alive targets
Rare: Now gains +4 TC for alive targets
Captain: Now gains +5 TC for alive targets
Added a bonus for an assistant for being alive from 0 to 1 kidnapping
someone alive is always harder and so are assistants
Ckey to receive rewards: Hoolny
## Why It's Good For The Game
The current price of kidnapping is absolutely insane this feeling of
absolute unfairness of price has been exclaimed by various players that
understand the difficulty of kidnapping
Kidnapping is a much more difficult task than murdering someone for
various different reasons like having to move to a specific location an
announcement of where the location you send them is the fact that to get
the actual best price for it you need to keep them alive and such also
the main fact that you need to disguise or your identity will be leaked
its a monumental task which before hand contractor traitor had a better
price system for it so I'm not sure why the price was so low.
Another issue is NOBODY does this there aren't enough incentives and its
way to hard to do it for such a small reward this will make it so
kidnapping becomes a thing that happens more often it's a pretty cool
fun interaction and mission to have
## Changelog
🆑
balance: Increased Bonus Reward for kidnapping alive targets
balance: Changed Virologist and Scientist into Common objectives for
kidnapping
balance: Changed Paramedic into Uncommon objectives for kidnapping
/🆑
* Kidnapping Alive Bonus TC price Increase: The Fair Kidnapping Wage Act of March 23th 2573
---------
Co-authored-by: Hoolny <84478872+SethLafuente@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* Machines can now be pried open multiple times and maintain their initial densities (#74163)
## About The Pull Request
These changes fix how machines are pried open with crowbars. Currently,
most machines can be pried open, but many of them have no method for
being closed again. This means they can be pried once, and then never
again (as their internal logic has them stuck in an "open" state).
Additionally, the densities of these machines is also inconsistent, as
density is tied to the procs for opening/closing machines (open =
non-dense, closed = dense). Thus, these new changes allow desired
densities to be passed to `open_machine()` and `close_machine()`, as
well as `default_pry_open()`, meaning that atypical machine densities
can be maintained (e.g. machines that should remain dense when open, or
non-dense when closed).
I've also added a `close_after_pry` boolean parameter to the
`default_pry_open()` proc, which determines whether to immediately close
a machine after opening it. This is useful for machines that don't
really have a use case for remaining open, often lacking a sprite to
represent this state as well.
* Note: Opening and immediately closing machines with this boolean will
still drop their contents onto the floor, but will now immediately
"close" in their logic, allowing for further prying attempts in the
future.
It's worth noting that this implements default density values for these
procs, which match the existing behavior for machines, so as to
(hopefully) not disrupt existing or expected machine behavior.
Two caveats to these changes currently exist:
1. On machines that immediately close after prying, the prying action
can now be spammed to the chat with repeated clicking. I'm uncertain if
this needs some sort of spam protection or if it's fine as is.
2. I've only been able to manually test this code. I'd love to write
unit tests for it, as it affects a lot of different machines, but don't
know where to begin with DM Unit Testing (or which files would be good
examples to reference in the code base).
* Note: I did manually test each and every machine that calls
`default_pry_open()` and they all seem to be working correctly. (Except
for `obj/machinery/plumbing/sender`, but that doesn't seem to need
prying, as it has no contents to drop, only reagents.)
As always, let me know if any improvements/changes should be made.
This closes#26833.
## Why It's Good For The Game
These changes allow crowbar prying to correctly occur multiple times on
any machine, which is intended behavior. It prevents player confusion
that could occur when a machine couldn't be pried open a second time
during a shift, even though it had previously been pried before, forcing
players to question themselves. (Are they missing something? Did they
perform the action a different way last time? Is the machine actually
still powered on instead of off? Etc.)
These changes also maintain the correct density for machines after
prying, preventing scenarios where a machine might behave differently
once it had been pried open. (An example of this was being able to walk
through a smartfridge after prying it open.) Additionally, players are
no longer required to know/use workarounds (such as machine disassembly)
to retrieve a powered-off machine's contents.
Overall, these changes improve consistency around machines, creating
more scenarios where they behave as players would expect.
## Changelog
🆑
fix: machines can now be pried open more than once.
fix: machines now have the correct density when pried open.
/🆑
---------
Co-authored-by: san7890 <the@ san7890.com>
* Machines can now be pried open multiple times and maintain their initial densities
* wew
---------
Co-authored-by: Antonio Tosti <5588048+atosti@users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* [no gbp] Wizard Apprentices don't get the Grand Ritual (#74116)
## About The Pull Request
So it turns out "wizard apprentice" is a subtype of wizard.
I moved the "grand ritual" initialising step into its own proc which the
apprentice datum overrides to do nothing, so apprentices will no longer
gain the Grand Ritual button or objectives.
## Why It's Good For The Game
This would allow a wizard with an apprentice to trigger twice as many
events, and plausibly trigger two of the finale effects, which certainly
wasn't intended.
Apprentices can still watch your back and can also actually perform the
ritual invocation too (they just can't draw their own circles) so
they're still handy to have around for this purpose.
## Changelog
🆑
fix: Wizard Apprentices can no longer draw their own ritual circles.
/🆑
* [no gbp] Wizard Apprentices don't get the Grand Ritual
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Replaces internal_organs with organs
* Makes all of the necessary internal_organs -> organs in our files to compile
And it seems to work too!
---------
Co-authored-by: Time-Green <timkoster1@hotmail.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Roundstart Xeno egg deliveries create a Captive Xenomorph team, gives regular xenos a fluff objective so their popup isn't blank. (#73852)
## About The Pull Request
Xenomorphs who are a product of the roundstart xenobio egg delivery will
now spawn as "Captive Xenomorphs", who receive an objective to break
containment. Here's how it works:
When a delivery egg is generated that area will be marked as the
"captivity area". Xenomorphs born within this area now have their own
team, and have their own section in the roundend report that will
greentext them based on if they were able to survive and escape
captivity. Xenomorphs born outside of this area will spawn as normal
Xenomorphs, with no escape objective or special fanfare.
To further encourage people from actually taking the role and
potentially resigning themselves to an hour in Xenobio CBT prison, the
first of the hive gets their own header on the roundend report.
(When I say "team" here, I mean they receive a different antag team
datum. They're still able to collaborate and cooperate with other
Xenomorphs, they just have a different title and extra objective in
addition to the bonus roundend report limelight.)
(This also adds a basic "survive and advance the hive" objective for all
xenomorphs, since their objective popup was otherwise completely blank).
Since the captivity area is entirely dependent on the location of the
egg itself, admins can plop one of these down anywhere, and mappers
don't have to put the egg mapping helper specifically in Xenobio.
For clarification -- To be qualified for the Captive Xenomorph team, **a
delivery egg must be spawned**, and the xeno you inhabit must be born in
the same area the egg was spawned. If the queen breaks captivity and
starts nesting elsewhere on the station, their children will be born as
normal Xenomorphs, not Captive Xenomorphs.
## Why It's Good For The Game
Adds a bit of distinction, and gives bragging rights, to anyone bold
enough to take a roundstart xeno roll and escape with it.
The Xeno egg delivery is already rare enough, I think it deserves a bit
more fanfare (especially considering the dramatic impact it sometimes
has on the direction of a round).
## Changelog
🆑
add: Xenomorphs born in the room the roundstart delivery egg was spawned
in will be part of a special "captive xenomorph" team, tasked with
escaping and tracked in the roundend report.
fix: Regular Xenomorphs no longer receive a blank objectives popup on
spawn.
/🆑
* Roundstart Xeno egg deliveries create a Captive Xenomorph team, gives regular xenos a fluff objective so their popup isn't blank.
---------
Co-authored-by: Rhials <Datguy33456@gmail.com>
* Kidnapping won't destroy implants, nodrop items (#74118)
## About The Pull Request
Fixes#73985
Kidnapping was looping through mob contents to find items to remove from
you, rather than equipped items. It was then forcemoving them out of
you, destroying the functionality of implants and nodrop items.
Being kidnapped will now only remove equipped items from you (not
everything inside you) and will not forcemove nodrop items out of your
inventory (so it won't confiscate your chaplain armblade).
Additionally, anything you picked up in the kidnapping area was being
sent to nullspace on exit, I changed this to have them drop on the
ground instead.
However, due to this long-standing convention we now have an expectation
that items are not trivially moved in or our of the kidnapping area, so
it also loops through any storage implants you may have and dumps their
contents too.
There are still ways around this (cavity implantation, for instance) but
they seem uncommon and restrictive enough that they're probably not a
big deal.
## Why It's Good For The Game
Kidnapping another traitor destroying their implants was an annoying and
unpleasant experience (especially if it was their uplink implant), and
does not seem to have been intended.
Also removes weird behaviour where your arm blade might fall off because
you got kidnapped.
## Changelog
🆑
fix: Implants and items which you cannot drop will no longer be forced
out of your character when you are kidnapped.
fix: Objects you try to take back from the kidnapping location as
souvenirs will drop to the ground when you leave instead of being
destroyed, except shirts and shoes (make sure to pick up your
monographed synidcate T-shirt).
/🆑
* Kidnapping won't destroy implants, nodrop items
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Prevents airlocks from shocking players who use the rust mansus grip on them (#74026)
## About The Pull Request
Wire code is hell and needs a refactor bad; maybe I'll do that in the
future.
### Mapping March
Ckey to receive rewards: N/A
## Why It's Good For The Game
Closes#73989
## Changelog
🆑
fix: airlocks will no longer shock you when using the rust mansus grip
to destroy them
/🆑
* Prevents airlocks from shocking players who use the rust mansus grip on them
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
* Heretic sacrifice checks last mind as well (#74059)
## About The Pull Request
Makes heretic sacrifice a bit more generous when checking for high value
sacrifice. Checks last mind to inhabit the body as well as current mind.
Should fix cases where minds are swapped out (decapitation).
Modifies the message slightly if it is a high value sacrifice to let the
player know.
Fixes#74028
Fixes (the original source behind) #73236 (but not the issue itself)
## Why It's Good For The Game
More clear objectives
## Changelog
🆑 Melbert
fix: Heretic sacrificing now checks both the last mind to inhabit the
body as well as the current mind when checking for high value targets
/🆑
---------
Co-authored-by: san7890 <the@ san7890.com>
* Heretic sacrifice checks last mind as well
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
* Admins can now customize the outfit Necrostone victims wear and how many thralls the stone can produce. (#74014)
## About The Pull Request
Adds a new var to the necrostone that can be set to an outfit by admins.
The original roman skeleton clothing has been converted to an outfit.
I've also removed some single letter var names and added support for
disabling the species change and outfit change code for admins in case
they want to have a stone that only sets species/outfit.
Bonus changes: Admins can modify the max thralls per stone.
The stone no longer changes its description to show how many thralls are
under control every time a thrall is created, instead it is added as a
span_notice when the stone is examined.
## Why It's Good For The Game
This seemed like the logical next step when species customization was
added, a stone that turns people into felinids is funny and all but
isn't good gimmick material, however with this theres a bit more gimmick
potential, such as giving all the heads of staff a necrostone that turns
people into their employees or something. Also the necrostone not using
outfits for the roman skeletons seemed dumb.
## Changelog
🆑
admin: Admins can now customize the outfit necrostone victims are
equiped with.
admin: Admins can now customize the maximum number of thralls that can
be created by a necrostone
qol: The necrostone's thrall counter is now a shown as a separate
colored line of text when examining the stone rather than part of its
description.
/🆑
* Admins can now customize the outfit Necrostone victims wear and how many thralls the stone can produce.
---------
Co-authored-by: NamelessFairy <40036527+NamelessFairy@users.noreply.github.com>
* Cleans up `..()` usage in organs' `Insert()` and `Remove()` (#74055)
## About The Pull Request
fumbled around while investigating #74047 and turns out there's other
organs that have the same issue as the reported alien organs in that
issue. went around and replaced parent calls where applicable
(cursed/demonic hearts, flashlight eyes, alien organs, abductor glands)
## Why It's Good For The Game
Fixes#74047
Considerably less ghost internal organs, hopefully less unreported jank
on removing organs
## Changelog
🆑
fix: fixed a few internal organs acting wonky on inserting/removing
(some xenomorph organs, abductor glands, flashlight eyes, demon/cursed
hearts)
/🆑
* Cleans up `..()` usage in organs' `Insert()` and `Remove()`
---------
Co-authored-by: Sealed101 <75863639+Sealed101@users.noreply.github.com>
* Paradox clones spawns with "copies" of their target's memories (#73988)
## About The Pull Request
Paradox clones spawn with a "quick copy" of their target's memories.
These are notably limited in that they can't be used for stories
(engraving or tattoos), but if people metagame Paradox clones by saying
"engrave something for me" there's no hope for this community
Closes#73931
## Why It's Good For The Game
Stops a meta-y exploit
## Changelog
🆑 Melbert
fix: Paradox Clones now know that their target knows.
/🆑
* Paradox clones spawns with "copies" of their target's memories
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Post-Revolutionary Fervor station trait, revolutionary bedsheets, and a megaphone (#73799)
## About The Pull Request
Upon revolution success, the chosen headrev will now also receive a
megaphone, and a "revolutionary bedsheet" repurposed from a stolen CC
bedsheet to commemorate their success. The post-revs confusion and lack
of command/security usually leads to an instantaneous, total breakdown
in cohesion. It's every man for himself -- that's no way to run a
commune! Just because the revolution has succeeded and nobody can see
your big blue "R" anymore doesn't mean you can't be a leader!
This also adds a new revolution-themed negative station trait --
Post-Revolutionary Fervor. When present, this trait trashes the command
areas at the start of the round. This means cracked windows, broken
consoles, vendors getting knocked over, and the occasional dead
greytider.
If you start cleaning at the start of the round, you might finish right
as the next batch of revs decides to crop up.
## Why It's Good For The Game
Giving one of the headrevs a bigger voice and a cool cape (or uncool,
depending on how you view the sprite) means that there's a chance for
them to step up and try to keep the wheels on. Just remember -- Nobody
is obligated to actually listen to this person, it's just a bedsheet.
Adds a neato station trait, which probably counts as command gameplay
content.
## Changelog
🆑 Rhials
add: The headrev who receives the revolutionary banner after a win will
also receive a commemorative bedsheet and megaphone.
add: Post-Revolutionary Fervor station trait. I hope you enjoy fixing
broken computer screens.
spriteadd: A revolutionary bedsheet.
/🆑
* Post-Revolutionary Fervor station trait, revolutionary bedsheets, and a megaphone
---------
Co-authored-by: Rhials <Datguy33456@gmail.com>
* Fixes cult spell buttons being stacked ontop of eachother. (#73914)
## About The Pull Request
The system for making sure spells didn't get stacked on top of each
other didn't account for spells being expended out of order (e.g. you
use all charges of your third spell but since you have 3 spells slot 4
must be open). I've changed the code to account for this.
Should fix: #66894
## Why It's Good For The Game
Really frustrating and annoying bug finally fixed.
## Changelog
🆑
fix: When learning new cult spells their buttons will no longer stack on
top of one another.
/🆑
* Fixes cult spell buttons being stacked ontop of eachother.
---------
Co-authored-by: NamelessFairy <40036527+NamelessFairy@users.noreply.github.com>
* Pirate ship arrival custom announcements (#73839)
## About The Pull Request
Makes the pirate ship's spawning/arrival announcement editable too, for
additional flavor and cool factor.
## Why It's Good For The Game
Adds a bit more variety and immersion to pirate groups' arrivals; makes
pirate gang code more flexible and variable, thus allowing for more
pirate type customization, if people are to add more.
## Changelog
🆑 Stalkeros, san7890 for the announcement texts
code: Made pirate groups' arrival messages editable and more importantly
unique for each group.
/🆑
---------
Co-authored-by: san7890 <the@ san7890.com>
* Pirate ship arrival custom announcements
---------
Co-authored-by: Stalkeros2 <42087567+Stalkeros2@users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
* Fake nuclear authentication disks now have a placebo keep_me_secure component (making them more convincing) (#73890)
## About The Pull Request
In #73453, we were given the `keep_me_secure` component. Something I
think was long overdue, really.
However, it came at a terrible price...
<details>
<summary>The Lore</summary>
Tell me, John Assistant with absolutely no disk verifier skillchip,
which nuclear authentication disk is real?
The one on the plastitanium glass table?
The one on the titanium glass table?
Or the one on the reinforced plasma glass table?
The one on the plastitanium glass table you say?
B-but how did you know?!
</details>
tldr: Anyone can tell the real disk apart from fakes because only the
real one has the `keep_me_secure` component examine message! This PR
fixes that by adding the `keep_me_secure` component to fake disks. It
won't actually do anything - and I added a check to `keep_me_secure` so
it won't process if there are no callbacks passed, avoiding Free Lag.
This just gives the fake disks the same examine message as the disk, so
it won't be so obvious.
## Why It's Good For The Game
Bugfix good. Futureproofing good. Fake disk noob trap bad. Disk verifier
skillchip should actually do something.
## Changelog
🆑
fix: Fake nuclear authentication disks have been updated to include the
holographic security sticker found on the real disk, one again making
them convincingly real to the average person.
code: The keep_me_secured component will now only process if it has at
least one callback argument passed.
/🆑
* Fake nuclear authentication disks now have a placebo keep_me_secure component (making them more convincing)
---------
Co-authored-by: Vladin Heir <44104681+VladinXXV@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>
* Delete humanform.dm
* bad NANA!!!
* Update simple_animal_freeze.dm
* Update changeling.dm
* e
* wew
* Fixes the issue that caused CI to fail compilation
* Forgot to remove this one.
* wew
* fix screenshot unit test
* fixes emissive CI
* color cutoffs
* more emissive fix
* Update wardrobes.dm
* tallboy
* fix
* regen screenshots
* Update dna.dm
* screenshots
* Update dna.dm
* Fixes the lesserform unit test
* Adds our own monkey screenshots because we have monkey jumpsuits :)
---------
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Limit theft/destroy secondary objectives to items which at least one person cares about
* Update objective_items.dm
---------
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>
* Grand Ritual: Alternate Wizard objective (Wizard Events II) (#72918)
Adds an alternate greentext objective for Wizards known as the "Grand
Ritual". This was initially the gimmick of a different wizard-related
antagonist downstream. I didn't get permission to port it, so I'm
attaching it to regular Wizards instead.
Wizards will spawn in with a new Grand Ritual button next to their
antagonist info button. Pressing it will pinpoint them towards their
next Ritual Location (a randomly chosen region of the space station).
Once within that location, pressing it will summon a magic circle and
obliterate any dense objects which are in the way. This also puts the
ability on a two minute cooldown.
Clicking on the magic circle with an empty hand will begin a three-stage
invocation to gather magical power. You can interrupt this invocation at
any time and will resume from the last stage you completed (if you
finished two stages you only need to do one more).
Once you complete a ritual, a random event will be triggered based on
how many rituals you have performed so far. These tend to be ones which
annoy the crew in some manner, and Wizard Events are included in the
list. Additionally, something weird will usually happen to the room you
are in.
Then you are assigned a new location and can toddle off to do it again.
Once you have done this three times, you will be picked up by the
station's sensors every time you start a subsequent ritual and should
expect annoyed company to come investigate.
Once you have done this six times, you can finally spend all of that
accumulated power on the seventh Grand Finale ritual. Completing this
grants you victory at the end of the round and will have a larger,
flashier effect which you can pick from a list of options, think of it
like a wizard equivalent of a Traitor Final Objective or Heretic
Ascension.
After that you can still keep doing rituals if you want to pester the
crew further by summoning more random events, you've already "won" at
this point so now it's your job to make them want to go home.
I think it'd be more fun to just find out what the Finale ritual can do
by seeing it happen but maintainers will probably want a list of its
precise capabilities, so here it is:
Currently completing a ritual also has a chance to create Heretic
Reality Tears (of both varieties, available for Heretics to eat and
visible to crew) as a kind of cross-antagonist interaction which seemed
to make sense to me but if this seems thematically or mechanically
inappropriate it's easy to strip out.
* wew
---------
Co-authored-by: Jacquerel <hnevard@gmail.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>
* Refactors abstract traitor objectives to be more abstract and enforces this by using unit tests. Rebalances some traitor objectives (#73777)
## About The Pull Request
In this PR, some of the traitor objectives are rebalanced to be more
consistent with scaling risk.
Abstract traitor objectives have had their telecrystal reward and
progression rewards moved to their non-abstract types and it's now
enforced that abstract objectives should not have these values set.
Additionally, it's encouraged that people don't set progression_minimum
on abstract types either, but I can see the usecase in doing so with
final objectives and assassinate objectives. This is why it's fine to
set progression_minimum on an abstract type as long as any of the
derivatives of that abstract type do not redefine the progression
minimum to avoid consistency errors when tweaking progression minimum
values. Setting the progression minimum on an abstract type means that
all derivatives of that abstract type should be unlocked at roughly the
same time.
## Why It's Good For The Game
The rebalances are so that same risk objectives of different types are
worth around the same amount. Repeatables should roughly award the same
amount of TC when it comes to comparing the risk, but the progression
rewards can vary.
The new standard enforcement on abstract traitor objectives is more so
for robustness and ease of balance, as it's easier to lose consistency
when rebalancing values between two objectives, because one of the
objectives derive their rewards from an abstract type. Generally
speaking, rewards from objectives of different risk level should not be
the same and it's easier to enforce this if developers have to
explicitly declare the rewards of the objectives they add.
This doesn't mean each objective has to declare explicitly what their
reward is. Derivatives that subtype off of non-abstract types can still
copy the rewards from their parent.
The progression minimum is fine to be set on abstract objectives as long
as derivatives don't change the progression minimum. If they do, then
it's better for consistency to declare the progression minimum on each
type rather than the abstract type so that higher-tier objectives don't
accidentally end up with a lower progression minimum when it comes to
rebalancing. Of course, this isn't a set rule on, but it's something I'm
going to try and enforce, when it makes sense, going forward, even if it
may increase the number of lines of code each traitor objective file may
have. Maintainability and robustness beat optimization.
## Changelog
🆑
code: Abstract types don't hold telecrystal rewards or progression
rewards anymore, this has been moved to the non-abstract types.
balance: Rebalances rewards from repeatable traitor objectives to be
more consistent with each other.
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Refactors abstract traitor objectives to be more abstract and enforces this by using unit tests. Rebalances some traitor objectives
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Fixes russian fugitive hunter to_chats, adds missing one for bounty hunters (#73826)
## About The Pull Request
Upon taking a fugitive spawner, you were SUPPOSED to receive a quick
lore blurb to help get you into character, or something. This only
worked for the spacepol hunters, however, as the to_chat's for the
Russian spawner would send to the user's antag datum rather than their
chat, and the bounty hunters were missing theirs entirely.
## Why It's Good For The Game
Reading and text is really good for your eyes and brain.
## Changelog
🆑 Rhials
spellcheck: Fixes the Russian/Bounty Hunter fugitive hunter spawn
backstory messages.
/🆑
* Fixes russian fugitive hunter to_chats, adds missing one for bounty hunters
---------
Co-authored-by: Rhials <Datguy33456@gmail.com>
* Fixes pirates and starfury assailants transferring minds (#73833)
## About The Pull Request
Same issue as before, these skipped the spawn step and snowflaked their
own creation process.
So I split off the create part of attack ghost so these could share.
Fixes#73823 , may fix also #73822 but I don't *think* it will, whatever
changed spawners a few months ago is a little sus
## Why It's Good For The Game
Changeling pirate bad
## Changelog
🆑 Melbert
fix: Fixes pirates and starfury assailants keeping minds of past lives
/🆑
* Fixes pirates and starfury assailants transferring minds
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
SkyratBot
