## About The Pull Request
Fixes#71092
## Why It's Good For The Game
Flaky tests bad, fixman good...
## Changelog
🆑
fix: Pubby's whiteship no longer breaks when it tries to dock
/🆑
## About The Pull Request
This PR improves our jetpacks in 2 major ways: partially decoupling them
and intentional space movement from SSnewphys, and implementing
consistent pushoff speeds.
Currently jetpacks work by applying constant newtonian force whenever an
input key is held down by a client and stabilizing the movement every
time they get processed by SSnewphys which is an SS_TICKER subsystem,
which means that it attempts to fire prior to everything else and has a
wait of a single tick. This would be fine if we could guarantee that
there isn't another SS_TICKER subsystem with a higher priority that
constantly overtimes... oh right, that'd be the most important subsystem
of SSinput.
Newtonian impulses, both when starting a drift and when applying
continious force rely on SSnewphys to fire the loop, which can end up
not happening due to overtime in input (and is a frequent issue on
highpop). To circumvent this, newtonian impulses now forcefully fire
their drift loop regardless of SSnewphys, thus ensuring that the
movement always happens in the tick it was called (If you ask something
to move with an ``instant`` flag you'd expect it to move the same tick).
Second issue stems from the fact that jetpacks try to move you at your
movement speed, except when pushing you off objects they hijack normal
movement code that would've ran, resulting in a single tile of slow,
janky movement (Or, when moving along walls, making the controls feel
"sticky" and worse than what you'd have without a jetpack in the first
place). By forcefully applying enough force to make players move at
expected speeds, we can solve that issue.
Third issue stems from a minor mistake in SSnewphys processing order -
process() on jetpacks ran **after** moveloops have fired, so all
stabilization only applied next tick. I swapped fire orders around which
solves this problem too, although it won't be triggering much as
stabilization would now forcefully fire the related loop by itself.
https://github.com/user-attachments/assets/1068f68b-2cd1-49b0-bff0-1f79ed0aed5a
Also I've refactored wings to be jetpacks since they behave exactly the
same, which is a bit cursed if you think about it.
## Why It's Good For The Game
Jetpack movement is highly inconsistent in speed/smoothness, janky and
gets ruined by even a slightest amount of overtime in subsystems above
it - this should solve all of those issues.
## Changelog
🆑
qol: Jetpacks are significantly smoother and nicer to use now - and not
affected by lag anymore!
code: Cleaned up spacemove/jetpack code a bit and moved some common code
to helpers.
refactor: Wings are now... jetpacks. They behave exactly the same and
this should reduce the amount of copypaste code in spacemove
significantly.
/🆑
## About The Pull Request
- Fixes#76827
This removes gravity from the following areas:
- Solars
- Nearstation
- Space
- Ordnance bomb testing
##### Note - Asteroid areas (Tram) or planet areas (Ice) are not
affected.
<details>
<summary>Examples of outside gravity turfs</summary>
</details>
Now stepping on floor plating in those areas will result in mobs
drifting. (like they do inside the station when gravity is offline)
Stepping on or near catwalks, lattices, or walls stills controls your
movement. Also refactored a little bit of the `has_gravity` code to use
defines instead of `TRUE/FALSE`.
## Why It's Good For The Game
Consistency. Mag boots are highly recommended when performing EVA.
## Changelog
🆑
fix: Fix gravity for areas in space near station (solars, nearspace,
bomb testing, etc.)
/🆑
## About The Pull Request
refer to title
No code changes were made here, i just copypasted code around
The only real difference is that I removed a pretty useless define that
depended on TESTING because it got in my way of splitting emergency.dm
tbh i didnt want a 50k line refactor pr that nobody is going to review
so im getting it out of the way in a separate PR
## Why It's Good For The Game
Shuttle code is literally all over the place please help me oh gosh
## Changelog
Nothing player facing or developer facing (at least I really hope so)
## About The Pull Request
Detomatix doesn't pass the ``bomb`` arg to ``log_bomber`` for a rather
obvious reason, and admin messaging code takes that into account. Not
the check that allows that code to run though, that part just runtimes.
Admins should probably be actually informed about players using
detomatixes, yeah.
## About The Pull Request
You can now fish from aquariums if you wish to. This includes some
backend changes to make it possible for the fish table from
get_fish_table() to contain instances, and all that it entails up to
spawn_reward(), which is a requirement for the gimmick to respect the
various traits and other variables of the already instantiated fish
rather than read from cached properties.
## Why It's Good For The Game
The fish progress score/index had only little nasty flaw that has been
nagging me since day one: Not all fish species can be caught. Skipping
McGill, which is a peculiar case that for cheevo purposes should be
considered a standard goldfish, there is the one, unsignificant yet rare
purple sludgefish which can only be gotten as a rare evolution of the
generic sludgefish. Talk about petty, but this may be a long-term nit I
prefer to handle right now.
Also why not? The 'unmarine mastodon' is near impossible to get unless
you somehow find a oil well which is locked behind a specific ruin.
## Changelog
🆑
fix: Aquariums are now potential fishing spots.
/🆑
## About The Pull Request
https://github.com/user-attachments/assets/173c1753-3da4-4180-80ea-eb49d19e7b2f
Purely visual. Pulling someone from an IV drip is dangerous so it's nice
to make it more clear than the current very small appearance change that
doesn't give you any more information than that *someone* is connected.
If you review tell me on Discord bc I don't check GitHub
## Changelog
🆑
qol: IV drips now create a beam from their spout to your body, and will
visually pull you closer.
/🆑
## About The Pull Request
Somewhat of a port of
https://github.com/ParadiseSS13/Paradise/pull/26401, albeit re-done from
scratch (with the power of find and replace)
Caller is a protected/reserved var in 516. We use it a lot. It's used in
more places than this, but I'm a perfectionist and can't think of better
names for most of the other uses (mostly mob AI, holocall, and
`InterceptClickOn` related), so I'm just doing pathfinding for now.
## Why It's Good For The Game
Prep for compiling on 516
## Changelog
No user-facing changes - this is merely renaming vars.
## About The Pull Request
~~Kept you waitin huh!~~
The projectile refactor is finally here, 4 years later. This PR (almost)
completely rewrites projectile logic to be more maintainable and
performant.
### Key changes:
* Instead of moving by a fixed amount of pixels, potentially skipping
tile corners and being performance-heavy, projectiles now use
raymarching in order to teleport through tiles and only visually animate
themselves. This allows us to do custom per-projectile animations and
makes the code much more reliable, sane and maintainable. You (did not)
serve us well, pixel_move.
* Speed variable now measures how many tiles (if SSprojectiles has
default values) a projectile passes in a tick instead of being a magical
Kevinz Unit™️ coefficient. pixel_speed_multiplier has been retired
because it never had a right to exist in the first place. __This means
that downstreams will need to set all of their custom projectiles' speed
values to ``pixel_speed_multiplier / speed``__ in order to prevent
projectiles from inverting their speed.
* Hitscans no longer operate with spartial vectors and instead only
store key points in which the projectile impacted something or changed
its angle. This should similarly make the code much easier to work with,
as well as fixing some visual jank due to incorrect calculations.
* Projectiles only delete themselves the ***next*** tick after impacting
something or reaching their maximum range. Doing so allows them to
finish their impact animation and hide themselves between ticks via
animation chains. This means that projectiles no longer disappear ~a
tile before hitting their target, and that we can finally make impact
markers be consistent with where the projectile actually landed instead
of being entirely random.
<details>
<summary>Here is an example of how this affects our slowest-moving
projectile: Magic Missiles.</summary>
Before:
https://github.com/user-attachments/assets/06b3a980-4701-4aeb-aa3e-e21cd056020e
After:
https://github.com/user-attachments/assets/abe8ed5c-4b81-4120-8d2f-cf16ff5be915
</details>
<details>
<summary>And here is a much faster, and currently jankier, disabler
SMG.</summary>
Before:
https://github.com/user-attachments/assets/2d84aef1-0c83-44ef-a698-8ec716587348
After:
https://github.com/user-attachments/assets/2e7c1336-f611-404f-b3ff-87433398d238
</details>
### But how will this affect the ~~trout population~~ gameplay?
Beyond improved visuals, smoother movement and a few minor bugfixes,
this should not have a major gameplay impact. If something changed its
behavior in an unexpected way or started looking odd, please make an
issue report.
Projectile impacts should now be consistent with their visual position,
so hitting and dodging shots should be slightly easier and more
intuitive.
This PR should be testmerged extensively due to the amount of changes it
brings and considerable difficulty in reviewing them. Please contact me
to ensure its good to merge.
Closes#71822Closes#78547Closes#78871Closes#83901Closes#87802Closes#88073
## Why It's Good For The Game
Our core projectile code is an ungodly abomination that nobody except
me, Kapu and Potato dared to poke in the past months (potentially
longer). It is laggy, overcomplicated and absolutely unmaintaineable -
while a lot of decisions made sense 4 years ago when we were attempting
to introduce pixel movement, nowadays they are only acting as major
roadblocks for any contributor who is attempting to make projectile
behavior that differs from normal in any way.
Huge thanks to Kapu and Potato (Lemon) on the discord for providing
insights, ideas and advice throughout the past months regarding
potential improvements to projectile code, almost all of which made it
in.
## Changelog
🆑
qol: Projectiles now visually impact their targets instead of
disappearing about a tile short of it.
fix: Fixed multiple minor issues with projectile behavior
refactor: Completely rewrote almost all of our projectile code - if
anything broke or started looking/behaving oddly, make an issue report!
/🆑
## About The Pull Request
Putting ``*`` at the end of a spawn type string will tell the command to
not offer subtypes of that string. For example, running ``laser/cap``
offers you two types: ``GUN_LASER/captain`` and
``GUN_LASER/captain/scattershot``. Adding a start to the end like
``laser/cap*`` would only offer ``GUN_LASER/captain`` without the
scattershot subtype, and instantly spawn it without an input window
because its the only fitting type.
## Why It's Good For The Game
Easier to spawn certain types without having subtypes offered to you
## About The Pull Request
* A generic /mob/eye/camera type has been made, containing everything
needed to interface with a cameranet
* /mob/eye/ai_eye has been refactored into a generic /mob/eye/camera
instance
* Advanced cameras no longer inherit from AI eyes, splitting off
behaviour
* Camera code has been somewhat cleaned up
* Probably some more stuff I'm forgetting right now
## Big man Southport:
## Changelog
🆑
code: made /proc/getviewsize() pure
refactor: mob/eye/ai_eye has been restructured, now inheriting from a
generic mob/eye/camera type
refactor: advanced cameras and their subtypes are now
mob/eye/camera/remote subtypes
code: the cameranet no longer expects the user to be an AI eye
code: remote camera eyes have had their initialization streamlined
code: remote cameras handle assigning and unassigning users by
themselves now
code: remote cameras now use weakrefs instead of hard referencing owners
and origins
code: also the sentient disease is_define was removed (we don't have
those anymore)
fix: AI eyes no longer assign real names to themselves, fixing their
orbit name
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Atomizing changes from an upcoming PR. Basically the immerse element
didn't work for things on the floor plane ever since the TOPDOWN_LAYER
was introduced to the code (eg disposal pipes don't appear underwater),
and the type checks for atmos pipe caps are deprecated by the
underfloor_accessibility var.
## Why It's Good For The Game
Fixing a couple visual nits.
## Changelog
🆑
fix: Fixed a couple nits with the water visuals not appearing on objects
with a very low layer (rendered just above the floor), as well as atmos
pipes looking a bit funky on untiled turfs beside catwalks and platings
when beside connected, under-floored pipes.
/🆑
## About The Pull Request
Title. I may have been wrong about how depended on this behaviour was
Also, uh, fixes#87986
## Why It's Good For The Game
trim_reduced no longer needs to exist because trimtext() does it faster,
and there's no reason to have a special proc if trim just calls that
proc anyways. I sincerely doubt the proc overhead is so severe that we
need another proc that will ever only be called directly 3 times in the
code.
Since trimtext() does something we don't expect, it's better to just
have SDQL2 queries use trim() so we're all on the same page.
## Changelog
NO!!!
## About The Pull Request
Fixes issues with var typing and proc arguments, discovered using
OpenDream's WIP TypeMaker feature (using improvements I haven't PR'd
upstream yet).
## Why It's Good For The Game
Codebase maintenance.
## About The Pull Request
adds repairbots to the game!
this pr serves as a massive rework and buff to floorbots. i was a bit
sad that they dont get built much anymore so ive given them tons of more
utilities and uses.
Repairbots still inherit to place tiles and repair breaches. but they
can now rebuild walls, rebuild windows and repair structure and
machinery. Also Ive given them voicelines to add more character to them.
In short, they are very depressed with their job (however they express
their happy go lucky attitude when u emag them where they will start
deconstructing the station)
to demonstrate capabilities, here's a slightly sped up clip of some
repairbots patching up an area that was maxcapped 4 times:
https://github.com/user-attachments/assets/bddac3b0-1984-4571-85d3-c5283dd7c0de
When repairbots feel threatened, they will retract into their little
toolbox which u can pick up and hold in ur hand, either to conveniently
carry and plop them down at breached sites, or to bash skull with it
U can build them using a toolbox, proximity sensor, cyborg arm and a
conveyor belt
## Why It's Good For The Game
refactors floorbots and makes them alot more useful tools for engineers
to use
## Changelog
🆑
refactor: floorbots have been refactored, please report any bugs
add: adds repairbots to the game!
/🆑
## About The Pull Request
1. Having a broken arm will affect your accuracy when firing a weapon
with that arm, even potentially causing damage to you if it's a weapon
with recoil. This effect is not applied under the effects of a
painkiller.
2. The sister effect of this (punching someone with a broken arm) now
also has an interact with painkillers (it can no longer block your
attack).
3. Being drunk heavily affects ranged weapon accuracy, unless you're the
bartender
4. A lot of hand handling cleanup, using new macros to make it a lot
more readable at a glance
## Why It's Good For The Game
We have this system for modifying firearm accuracy but we don't really
use it commonly, and I feel like it slots in well with a lot of places
For broken arms, it adds some more depth to the wound system, in the
same way that trying to punch someone with a broken arm causes pain. (I
actually want to expand this to melee weapon accuracy and attacking with
melee weapons in general, but that's for a later time)
For drunkenness, it just adds to the drunk shenanigans. It also slightly
reduces the effectiveness of drinks as combat healing chemicals, such as
quadsec - makes it a bit more of a trade off.
## Changelog
🆑 Melbert
balance: Having a broken arm affects your accuracy with ranged weapons
fired with that arm. Utilizing a painkiller will nullify this effect,
however.
balance: Painkillers will prevent your punches from being cancelled due
to having a broken arm. You'll still take damage, though.
balance: Being drunk now affects your accuracy with ranged weapon. The
bartender is immune to this effect via their skillchip.
code: A lot of code involving left and right hand handling has been
cleaned up, easier to read. Report any oddities, like left and rights
being flipped
/🆑
## About The Pull Request
Significantly buffed the anomalock modules.
Anomalock modules can be used with eachother.
Antigravity module costs 2 complexity.
Teleporter module is thrice as fast at teleporting with a slightly
reduced cooldown, but has a much larger power cost.
Changed how teleporter tracks maximum range to be less painful to the
end user.
Kinesis module's default range has been extended to 8.
Kinesis module can drag around people in critical condition or worse.
## Why It's Good For The Game
These modules have historically been, well, kind of a complete joke.
They seem to have been crippled out of fear of them being overpowering
with the end result of being unusable.
Anomaly items are allowed and meant to be fun, strong, and wild, so I
really don't see why these need to be so weak. The amount of times I'd
rather make a teleporter that takes 3 seconds to get you anywhere
instead of an instant portal gun or a bag of holding is roughly zero.
People hate modsuits, and in part that hate is because of modules which
do very, very little due to severe undertuning. Let's fix that with the
anomaly ones here.
> Anomalock modules can be used with eachother.
Let people get a buncha anomaly modulse together if they want to. An
antigravity user with teleporting and kinesis could be something to
fear, but not so much as to strike it from existence altogether without
even letting people mess around with it first.
> Antigravity module costs 2 complexity.
Antigravity module is glorified wittel -> gravitum, but it takes a core
and 3 complexity. At least let it be somewhat cheap.
> Teleporter module is thrice as fast at teleporting with a slightly
reduced cooldown, but has a much larger power cost.
Teleporter module is a big damn joke ATM, as stated above being
effectively overshadowed in every way by the portal gun. This now gives
it a fun niche instead, of being able to teleport around everywhere at
the cost of a massive power draw.
> Changed how teleporter tracks maximum range to be less painful to the
end user.
view() was working weirdly when I was using it. It was failing to
register tiles somewhat near the end of the screen, so I just ditched it
for a get_dist check that I threw 9 in as a somewhat arbitrary value
for.
> Kinesis module's default range has been extended to 8.
There's this bug on live where when you kinesis someone it flies all the
way to the SW corner of the screen for seemingly no reason. I don't know
why it happens but it drives me mad.
Even without that bug, 5 tiles is extremely frustrating to handle - it's
super, super annoying to find a middleground between 'not slapping you
in the face', 'not losing your grip'. 8 tiles is a lot more forgiving
and makes the module actually fun to use.
> Kinesis module can drag around people in critical condition or worse.
This one might be a bit nuts, but I really want to see this ingame, it's
kind of the best part of the module yet is unobtainable. Maybe some
stuff would need to be tuned for it, like making human throws flimsy.
## Changelog
🆑
balance: Significantly buffed the anomalock modules.
balance: Anomalock modules can be used with eachother.
balance: Antigravity module costs 2 complexity.
balance: Teleporter module is thrice as fast at teleporting with a
slightly reduced cooldown, but has a much larger power cost.
code: Changed how teleporter tracks maximum range to be less painful to
the end user.
refactor: Refactored LoS checks to be a proc on atom, los_check
balance: Kinesis module's default range has been extended to 8.
balance: Kinesis module can drag around people in critical condition or
worse.
/🆑
## Why It's Good For The Game
Clarity and consistency regarding DM's systems.
Internally, `eye` is used for anything that controls the client's view.
How `eye` is used in DM is consistent with how we use the term, so I
figured this would add clarity.
Being named mob/camera also makes it unclear exactly what it's doing.
The name implies that it would function similar to how mob/camera/ai_eye
does, but most of the time it's only used as... an eye.
My ulterior reason for this PR is that I want to clean up
mob/camera/ai_eye and it's subtypes after this.
## Changelog
🆑
server: mob/camera has been renamed to mob/eye, which may break
downstreams
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
I'm adding a score that tracks which types of fish you've caught across
multiple rounds. To do so, I had to add a new score subtype that manages
the score value not being a number. Thankfully the achievement code is
fairly flexible so not a whole lot had to be done, although I've to add
a new column to the achievements table in the DB, because the 'value' is
for integers, while we need one for text strings ~~(the contents of the
list are converted to text with a delimiter before being saved cuz I'm
not sure if and how our DM slash SQL integration handles using lists
directly and I don't want to waste time finding it out)~~.
EDIT: It's mostly done beside the reviews that are going to point out
things that need to be changed. The UI changes are done. It's time for
reviews.
Here are screenshots of the UI with all fish still uncatched beside one
(I've since then the typo on its name and removed an extra zero from the
index number, as well as a nit with the spacing between cells):
## Why It's Good For The Game
We have about dozens over dozens of different fish in the game now, many
of which are just fluff anyway. It's getting to the point it's perhaps
doable to add a score or something to be a braggard about.
## Changelog
🆑
add: Added a new score that keeps track of all different fish that
you've caught between shifts.
server: Added a new schema table to store the aforementioned entries and
the ckeys associated to them, with an additional timestamp column.
/🆑
## About The Pull Request
iirc, BYOND will automatically turn `"byond:" + "whatever"` into
`"byond:whatever"` during compile, but `"byond:["whatever"]"` will still
be formatted during runtime instead. no reason *not* to do this, it
doesn't hurt.
## Why It's Good For The Game
Micro-optimization with no downsides.
## Changelog
No user-facing changes at all.
## About The Pull Request
This PR kills the abstract internal and external typepaths for organs,
now replaced by an EXTERNAL_ORGAN flag to distinguish the two kinds.
This PR also fixes fox ears (from #87162, no tail is added) and
mushpeople's caps (they should be red, the screenshot is a tad
outdated).
And yes, you can now use a hair dye spray to recolor body parts like
most tails, podpeople hair, mushpeople caps and cat ears. The process
can be reversed by using the spray again.
## Why It's Good For The Game
Time-Green put some effort during the last few months to untie functions
and mechanics from external/internal organ pathing. Now, all that this
pathing is good for are a few typechecks, easily replaceable with
bitflags.
Also podpeople and mushpeople need a way to recolor their "hair". This
kind of applies to fish tails from the fish infusion, which colors can't
be selected right now. The rest is just there if you ever want to
recolor your lizard tail for some reason.
Proof of testing btw (screenshot taken before mushpeople cap fix, right
side has dyed body parts, moth can't be dyed, they're already fabolous):
## Changelog
🆑
code: Removed internal/external pathing from organs in favor of a bit
flag. Hopefully this shouldn't break anything about organs.
fix: Fixed invisible fox ears.
fix: Fixed mushpeople caps not being colored red by default.
add: You can now dye most tails, podpeople hair, mushpeople caps etc.
with a hair dye spray.
/🆑
## About The Pull Request
This makes the GPS UI give the general direction of a GPS on a different
linked z-level.
https://github.com/user-attachments/assets/98c6dfd8-5ced-4145-b14a-3813821ef30c
## Why It's Good For The Game
Makes navigating through space less of a chore, as previously, I believe
the only way was to manually write down or memorize what direction was
linked to what z-level.
## Changelog
🆑
add: GPSes now show the general direction of cross-linked z-levels.
/🆑
## About The Pull Request
BYOND added a native `trimtext` proc in 515, which as far as I know,
does the same thing as the `trim_reduced` proc - trims whitespace off
both ends of a string, but `trimtext` should be faster, as it's a
builtin rather than implemented in DM.
Also, added a global `_trimtext` proc, for use from SDQL2 or Lua, as
it's a builtin and can't be `call()`'d.
## Why It's Good For The Game
Micro-optimizations my beloved - especially since I imagine this proc is
called quite a lot, even if it doesn't really have a performance impact
anyways, but it can't hurt.
## Changelog
🆑
refactor: Refactored some text helper procs to use BYOND's native text
trimming proc.
admin: Added a _trimtext proc, for use with SDQL2 or Lua scripting.
/🆑
## About The Pull Request
On a downstream, we have an antagonist, that is a less competent
wizards. This antagonist's preview outfit has a beer bottle in their
hand, which has caused runtimes, as the bottle did not have any reagents
instantiated, and it tried check its length for sloshing. After putting
in a check for the `initial` argument of `on_equip`, I have noticed that
the problem goes deeper: the various procs that handle putting something
in your hand do not pass along if the items is put in your hand as a
preview or not. This PR adds a new optional var to these procs, ensuring
that unwanted behaviour during previews won't trigger.
I also swapped `visualsOnly` to snake case, as it looked inconsistent
with the rest of the code style.
## Why It's Good For The Game
Making the argument that ensures avoiding side effects during previews
work with all kinds of items is good.
## Changelog
🆑
fix: if an outfit puts a reagent container in the preview dummy's hand,
it will not try to slosh
code: outfits putting items in your hand will respect the visual_only
argument
/🆑
## About The Pull Request
This adds a new preference, "Enable AI VOX announcements", which allows
you to toggle hearing the vocal AI VOX announcements.
Previously this was handled by the "Enable announcement sounds" setting,
but tbh having it lumped in with that sucks because it's very reasonable
to be okay with announcement dings, while not wanting to hear voxtest or
some shit.
## Why It's Good For The Game
I DO want to hear the normal announcement dings, but I ***never*** want
to hear the vocal AI announcements, and spamming "Stop Sounds" for every
single word to skip past it is annoying as hell.
## Changelog
🆑
add: Added a separate preference for hearing vocal AI announcements
(also known as VOX), as opposed to lumping it into the "Enable
announcement sounds" preference.
/🆑
## About The Pull Request
Closes#86864
Added a policy message and associated config i think to when a heretic
is soultrapped, allowing headmins to ~~ruin my feature~~ decide how
they're allowed to act.
Haunted longswords can be, and start, binded. Binded swords are weaker
than usual, being basically just talking cultist longswords. You can,
however, unbind them, which will heavily buff their stats, unlock their
powers, allow you use of a heretic's path spell, and let them attempt to
fling around and cast spells.
Reduced its throwing damage, turning it from a 3-hit-crit to a
4-hit-crit.
Binding and unbinding needs a bible, a ritual dagger, or an amber focus,
depending on what role you are.
Added type_english_list() which recieves a list of types and returns 'an
x, a y, and a z' strings.
## Why It's Good For The Game
> Added a policy message and associated config i think to when a heretic
is soultrapped, allowing headmins to ~~ruin my feature~~ decide how
they're allowed to act.
Policy messages are required for new antags and a good idea besides.
This slipped under the radar because of being bundled with a separate PR
and the muddiness of it being 'new', but it's here now.
> Haunted longswords can be, and start, binded. Binded swords are weaker
than usual, being basically just talking cultist longswords. You can,
however, unbind them, which will heavily buff their stats, unlock their
powers, allow you use of a heretic's path spell, and let them attempt to
fling around and cast spells.
There's been some problems caused by an unfortunate lack of visibility
on how the new sword is not necessarily your ally and may even
immediately attempt retaliation, for, you know, being killed and
sacrificed. To fix this, I've added a binding feature to it. The sword
starts bound, but is fairly underwhelming in this state. It's suggested
to talk to its wielders and tempt them into unbinding it, done by an UI
button, which will allow it to use its spells and possibly backstab
them, or help them in battle.
> Reduced its throwing damage, turning it from a 3-hit-crit to a
4-hit-crit.
The attacks were dealing too much damage, surprising hapless people
being hit by random flying swords, who didn't react until it was too
late.
This feature is still fucking awesome, and I spent some time wracking my
brain on how to fix the given issues, and came up with this system which
mantains and enhances the 'forbidden cursed sword' trope aspects of it
while also stopping it from being as much of a noob trap as it used to
be, Neutral antagonists that can help any side are cool and fun.
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
Blade Heretic has received a few changes.
The cost of crafting a Dark blade has been reduced in exchange for a
lower blade capacity, The Dark blade itself has received a new sprite.
Realignment pulls you out stuns a bit faster and grants baton resistance
while active.
You may now infuse your blades with a (weaker) mansus grasp upon
unlocking the ability to dual wield, they also gain increased demolition
modifier.
Mawed Crucible now slowly refills and requires fewer organs to brew a
potion; you may now use a charge to refill your eldritch flask.
The potion themselves have also received changes more on that below.
The cooldown on the cursed curio shield has been reduced.
Lionhunter's rifle no longer does increased damage on scoped targets,
instead it marks them with Mansus grasp and teleports the heretic to
them.
Lastly Blade ascension has been fixed, you once again get the Ring of
Blades.
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
Oh boy, here we go.
# **Blade Heretic changes**
Blade Heretic sits in a pretty decent spot, I wouldn't call the path
weak by any stretch of imagination, but there are few aspects that could
be reasonably improved without changing the overall strength of the path
significantly.
**Sundered Blade**
I think these are too expensive to craft, especially compared to the
other blades which require very basic materials.
It's not uncommon to run into situations where you just cannot afford to
make more than a set of blades, and i'd argue it's not fun for the crew
to have their titanium or silver deposit drained every time a blade
heretic rolls around.
As a solution, i'm halving the cost in exchange of lowering the cap from
5 to 4 blades.
**Realingment**
This spell is lowkey awful; 25 stamina regen per second really doesn't
make much of a difference when you are getting chain batoned, I have
footage of blade heretics dying to a single shove stun while this abilty
was active.
The stamina regen and reduce immobility timer has been buffed on top of
granting baton resist so long as it stays active, so you can properly
get in fighting position without getting constantly knocked down.
Mind you, It's still no CNS rebooter, so stuns will still yield a few
seconds of vulnerability.
**Swift Blades reworked into Empowered Blades**
You may now use your Mansus grasp to infuse your Dark blades.
It comes with the tradeoff of losing the knockdown and the stamina
damage, you still retain the backstab.
Video Demonstration: https://www.youtube.com/watch?v=9cO9BOD8Zz4
Dark Blades also gain increased demolition modifier.
Dual wielding puts the heretic in the annoying position of having to
switch between the second Blade and an empty hand to use Mansus grasp.
Blade is supposed to be a master of melee combat, but they are still a
dark mage, so why shouldn't they be able to infuse their blades?
It still comes with a tradeoff, I'd reckon super sweaty players will
still want to hotswap, but hey, the option is there.
The added demolition modifier is to provide Blade with some way of
breaking in and out of places, given the path has no jaunts or utility
whatsoever, this seems reasonable to me.
Lastly Malestrom of Silver finally works now; you once again get the
blade aura upon ascending.
# **Side Knowledge changes**
**Mawed Crucible**
The crucible now passively refills, and has a special interaction to
refill the Eldritch Flask, the potion themselves have received changes.
- Xray Potion: duration bumped from 60 to 90 seconds.
- Wall phasing potion: Duration bumped from 15 to 40 seconds, you may
now recall to your original location at will.
- Potion of the Wounded soldier: Upon expiring, it heals your wounds and
regrows missing limbs.
**Reasoning**: Let's be honest here, noone ever makes this thing, the
cost of making 1 potion is exorbitant and the potion themselves are not
even that good to begin with.
I'm not gonna explain every change in detail, but considering the
crucible is one of the OG side knoweldges and you hardly hear anyone
talk about it, we can safely give it a few buffs.
**Unfathomable Curio**
Cooldown on the shield has been halved.
**Reasoning**: discussed it with Rex (the guy who created it), 60
seconds for 1 block is a bit excessive , 30 seconds seems reasonable
enough.
**Lionhunter's Rifle**
Made a bit easier to craft and maintain, it can now be stored in the
vest slot of the Eldritch Robes.
The homing projectile now fully penetrates armor instead of having bonus
damage; it also marks the victim with Mansus grasp and teleports the
Heretic directly to them, the homing on the projectile itself has been
improved.
**Reasoning**: another side knowledge that sadly barely sees any play.
Frankly this gun just doesn't have a purpose to exist, long range
weaponry don't really mix with Heretic toolkit all that well, as you
want to get close to your target to drag em to the spook dimension, not
snipe 'em from a distance
Lionhunter now works as an initiation tool, upon marking the target, the
Heretic transforms into the fired bullet until it connects, applying
mansus grasp on the victim.
Keep in mind you still need xray or thermals to use the rifle to its
full potential, either from the Crucible or the ashen medallion.
Video Demonstration: https://www.youtube.com/watch?v=AXmidKrx-Fg
As a trade off, the damage has been halved from 60 to 30.
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and its 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. -->
🆑
balance: Sundered Blades now require 1 Titanium or Silver bar to craft
and their capacity has been reduced to 4.
balance: Realignment pulls you out of stuns a bit faster and grants
baton resist while active.
balance: Blade Heretic dual wielding now let's you infuse Your Dark
Blades with a weaker mansus grasp and grants an increase in demolition
modifier.
fix: Malestrom of Silver grants the ring of protective blades once
again.
balance: Mawed Crucible requires 3 organs to brew one potion, passively
refills overtime and can be used to refill the Eldritch Flask
balance: Brew of Crucible soul effect bumped to 40 seconds and can be
ended early.
balance: Brew Of Dusk and Dawn effect bumped to 3 minutes.
balance: Brew of the wounded soldier now offers a very minor passive
heal and fully heals your wounds and limbs upon expiring.
balance: Cursed Curio shield now recharges faster.
balance: Lionhunter's rifle has been reworked, it now fits on the
eldritch robes vest slots, it's cheaper to craft it and its ammunition
and works as an initiation tool.
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
---------
Co-authored-by: Xander3359 <66163761+Xander3359@users.noreply.github.com>
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
I've added an action granted by the fishing skillchip that dispenses a
fishign tip from the fishing tips text file when activated, allowing
players who have it to receive fishing-related tips and info on demand.
Also backend stuff: this PR adds action types support to skillchips and
moves all the simple generic skillchips still lingering in the
skillchip.dm file into the generic_skillchips folder. Maybe it
classifies as a small code improvement.
## Why It's Good For The Game
I think the skillchip should both aid mobs without fishing skill (IC),
and players with little experience with the feature (OOC)
## Changelog
🆑
add: The fishing skillchip now grants an action that dispenses fishing
tips.
/🆑
## About The Pull Request
All usages of world.icon_size in code have been replaced with new
`ICONSIZE_X`, `ICONSIZE_Y` and `ICONSIZE_ALL` defines depending on
context
Replaces some "32" magic numbers with the defines
A few bits of code have been modified to split up x/y math as well
## Why It's Good For The Game
Magic number bad, code more readable, code more flexible and I'm told
there's an access cost to doing world.icon_size so minor performance
gains
## Changelog
🆑 tonty
code: made some code relating to the world's icon size more readable
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
123 changed files and multiple crashes after writing broken regex, I
replaced most remains of direct spans with macros. This cleans up the
code and makes it easier to work with in general, see justification for
the original PR. I also fixed a bunch of broken and/or unclosed spans
here too.
I intentionally avoided replacing spans with multiple classes (in most
cases) and spans in the middle of strings as it would impact readability
(in my opinion at least) and could be done later if required.
## Why It's Good For The Game
Cleaner code, actually using our macros, fixes borked HTML in some
places. See original PR.
## Changelog
Nothing player-facing
## About The Pull Request
This PR significantly enhances how zero-g movement works. Its no longer
locked to one of 8 directions, everything now has inertia and is
affected by weight. This means that throwing a piece of wire will no
longer completely reverse your movement direction, and that being thrown
out of mass driver no longer will slow you down to a halt at some point.
This leads to following gameplay changes:
* Guns now accelerate you. Ballistics have higher acceleration than
lasers, and higher calibers have higher acceleration than smaller ones.
This means that firing full-auto weapons in zero-g will make you drift
and accelerate significantly. While this can be a hilarious way to
travel in space, it makes using them trickier.
* Impacting a wall or an object while moving at high speeds will cause
you to violently crash into it as if you were thrown. Careful when
exploring!
* Jetpacks now have inertia. Changes introduced in #84712 have been
mostly reverted, although speed buff has been reduced to 0.3 instead of
0.5 (although this is compensated by new movement mechanics, so overall
speed should be roughly equal). All MODsuit jetpacks now possess the
speed boost. Advanced MODsuit jets (which has also been added back) and
captain's jetpack instead have higher acceleration and stabilization
power, providing much more precise control over your movement.
* Firing guns while moving on a jetpack will partially negate your
pack's acceleration, slowing you down. Non-advanced jetpacks'
stabilization is not enough to compensate for heavy caliber weaponry as
sniper rifles, shotguns or rocket launchers.
* You no longer instantly decelerate upon sliding along a wall. Instead,
it may take a few tiles if you are moving at extreme speeds. Passing
over lattices still allows you to grab onto them!
As space movement is angle-based instead of dir-based now, its much more
smooth than before due to using new movement logic.
Example of jetpack stabilization in action:
https://github.com/tgstation/tgstation/assets/44720187/6761a4fd-b7de-4523-97ea-38144b8aab41
And, of course, you can do this now.
**This pull request requires extensive gameplay testing before
merging**, as a large amount of numbers have been picked arbitrarily in
an attempt to keep consistency with previous behavior (guns and
normal-sized items applying 1 drift force, which is equal to what
everything applied before this PR). Jetpacks and impacts may also
require adjustments as to not be frustrating to use.
Closes#85165
## Why It's Good For The Game
Zero-G refactor - currently our zero-g movement is rather ugly and can
be uncomfortable to work with. A piece of cable being able to accelerate
you the same as a duffelbag full of items when thrown makes no sense,
and so does instantly changing directions. Inertia-based version is
smoother and more intuitive. This also makes being thrown into space
more of a hazard (possibly opening the door for explosive
decompressions?)
Jetpack inertia and gun changes - this is mostly a consequence of
inertia-based movement. However, zero-g combat being preferred during
modes like warops was an issue due to it negatively affecting everyone
without jetpacks which are in limited supply onboard. This reverts the
mobility changes which severely impacted space exploration, while making
zero-g combat more dangerous and having it require more skill to be a
viable option.
## What's left
- [x] Refactor moth wings to use jetpack code
- [x] Refactor functional wings to use jetpack code
- [x] Locate and fix a recursion runtime that sometimes occurs upon
splattering against a wall
- [x] Add craftable tethers and modify engineering MOD tethers to use
the same system
## Changelog
🆑
add: You can now craft tether anchors, which can be secured with a
wrench and attached to with right click. They won't let you drift into
space and you can adjust tether length/cut it via lmb/rmb/ctrl click on
the wire.
add: MOD tethers now remotely place and connect to tether anchors
instead of throwing you at where they landed.
balance: MOD tethers can now be used in gravity
balance: Jetpacks are now inertia-based.
balance: Guns can accelerate you significantly in zero-g.
balance: All jetpacks now give you equal speed buff, however advanced
MOD ion jets and captain's jetpack have higher acceleration/deceleration
values.
refactor: Refactored zero-g movement to be inertia-based and utilize
angles instead of directions.
/🆑
## About The Pull Request
After the external organ removal pr, cat ears stopped being as weirdly
specialcased, and instead just used a `/datum/bodypart_overlay/mutant`
subtype. However, this was set up in a way where the inner ears were put
on a different layer from the outer ears, leading to wonky layering.
In this pr, we revert their layers and instead apply the inner ears as
an overlay onto the base ears, fixing this.
Thank you Melbert for the idea. o7
### Addendum:
Additionally, as this pr tripped the screenshot tests, makes the
`getFlatIcon(...)` proc account for `RESET_COLOR` on under/overlays.
We do this by making it stop applying the colour after merging all the
under/overlays, and instead apply it and the parent color _before_
merging any under/overlays, while proxying the parent color as a new
parameter `parentcolor` to any new `getFlatIcon(...)` calls.
This coincidentally also fixes usage of `getFlatIcon(...)` on husked
bodies, as those also used `RESET_COLOR` for their blood overlay. The
screenshot tests had to be updated for this.
## Why It's Good For The Game
Fixes#86453.
## Changelog
🆑
fix: Fixed cat ears not layering properly.
fix: Husked bodies show their blood with the right colours in
photographs.
/🆑
## About The Pull Request
<details>
- renamed ai folder to announcer
-- announcer --
- moved vox_fem to announcer
- moved approachingTG to announcer
- separated the ambience folder into ambience and instrumental
-- ambience --
- created holy folder moved all related sounds there
- created engineering folder and moved all related sounds there
- created security folder and moved ambidet there
- created general folder and moved ambigen there
- created icemoon folder and moved all icebox-related ambience there
- created medical folder and moved all medbay-related ambi there
- created ruin folder and moves all ruins ambi there
- created beach folder and moved seag and shore there
- created lavaland folder and moved related ambi there
- created aurora_caelus folder and placed its ambi there
- created misc folder and moved the rest of the files that don't have a
specific category into it
-- instrumental --
- moved traitor folder here
- created lobby_music folder and placed our songs there (title0 not used
anywhere? - server-side modification?)
-- items --
- moved secdeath to hailer
- moved surgery to handling
-- effects --
- moved chemistry into effects
- moved hallucinations into effects
- moved health into effects
- moved magic into effects
-- vehicles --
- moved mecha into vehicles
created mobs folder
-- mobs --
- moved creatures folder into mobs
- moved voice into mobs
renamed creatures to non-humanoids
renamed voice to humanoids
-- non-humanoids--
created cyborg folder
created hiss folder
moved harmalarm.ogg to cyborg
-- humanoids --
-- misc --
moved ghostwhisper to misc
moved insane_low_laugh to misc
I give up trying to document this.
</details>
- [X] ambience
- [x] announcer
- [x] effects
- [X] instrumental
- [x] items
- [x] machines
- [x] misc
- [X] mobs
- [X] runtime
- [X] vehicles
- [ ] attributions
## Why It's Good For The Game
This folder is so disorganized that it's vomit inducing, will make it
easier to find and add new sounds, providng a minor structure to the
sound folder.
## Changelog
🆑 grungussuss
refactor: the sound folder in the source code has been reorganized,
please report any oddities with sounds playing or not playing
server: lobby music has been repathed to sound/music/lobby_music
/🆑
Fixes#86784
## About The Pull Request
Although some of the issues found were a direct result from #86692
(c698196766), there was still 40% of
length-related issues that wouldn't be covered anyways that are fixed in
this PR. I.E.:
* Name inputs without `MAX_NAME_LEN`
* Desc inputs without `MAX_DESC_LEN`
* Plaque inputs without `MAX_PLAQUE_LEN`
* Some people just screwed up the arguments so it would prefill
something like "40" in the `default` var because they didn't name their
vars.
To help me audit I added a lot of `max_length` named arguments to help
people understand it better. I think it might be kinder to have a
wrapper that handles adding `MAX_MESSAGE_LEN` in a lot of these cases
but I think there is some reason for a coder to be cognitive about input
texts? Let me know what you think. I didn't update anything
admin-related from what I can recall, let me know if anything needs to
be unlimited again.
## Why It's Good For The Game
The change to `INFINITY` notwithstanding, there were still an abundance
of issues that we needed to check up on. A lot of these are filtered on
down the line but it is clear that there needs to be something to catch
these issues. Maybe we could lint to make `max_length` a mandatory
argument? I don't know if that's necessary at all but I think that the
limit should be set by the invoker due to the wide arrangement of cases
that this proc could be used in.
This could all be a big nothingburger if the aforementioned PR is
reverted but a big chunk of cases fixed in this PR need to be fixed
regardless of that since people could put in 1024 character names for
stuff like guardians (or more now with the change). Consider this
"revert agnostic".
## Changelog
🆑
fix: A lot of instances where you could fill in 1024-character names
(normal limit is 42) have been patched out, along with too-long plaque
names, too-long descriptions, and more.
/🆑
## About The Pull Request
The idea was born from a small conversation about bepis nodes having low
visibility, which somehow degressed into the idea of announcing
researched nodes to the channels of the interested departments thru the
announcement system machine, which is what I'm doing here, while also
adding documentation, defines and purging some, not all, instances of
camel cases from announcement_system.dm.
Oh, by the by, like the arrival and new head arrival messages, it can be
customized or disabled by interacting with the announcement system.
## Why It's Good For The Game
I think it's helpful to let players know when the research of their dept
is researched, and I think it's kinda interesting to announce bepis tech
on common like it's some hot stuff while it actually isn't just because
it's often missed out and miscellaneous.
## Changelog
🆑
add: Automated announcement systems now announce researched nodes to
their respective departments. You can stop this by either disabling the
announcement systems or by using a multitool on the circuitboard of the
console you're researching nodes from.
/🆑
## About The Pull Request
I've added an get_icon_dimensions() call to a place where `icon.Width()`
and `icon.Height()` are called twice each. get_icon_dimensions uses a
cache of values so follow-up getFlatIcon() calls with the same current
icon won't have it call`icon.Width()` or `icon.Height()` which aren't
exactly cheap procs iirc.
I've also removed two of the fairly expensive
`length(icon_states(icon(curicon, curstate, dir)))` checks, because all
icon states have NORTH, EAST and WEST directions except 1-dir
icon_states which are always facing SOUTH. That is, unless there is some
farfetched procgenned bullshit that's probably not even possible and
worth checking against. We'll see.
## Why It's Good For The Game
GetFlatIcon is a very expensive proc, every bit of improvement is worth
it.
## Changelog
N/A
## About The Previous Pull Request
#85308 reverted by #85929
~~Causes the round to not start when a player isn't eligible for any
jobs at a specific priority level due to runtimes trying to `pick()`
from an empty list aborting the entire job assignment stack.~~
(Fixed???? by
e0e9f2f430)
Maybe we should test merge this for a mo just to make sure no more
cheeky runtimes pop up before merging.
## About The Pull Request
This PR does a couple of minor things:
Makes the job debug logging a bit easier to follow.
Minorly brings some SSjob code up to code standards, converting proc
names to snake_case and doing some otherm is cleanup.
Refactored some stuff into different procs, updated some comments.
And some major things:
Changes the job assignment logic.
Old behaviour
> Assign dynamic priority roles
> Force one Head of Staff (if possible)
> Assign all AIs
> Assign overflow roles (bugged in 2 ways)
> Shuffle the available jobs list once, at the start of the random job
assignment loop
> Pick and assign random jobs for random players from High prefs down,
with a priority on Head of Staff roles
> Handle everyone that couldn't be assigned a random job
New behaviour
> Assign dynamic priority roles
> Assign all Head of Staff roles to players with High prefs
> If no Head of Staff was made in the above way, force one Head of Staff
(if possible)
> Assign all AIs
> Assign overflow roles (fixed)
> Prioritise and fill unfilled head roles at each job priority pref
level, from High prefs down.
> Build a list of all jobs that each unassigned player could be eligible
for at the above pref level.
> Pick a job from that list at random and assign it to the player.
> Handle everyone that couldn't be assigned a random job.
In reality there should be little impact on overall job assignment, the
code changes read more as semantics. For example, the priority check for
filling Head slots will have the same candidate pool in both old and new
versions, but in the new version we're more clearly saying that Heads
are important and we want to prioritise filling them for the sake of
round progression even though the outcome in new and old is the same.
A key change will lead to an increase in assistants - Overflow fixes.
Currently the code block to do early assignments to the Overflow role
doesn't work - or works but not as you'd expect. The idea was is that
because enabling the Overflow role in the prefs menu is an On/Off toggle
that sets the job to High priority when enabled and prevents any other
High priority pref, players that have the Overflow role enabled will
**always** get it. It's their highest priority job with infinite slots.
So we do a pass right at the start to give everyone with the Overflow
role enabled that role and save us wasting time later on in random job
code giving them that same role but with more work.
The problem is the code for this only assigns the Overflow role to
people with it set to Low priority in their prefs, resulting in log
readouts like:
```
[2024-07-27 09:49:43.469] DEBUG-JOB: DO, Running Overflow Check 1
[2024-07-27 09:49:43.469] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority
[2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Radioprague, TheirLevel: Medium Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caluan, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caractaser, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Apsua, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.475] DEBUG-JOB: AC1, Candidates: 0
```
Where nobody gets pre-assigned the overflow role because their prefs are
all set to the High priority from being toggled... Except wait a second,
some people have it at Medium priority when it should just be a No
Role/High Priority Role toggle?
And herein we meet a problem. My hypothesis is that traits and stuff
that change the overflow have allowed players to set the "ordinary"
overflow role of Assistant to Medium and/or Low priority.
This still shows as enabled in the prefs menu, but leads to an outcome
where a player with assistant enabled is assigned Cook instead.
```
[2024-07-27 09:49:47.775] DEBUG-JOB: DO, Running Overflow Check 1
[2024-07-27 09:49:47.775] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority
...
[2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority
...
[2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0
```
So players with the Overflow job pref set to Low (an unexpected state,
should be disabled or High) would be guaranteed to get that role if none
of the higher priority Head of Staff/AI/Dynamic roles took over via the
bugged "force overflow for people with the pref enabled" proc.
Players with the Overflow job pref set to High would be guaranteed to
get that role if none of the higher priority Head of Staff/AI/Dynamic
roles took over via the random job assignment code giving them their
Highest priority role thanks to the infinite job slots of the Overflow.
And players with the Overflow job pref set to Medium (an unexpected
state, should be disabled or High) would get Assistant if the shuffle
step of the available jobs list put Assisstant before any of the other
jobs they had prefs enabled for at Medium that weren't already filled,
otherwise they'd get another random job.
This code is now changed to ignore the priority the player has set when
looking for people to fill the overflow role. As long as it **is**
enabled, the player will get it unless they're forced into a dynamic
ruleset role (AI when malf rolls) or a Head of Staff role due to their
other prefs (they have RD set to med or low, and no other player has a
Head of Staff at high so they get randomly picked and miss the overflow
role).
This will increase the number of assistants in shifts where their pref
state has Assisstant in the bugged Medium priority, but doesn't change
it for bugged Low and not-bugged High/On priority.
On the other side of the coin, we have how the random jobs are picked.
They're kinda not random, and I noticed this reading the logs then
reading the code.
The list of available jobs to pick from is randomly shuffled - but only
**once**. All players pull from a list of jobs in the same order. So you
end up with a log block like this:
```
[2024-07-27 09:49:47.985] DEBUG-JOB: DO pass, Player: Pierow, Level:3, Job:Botanist
[2024-07-27 09:49:47.985] DEBUG-JOB: Running AR, Player: Pierow, Job: /datum/job/botanist, LateJoin: 0
[2024-07-27 09:49:47.985] DEBUG-JOB: Player: Pierow is now Rank: Botanist, JCP:0, JPL:2
[2024-07-27 09:49:47.986] DEBUG-JOB: DO pass, Player: Daddos, Level:3, Job:Botanist
[2024-07-27 09:49:47.986] DEBUG-JOB: Running AR, Player: Daddos, Job: /datum/job/botanist, LateJoin: 0
[2024-07-27 09:49:47.986] DEBUG-JOB: Player: Daddos is now Rank: Botanist, JCP:1, JPL:2
[2024-07-27 09:49:47.986] DEBUG-JOB: FOC job filled and not overflow, Player: Bebrus2, Job: /datum/job/botanist, Current: 2, Limit: 2
[2024-07-27 09:49:47.987] DEBUG-JOB: FOC player job not enabled, Player: Bebrus2
[2024-07-27 09:49:47.987] DEBUG-JOB: DO pass, Player: Bebrus2, Level:3, Job:Cook
[2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0
[2024-07-27 09:49:47.988] DEBUG-JOB: Player: Bebrus2 is now Rank: Cook, JCP:0, JPL:1
[2024-07-27 09:49:47.988] DEBUG-JOB: FOC player job not enabled, Player: Redwizz
[2024-07-27 09:49:47.988] DEBUG-JOB: FOC job filled and not overflow, Player: Redwizz, Job: /datum/job/cook, Current: 1, Limit: 1
```
The list is shuffled into an order of something like `list("Scientist",
"Botanist", "Cook", "Sec Officer", ...)` then iterated over for each
player. So every random job selection goes:
> "Does Player1 have Scientist enabled and at the right priority? No?
Okay, Botanist? Yes? You get botanist."
> "Does Player2 have Scientist enabled and at the right priority? No?
Okay, Botanist? Yes? You get botanist."
> "Does Player3 have Scientist enabled and at the right priority? No?
Okay, Botanist has no slots left so we'll remove it from the list. Okay,
Cook? Yes? You get cook."
> "Does Player4 have Scientist enabled and at the right priority? No?
Okay, Cook has no slots left so we'll remove it from the list. Okay, Sec
Officer? ..."
This can lead to stacked individual departments if it gets randomly
rolled to the start of the list in the shuffle, and completely empty
departments if they end up at the end.
On high pop shifts this is probably less of an issue. Player prefs add
noise to this and as departments at the front fill up, those at the back
pick up some of the lower pref players.
But have you ever had a shift where there's just like... No fucking sec
even though there's tons of players? The logging (before I made changes
in this PR) was a bit ass, but my hypothesis there is that sec officer
was shuffled right at the end of the random job list, so every other
department was filled up before sec officers were picked.
To mitigate this, I made the list shuffle every single time the game
picks a random available job for the player. This should lead to a more
balanced selection of available jobs by avoiding situations where the
code is biased towards packing some departments by accident.
## Why It's Good For The Game
Overflow fixes mean people who go to their prefs and see the Overflow
Role is On will all have the same experience - They will be the Overflow
role.
More random random job selection should prevent individual departments
having a jobs be stacked when it would have otherwise been possible for
a more balanced selection but the code unintentially biased random
departments to be overstaffed and understaffed each shift.
## Changelog
🆑
fix: Having the Overflow Role set to On will properly ensure you get
that role at a High priority as intended by the game code.
fix: Job selection is now a little bit more random. Fixes an
unintentional bias in random job assignment that could lead to
feast-or-famine for roles where everyone is assigned one job and nobody
is assigned another job.
/🆑
## About The Pull Request
Fixes psyker echolocation permanently breaking when in the vicinity of
holopad holograms or someone being fulton'd
Also fixes non humans that have human appearances (eg syndicate
commandos) being invisible to psykers.
Also also fixes a runtime related to fulton extraction that I found
while testing the above
## Why It's Good For The Game
My eyes!
## Changelog
🆑
fix: Echolocation no longer breaks when witnessing a hologram
fix: Echolocation no longer breaks when witnessing a fulton extraction
fix: Humanoid NPCs are no longer invisible to echolocation users
/🆑
## About The Pull Request
This reverts commit 39e58f8b20 (#86020),
also reverts the "fix" from 8578180f8c7ef8c8745efbea3faa264c4bfc3984
(#86517 but keeping the unit test because sure).
get_steps_to() pathfinds, it cannot be used in a raycasting algorithm in
place of get_step_towards() (which is essentially get_step(us,
get_dir(us,them))). the original pr was making every usage of can_see()
and assorted procs pathfind to the target across the station instead of
checking visibility in a straight line to the target, leading to lemon
reporting can_see() taking up significantly more time than usual.
the fix inserting CanReach() doesnt work at all, CanReach() is for
checking if you can interact with an item in a possibly nested container
in the same or adjacent turf, it has nothing to do with visibility on
turfs.
## Why It's Good For The Game
optimizes the optimization, fixes the fix
## About The Pull Request
I've come to realize manually updating all fishing stuff on the very
much outdated wiki would be a colossal pain in the rear, so I've decided
to automate a few bits to generate autowiki lists containing information
about fish, fish traits, bait, hooks, reels, fishng rods, fish sources
and fish experiments.
Now tested.
## Why It's Good For The Game
Making a huge autowiki for a feature that's being constantly updated (by
me) but still has a particularly lame and outdated page on the wiki.
## Changelog
N/A
## About The Pull Request
This "buffs" the hallucinatory anomaly by giving it a bit more impact
and flair. This affects both the detonate effect and what happens when
one initially spawns.
When a hallucinatory anomaly spawns, it will spawn surrounded by "decoy"
hallucination anomalies -- Illusions meant to distract you from the real
one. The idea is that these are not actually there, and that they are
the result of reality getting muddy in proximity to the anomaly.
Scanning one of these will provide a message, either of nothing
happening or a minor hallucination as your character suffers from the
real anomaly's effects.
Using an anomaly neutralizer on a decoy will do nothing. There's nothing
to neutralize, because nothing is there. You're losing your grip on
reality.
Now, the detonate effect will affect people at a wider radius, through
walls. This is done with a second helper different from
`visible_hallucination_pulse()`, which does affect the blind and ignores
walls, `hallucination_pulse()`.
## Why It's Good For The Game
Hallucinatory anomalies are easily the most underwhelming and
understated anomaly in the group. They have the impact of a dry fart on
a round, rarely affecting anyone and vanishing without anyone noticing
or caring.
It makes little sense for the detonate effect to impact only those who
can see it. Anyone with a pulse can make the connection between the
"hallucination anomaly" vanishing and Bubblegum bodyslamming them less
than a second later. By affecting those out of sight, in a wider range,
there's a higher chance the detonation will not only catch people off
guard, but lead to more chaos on comms.
As for the illusory decoy anomalies, it was just a neat idea I had to
differentiate how people typically deal with them. It makes for a more
trippy experience for whoever has to deal with them, and adds confusion
(which is the whole shtick with hallucinations -- confusion).
So, overall, more snazziness and personality, and more of an impact when
left alone.
## Changelog
🆑 Rhials
balance: Hallucinatory anomalies now have a wider range, and will spawn
hallucinatory decoys of itself to mislead you.
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
can_see wasnt working after the new inbuilt byond procs were introduced
to it.
## Why It's Good For The Game
closes#86515
## Changelog
🆑
fix: basic mobs will now act hostile again
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
BYOND 515 added a new proc called `get_steps_to` - which is basically
`get_step_towards`, but instead it returns a list of directions! Ain't
that nifty and useful? So we can just calculate the path once.
Several helper procs - `can_see`, `CheckToolReach`, and
`get_hearers_in_LOS`, use `get_step_towards` in a loop, so I've
refactored them to just calculate the path once using `get_steps_to`,
and then loop through the returned path of directions.
## Why It's Good For The Game
In theory, should micro-optimize performance, by only calculating the
pathfinding once.
## Changelog
🆑
refactor: Refactored some functions related to line-of-sight and reach
to improve performance.
/🆑
## About The Pull Request
this is a revival of #82635 . i got permission from potato to reopen
this, he did almost all the work. i only just solved the conflicts and
fixed all the bugs that were preventing the original from being merged
(but it should be TMed first)
## Why It's Good For The Game
slightly improves the performance of basic mob AI
## Changelog
🆑
LemonInTheDark
refactor: able_to_run and incapacitated have been refactored to be event
based
/🆑
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: ZephyrTFA <matthew@tfaluc.com>
## About The Pull Request
Currently, if dreamluau is absent (which it might be on linux instances
that don't automatically download it), every `call_ext` call runtimes,
crashing the calling proc. This fixes that by using a flag that skips
calling `call_ext` if unset.
## Why It's Good For The Game
Apparently this could really bork the garbage collection subsystem, so
fixing it is a really good idea.
## Changelog
Does this even count as a player-facing change?
