## About The Pull Request
I think it's been related to the recent DDOS's but looking at the
non-connected wall turf overlay while loading into the game and waiting
for the config-loaded start screen to load is just ugly as hell on
production servers. So, let's fix this in a way that we really should
have done pre-wallening: using cordons.
Cordons just give us a fully solid white background and are probably
faster to load than the indestructible turfs (claim unverified), but
visually it just looks better if an admin deletes the start screen for a
laugh or just having a nice solid black background while the lobby
screen loads in instead of the weird noncongruous turf type we made.
<details>
<summary>
Photos
</summary>
This is what the lobby screen looks like if the image is deleted/while
it's loading in:
This is what it looks like when zoomed out on the map after deleting the
sprite. will just appear as world border to any mobs that venture out
into the wastes.
</details>
## Why It's Good For The Game
Looks way cleaner than the current solution, can discard a needless turf
type for something that looks nice. We were already punching a hole in
the CentCom z-level so why not just make it fully more obvious.
I left the `misc/start` area as-is in case admins still want to plop
down schenanigan meme buildings in the lobby. I also made it so that
deleting the lobby screen baseturfs to the cordon type, so you aren't
left with an ugly hole to space in the title screen.
## Changelog
🆑
fix: The area of the CentCom Z-Level dedicated to the Lobby Screen
should look far better now, with a solid black title screen should the
lobby image not load in/get deleted.
/🆑
## About The Pull Request
Ever since Clarkes could pick up boulders they've been broken if you
ever collected one. The UI would break and all your precious minerals
would be trapped inside the Clarke, only being obtainable if you broke
the Clarke itself.
This also updates the Clarke Storage to differentiate by ore name rather
than icon, as otherwise the lower quality boulders would be mixed with
normal boulders with no way to differentiate them in the UI.
## Why It's Good For The Game
Fixes https://github.com/tgstation/tgstation/issues/84364
Before:
<details>
<summary>Before</summary>
https://github.com/user-attachments/assets/f90daf35-733a-42bd-8af5-7e6712f09fba
</details>
<details>
<summary>After</summary>
https://github.com/user-attachments/assets/4510803c-6dee-403e-a051-966a8a66c17c
</details>
## Changelog
🆑 TwistedSilicon
fix: Clarkes will no longer become unable to dump ores upon picking a
boulder up. Mine away.
/🆑
## About The Pull Request
*The Miami Mutilator is at large once again. Thank god we have such
hardboiled detectives as Manny Pardo on the case.*
This pull request allows for players to use white crayons, which have
now been renamed to sticks of chalk, to generate outlines of dead or
"dead" bodies found throughout the station in an attempt to let
detectives actually set up crime scenes as opposed to, more typically,
just causing them.
Players will attempt to draw a chalk outline if the target is a mob and
the mob is dead (or fake-dead), using a single charge of the
crayon/chalk. Also, adds a quick macro so that we can get the proper
left/right orientation of the dead mob for reference.
## Why It's Good For The Game
Detective should have more thematic, simple ways to organize crime
scenes in-round, and what better way to do that then through existing
items and mechanics that we already have. Also, I was 100% shocked to
learn that these have always been white crayons as opposed to sticks of
chalk, which certainly seems odd. In essence, this change doesn't really
let you do anything "new", but just makes it easier and simpler to do so
in a regular round without nearly as much fiddling.
This mechanic exists exclusively within the afterattack of sticks of
chalk as opposed to all crayons for thematic reasons, but I'm not 100%
sold on that and it would be simple to move over to all crayons if
people feel strongly about that.
## Changelog
🆑
add: White crayons (Renamed to Sticks of Chalk) may now be used on dead
bodies to draw a body outline onto the ground easily.
/🆑
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
## About The Pull Request
I've refactored the FISH_SAFE_STORAGE trait into an element, mainly
because there were a few problems with how it worked: It wasn't stopping
hunger from raising, ditto with the breeding wait, and it offered no
healing whatsoever, which I find kind of a bummer. The new element will
keep the fish from getting any hungrier or ready to reproduce and will
heal them up to 65% of their base health.
Also, I've added a new bluespace fish case as a techweb design, found
along with other stuff in the advanced fishing node, though if you want
I can move it to a bluespace node. This should make it possible to
reasonably store and carry around larger fish.
Examining a fish will no longer give out readings on weight and size if
you haven't at least attempted fishing once (you can get to novice level
in less than a minute). While examining a fish with apprentice level or
higher will also give readings on the general conditions of the fish (is
it starving? drowning? has it lost a considerable chunk of health?). The
fishing skillchip also gives you these traits.
I've also converted two fish variables into traits, because fish have
waaaay too many variables. and gave some topdown shading to the
pre-existing fishbox sprite.
## Why It's Good For The Game
## Changelog
🆑
add: Added a bluespace fish case to the advanced fishing node.
balance: Fish cases will keep a fish from getting hungrier or ready to
reproduce, while also healing it up to 65% health.
balance: Examining a fish with zero fishing skill whatsoever won't give
a reading on its size and weight. Conversely, examining one with the
skill leveled two times will give general information on if it's
starving, sick, hungry, or dead.
/🆑
## About The Pull Request
Updates all worn tank sprites to fit new tanks/jetpacks
## Why It's Good For The Game
They're rather crunchy and outdated, their palette doesn't fit with
current tanks either
## Changelog
🆑
image: Gas tanks got updated worn sprites
/🆑
## About The Pull Request
Following the PR that split the slowdown between spacesuits and helmets,
the CentCom special ops 'space suit' (officer's beret and winter coat),
which previously had no slowdown, gained a slowdown on the beret only.
Considering it is an adminspawned outfit and cannot be found anywhere,
there shouldn't be any balance issues with it.
## Why It's Good For The Game
The CentCom winter coat had its slowdown removed, why wouldn't the
beret? Seemed like an oversight from the original PR.
## Changelog
🆑
qol: The CentCom officer's beret has had its slowdown removed to be in
line with the winter coat.
/🆑
## About The Pull Request
Oops! A minor mapping change made it's way through on runtime unwiring
the APC on runtime as a consequence of some directional wallmount
changes I did. This moves the APC back to the top left corner with a
wire connection yet again.
## Why It's Good For The Game
Prevents runtime station from running out of power during standard
testing.
## Changelog
🆑
fix: Runtimestation's APC is now connected to the grid again.
/🆑
## About The Pull Request
Found by Melbert on discord, caused by paint mode not applying when
painting random decals.
## Changelog
🆑
fix: Random spraypaint setting now properly paints large decals
/🆑
## About The Pull Request
Apparently this wasn't a thing, somehow. Adds stat change logging to
combat log for admins.
## Why It's Good For The Game
Admins want this for some reason, got requested in coderbus.
## Changelog
🆑
admin: Stat change is now logged for living mobs
/🆑
## About The Pull Request
Apparently, that's why you couldn't examine the button at all. For some
reason, this is only the case with the lobby buttons tho, as you can
examine other nameless atoms, even though they still don't show up in
the right-click context menu.
## Why It's Good For The Game
Fixing a long-standing issue with lobby buttons.
## Changelog
🆑
fix: Fixes lobby buttons from station traits having no name and being
unexaminable.
/🆑
## About The Pull Request
Updates Icebox, also adds a few mapping touches to work with the new
Wallening.
Also adds a corpse trapdoor in medical into the morgue since I replaced
the stairs, and maybe some other things
## Changelog
🆑 Melbert
qol: Icebox now has a trapdoor from Medbay leading into the Morgue (for
corpses, of course)
/🆑
## About The Pull Request
Turns
`ON_WALL_LAYER`
into
`FLAT_ON_WALL_LAYER`
`ON_WALL_LAYER`
`HIGH_ON_WALL_LAYER`
Where `FLAT_ON_WALL_LAYER` is meant for lower-priority wall mounts like
signs and posters
`ON_WALL_LAYER` is default
and `HIGH_ON_WALL_LAYER` is for stuff that "hang over" the wall
Also makes the incident display actually wall mounted
## Why It's Good For The Game
I noticed this while doing mapping and I thought it was a really cool
effect
Unfortunately this effect was a coinflip because all wall mounts were on
the same layer. Sometimes it'd look like this
So this allows us to do this kinda stuff consistently.
Also has the added effect of letting us "de-prioritize" stuff like
posters, so we can hang stuff *over* posters and signs, which could be
useful.
## Changelog
🆑 Melbert
qol: Some wall mounts will now consistently layer over others (light
switches and cameras, notably, should always layer above other mounts
like signs and status displays)
/🆑
## About The Pull Request
ai controllers would have the wrong status when moving z levels
## Why It's Good For The Game
fixes ai controllers incorrectly idling when changing z level
## Changelog
🆑
fix: fixes ai controllers incorrectly idling when changing z level
/🆑
## 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.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
https://github.com/user-attachments/assets/98aa2177-ee0f-48d0-bbd4-83d01e688b54
it makes gravity in a radius
you may order it from cargo
may take power from wire instead
## Why It's Good For The Game
good for like space bases and stuff
## Changelog
🆑
add: portable gravity unit, bought at cargo
/🆑
## About The Pull Request
Updates many of the impacted items from the wallening on the Birdshot
Station. Due to the clashing between StrongDMM 2 and the Wallening
Project, I'm sure this hasn't caught everything. Going to want several
pairs of eyes for this one.
## Why It's Good For The Game
Getting maps back into rotation is very high on the priority list.
## Changelog
🆑
fix: Updates much of Birdshot for the Wallening
/🆑
## About The Pull Request
Digitigrade legs use the claw footprint sprite
## Why It's Good For The Game
#81588 added support for legs to use alternative footprint sprites and
then just didn't add it to anything but monkey legs, even though the
sprites already exist. So let's use them
## Changelog
🆑 Melbert
qol: Xenos and digi lizards have claw footprints
/🆑
…swapped and gave Access Buttons a South Sprite
## About The Pull Request
This pull request fixes the Access Buttons' sprite by swapping the East
and West access button sprites, which were previously reversed.
Additionally, it adds a South-facing sprite for the access buttons to
ensure it can be used and viewed from all directions.
### Before/After:
## Why It's Good For The Game
Correcting the sprite orientation improves the visuals of the access
buttons. The addition of a South-facing sprite ensures that access
buttons can be used from all directions allowing for more freedom with
map design if someone needed an access button for an area facing south.
## Changelog
🆑
fix: Swapped East and West sprites for access buttons to correct
previous misalignment.
add: Added South-facing sprite for access buttons.
/🆑
## About The Pull Request
Brings barriers to 3/4 wallening-appropriate perspective.
## Why It's Good For The Game
Brings the sprite to current standards.
## Changelog
🆑
image: adjusted security barriers to be in 3/4 perspective.
/🆑
