## About The Pull Request
Makes client upload limit a config. Increases max file size admins can
upload to 5mb, up from 2.5mb.
## Why It's Good For The Game
Makes it easier to do custom maps for events. Some of our in-game maps
are already larger than 2.5mb (delta is almost 3mb).
## Changelog
🆑
admin: admins can now upload files to the server up to 5mb (used to be
2.5mb)
config: file upload restriction is now config
/🆑
## About Why It's Good For The Game The Pull Request
What it says on the tin. A requested feature for people who like to keep
an eye on swaths of new players. A config that is off by default, but a
Discord role ID can be added to have TGS ping that role.
Also sends alerts to Discord if a player with sketchy telemetry joins.
## Changelog
🆑 Tattle
admin: Pings an admin role on discord when a new player joins (when
enabled by config)
/🆑
---------
Co-authored-by: tattle <article.disaster@gmail.com>
## About The Pull Request
Removes the TTS voice disable option, which was already unavailable on
TG as it was set to off by default. The reason this was added was so
that downstreams could toggle the config on or off.
## Why It's Good For The Game
I think this option fundamentally undermines the TTS system because it
allows individual players to disable their voice globally, meaning that
players who have TTS enabled will not be able to hear them.
This worsens the experience for players who have TTS enabled and it's
not something I want to include as an option. If players don't like
their voice, they can turn TTS off for themselves so that they don't
hear the voices. If players don't want to customize their voice, they
can quickly choose a random voice, and we can take directions in the
future to make voice randomization consistent with gender so that a male
does not get randomly assigned a female voice and vice versa.
This option is already unavailable on TG servers because it was
primarily added for downstreams, but I don't think giving downstreams
the option to undermine the TTS system is the right direction to take.
Downstreams are still completely free to code this option on their own
codebase.
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com>
## About The Pull Request
Hey there,
#75992 (fc54fd6a60) made me realize just
how wacky the job config system is to people trying to add more new
stuff to it, so I finally got the motivation to fix it up.
The gist is that it does all of the same stuff on the front-end as you
would expect, but instead of having to modify core generation code to
create/recreate the files, it instead uses a robust series of getters
and setters. It's much better to use these getters and setters because
we can apply needed game logic (like ensuring that the age that the
server operator puts in is actually sane, and not completely out of
bounds (if you want to permanently price people out of a position, just
set it to 0)). The getters are also nifty too, because they let me atone
for an early mistake I made with how assistants are meant to work with
"unlimited" nonsense.
All a new coder who wants to add stuff to the config needs to do now is
create the define, create the datum, add the procs for the datums, and
that's it! They don't have to do any of the wacky stuff or account for
weird stuff or do any weird copypasta, it's all handled by the system.
One datum is all you need, quite neat.
This also fixes some issues in #75992 that probably weren't discovered
in testing, but the only good way to fix it was a retune+refactor, which
is included in this PR.
## Why It's Good For The Game
Much more extensible, ensuring this system actually works as fully
intended, etc.
I fixed up the documentation (they didn't regenerate the job config
after they updated the code-side documentation) and some weird spacing
stuff that I missed in my review of that aforementioned PR. Everything
should work as expected, it's been tested quite a bit. It's also in its
own folder now, which is neat because we can share the local defines and
split all this stuff out of the already-quite-large SSjob file.
## Changelog
🆑
server: job_config.toml should now comply with reload-configuration
verb, meaning you can hot-reload the configuration from disk and have it
apply ingame automatically.
config: The documentation for setting Minimum Character Age on a per-Job
basis has been altered to be more explicit.
fix: The Minimum Character Age configuration entry is now sanitized to
ensure that it's within the codebase-defined ages, since there's no
(legitimate) way to get a character outside of those ages anyways.
Invalid values will log to the config log.
/🆑
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
## About The Pull Request
This check is redundant because 512 fixed the exploit it was designed to
check. Randomizers still exist, but this code doesn't apply to them
since they use a different method.
Someone else tried this before but got his shit slapped for it being his
first PR and there being a possibility he was removing it so he could
bypass it. I'm not banned and have no possible ulterior motives; I just
want to get rid of dead code.
## Why It's Good For The Game
I'd make an Old Yeller joke, but the code's already dead, so.
Fixes#43227
## Changelog
This is not a player-facing change.
## About The Pull Request
https://github.com/tgstation/tgstation/assets/4081722/5ca8e015-21f9-4159-9953-bc370152d01f
Improves the audio quality and speaker fidelity by implementing
Retrieval Voice Conversion as an intermediary layer, utilizing the
repository at https://github.com/ddPn08/rvc-webui.
Leverages RVC to allow players to set a pitch for their voice.
https://github.com/tgstation/tgstation/assets/4081722/0eb76ed7-ad67-4da2-9ceb-02605eea2c83
Makes silicons utilize a player's chosen voice preference on their
character slot, and adds a preview button to hear the voice as a silicon
on character creation.
Adds a toggle on character creation to disable having a voice on a
specific character slot.
Adds support for per-tongue voice filters.
Reworks the silicon voice effect to be a special effect done on the TTS
server level instead of via normal filters.
Reworks the vending machine effect to use the new robotic voicebox
effect.
## Why It's Good For The Game
Vastly improves the audio quality and speaker fidelity of our TTS
system.
Allows players to further customize their voice per character, naturally
pitching the voice up or down with cutting edge machine learning based
pitch adjustment.
Allows silicon players to have a consistent voice that's also audible
and understandable regardless of the voice or pitch of the speaker.
Improves vending machine audio quality.
Enhances the immersion of snail tongues and robotic voiceboxes.
Adjusts how Poly's pitch adjustment works based on if RVC is available
or not.
Allows players who feel that a voice doesn't fit their character to
disable having TTS on their specific character.
Provides server operators a way to disable specific voices in situations
with a shared voice server.
## Changelog
🆑 Iamgoofball, Nadare, ddPn08, Mangio621, the rest of the RVC dev
team
add: Improves the audio quality and speaker fidelity by implementing
Retrieval Voice Conversion as an intermediary layer, utilizing the
repository at https://github.com/ddPn08/rvc-webui.
add: Leverages RVC to allow players to set a pitch for their voice.
add: Makes silicons utilize a player's chosen voice preference on their
character slot, and adds a preview button to hear the voice as a silicon
on character creation.
add: Adds a toggle on character creation to disable having a voice on a
specific character slot.
add: Adds support for per-tongue voice filters.
add: Reworks the silicon voice effect to be a special effect done on the
TTS server level instead of via normal filters.
add: Reworks the vending machine effect to use the new robotic voicebox
effect.
/🆑
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
## About The Pull Request
Alternative to #75277
Kept you waiting, huh?
This PR is the first part of a Xenomorph rework which seeks to make the
big lugs more balanced and up to date with /tg/'s current design. This
mainly involves curtailing xenomorph's infamous hardstuns into more
interactive forms of combat, while also giving some buffs to the
xenomorph's more unique abilities in order to keep them threatening.
Part 1 will focus on simple number changes and some simple mechanic
changes. In the future, changes will be made to endgame involving
xenomorphs, along with changes to other facets of Xenomorphs.
Highly based off of #55937.
Changes:
- Xenomorph disarm has been completely reworked. While a disarm will
attempt to, well, disarm, a human opponent should they be holding
something, it will no longer immediately hardstun targets when they
aren't. Instead, the xenomorph will shove the target several tiles back
and inflict 35 stamina damage. If the target slams into a wall, this
will also come with the added effect of knocking them down. If a human
is incapacitated, however, right click will slam them into the ground,
which paralyzes them for a lengthy 5 seconds (which is ultimately half
the time xenos could stun you for before), allowing for safe transport
back to the nest as long as you keep them close.
- Humans can now shove xenomorphs. Due to being the superior predator,
however, you can't knock down xenomorphs from shoving. You can slow them
for a little bit akin to humans though.
- Neurotoxin no longer is a hardstun. Instead, it deals 50 stamina
damage on contact. It is still resisted by BIO armor.
**HUNTER:**
- Speed reduced from -1 to -0.3.
- Pounce speed is twice as fast as before (1 to 2)
- Hardstun time on pounce reduced from 10 seconds to 5 seconds.
Hunters being insanely fast has been a major balance-ruining factor of
xenomorphs for many years now. These buggers could practically ambush
anyone, hardstun them immediately, and then leave before anyone could do
anything. Now, with their speed nerfed and in combination with the xeno
shove changes, hunters will need to spend more time to down a target.
Their pounce was practically useless, so its been sped up in order to
make it more practical to use.
**SENTINEL**
- Speed reduced from 0 to 0.2
- Cloak alpha reduced from 0.75 to 0.25 (you're more hidden now)
Sentinels receive a large nerf in regards to their spit, but their
before useless cloaking ability has been greatly improved upon as
compensation. They now serve better as defenders and ranged ambushers.
**XENOMORPH DRONE**
- No changes
As in the original PR, drones are perfeclty balanced in my eyes, so no
changes were required.
**XENOMORPH PRAETORIAN**
- Speed increased from 1 to 0.5
- No changes
Praetorians get affected by the nerfs of the other xeno abilities, but
now they're a bit faster in order to close the gap to use their
abilities.
**XENOMORPH QUEEN**
- Speed increased from 3 to 2
- Health increased from 400 to 500
- Damage increased from 20 to 50
Xenomorph queens have been sped up and made more tanky and lethal in
close-range combat. Fighting this beast up-close should be a death
sentence to almost anything else in the game. Speed increases will help
her re-position and close the gap on potential prey.
**OTHER CHANGES**
- Fixed a bug where simplemobs didn't actually use xenomorph's damage
values when they were attacked by them.
## Why It's Good For The Game
Xenomorphs are old, and haven't been updated for quite a long time. This
has left them as sources of a bunch of hardstuns which made counterplay
from a modern spaceman extremely difficult. With these changes, fighting
xenomorphs is more interactive and should end up being more enjoyable
for both crew and xenos. Buffs were also given out to incentivize usage
of xenomorph's unique abilities as opposed to the standard disarm spam
which was most effective for them until now.
## Changelog
🆑
balance: Xenos have been rebalanced, removing their hardstuns on their
disarm and neurotoxin, along with a slew of other changes. Xenos have
received buffs to their more unique abilities in return.
fix: Fixed simplemobs ignoring xenomorph's melee damage values when
being attacked by them.
/🆑
## About The Pull Request
Adds some hooks to the MC that detect if something ate a ton of real
time last tick, and reacts by dumping our current profile into a file
It's really frustrating to see a spike in td in our performance logs,
but see no reason in the profile because it's only taken every 5
minutes. This resolves that
I'm throwing this up so mso can give it a look over, not sure if I want
to use defines or configs here, taking suggestions
🆑
server: Adds a system to emergency dump profiles if too much time passes
between ticks
config: Added configs that control how often emergency profiles are
allowed to dump, alongside the threshold for what counts as too much
time between ticks
/🆑
## About The Pull Request
Adds optional (disabled by default) respawn delay. If the player is
observer and have a body, it will firstly check the body. If the body is
destroyed or if there was none, then it will check observer's login
time.
## Why It's Good For The Game
Optional respawn delay is good, when you want players to comeback not
only as a midround event, but don't want them to not care about their
life. Also, if respawn is enabled, removes "money dupe" and other
problems with 0 respawn delay.
This proc can also be used for ghost-roles or anything else, where we
need to check how much time has elapsed since their death, but is not
implemented here.
## Changelog
🆑
add: Added optional respawn delay (disabled by default), which prevents
returning to lobby while dead.
/🆑
## About The Pull Request
Converts all logging, excluding perf and investigate, to json.
I focused on making the system as easy to use and as easy to add new
categories as possible.
Due to issues related to logging to world at global creation logger is
now a byond real, which is created directly before Master
Log categories support versioning, secret flagging, and sub-category
filtering. Although all of this is entirely optional for coders.
If you ever want to add a new category and use it, all you need to do is
make the barebones category datum and the define.
I've kept existing procs such as log_game, and simply turned them into a
wrapper for Logger.Log(xxx, ...)
## Why It's Good For The Game
Makes processing and filtering logs much easier in the future, while
only minimally downgrading log crawling experience.
I am also working on a log viewer frontend for admin usage however that
will take a little bit longer to finish up.
Also makes special logging and data tracking much easier thanks to a
data list processing implementation and handling
## Changelog
🆑
server: All logs are now formatted in json, excluding perf and
investigations
/🆑
---------
Signed-off-by: GitHub <noreply@github.com>
Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
https://user-images.githubusercontent.com/35135081/235344815-8e825ba9-52cf-44e8-b8e2-a2aeb5d47276.mp4
- Downloads a portable MariaDB (doesn't pollute your main system)
- Sets up a database with a random password on port 1338 (configurable)
- Installs the initial schema
- Every time after, will run updates
Major versions right now explicitly escape hatch, because those
historically come with something like a Python script, and I do not want
it to pretend to work.
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
All basic mobs became slower because of #75186. This fixes that.
## Why It's Good For The Game
Intended speed.
## Changelog
🆑
fix: Fixes the speed of all basic mobs.
/🆑
## About The Pull Request
Adds default multiplicative movespeed for basic mobs, so their speed is
configurable via config.
## Why It's Good For The Game
Closing things which were probably missed in the development of basic
mobs
## Changelog
🆑
code: Adds default multiplicative movespeed for basic mobs, to make them
editable in config
config: Default multiplicative movespeed for basic mobs in example
config
/🆑
## About The Pull Request
Hey there,
This was spoken about in #70492 (specifically
https://github.com/tgstation/tgstation/pull/70492#issuecomment-1278069607),
and I have been waiting for this to be implemented for some time. It
never got implemented, so I decided to code it myself.
Basically, **if the server host doesn't disable it**, you are free to
export your JSONs as a player, right from the stat-panel. It's a pretty
JSON on 515 versions, too!
It's right here:
Here's what the prettified JSON looks like on 515.
There's a cooldown (default to 10 seconds) between exporting your
preferences.
#### Why is this config?
It's because in the past, a server host could always just file-share the
.sav or .json or whatever to the player, but they would have to do the
explicit option of actually bothering to make the files accessible to
the player. In that same line of logic, the server operator will have to
explicitly make the files accessible. This is mostly because I'm not
sure how good `ftp()` is at being a player function and wanted to have
some sort of cap/control somehow in case an exploit vector is detected
or it's just plain spammed by bots, so we'll just leave it up to the
direct providers of this data to elect if they wish to provide the data
or not.
## Why It's Good For The Game
Players don't have to log into Server A to remember what hairstyle they
loved using when they want to swap to Server B! That's amazing actually.
I always forget what ponytail my character has, and it'll be nice to
have the hairstyle in a readily accessible place (after I prettify the
JSON for myself).
It's also more convenient for server hosts to make player data like this
accessible if they really want to, too.
If we ever add an _import_ feature in the future (which would have to be
done with a LOT of care), this will also be useful. I wouldn't advise it
though having taken a precursory look at how much goes into it while
trying to ascertain the scope of this PR.
## Changelog
🆑
qol: The game now supports export of your preferences into a JSON file!
The verb (export-preferences) should now be available in the OOC tab of
your stat-panel if enabled by server operators.
server: Exporting player preferences is controlled by a configuration
option, 'FORBID_PREFERENCES_EXPORT'. If you do not wish to let clients
access the ftp() function to their own preferences file (probably for
bandwidth reasons?) you should uncomment this or add it to your config
somehow.
config: Server operators are also able to set the cooldown between
requests to download the JSON Preferences file via the
'SECONDS_COOLDOWN_FOR_PREFERENCES_EXPORT' config option.
/🆑
## About The Pull Request
I was helping someone debug some weird bug with spritesheets a bit ago,
and I didn't like having to manually comment out all of the `fdel()`
stuff in order to help visualize what the potential issue might have
been with the spritesheets on either their DM-side generation or their
TGUI-level display. I decided to add a compile-time level flag that will
automatically copy over any generated spritesheet assets (css and pngs)
to the round-specific `data/logs` folder for analysis when a developer
should need it.
I also had to switch around some vars and make a few new ones to reduce
how copy-pasta it might get and ensure standardization/readability while
also being 0.001 times faster since we benefit from the string cache
(unprovable fact).
## Why It's Good For The Game
It's incredibly useful to see the actual flattened spritesheet itself
sometimes when you're doing this type of work and you keep getting odd
bugs here and there. Also saves headache from having to clear out the
temp `/data/spritesheets` folder every time you comment shit out, as
well as having an effective paper trail for A/B testing whatever
bullshit you've got going on.
## Changelog
Doesn't affect players.
dbcore was very fuckulated.
It had 3 lists of queries, but they all had their own current_run style
list to support mc_tick_check (as it was already being done before with
the undeleted query check, so i can understand why they ~~cargo culted~~
mirrored the behavior) This was silly and confusing and unneeded given
two of those loops can only process at most 25 items at a time on
default config, plus these were cheap operations (ask rustg to start
thread, ask rustg to check on thread).
Because of the confusingness of the 6 lists for 3 query states, The code
to run pending/queued queries immediately during world shutdown was
instead looking at the current_run list for active queries, **meaning
those queries got ran twice.**
The queued query system only checked the current active query count in
fire(), meaning even when there was nothing going on in this subsystem
new queries had to wait for the next fire() to run (10 ticks, so 500ms
on default config)
Those have all been fixed.
the config `BSQL_THREAD_LIMIT` has been renamed to
`POOLING_MAX_SQL_CONNECTIONS` and its default was lowered to match
MAX_CONCURRENT_QUERIES .
added a new config `POOLING_MIN_SQL_CONNECTIONS`, allowing you to
pre-allocate a reserve of sql threads.
The queue processing part of SSdbcore's fire() has been made to not obey
mc_tick_check for clarity and to make the following change easier to do:
If there is less than `MAX_CONCURRENT_QUERIES` in the active queue, new
queries activate immediately.
(its ok that there are two configs that kinda do the same thing,
POOLING_MAX_SQL_CONNECTIONS maps to max-threads in the mysql crate, and
it seems to only be a suggestion, meanwhile MAX_CONCURRENT_QUERIES can't
do anything during init, which is when the highest amount of concurrent
queries tend to happen.)
🆑
config: database configs have been updated for better control over the
connection pool
server: BSQL_THREAD_LIMIT has been renamed to
POOLING_MAX_SQL_CONNECTIONS, old configs will whine but still work.
fix: fixed rare race condition that could lead to a sql query being ran
twice during world shutdown.
/🆑
I have not tested this pr.
## About The Pull Request
We have a config flag to set random shift start times or server sync'd
start times, but not one to simply set the shift start time.
## Why It's Good For The Game
Control over the shift start time. This way events such as breakfast can
occur during actual breakfast hours.
## Changelog
🆑 LT3
config: Station shift start time can now be set in the server config
/🆑
---------
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
## About The Pull Request
It was config'd off to save init time, but having it function in testing
and mapping is more valuble then the time spend on it.
On that topic, we spend roughly 1.7 seconds of init on this.
~1.3 is spent handling the light sources and their light object
modifications (this is potentailly inflated since other sources could
cause the same objects to need updates)
~0.3 is spent searching for space turfs around lighting_objects during
init.
This will impact change_turf slightly too, costing about ~0.07 in local
testing.
It does save time for live however, since we avoid these config checks.
## Why It's Good For The Game
I believe this time is worth spending.
I've had people try to "fix" artifacts of starlight not being enabled,
things that aren't bugs.
The test environment should as much as we can make it reflect the visual
reality of the game. This helps ensure that
## Changelog
🆑
server: The starlight config has been removed, as it is enabled by
default
/🆑
This adds a config to secure discord chat commands used by admins.
When enabled it compares the discord id the chat command came from with
the linked discords db to find their ckey, then checks they have the
correct admin rights.
The check automatically self disables if the db is down or if legacy
admin ranks are enabled. (There is no config for discord account linking
or i'd just use that.)
Moved non-admin discord commands out of the admin modules folder and
into the discord modules folder.
Deleted some defunct shit. There was a global list and admin only notify
command that was used by nothing.
There was a whole discord config section that was used by nothing.
## About The Pull Request
MSO was being tsundere about this and it seemed useful, so here we go
## Changelog
🆑
config: Added a warning build config setting, you can now lightly
repremand but not block clients with older builds but fine major
versions
/🆑
## About The Pull Request
config validation didn't actually throw on invalid configs, thus CI
never caught breaking changes
## Why It's Good For The Game
config should work
## About The Pull Request
This basically does what we do for roundstart announcements, but for
round end.
With a delay between a round ending, the server rebooting, and a new
round starting, sometimes it feels like players would be more likely to
catch a roundstart when they know the previous game has just ended, and
not a few moments before the next one starts.
## Why It's Good For The Game
This idea was suggested to me several times by many people who don't
have good connections to servers and keep missing roundstart because
they just aren't given enough time to get on SS13.
I also included Round ID in this, so people who know what time they've
played a round can also now easily see which round it was, if they
wanted to go back to look at the logs for any reason they have.
## Changelog
🆑
config: There's now a config-optional announcer for a round ending.
/🆑
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
Initialization is significantly slowed down by the presence of clients,
though when testing features, you need to join the server. I've been
told that some devs (particularly Mothblocks) are alt-tabbed out of
Dream Daemon while doing dev work, meaning that they are liable to miss
initializations completing, causing an effective slowdown in the dev
cycle. Mothblocks said it would be nice if there was a way to produce a
desktop notification when initialization completes.
I originally intended to add a function to rust_g that would produce a
Windows toast notification with a button allowing you to immediately
launch Dream Seeker. However, I couldn't find a reliable way to detect
if the OS version was Windows 7 or earlier, so running this function on
such an OS would cause a rust panic (which I was told is only a problem
because MSO probably still uses Windows 7).
Fortunately, PowerShell scripts can access the necessary .NET APIs to
produce toast notifications on Windows 10, while also failing more
gracefully than crashing the host process. So I recreated the
functionality I intended in PowerShell.
Toast notifications will only be sent on Windows, if the
TOAST_NOTIFICATION_ON_INIT config flag is enabled, AND there are no
clients on the server.
**Note for downstreams:** If you want the toast notification to have
your downstream's icon, copy it, scale the copy down to 16x16, and
either rename it "tg_16.png" or change that path in the call to
`world.shelleo` to the name of the new file.
Video Demo:
https://user-images.githubusercontent.com/12720844/210492033-963923d7-a1de-4326-9c9f-4f0c0b71d1a5.mp4
## Why It's Good For The Game
This isn't really a line item in the Dev Cycles Initiative, but even if
Mothblocks was exaggerating the benefits, it would still be a
significant speedup in the dev cycles.
## Changelog
No player-facing changes.
# Requires https://github.com/tgstation/tgstation/pull/72320
## About The Pull Request
https://user-images.githubusercontent.com/35135081/209700892-e54be6cf-d18c-4d12-acd1-e5eb46e9d82d.mp4https://user-images.githubusercontent.com/35135081/209700911-751b8a0e-d770-49fa-a6eb-ce50aa0fa670.mp4
---
Adds a system for tutorials that:
- Are contextually given
- Are not given again after completion
- Can optionally not trigger for anyone who first played before a
certain date
Uses this system for a tutorial for switching hands/dropping items. This
tutorial is triggered when you try to click on an item with another
item, and `afterattack` return FALSE. In order for this to work as
smoothly as possible, I'm going to open a separate PR that cleans up the
`afterattack` on everything to either return TRUE/FALSE.
## Why It's Good For The Game
SS13 is an extremely confusing game, being able to do tutorials in a
non-intrusive way (like a separate tutorial mode) is nice.
The system in place is going to be perfectly usable for introducing
mechanics to both fresh players and experienced players alike (such as
for future content).
## Changelog
🆑
qol: New players will now get a contextual tutorial for how to switch
hands and drop items.
/🆑
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
## About The Pull Request
This is an expanding of
https://github.com/tgstation/tgstation/pull/69708
Adds a config to not connect machines to a techweb at the start of a
round
Adds the ability to multitool a server to get its techweb in its buffer,
which can then be used on machines to sync them.
Adds support for some machines to not cry when they don't have a techweb
linked to it, in case they actually don't.
If the config to not have machines connected to the science server is
enabled, research servers will make their own techwebs instead. This is
barebones though and would need more work if this option is used.
For misc stuff:
- I replaced checking ``GLOB.machines`` for research servers, to instead
check ``SSresearch.servers``, where we can use ``as anything``.
- Removed unused vars on the RD server control
- I renamed the operating computer's .dm file to remove the capitalized
letter from it. It's now operating_computer instead of Operations.
## Why It's Good For The Game
This is adding support for 2 different cases that can be used in the
future:
1. Off-station roles, we can make roles like Oldstation have their own
techweb so they don't ruin science's efforts, or use their advanced
research to get things we don't want, or even possibly have some
blacklist webs for ghost roles (like teleporters) so that way we don't
need to have this dance where we have to give them a very specific
amount of materials for them to do things while not being able to get a
teleporter and leaving. I heard discussions that people wanted this a
while back, and one of the main things preventing this from happening is
the lack of support. Hopefully this is encouragement to make it a
reality, because I think it would be a really cool expansion of ghost
roles and a good way to prevent them from messing with the round in
progress.
2. Downstreams who want to do different things with Science. Personally
I made this PR with voidcrew(shiptest) in mind and think this would make
their lives easier. I didn't expand too much on this because I'm leaving
up mostly to the downstreams to figure out what they want to do with
these systems.
## Changelog
This generally isn't really player facing, since most of the changes
would only come into effect if the config is enabled??
🆑
fix: Research servers now only show servers connected to their techweb.
/🆑
fix: Fixed a runtime preventing nonhuman cadavers from spawning properly.
config: Cadaver spawners will no longer yell at you when morgue_cadaver_other_species_probability is blank.
config: morgue_cadaver_disable_nonhumans will now properly disable nonhuman races! (It was reversed, woops.)
* Rocking The Boat, er, Map Vote
Hey there,
A while ago, I spooke (typo intentional) to some other people. One frustration I heard was the fact that people would sometimes sneak through map votes during the very start of a shift, during a high-paced portion, or just as a meme. People in OOC would then flood the vote, putting in any given station. However, if a vote happens 10 minutes in- and the round goes for 70 minutes and not many of the original players are around, then it's not particularly fair to those who have to play next shift on a map they bemoan.
So, we can rock the vote! If a player isn't particularly chuffed with the hand they are given, they can poll the players to see if they want to change the map as well. If rocking the vote goes through, huzzah, you get the ability to vote for the map again. If it doesn't go through: tough luck. You can rock the vote one time per shift by default, and server operators can change the amount of times you can call to rock the map vote at their discretion. Calling to rock the vote either successfully or non-successfully counts as a "call", and when that limit is exceeded: no more calls.
Does this mean that we will only rotate between two maps because pissants will keep rocking the vote until they get what they like? Maybe? I still see people bemoan getting Tram or shit the bed over IceBox, but I think enough people get sick of bread-on-butter to take the server where it need to go. If operators don't really like seeing only two maps play, they can always adjust the config to ensure it doesn't happen.
* makes the grammar grammar
it would be "Rock the Vote vote" otherwise
lternative to #68527
About The Pull Request
Hey there,
This is an alternative PR that I concocted based on talking with Goof on that PR. Basically, we already have a nicely complicated system to track and balance the number of security officers we have in a shift based on some config coefficient setting, by which we can set the amount of lockers that spawn in on the start of a round, as well as determine truly how many security officers we have.
image
So, I've decided to leverage this in another way. Basically, based on the number of security officers in a shift, their specific departmental officers will also get more (elevated) accesses. They already start with a certain amount of access, but they can get more if it is a low-pop shift with the mechanic introduced in this PR. For example, an Engineering Security Officer can access Atmospherics and Engineering departments by default, but they can't access Telecommunications unless there is a lower population of players AT SHIFT START. Same for a Medical Security Officer accessing Medbay, but not Plumbing.
Update: I have made it such that there are three system that server operators can set:
They can use the Scaling System that operates in the same method outlined in the rest of the PR.
They can disable giving departmental security officers "elevated access" (such as access beyond the "front doors") to these officers.
Finally, they can also just always ensure that departmental security officers get the maximal accesses possible.
The default setting is the "Scaling System" outlined in this PR, which is already dependent on the general Security Officer Scaling Co-Efficient.
Why It's Good For The Game
I think it's better to involve some more nuanced config scaling that we already have present in the game. The major theme that we want to avoid is that departmental security officers having maximal accesses when there is an already large number of persons on the security force will result in "miserable" shifts for the common person working within a department (security metaprotections). However, some server operators (as well as server cultures) tend to have very wide ranges in how many security officers they have on a shift-by-shift basis. One day, you could have 0-2 security officers, the next, you could have 4-6. It's all variable on who's playing (as always). There is also a significant variation between server to server in regards to how many security officer slots you tend to have on spawn, but this is already manageable by the security officer co-efficient in config.
I believe this PR is an acceptable proposal within the bounds of #68527 (comment) , although it may bend certain aspects of it, I definitely do see where some people may be coming from. I believe I've adjusted the accesses to a "sane"/justifiable amount, but I'll come back to think on everything.
"Red-tiding" may or may not be a problem, but there's always just going to be something inherently silly with a security officer being able to walk into plumbing to start plumbing. I hoped that this would be seen as a positive as opposed to a negative, but I can see how it could negatively impact player experience. HOWEVER, interplayer experience should not be handled by the codebase in all aspects, which is why I've also passed in the associated config variables, so that server operators (who should handle the interplayer experience with their level of discretion and nuance) can.
What accesses are where?
The general philosophy as I thought through designing this would be that the security officer should at the very least have general "front-door" access into a department, and maybe something benign. If we had even more per-door accesses, this could definitely be a bit more granular (one example I can think of would only atmospherics technicians having access to the "Pump Room", while Security Officers would not. However, this is for a later date). So, you have the "default" access you always get, and a potential to get "elevated" access as a Departmental Security Officer.
The balances are as such:
The Cargo Security Officer will have access to the Cargo Bay, Mining Section, and the Shipping Room. The first two are rather general areas, with the Shipping Room being a rather good help for rescuing (or "rescuing") flushed crewmembers when the cargo techies can't get to it/no AI. The Auxiliary Base is not essential to the security officer's functions, and the mining station helps restrict access further on stations like IceBox. This would also grant them extra access to the Lavaland base, so let's snip that out.
The Engineering Security Officer should have access to only general Engineering and Atmospherics. Construction pertains to certain rooms in maintenance I believe, and Engine-Equipment should be the one that grants access to APCs (lol). I don't think a security officer should have the latter one to be honest, but I think we'll be stretching the scope of this PR. Telecommunications is a bit weird, it's a critical station function, but I think you also shouldn't be able to nick one goon's ID and have access, so let's give it to them only when it's "needed".
The Medical Security Officer should have access to only the general Medbay Area and the Morgue, in case someone starts trotting on the doctor's turf, or if there's someone doing unsavory things to the bodies while the doctors are away. They will not have access to the specialized (dangerous) areas unless the ratio of secoffs to the population is low enough should it necessitate it (Plumbing Room, Pharmacy, Virology). I also added Surgery to the scaling access, but I'm iffy on that one. I don't particularly see why they should have it as a base access, but I also do see there being some need in dire straits (in relation to helping people, not tiding).
The Science Security Officer definitely got a huge cut. They now only have general access to R&D and normal scientist areas like the lathe room, circuits lab (presumably)since these are generally trafficked areas, but I definitely clamped down on additional access they might get in a "normally balanced" situation (no ordnance+storage, no xenobio, no genetics, no to robotics, etc.) They don't have a particular use in these areas and can even be a bit obstructive to flow in normal circumstances, but if abnormal circumstances arise and there's not a lot of security hands-on-deck, then their access is expanded.
Honestly, balancing this both makes sense and is conversely rather odd. I'm just running off what we already hold to be true and expected (or at least as of the last two months), and we can go from there.
Changelog
cl
balance: Nanotrasen realized that the more access they had on their cards was costing them a pretty penny, so they trimmed back the number of accesses a certain departmental Security Guard might have. However, any given guard will get back a greater amount of accesses depending on how many security guards there are in relation to the population.
config: Hey server operators, listen! We've changed up how Departmental Security Officers get their accesses, so be sure to review the DEPSEC_ACCESS_LEVEL config number to see what you want to work best for your server.
/cl
Also, every single line of code found in 4533f07 that is now presently in this PR is deliberate
* destroy proc holder pt1
- change proc_holder/spell to action/cooldown/spell
- docs all the spell vars, renames some of them
- removes some useless vars
- start with pointed spells, as they're easy
* kill proc_holder pt2
- kill a buncha vars and replace it with flags
- convert a ton over
- general code improvements
* kill proc_holders pt3
- convert a good few more spells
- rename some signals
- handle statpanel
- better docs
* kiill proc_holder pt4:
- restructure the file system of action.dm, separating a good amount of item actions and miscellaneous garbage into files where they belong slightly better. Also splits off item actions, cooldown actions, innate actions, etc. into their own files, overlal making it much better to work with
- converts touch attacks to actions
- converts blood crawl, jaunt subtype
* kills proc_holder pt5
- clears up some icon issues so all the currently converted pages don't have errors
- shapeshift
- some more action cleanup
* kills proc_holder pt5.5:
- some documentation
- reworks feedback to prevent oversight with teleports and stuff
* kills proc_holder pt6:
- converted cult spells
- converted magic missile
- converted mime spells
- chipped away at the errors
- removed some vars which were too general, replaced them with more locally applicable vars. for example "range" which could mean "projectile range" or "aoe radius" or whatever - instead of having a broad net which everyone applies to in a confusing matter, instead lets each spell delegate on their own.
- merged magic/spell and magic/aoe, as the comment intended
- more unified behavior for spell levelling
* kill proc_holders pt 6.5:
- replacing a buncha old proc_holders that have been updated to reduce some errors. sub 900 baby
* kills proc_holder pt 6.75:
- minor fixes
* kills proc_holder pt7:
- cuts down on some errors
- refactors some wiz events
* kills proc_holder pt 7.5:
- malf ranged modules
- some minor errors
* kills proc_holder pt 7.75:
- mor eminor error handling, cleaning up changes
* kill proc_holder pt8:
- refactors spell book
- refactors spell implant
- some more minor error fixing
* kill proc_holder pt 8.5:
- scan ability
* Adds some robust documentation
* kill proc_holder pt9:
- converts some / most mutations over
* kill proc_holder pt10:
- sort out all the granters
- refactor them slightly
- fix some compile errors
* Some set-unset sanity - going to need to test removing Share()
* Removes transfer actions. It doesn't seem to do anything.
- Transfer_actions was called when current = new_character so locially speaking the early return in Grant() should cause it to NOOP. Test this in the future though
* Removes sharing from actions, docs actions better
* Some better documentation for spell and spell components
* Kills proc_holder pt11:
- Finally finishes ALL THE SPELLS IN THE SPELL FOLDER
- Fixes some more errors
* kills proc_holder pt11.5:
- minor error fixing and sanity
* Method of sharing actions. Can be improved in the future, needs testing
* Implements a way to update the stat panel entry for a spell. Also gets rid of VV stuff, as you can update the bigflags directly in VV now.
* Curse of madness bug I put in.
* kills proc_holder pt12:
- sub 500 errors!
- converts cytology mobs
- converts and refactors spiders slightly
- some minor fixing around the place as usual
* kill proc_holder pt13
- Finishes heretic spells
- Sub 300 errors!
- some touch refactoring to account for mansus grasp
* kills proc_holder pt14:
- revenant
- minor bugfixing for heretic stuff
* kills proc_holder pt14.5:
- some missed stuff for revenant + heretic
* kills proc_holder pt15:
- alien abilities
- more minor fixing
- sub 100 errors. The end is nigh
* kill proc_holder pt16? 17:
- Finishes cult spells
- sub 50 errors!
- refactors the way charge works
- renames / moves some signals
* kills proc_holder pt final:
- sdql spells
- no more errors!
* Bugfixes round 1
* Various bugfixing
- documentation done
- give spell works
- can cast spell gives feedback conditionally
- is available takes into account casting ability
* Some accidental reversions + fixes
* Unit tests
* Completely refactors jaunting
- All bloodcrawling is now handled on the action itself instead of across various living procs
- slaughter demons have their own blood crawls
- jaunting dummies don't have side effects on destroy() anymore
* Wizard spell logging and even more refactoring
* Makes Playing Lobby Music A Config
Hey there,
Apparently some people don't like listening to the soulful lobby music we have to offer. How unfortunate. This adds a config flag to disable said title screen music. I've heard people who like debugging a lot don't want to get their ears-bleeding via flipflap, but I find it hard to agree.
* ALLOW to DISALLOW
whoops
* FUCK
* MSO's suggestions
I also added a small portion in regards to player preferences in case people weren't aware of that.
* lol
physics burned my brain out on parentheses
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* The Quartermaster is officially a head of staff, with new accesses, a silver ID, ect ect.
* The HoP lost their cargo-related equipment and access, including the Vault monitor, and frequency.
Right now there is only 1 source of cloning: pod cloning-- and pod cloning is exceedingly rare. I don't think this warrants its own file anymore with the death of regular cloning a few years back.
I don't know when we removed sandbox but this datum doesn't exist anymore and this var is unused
Also the config does nothing anymore so might as well throw that out
* Adds MC initialization stages. Earlier stages can fire while later ones init.
Removes TICK_LIMIT_MC_INIT config for barely doing anything to speed up init and being inconvenient to work with if fires and inits can happen at the same time.
Adds new configs for non-urgent ahelps to be sent to a channel when no admins are on. This will include urgent ahelps too.
Adds a response message that is sent to discord when an ahelp is responded to in any way
Player counts are now sent in the embed.
