## About The Pull Request
In my infinite hubris and sloth, I foolishly assumed mob spawners
'spawn' 'mobs'. In truth, they actually do Absolutely Nothing and it's
just the ghost_role and corpse subtypes that actually do anything. It's
still my bad but, bruh. bruh uruhurb,,,
## Why It's Good For The Game
closes#91575
Cock
Roach
## Changelog
🆑
fix: Fixed cockroach spawners not doing anything
/🆑
## About The Pull Request
Adds bloodroaches.
These are cockroaches that have gorged themselves on blood in
maintenance. They're very gross!
Splatting one causes an explosion of blood all around the death
perimeter, splashing both turfs and mobs with blood.
They have a 1% chance of spawning in place of normal roaches.
They also spawn in:
- Abandoned crates, replacing the 30 roaches with 30 bloodroaches.
- As backup anomalous crystal possession targets.
- Grimy fridges
Added a trait given to things killed by pest spray, used to check on
death explosion for bloodroaches.
Changed roach spawns in maps to use mob spawners, so I can replace them
with bloodroaches 1% of the time.
## Why It's Good For The Game
Splatting a random roach in maintenance that explodes into blood sounds
hilarious. It also adds janitorial depth by requiring pest spray to
carefully eliminate these pests
## Changelog
🆑
add: Added bloodroaches, a rare variant of cockroaches that explode into
a shower of blood when squashed.
/🆑
## About The Pull Request
Converts `/datum/player_details` into `/datum/persistent_client`.
Persistent Clients persist across connections. The only time a mob's
persistent client will change is if the ckey it's bound to logs into a
different mob, or the mob is deleted (duh).
Also adds PossessByPlayer() so that transfering mob control is cleaner
and makes more immediate sense if you don't know byond-fu.
## Why It's Good For The Game
Clients are an abstract representation of a connection that can be
dropped at almost any moment so putting things that should be stable to
access at any time onto an undying object is ideal. This allows for
future expansions like abstracting away client.screen and managing
everything cleanly.
## 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 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
This will fix#83730, fix#85985 and fix#86033.
## Why It's Good For The Game
See above.
## Changelog
🆑
fix: You can no longer pickup closets and crates wrapped in a package
with a fishing rod.
fix: Fixed a few harddel issues with mob spawns that caused charred
corpses fished from lavaland to create an invisible blockade.
fix: Fixed being able to fish up mobs that have fallen in totally
different z-levels with a rescue hook (i.e. from bitrunning domains to
lavaland).
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## 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
Basically, adds a version of `randomize_human` that's a tad more
curated, IE, primarily picks results to create a more "coherent" result
than full randomization.
Shown here: Humans, Lizards, Felinids. Looks a bit boring, but that's
the point.
Non-humans I left almost entirely untouched, as they generally form a
more "coherent" mob from pure randomization already.
## Why It's Good For The Game
Basically just aiming to perform a more "consistent" style for humonkeys
and corpses.
For monkeys, it doesn't make the most sense when they pop up with a
giant red afro.
For corpses, it's a bit hard to feel immersed in the ruins when they've
all got pink and green mustaches.
## Changelog
🆑 Melbert
add: Humonkeys and random corpse spawns now look more... human.
/🆑
## About The Pull Request
See changelog for shortlist
1. **Threat changes.** I was a bit unsatisfied with the rate of antag
spawns. These have been increased considerably. The clamped probability
has been increased from 1-10 to 5-15. The probability increases from 5
to 15 as domains are completed. Generally, in a standard round, the
chance of spawning at least one antag should be around ~50% at 7 domains
completed. Emagging a server doubles this rate.
2. **Map changes.** Starfront saloon was a cool idea on paper: A totally
modular map. However, it looked very uninspired and was so much of a
chore on the map loading system that it prompted players to admin help
how long it took, thinking it was broken. I've removed the map. I have
others I want to implement that don't look so bad.
3. **QoL changes**. Ghost observer experience is improved. Previously,
you could click netpods to view their avatar, and now you can click the
hololadder to return. I've included examine text to show this. The
server's examine text will now also give you clues that it's emagged
(ghost only). The examine text on hololadders has also been improved.
4. **Bitrunning antags.** These were designed as temporary, but they
were everything but. Spawning as one would prevent your revival, which
just isn't a good tradeoff for something that's going to get deleted in
a minute. Now, this system uses temp bodies just like CTF, so you can
return once you're dead. (exception: coming station side)
5. **Maps**: Syndicate assault is still one of my favorites, but there's
cheesy exploits like instantly breaking the display case to lock down
the ship, turning on turrets which are EXTRA lethal, etc. I've added
some pistols to the closets and removed some of these exploits.
6. **Cooldown**: Yes, no one seems to upgrade these ever, and it proved
a poor technique to encourage bitrunners to leave their rooms. I had
other plans to encourage this, not included here, so I think lowering
the cooldown time is beneficial. 3min -> 2min
> [!NOTE]
> File diff: removed a map
## Why It's Good For The Game
Closes#83787
General updates and QoL for bitrunning to keep it fresh. I was quite
disappointed with the scaling of threat, and most players haven't even
seen bitrunning antags except when I admin spawn them. These numbers
aren't hard set in my mind, and could be adjusted.
I generally want bitrunning easier to access and more "temporary" which
is in keeping with its design doc.
## Changelog
🆑
fix: Bitrunning made more illegal: Increased the rate at which antags
spawn.
fix: "Temporary" bitrunning antagonists and spawners are made actually
temporary. You will return to your original body after death, just like
CTF.
add: Added more examine text for ghosts to bitrunning equipment.
balance: Server cooldown reduced by 1 minute at base level.
add: As an observer, you can now switch views between station and
virtual domain by clicking the hololadder and netpod respectively.
del: Removed the starfront saloon BR map.
fix: Syndicate assault map: Added pistols, reduced exploits.
/🆑
## About The Pull Request
This PR moves random name generation for species onto their languages.
What does this mean?
- For species with a predefined name list, such as Lizards and Moths,
nothing.
- For species without predefined name lists, such as Felinids, their
names will now be randomly generated from their language's syllables.
(In the prefs menu:)
Why?
- Well, we actually had some dead code that did this. All I did was fix
it up and re-enable it.
- Generates some pretty believable in-universe names for various
languages that are lacking name lists. Obviously defined lists would be
preferred, but until they are added, at least.
- Moves some stuff off of species, which is always nice.
- Also hopefully makes it a tad easier to work with name generation.
There's now a standard framework for getting a random name for a mob,
and for getting a random name based on a species.
Misc:
- Adds a generic `species_prototype` global, uses it in a lot of places
in prefs code.
- Makes `GLOB.species_list` init via the global defines
- Deletes Language SS
- Alphabetizes some instances of admin tooling using the list of all
species IDs
- Docs language stuff
- Deletes random_skin_tone, it does pretty much nothin
## Changelog
🆑 Melbert
refactor: Random Name Generation has been refactored. Report any
instances of people having weird (or "Unknown") names.
qol: Felinids, Slimepeople, Podpeople, and some other species without
defined namelists now automatically generate names based on their
primary language(s).
qol: More non-human names can be generated in codewords (and other misc.
areas) than just lizard names.
/🆑
## About The Pull Request
Saw this in CI.
~~Quick fix for it--because turrets are not mobs trying to call this
proc on them will runtime. So let's give them their own implementation
of the proc.~~ Just kidding, let's refactor faction checking entirely
## Why It's Good For The Game
Fixes an issue with basic mob AI targeting and turrets.
## Changelog
🆑
fix: basic mobs will no longer runtime when trying to check the faction
of a porta turret
refactor: faction checking is now done at the atom/movable level
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Adds a small new lavaland ruin, the Watchers' Grave.
You will need to figure out yourself how to find a way through the walls
surrounding it (it's not very hard).
This is mostly just atmospheric but also serves as a delivery vehicle
for a unique item; an orphaned Watcher egg.
(That's kind of it in terms of loot, unless you count a handful of
lavaland mob corpses and mushrooms).
You can either eat this (it's an egg), throw it at someone to spawn an
angry watcher, or keep hold of it for a while and see what happens.
<details>
That's right it's your very own baby watcher.
It orbits your head and shoots at lavaland creatures for unimpressive
damage. It won't ever intentionally shoot a player but they might walk
in front of it, as it doesn't hurt very much they will probably forgive
you.
If you die it will continue circling your corpse to guard it against
predation.
</details>
In creating this ruin I also added a new component called "corpse
description".
It provides some extra examine text to a corpse which is removed
permanently if the mob is revived.
There's a field you can varedit on corpse spawners (or make a subtype)
which will automatically apply it to spawned corpses.
You can use it for environmental storytelling. Or admins can use it to
make fun of how you died.
Also I fixed basic mobs runtiming when examined by ghosts.
## Why It's Good For The Game
More variety in map generation. It's cute.
Adds a tool that mappers might like.
## Changelog
🆑
add: Adds a new lavaland ruin where you can find a unique egg.
/🆑
## About The Pull Request
Transferred.
## Why It's Good For The Game
How did this get to be in 71 files?! This bothers me.
Also changes 'quality_oil' typepath in the reactions to 'olive_oil' to
match its rename post-foodening.
## Changelog
N/A
## About The Pull Request
`is_banned_from(...)` expects a ckey.
`/obj/effect/mob_spawn/ghost_role/attack_ghost(...)` checks for role
bans by using key instead.
This can lead to players whose keys and ckeys are different being able
to evade certain ghost role bans; by accident or otherwise.
This PR takes a two-pronged approach. The first fixes ghost roles
passing in the key instead of the ckey to is_banned_from. This fixes the
bug, and makes it consistent with all other cases of
`is_banned_from(...)` being called.
The second is to redefine the behaviour of `is_banned_from(...)` to
accept either a ckey OR a key, since converting from key to canonical
key should be a fairly trivial operation. This prevents this specific
bug from ever occuring again, by making it intended functionality to
pass either key or ckey similar to how the roles param accepts either a
string role or a list of roles.
### ***Please review the code carefully, my changes to
`is_banned_from(...)` have not been tested. No logical flow should have
been changed.***
## Why It's Good For The Game
Ban systems working good.
## Changelog
🆑
fix: Fixes an issue where role banned players would be able to accept
certain ghost roles they're meant to be banned from.
/🆑
<!-- 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
create_from_ghost() now returns the body it produces.
This should fix the pirate/fugitive ghost orbit notifications, since
they expect to have a mob returned by this proc. Since the mob they
expect to be returned is used as the subject for the ghost orbit popup,
the popup would have no source and end up being blank.
<!-- 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
Players selected to play pirate/fugitive will now have a functioning
orbit popup.
<!-- 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. -->
<!-- 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. -->
## About The Pull Request
I love it when we add something and we have like three PRs around the
same time touching the same code and none of it conflicts, it's awesome,
believe me!
Adds the `!infinite_use` to the other check that checked the uses left,
to ensure that it still allows infinite spawners to remain infinite.
## Why It's Good For The Game
Code that works is always good for the game.
## Changelog
🆑 GoldenAlpharex
fix: Ghost role spawners that are set to have infinite uses no longer
run out of uses.
/🆑
## About The Pull Request
Turns out https://github.com/tgstation/tgstation/pull/73833 happened
before my PR was merged, and somehow miraculously didn't conflict with
it.
However, it still made it so the ckey was now null, and the way that Git
handled the conflict, made it so the variable was now at the wrong spot,
and now it was null.
Fun times.
## Why It's Good For The Game
People gotta be able to spawn in from other spawners, that's the whole
point.
## Changelog
🆑 GoldenAlpharex
fix: Fixes ghost role spawners not allowing you to spawn from more than
one ghost role per round.
/🆑
## About The Pull Request
Turns out there was no verification to ensure that you weren't already
in the process of trying to join a ghost role, when clicking on a ghost
role spawner.
That resulted in people being able to double-click on a spawner and
basically, trying to spawn twice... Or thrice... Or even more than that
if they're fast.
Of course, that's not a good thing, so I made it so you can only try to
spawn one time at a time, which includes only getting one prompt at a
time. That includes ALL spawners, because I know that bug will otherwise
pop up at some point from someone thinking they're clever.
I added a CRASH() for the handling of ckey-less ghosts, in case someone
tries to do another subtype that somehow manages to bypass all of the
checks I already added. That way, they'll know if they fuck up.
I also made a second uses check considering there's stoplags in the
is_banned() check.
Fixes https://github.com/tgstation/tgstation/issues/73619.
## Why It's Good For The Game
Having mindless bodies is just not very cash money and it can break
spawners to the point of making them go to negative amounts of uses,
which isn't very cash money.
## Changelog
🆑 GoldenAlpharex
fix: You should only be able to spawn as one ghost role at a time. Close
the prompt if you want to spawn as another one. Begone soulless
randomgen humans!
/🆑
## About The Pull Request
Same issue as before, these skipped the spawn step and snowflaked their
own creation process.
So I split off the create part of attack ghost so these could share.
Fixes#73823 , may fix also #73822 but I don't *think* it will, whatever
changed spawners a few months ago is a little sus
## Why It's Good For The Game
Changeling pirate bad
## Changelog
🆑 Melbert
fix: Fixes pirates and starfury assailants keeping minds of past lives
/🆑
## About The Pull Request
Gives a more 'proper' way for mob spawners to be infinite than just "set
a very large number".
## Why It's Good For The Game
Useful for admins
## Changelog
not really player facing
## About The Pull Request
I made it so mob spawners transfer existing minds because of golem
shells but ghosts have minds on occasion.
Disassociates mind before spawning from ghosts.
## Why It's Good For The Game
Wizard golems Fixes#73577
## Changelog
🆑 Melbert
fix: Ghost roles from spawners keeping antag datums
/🆑
## About The Pull Request
Fixes#73468
The admin message in `mob_spawn/ghost_role/attack_ghost` was warning
admins any time a ghost role spawner did not create a mob, however
clicking a spider egg opens a radial menu. Neglecting to choose one of
the options (and closing the menu) does not return a mob, and was
implying that some kind of error occurred when this is actually expected
behaviour.
Also as noted in the comments this probably needn't message admins in
the first place, we now log it as a crash instead.
## Why It's Good For The Game
We shouldn't print a log message in admin chat for expected behaviour.
Logging changes will help diagnose if this was masking an _actual_ bug.
## Changelog
🆑
fix: Clicking a spider egg and then closing the radial menu won't print
a message in admin channel informing admins that the egg didn't spawn
anything.
/🆑
## About The Pull Request
Fixes#73368
Golems didn't mind transfer on body swap until after the body was
finished creating, this created an issue as golems also did mind
assignment business while creating the body. So the
`mind.enslave_to_creator()` part runtime error'd and caused the create
to fail, which in turn caused the shell to not be consumed.
While sorting this out, I noticed that shells and golems hold a hard
reference to their owner. Yep, hard deletes. Changes mind `enslaved_to`
to a weakref, changes golem `owner` to a weakref, straight up removes
golem `owner` tracking on species because it was ONLY used for card
board golems when it could've just grabbed mind master
## Why It's Good For The Game
No more infinite golem shells
## Changelog
🆑 Melbert
fix: Transferring golem shells no longer make you a free man and also
results in infinite golem shells
fix: Servant golems are considerably less free
fix: Fixes some hard deletes related to mob minds being enslaved to
other mobs
/🆑
## About The Pull Request
By means of making a particularly popular ghost role (do NOT put
catgirls on icebox bro you don't know the consequences) I have
discovered a strange bug where despite any of the checks that are in
place, it will still attempt to spawn more people than the role should
allow. I've found the likely caused to be that a lot of people are
clicking the role then clicking spawn at once, and the spawner simply
does not have time to tell everyone "wait no you can't do that" before
it deletes itself from running out of uses.
The solution? Even easier than the reservation thing: Subtract uses
**BEFORE** spawning the mob, as spawning the mob can take some time,
then if it fails to spawn somehow we can refund the uses.
## Why It's Good For The Game
Ghost roles spawning in the nullspace spawn room every now and then is a
bad thing I think.
## Changelog
🆑
fix: Ghost role spawners will now no longer try and spawn people when
they /should/ have been out of uses but due to a bug were not
/🆑
## About The Pull Request
A very minor change but one that will save headache down the line. Adds
plasmaman support to mob spawners, meaning they will be guaranteed to
get their internals and suit upon spawning from those.
Modified the equip proc to be able to automatically turn hand slot
internals on without the need for snowflakey open_internals checks
everywhere, as that should already handled by the it (shown below). Just
modified it to work on hand slots.
4b832e7d01/code/datums/outfit.dm (L245-L248)
## Why It's Good For The Game
Adds support for present and future mob spawners involving plasmapeople.
## Changelog
🆑
qol: prevents mob spawner plasmamen from spawning without their suit and
internals.
code: the equip proc can now find internals in the hand slot and
automatically open them, allowing for less snowflakey code down the
line.
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
revive of #68760
this time a proc, not an element
this time supports cardboard cutouts
this time supports mob corpses
## Why It's Good For The Game
prevents these icons ever being outdated, they'll always look what they
are supposed to, saves spriting work
## Changelog
🆑 Fikou, a hood by Viro
refactor: humanoid mobs and cardboard cutouts automatically generate
their sprites, they no longer will be outdated
/🆑
Co-authored-by: Time-Green <timkoster1@hotmail.com>
## About The Pull Request
**Comes with an UpdatePaths!**
Removes the tablet subtype, PDAs now replaces them entirely.
Nukie and Silicon tablets are now subtypes of the PDA instead, while
contractor ones were removed entirely as they didn't do anything and
were unused (though it wouldn't be hard to re-add).
Nukie PDAs are now the only type of PDA that uses modular_tablets.dmi,
which is just larger icons of modular_pda. Each application requires an
icon state in both of these, for 2 different sizes, which makes it
annoying to make new applications, especially if it can also run on
computers/laptops.
### Icons
Because Silicon tablets are now a subtype of PDA, they use PDA icons
instead of tablet ones. Luckily for us, they already exist in code.
AI's don't use a tablet icon though, so they aren't affected.
## Why It's Good For The Game
There's very little difference between tablets and PDAs, PDAs overshadow
them in every single way, so at this point I don't see why we should
have both of these, and if you compare the two in usefulness and actual
in-game use by players, it's a no-brainer than the item all players get
roundstart and comes with a messenger should be the one we go with.
Also as said in the about section, when making an app you would need to
make icon states for the program running for all hardware it can run on,
which is Computer, Laptop, PDA, and Tablet.
Laptop is just a smaller computer icon
PDA is just a smaller tablet icon
However, you can't simply shrink the size of the icon, instead you have
to completely resprite the same app icon FOUR TIMES for it to not
bluescreen on all these different devices.
<details>
<summary>
Here's examples of it
</summary>
Computer (NOTE: *They share the same icon file as regular computers*)
<img
src="https://user-images.githubusercontent.com/53777086/203876801-486a8054-489a-4983-bdad-a2599b4dc379.png"/>
Laptop
<img
src="https://user-images.githubusercontent.com/53777086/203876333-58e5d135-f4c6-4a02-8948-1df771e294a4.png"/>
Tablet
<img
src="https://user-images.githubusercontent.com/53777086/203876352-816c7fb1-c681-40b9-99e0-052f49632c7f.png"/>
PDA
<img
src="https://user-images.githubusercontent.com/53777086/203876358-1cf7253d-3c6a-456a-8133-ebf7f0351637.png"/>
</details>
If we wish to help in simplifying this, we should remove tablet icons
entirely, which means 1 less icon to worry about. To do this, we'd need
to resprite nukie PDAs, however I am very much not a spriter and never
tried GAGS, so I'll leave it to someone else to do.
## Changelog
🆑
del: Tablets are now removed, PDAs are now the base 'tablet'. Silicon
and nukie tablets are now PDAs.
/🆑
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Removes HDD's entirely
HDDs have been removed, though the code for it is still currently lingering as it's required for portable disks. I'll have to find a solution to this one day, but as I am going to sleep, this is a problem for future me.
* starts on removing SSD
* updatepaths and kills off SSD
* update path :D
* Fixes to programs and icons
* Ready for review now
I read over everything I did and tried to fix anything I saw wasn't done right. Hopefully better comments now.
* merge conflict fix
* can't win them all
* takes viruses into account in paths, fixes it in snowcabin
* Renames the updatepaths
* removes the qdel loop
* accidentally new'ed programs twice
* Fix program's computer var
* destroy pen and disk, dont run kill program on something killed
* more fixes for pens and idle threads
* Fixes PDAs installing apps twice.
* simplifies inserted disk & PDA disk
* fuck's sake
* Use istype instead
* revert
* Revert "revert"
This reverts commit 9ede628c6fef9c7c86417234f6d8ada1ff9e2fef.
* why did that happen
* Update code/modules/modular_computers/computers/item/tablet.dm
* MC_SSD added to master lol
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
* Removes a ton of unused vars, re-organizes the rest
Removes a ton of unused vars from Modular computers
Re-organizes the rest, and adds autodoc comments to most of them
Moved 2 vars (saved_image and invisible) from the tablet to the messenger app, since that's where it was used. I didn't see the point of having these vars be on every computer anyways, only PDAs have the app.
Renames Clown's honk virus var
Makes Messenger app's saved image, actually used.
* static list and NODECONSTRUCT_1 check
* oops
About The Pull Request
replaces a ton of log_game with user.log_message so the log is added to individual and global logs.
adds a few logs for individual LOG_VICTIM, LOG_ATTACK etc logging.
adds logging for bluespace launchpad's tele coords being changed.
took the word "has" out of log_combat, as it's extra and just lengthens the log.
Why It's Good For The Admins
It's extremely laggy to open game.txt so an alternative is individual game logs
Changelog
cl
admin: A lot of game logs will now also be in individual game logs, for convenience in log diving.
admin: Added logging for bluespace launchpad x and y offset changes, which go to individual game logs.
admin: Attack logs will now be slightly shorter, one useless word was removed.
/cl
Converts PDA functions and applications over to modular tablets and devices, namely the messaging function. HREF data code is quite honestly clunky and difficult to work with, as I've definitely experienced whilst working on this. By moving from this system over the easier to read (and frankly, easier to add to) TGUI system, you get cleaner looking and more user friendly UIs and a greater degree of standardization amongst other UIs.
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
Fixes names of golems from golem shells.
This whole manual transfer mess (golems having a special ability to swap into another mob spawner) needs better implementation.
About The Super Hyper Ultra Ultimate Deluxe Perfect Amazing Shining Mob Spawn Refactor
The Super Hyper Ultra Ultimate Deluxe Perfect Amazing Shining Mob Spawn Refactor is my attempt to clean up the file structure, the code, and the type tree for mob spawns.
Splits mob spawn types into corpses (dead spawns) and ghost roles (living spawns you can possess). The vars that didn't make sense for corpses and vice versa for ghost roles are now appropriately there
Because of above, there are no longer the fucking "death, roundstart, and instant" vars. thank god
Removes a lot of single or very few used vars, whose properties can be applied on special().
All Mob Spawns are given fitting folders instead of just being stuck in a single ghost roles file. Corpses are in the corpse folder, Ghost Roles are in the ghost role folder. Only exception are drones which should stay near their respective homes
Just generally cleaner all around you know
spider structures file renamed to spiderwebs now that spider eggs are gone
Why Super Hyper Ultra Ultimate Deluxe Perfect Amazing Shining Mob Spawn Refactor Is Good For The Game
The Super Hyper Ultra Ultimate Deluxe Perfect Amazing Shining Mob Spawn Refactor cleans up so many terrible cases and uses
Changelog For The Super Hyper Ultra Ultimate Deluxe Perfect Amazing Shining Mob Spawn Refactor
cl armhulen
refactor: Mob spawns are refactored, no more assortment of "random, instant, and roundstart" vars on every mob spawn type
refactor: if there are some minimal differences in how mob spawners feel, that's why!
/cl
