## About The Pull Request
Last Christmas we had and resolved this bug #88595 where via the
mechanic of buying random trash, Cargo could roll on the roulette to try
and get random Christmas presents and open them for random items.
This was removed because it's not supposed to work that way and was a
way of exploiting Christmas cheer for personal gain, which is grinchsome
behaviour.
That said, being able to order Christmas presents is also kind of
soulful, so this PR brings that mechanic back but on purpose this time.
During the Christmas season _only_, Cargo can spend 3000 credits of
their budget to order a "Surplus Christmas Gifts" crate which contains
4-6 presents _with pre-assigned recipients_.
In a similar system to addressed mail, only the person written on the
gift tag can open the present, so unless you're sufficiently scroogeous
to collect a huge pile of presents on the cargo room floor in hopes of
getting a couple with your name on (in my testing these contained raw
unbaked croissant dough, and a piece of paper from a space ruin) you
should mostly be using this to deliver generalised holiday cheer to the
crew rather than just yourself.
This PR also contains (maybe as more lines than the actual feature) a
refactor changing a bunch of boolean vars on `/datum/supply_pack` into
bitflags, because I needed to add one more and it seemed silly to have
so many booleans.
## Why It's Good For The Game
It allows those with the yuletide spirit to deliver some christmas cheer
to their fellow man, isn't that the season's reason?
## Changelog
🆑
add: When the game considers it to be Christmas, Cargo can order
additional Christmas gifts pre-addressed to random crew members.
/🆑
## About The Pull Request
/area/station/ai_monitored's behaviour was isolated into a component,
`/datum/component/monitored_area`, which itself uses
`/datum/motion_group`s to query cameras. Functionally, it (should) work
identically to the old implementation. I'm sure that behaviour could
have been further cleaned up, camera code is quite dreadful, but it's
better to focus on isolating the behaviour first. Baby steps.
Areas that want to opt into monitoring can set `var/motion_monitored` to
TRUE (this approach was taken to make subtyping easier).
The following non-AI areas were changed:
- /area/station/ai_monitored/security/armory ->
/area/station/security/armory
- /area/station/ai_monitored/command/nuke_storage ->
/area/station/command/vault
- /area/station/ai_monitored/command/storage/eva ->
/area/station/command/eva
All other `/area/station/ai_monitored` subtypes were repathed into
`/area/station/ai` and cleaned up in a way that I thought made logical
sense. It is **much** more readable now. For example:
- /area/station/ai_monitored/turret_protected/aisat ->
/area/station/ai/satellite
- /area/station/ai_monitored/command/storage/satellite ->
/area/station/ai/satellite/maintenance/storage
- /area/station/ai_monitored/turret_protected/ai ->
/area/station/ai/satellite/chamber
## About The Pull Request
Pre-discussed with @Watermelon914, this PR removes Secondary & Final
Objectives from all Traitors, rather than just midround ones. It also
removes all of the surrounding supporting code.
Randomly assigned Primary Objectives still exist, I just used the
ability to rewrite mine to take the screenshot.
In terms of final objectives, the surrounding items that were available
still exist but don't necessarily have sources.
If anyone has good ideas for readding these in some other form it can be
done in future PRs.
It also allows all traitors to buy the Contractor kit, previously
limited to midround traitors which lacked secondary objectives, because
now all traitors lack secondary objectives.
This essentially limits all traitors to a maximum of 20 TC (16 if they
spawn with an uplink implant). Currently I don't foresee that they
strictly need any additional way of gaining TC during a round as 20 is
quite sufficient, but it may take some time to adjust and get used to it
after such a long time of having access to more. If we need to adjust
the starting value or add a slow drip of more points over time or
something, that can be done in followup PRs.
This also removes the ability to recreate your uplink added by my
beautiful wife in #74315
This was part of the progression traitor design document, but ultimately
probably a bad idea as it essentially made traitors impossible to
properly disarm. You will once more just need to carefully protect your
uplink.
**This does not remove the threat/progression system**.
Like midround traitors, all Reputation requirements on gear are now
simple timelocks, most of which will have elapsed by the time 30 minutes
have passed.
**Finally** this PR also adds Romerol to the traitor uplink for 25 TC
and 30 minutes of reputation, as a treat (and because I removed the
final objective that previously granted it).
## Why It's Good For The Game
We've tried this system for a long time (3 years last month!) and while
I think it had a lot of promise, enabled some cool moments, and also
solved several of the problems it set out to solve, overall I think some
of the behaviours it has encouraged in players have been overall
negative for the game.
While the _game systems_ are fine, even quite fun and cool (especially
final objectives) I am of the opinion that having them in the game
creates a net negative purely in the way that they react with players'
_brains_, creating incentives towards behaviour we don't actually want
people to pursue.
While it's hard-to-impossible to prove any of this with hard data, there
has been a prevailing feeling for some time among many (though certainly
not all) people that the simple fact of _having_ a constant drip-feed of
objective available to players leads directly to less interesting
antagonist play. While certainly nobody is _forced_ to do secondary
objectives you are directly and quite strongly rewarded for doing so,
doing so efficiently, and doing so in a way which makes sure that nobody
(alive) sees you do it. This leads to a tendency to play defensively and
try to maximise the number of tasks you can complete in one round, which
also has a knock-on effect of generally minimising the number of people
you attempt to interact with in a round (unless you are killing them).
Even people who _intend_ on doing some more interesting gimmick can fall
into this trap, as "having more tools" is always useful for anyone who
is intending on any kind of plan at all, but then executing on the
secondary objectives again incentivises you to lay low, not interact
with anyone, be efficient, and then reduces the time you are spending
doing the thing that's your actual plan for the round. Removing the
ever-present temptation to fish for extra TC leaves "doing whatever your
actual plan is" as the sole thing to optimise.
Final Objectives too have created unfortunate psychological effects
between crewsided players and other antagonists. Because of the _threat_
(no matter how remote, Final Objectives have always been tuned to be
appropriately rare) that leaving any antagonist alone will cause them to
snowball by acquiring more power, it starts to feel foolish to respond
to any threat with less than the maximum possible level of force even if
they seem relatively innocuous in the moment. This even has an effect on
other non-progression antagonists, as traitors are the most common
antagonist type and how people treat them is going to be their default
level of reaction to most other station threats.
While there has always been the promise of expanding the system with
novel and exciting objectives that leverage appearing mid-round to do
something unique, we've taken very little advantage of that over time.
Most objectives we have added that didn't boil down to "kill someone,
with a twist" have been somewhat unsuccessful, serving either as ways to
get yourself arrested and killed for no reason or ways to get free
telecrystals by doing something the crew don't really care about
stopping you from doing. The option still exists to add more roundstart
objectives to traitors, if someone suddenly has a great idea that would
fit in this space.
The ideal outcome of making this change is a slight relaxation of crew
attitude towards feeling like their only option after catching an
antagonist that isn't sandbagging is to permanently remove them from the
round (although it's fine to do this still in many scenarios), and a
broadening of traitorous activity which is not purely focused on
collecting as many checkboxes as possible and might give people more
time to roleplay with other players, not worrying that this time could
have been more efficiently spent pursuing a different secondary goal.
I don't anticipate or desire that this will prevent traitors from
killing anyone (or even stop them from killing people they don't have a
specific objective to kill), I just want to remove the FOMO from
people's minds.
Also this gives us something to talk about at the coder townhall meeting
on the 22nd.
## Changelog
🆑
del: Misplaced or stolen traitor uplinks can no longer be recreated
using a radio code and special device, guard yours carefully or buy a
backup implant.
del: Roundstart traitors can no longer take on additional objectives in
order to earn additional Telecrystals and fast-forward any unlock timers
on items. They also cannot earn the ability to complete a Final
Objective.
balance: Roundstart traitors can now buy the Contractor Kit from their
traitor uplink, rather than only midround traitors.
add: Traitors can buy Romerol for 25 TC, after 30 minutes of time has
passed in a round.
/🆑
## About The Pull Request
Must have missed this in initial tests. Cancelling the stray syndicate
cargo pod event while modifying the telecrystal value or uplink type did
not cancel it. Now it does.
Bonus - Uplinks that have been introduced since customization was added
have been added
## Why It's Good For The Game
I may have accidently dropped a syndicate cargo pod on a station today
and I'd prefer to do it intentionally.
## Changelog
🆑
fix: Admin fired stray syndicate cargo pods will not rebel against admin
whims and launch themselves when cancelled.
admin: Admins have new categories to fill syndicate cargo pods with.
/🆑
## About The Pull Request
Three changes to ghost orbit popups. Let's check them one-by-one.
First off -- The obsession awakening and blob host midrounds now have a
ghost popup when summoned via Dynamic. They already have them when
summoned by a random event roll, so this is mostly just bringing the two
different spawn methods in line with each other. None of the other
midround dynamic picks (autotraitor, revs, etc) have had this added,
because they're less focused on spectacle and require more mystery to
function properly.
Second -- The electrified railings on the tram no longer notify ghosts
every time someone gets shocked. Electrocute_act is called on anything
that passes by it, and the popup would be thrown regardless of whether
or not they've "fallen in the path of an oncoming tram" or not. Making
it check if the electrocute_act actually successfully stunned a player,
and that they're about to be hit, would probably require an unwieldy
rewrite to the behavior that I'd rather not resort to. I brought this
helper call into this world, and now I'm taking it out.
Lastly -- The supply pod random event can now be properly jumped to.
Originally, it would track the landing indicator, which would delete
almost immediately and leave an un-orbitable popup on your screen. Now
you jump to the landing zone, regardless of when you click the toast
popup.
This is really long PR body for such tiny changes please don't think
this is anything more than it actually is.
## Why It's Good For The Game
Minor improvements to some ghost orbit popups, because Observers are
players too!
## Changelog
🆑
qol: Dynamic midrounds "Obsession Awakening" and "Blob Host" now have
ghost orbit popups, so you can see them happening in real time.
qol: There is no longer a ghost orbit popup for players being shocked by
an electrified tram rail.
qol: The Stray Cargo orbit popup no longer has a half-second window to
orbit before it becomes useless.
/🆑
## About The Pull Request
Adds an announce_to_ghosts for the landing zone indicator spawned by the
cargo pod event. This means that the ghosts are alerted to where the pod
lands and also get to see the effects of the impact if they choose to
hop over.
## Why It's Good For The Game
Gives deadchat yet another form of idle stimulation -- something for
them to congregate around and have a thoughtful discussion about.
I realize that this is the third "adds a ghost orbit popup to a random
event" PR, so give me a heads up if there are any other events that
would benefit from having an announce_to_ghosts and I can just add them
here.
## Changelog
🆑
qol: Ghosts are now notified and given an orbit popup for the Stray
Cargo Pod random event.
/🆑
False alarms for stray cargo pods were no generating a impact_area which
is used for the announcements, I've added code that checks if the alarm
is false and generates one in this case.
## About The Pull Request
Requested by @tralezab
Admin event setups now use a list rather than a single setup. This means
common functionality list setting position and picking an option from a
list can be applied to events that have multiple customizable factors
rather than needing to making entirely overridden subtypes for every
event.
Adds a few new subtypes of event_admin_setup:
- input_number for setting a number value. An example can be found in
the heart attack event.
- set_location for causing an event to occur in a specific location. An
example can be found in the stray cargo pod event.
- question, yes no question that returns true/false. An example of its
usage can be found in immovable rod
- candidate_check, a more niche subtype used to block events that do not
function unless theres a specific number of valid candidates. An example
of its usage can be found in the disease events.
While doing the refactor I also implemented some simple extra options
for some of the refactored events. Classic Disease now has an option for
admins to roll **any** disease rather than just the "safe" ones. And
shuttle catastrophe now allows admins to select which shuttle is used.
## Why It's Good For The Game
Cuts back on duplicate lines of code a lot, should make adding more
customization to events slightly easier. Also more admin customization.
## Changelog
🆑
refactor: Admin event setup's have been refactored to use lists.
fix: When admins customize the pirate event all options will be
available rather than just options that have not been randomly rolled.
fix: The stray meteor event no longer runtimes when customized by
admins.
admin: Admins can now select the shuttle brought in by the shuttle
catastrophe event.
admin: Admins can now randomize the disease outbreak classic event to
roll any disease type, including transformation diseases so have fun
with that.
/🆑
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.
## About The Pull Request
Gives admins the ability to rig where the stray drop pod will drop in
addition to rigging what type of cargo crate regular drop pods contains
and how many telecrystals and which uplink syndicate droppods will use.
## Why It's Good For The Game
More control for admins regarding drop pods, while admins can spawn drop
pods normally these drop pods have slightly different behavior that
changes their usecase. I think it'd be highly useful for admins to for
example spawn in a clown ops surplus crate as part of a TC trade or
randomly spawn a crate full of gnomes thats announced to the crew so
they can hunt for them.
## Changelog
🆑
admin: Admins can now customize the crate type and landing zone of the
stray drop pod event.
/🆑
## About The Pull Request
Area contents isn't a real list, instead it involves filtering
everything in world
This is slow, and something we should have better support for.
So instead, lets manage a list of turfs inside our area. This is simple,
since we already move turfs by area contents anyway
This should speed up the uses I've found, and opens us up to using this
pattern more often, which should make dev work easier.
By nature this is a tad fragile, so I've added a unit test to double
check my work
Rather then instantly removing turfs from the contained_turfs list, we
enter them into a list of turfs to pull out, later.
Then we just use a getter for contained_turfs rather then a var read
This means we don't need to generate a lot of usage off removing turf by
turf from space, and can instead do it only when we need to
I've added a subsystem to manage this process as well, to ensure we
don't get any out of memory errors. It goes entry by entry, ensuring we
get no overtime.
This allows me to keep things like space clean, while keeping high
amounts of usage on a sepearate subsystem when convienient
As a part of this goal of keeping space's churn as low as possible, I've
setup code to ensure we do not add turfs to areas during a z level
increment adjacent mapload. this saves a LOT of time, but is a tad
messy
I've expanded where we use contained_turfs, including into some cases
that filter for objects in areas. need to see if this is sane or not.
Builds sortedAreas on demand, caching until we mark the cache as
violated
It's faster, and it also has the same behavior
I'm not posting speed changes cause frankly they're gonna be a bit
scattered and I'm scared to.
@Mothblocks if you'd like I can look into it. I think it'll pay for
itself just off `reg_in_areas_in_z` (I looked into it. it's really hard
to tell, sometimes it's a bit slower (0.7), sometimes it's 2 seconds
(0.5 if you use the old master figure) faster. life is pain.)
## Why It's Good For The Game
Less stupid, more flexible, more speed
Co-authored-by: san7890 <the@san7890.com>
About The Pull Request
Brings back the scrubber overflow event, previously removed in #53549
This version has nerfed numbers because foam changes made it stupidly powerful.
Also snake_cases some event variables.
Why It's Good For The Game
More dangerous but not station-damaging events. Bonus: janitor content.
Changelog
cl
add: Re-adds the scrubber overflow event as a random event
/cl
About The Pull Request
kép
This PR does the following:
Force event menu uses tgUI.
Arranged events into categories, and added a little description to each. The descriptions appear as tooltips when you hover over the Trigger button.
Rewrote how "Announce to crew?" works. It no longer pops up a panel after the event has been already announced. Instead, the admins select it via a checkbox, and the result is passed through an optional argument.
announceChance's comment is tweaked a bit to reflect how it actually works at the moment.
Moved rpgtitles to wizard events, where it belongs.
Fake Virus and Electric Storms show up to observers, as I believe they are not as common as Space Dust or Camera Failure, and should be cancelable.
Potential issues:
This only solves half of #68408, I don't think admin triggering having a timer and a cancel button is a big issue, as it allows other admins to overrule you if needed, but if i is, I will try to fix it within this PR.
Fixes#68408. Events now spawn immediately, and the the announceChance is overwritten before it begins.
My choices for categories and descriptions might not be the best, feedback would be appreciated.
Why It's Good For The Game
The old spawn menu was completely unorganized, and you could only search using the browser search tool. I believe a built in search bar helps with this issue a bit. I also believe that organizing the events into categories, and adding descriptions will help with newer admins who might not be familiar with all events.
Changelog
cl
refactor: The Force Event UI has been refactored
refactor: Events now have categories and descriptions
refactor: Admin triggered events happen immediately
balance: Fake Virus and Electric Storms are shown to admins, making them cancelable
/cl
Areas.dmi right now houses all of our mapped turfs icons (which is roughly 400 icons). Not an issue, but it's incredibly large and clunky to navigate right now. This isn't an issue for the average coder and/or player code diving, but it is for mappers wanting to add new turfs. Currently, the file has some organization, but its still an overall mess. This PR aims to slice the behemoth with multiple .dmi files corresponding to specific areas.
I also plan to repath /area/* -> /area/station/* for station turf only. This is to clean it up, as most other turfs follow this format (that being /area/turf_zone/*).
I'm also writing an update paths file as I go along.
About The Pull Request
Adds an argument to typecache generation that allows specifying the whether to include/exclude types in the input list.
Also adds another argument to specify whether to remove falsey values after the typecache is generated.
Why It's Good For The Game
Might make zaps slightly faster???
Honestly I just thought it would be a good way to condense some whitelist/blacklist typecache sets.
Creates update_name and update_desc
Creates the wrapper proc update_appearance to batch update_name, update_desc, and update_icon together
Less non-icon handling code in update_icon and friends
Signal hooks for things that want to change names and descriptions
99%+ of the changes in this are just from switching everything over to update_appearance from update_icon
This PR repaths areas to follow a department - purpose - room formula (just department - room if purpose is unnecessary), reorganizes the area file to properly sort by department, removes some unused areas, and better utilizes child subtypes for areas. It fixes several problems with areas which were previously improperly subtyped causing problems like the lack of AI monitoring on vault areas and the inability to use the civilian door remote on most service areas.
Properly organizing our areas will make mistakes in adding areas or duplicates harder to do. By organizing each department in this way, it also provides better infrastructure for autoname devices and any future code that has to reference areas by department.
WIP overlays
icon upd8
more
need to figure out whats going on with extractionpods
compile
the icon update
more!!
why are skillcapes broken
boat lmao
seethrough fix
Second drive-by
Code cleanup and improvements
Specifically surrounding contractor pods and reverse mode working properly
accidently left in an extra dmi whups
do the impossible see the invisible
new effect booster pack
MFW MRW Linter fail
* Case of lower
* More changes
* Ruins the nice 420 diff, brainfart when doing the second batch of conversions
* More changes
* Next batch. I think
* Converts even more paths
* Restarts bots
* Capital Free Zone
* Come on travis, do something
* Renames areas
* Bots, please stop dying
* Updates CONTRIBUTING.md and updates a few paths I missed.
* APC recgarftzfvas
/obj/item/computer_hardware/recharger/apc to /obj/item/computer_hardware/recharger/apc_recharger
About The Pull Request
Adds an event where a cargo pod containing a random cargo supply pack crash-lands on a random spot on the station.
Added a rare variant (post 30 minutes) that spawns a null crate with 30 TCs of gear.
Crates which would be locked when ordered from cargo will start unlocked when falling with a stray cargo pod.
Note: i'm not yet able to compile or test the code myself, will do it as soon as possible, before tomorrow done, all fine
Why It's Good For The Game
A fairly neutral event that could benefit some lucky assistant, throw shotguns inside the cult base, or simply land on the head of some very unlucky person.
I think more variety will be nice for the game.
Changelog
🆑 XDTM
add: Added the Stray Cargo Pod event, which drops a pod containing a random cargo crate into a random location. Rarely, one might even contain assorted syndicate gear!
/🆑
