## About The Pull Request
This PR started with the idea of adding support for map feedback
threads, which I added to the roundend report, escape menu, and stat
panel. To do this though I had to make pretty annoying changes to the
stat panel and had to touch every single time something to the stat
panel was added, so since we now have a way to have links in the stat
panel I thought of taking full advantage of it and add some QOL.
AIs can now track their borgs by clicking their status on the stat panel
https://github.com/user-attachments/assets/1789dc46-5d12-48e9-bb8d-d3278aa19639
With Melbert's comment, I added another stat panel entry that directs
you to the Webmap page, which currently seems to be a little messed up
(https://github.com/AffectedArc07/SS13WebMap/issues/41 &
https://github.com/AffectedArc07/SS13WebMap/issues/42) but if they get
fixed this would be a swag asf feature
##### Code bounty for Ezel/Improvedname
## Why It's Good For The Game
Feedback threads was a suggestion from a player and is fully in control
of admins as an optional thing, and while we still have stat panel I
think it's nice to be able to take advantage of its features.
## Changelog
🆑
admin: Admins can now link a URL for maps, used to give feedback on said
maps. Accessible through the roundend report, escape menu, and stat
panel.
qol: AIs can track their borgs by clicking on them in the stat panel.
qol: You can now directly go to the webmap of maps from the stat panel
(assuming it's set in config).
/🆑
## About The Pull Request
As said in https://forums.tgstation13.org/viewtopic.php?t=38517 - Admins
don't want to touch the event multiplier configs because,
``for example changing the mult to 1.5 would make heart attack only roll
on 60+ pop``
and ends with;
``it would be better to make a pull request to the codebase and alter
the min_player var on the events that are issues``
So why not let ALL events be editable by admins?
This PR makes every single event possible to be edited, though the json
only comes with the non-wizard non-holiday ones (though they are totally
addable if admins want to put it in, I just didnt think we should make
it obvious it's possible so they DONT)
The config is off by default (no effect regardless since I have it the
same as code-side).
## Why It's Good For The Game
The multiplier config is rendered irrelevant by instead being able to
tweak the individual events to your liking, especially when one touch of
that causes certain events to be rendered never runnable.
This is (sorta) an admin request, and it also makes event rarities and
such an admin issue, therefore not our problem anymore (mostly), wahoo.
Get FUCKED, Grid Check!
## Changelog
🆑
config: Removed event time/weight multipliers, now all events vars are
editable in config.
/🆑
---------
Co-authored-by: CRITAWAKETS <sebastienracicot@hotmail.com>
## About The Pull Request
Dream Seeker will not send topic calls greater than 2kb in size. There
are cases where tgui will attempt to send `ui_act` payloads larger than
this, such as writing on paper. This PR takes payloads that would be
larger than 2kb, splits them into payloads that would be roughly 1kb
(after URL encoding), and sends them to the server in sequence. To
prevent abuse and/or topic spam, a config option has been added to put a
limit on the number of chunks for which the server will accept a
payload, defaulting to 10.
## Why It's Good For The Game
Fixes#90056, along with several other things that were affected by the
change to WebView2 in 516.
## Changelog
🆑
code: Any tgui message that would be too big to send to the server is
now split into chunks and sent in sequence. This fixes several issues,
such as...
fix: It is once again possible to save large amounts of text on paper at
once.
/🆑
---------
Co-authored-by: Lucy <lucy@absolucy.moe>
🆑
config: Added `TTS_HTTP_TIMEOUT_SECONDS` for setting the maximum
duration TTS HTTP requests can run for before being aborted.
/🆑
DNM because we need the rust-g PR to get released:
https://github.com/tgstation/rust-g/pull/210
Crit prio because rounds will not restart if there are hung TTS requests
and the TTS server is absolute dogshit and doesn't prevent them.
<!-- 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
When you import a config file inside a subdirectory, the config loader
will now look IN that subdirectory, instead of exiting out to the parent
folder.
As a consequence, adds support for ".." to our deduplication system to
avoid infinite loops due to headmin brain.
## Why It's Good For The Game
jannies are on some shit wanna make their lives a bit nicer
Note: I am testing on windows and also have only a loose grasp of how
linux works, might fuck up in that environment idk
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and its effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
config: the config loader now supports relatively pathed imports
(importing a file inside a subfolder now acts as if you were IN that
subfolder)
/🆑
<!-- 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
Replaces the asset subsystem's spritesheet generator with a rust-based
implementation (https://github.com/tgstation/rust-g/pull/160).
This is a rough port of
https://github.com/BeeStation/BeeStation-Hornet/pull/10404, but it
includes fixes for some cases I didn't catch that apply on TG.
(FWIW we've been using this system on prod for over a year and
encountered no major issues.)
### TG MAINTAINER NOTE
### Batched Spritesheets
`/datum/asset/spritesheet_batched`: A version of the spritesheet system
that collects a list of `/datum/universal_icon`s and sends them off to
rustg asynchronously, and the generation also runs on another thread, so
the game doesn't block during realize_spritesheet. The rust generation
is about 10x faster when it comes to actual icon generation, but the
biggest perk of the batched spritesheets is the caching system.
This PR notably does not convert a few things to the new spritesheet
generator.
- Species and antagonist icons in the preferences view because they use
getFlatIcon ~~which can't be converted to universal icons~~.
- Yes, this is still a *massive* cost to init, unfortunately. On Bee, I
actually enabled the 'legacy' cache on prod and development, which you
can see in my PR. That's why I added the 'clear cache' verb and the
`unregister()` procs, because it can force a regeneration at runtime. I
decided not to port this, since I think it would be detrimental to the
large amount of contributors here.
- It is *technically* possible to port parts of this to the uni_icon
system by making a uni_icon version of getFlatIcon. However, some
overlays use runtime-generated icons which are ~~completely unparseable
to IconForge, since they're stored in the RSC and don't exist as files
anywhere~~. This is most noticeable with things like hair (which blend
additively with the hair mask on the server, thus making them invisible
to `get_flat_uni_icon`). It also doesn't help that species and antag
icons will still need to generate a bunch of dummies and delete them to
even verify cache validity.
- It is actually possible to write the RSC icons to the filesystem
(using fcopy) and reference them in IconForge. However, I'm going to
wait on doing this until I port my GAGS implementation because it
requires GAGS to exist on the filesystem as well.
#### Caching
IconForge generates a cache based on the set of icons used, all
transform operations applied, and the source DMIs of each icon used
within the spritesheet. It can compare the hashes and invalidate the
cache automatically if any of these change. This means we can enable
caching on development, and have absolutely no downsides, because if
anything changes, the cache invalidates itself.
The caching has a mean cost of ~5ms and saves a lot of time compared to
generating the spritesheet, even with rust's faster generation. The main
downside is that the cache still requires building the list of icons and
their transforms, then json encoding it to send to rustg.
Here's an abbreviated example of a cache JSON. All of these need to
match for the cache to be valid. `input_hash` contains the transform
definitions for all the sprites in the spritesheet, so if the input to
iconforge changes, that hash catches it. The `sizes` and `sprites` are
loaded into DM.
```json
{
"input_hash": "99f1bc67d590e000",
"dmi_hashes": {
"icons/ui/achievements/achievements.dmi": "771200c75da11c62"
},
"sizes": [
"76x76"
],
"sprites": {
"achievement-rustascend": {
"size_id": "76x76",
"position": 1
}
},
"rustg_version": "3.6.0",
"dm_version": 1
}
```
### Universal Icons
Universal icons are just a collection of DMI, Icon State, and any icon
transformation procs you apply (blends, crops, scales). They can be
convered to DM icons via `to_icon()`. I've included an implementation of
GAGS that produces universal icons, allowing GAGS items to be converted
into them. IconForge can read universal icons and add them to
spritesheets. It's basically just a wrapper that reimplements BYOND icon
procs.
### Other Stuff
Converts some uses of md5asfile within legacy spritesheets to use
rustg_hash_file instead, improving the performance of their generation.
Fixes lizard body markings not showing in previews, and re-adds eyes to
the ethereal color preview. This is a side effect of IconForge having
*much* better error handling than DM icon procs. Invalid stuff that gets
passed around will error instead of silently doing nothing.
Changes the CSS used in legacy spritesheet generation to split
`background: url(...) no-repeat` into separate props. This is necessary
for WebView2, as IE treats these properties differently - adding
`background-color` to an icon object (as seen in the R&D console) won't
work if you don't split these out.
Deletes unused spritesheets and their associated icons (condiments
spritesheet, old PDA spritesheet)
## Why It's Good For The Game
If you press "Character Setup", the 10-13sec of lag is now approximately
0.5-2 seconds.
Tracy profile showing the time spent on get_asset_datum. I pressed the
preferences button during init on both branches. Do note that this was
ran with a smart cache HIT, so no generation occurred.
Much lower worst-case for /datum/asset/New (which includes
`create_spritesheets()` and `register()`)
Here's a look at the internal costs from rustg - as you can see
`generate_spritesheet()` is very fast:
### Comparison for a single spritesheet - chat spritesheet:
**Before**
**After**
## Changelog
🆑
fix: Fixed lizard body markings and ethereal feature previews in the
preference menu missing some overlays.
refactor: Optimized spritesheet asset generation greatly using rustg
IconForge, greatly reducing post-initialization lag as well as reducing
init times and saving server computation.
config: Added 'smart' asset caching, for batched rustg IconForge
spritesheets. It is persistent and suitable for use on local, with
automatic invalidation.
add: Added admin verbs - Debug -> Clear Smart/Legacy Asset Cache for
spritesheets.
fix: Fixed R&D console icons breaking on WebView2/516
/🆑
## About The Pull Request
This incredibly detailed PR adds the ability to construct custom
shuttles, which function similarly to whiteships.
To construct a custom shuttle, you need the following items:
- Shuttle frame rods
These rods can be hand-crafted by using 5 rods on 1 sheet of titanium,
or printed at a sci/engi/cargo lathe after researching the Shuttle
Engineering techweb node.
Lattices built with these rods, and catwalks/floors built on top of
these lattices, are valid for shuttle construction.
- Shuttle engines
Did you know shuttle engines have boards that weren't normally
obtainable? Well the board for one specific engine type is now available
from the sci/engi/cargo lathe after researching Shuttle Engineering. Of
course, the old options remain. You can steal engines from other
shuttles, including escape pods (it's not like engines are strictly
necessary for *those* shuttles anyways). Alternatively, the shuttle
engine supply pack is no longer locked behind the purchase of the BYOS.
- Flight Control & Navigation Console boards
These boards are printed at the sci/engi/cargo lathe after researching
the Shuttle Engineering techweb node.
If built on a custom shuttle, it will automatically link to it, unless
the shuttle already has such a console.
If built on a turf that is valid for custom shuttle construction, it
will automatically link to any shuttle constructed from or expanded with
that turf.
- Shuttle blueprints
Standard shuttle blueprints can be printed at the sci/engi/cargo lathe
after researching the Shuttle Engineering techweb node.
A cyborg upgrade granting access to a shuttle blueprint database can be
printed at the exofab after researching the aforementioned node.
Crude shuttle blueprints can be crafted by hand with a sheet of paper
and either a rainbow crayon or 10 uses of a blue crayon or spraycan.
If Science won't research the tech, you can also buy a goody pack
containing a flight control board, a docker board, two engine boards,
and a set of shuttle blueprints for 1200 credits, if you have aux base
access.
A shuttle can be constructed atop any continuous region of turfs
containing a shuttle rod lattice or a catwalk/tile built upon such.
Currently, this region cannot intersect any area other than space,
lavaland, the icemoon, or the station asteroid. Preexisting custom areas
can be included in the construction of the shuttle, but only if every
turf in the custom area is valid for shuttle construction.
In the shuttle blueprint UI, you can toggle a visualizer to display
which turfs fulfill all of the aforementioned conditions.
The following video goes through the basic process of shuttle
construction.
https://github.com/user-attachments/assets/3283422e-a201-4978-972d-67527b5df4ee
The blueprint used to construct the shuttle will be its master
blueprint. The master blueprint can be copied to other blank shuttle
blueprints (or to engiborgs with the shuttle database upgrade), and
allows the holder to perform a christening ritual on the shuttle to
rename it.
If a shuttle's master blueprint ceases to exist, a blank blueprint can
be linked to the shuttle to become the new master blueprint, or an
existing blueprint associated with that shuttle can be promoted to the
master blueprint.
Once constructed, the following options are available from the blueprint
UI to modify it:
- Create Area
Convert a continuous open area of the shuttle into a new area with the
name written in the above text input. This operates very similarly to
regular area construction.
- Rename Area
Change the name of the area you're currently in to the name written in
the above text input.
- Expand Area
Add a continuous open area of the shuttle to the neighboring area
selected from the dropdown to the left. This operates like regular area
expansion.
- Expand Shuttle
Expand a shuttle with valid frame turfs as defined above. These turfs
must be physically connected to the shuttle.
- Remove Area
Remove an area, giving its tiles to the default shuttle area.
- Cleanup Empty Space (implemented after the above video was recorded)
Removes all completely empty turfs from the shuttle. If all the turfs in
one of the shuttle's areas were removed, that area is deleted. If
absolutely no turfs of the shuttle remain, the shuttle itself is
deleted. Due to the ability for this action to delete the shuttle, only
the master blueprint can do it.
As mentioned above, the shuttle's master blueprint can be used to
christen its associated shuttle. To do this, fill a glass drink bottle
with some amount of reagents, then hit it against one of the shuttle's
walls from outside while holding the master blueprint. You will be
prompted to enter a new name for the shuttle. The variety of things that
can happen while inputting a new name can cause the christening rite to
fail in one of several humorous ways.
### Optional (Unless specifically requested by a maintainer) Todo's
- [x] A way for shuttle circuits to be obtainable without techweb nodes
- [x] A more convenient way to carry around shuttle engines or the means
to deploy them
- [ ] A shuttle construction guide available as a reference book
- [ ] Allow boards to be linked to shuttles before construction so they
can be used outside the shuttle
## Why It's Good For The Game
Shuttles have been part of the sandbox for an incredibly long time, but
their limited accessibility has rendered them the exclusive territory of
lucky space explorers or the few antagonists who get one off the bat
(nukies and pirates). Giving players the means to construct shuttles to
their liking opens up a variety of possibilities for gimmicks for antags
and non-antags alike.
Besides the applications for antaggery and crew-sided gimmicks, this
provides side content for several departments to engage with during the
relatively-frequent periods of time where they have little else to do as
part of their intended roles.
With respect to engineering, if the station isn't actively being
damaged, the supermatter is in perfect working order, and nobody is
clamoring for machine upgrades, engineers have little else to resort to
other than construction projects. While the BSA station goal provides an
incentive for engineers to construct dedicated rooms for the cannon, it
will not necessarily be available every round. Custom shuttles not only
provide such a construction project to pursue, but provide the rare
opportunity, as well as a very good reason, to set up an independent
power network, complete with its own power source.
While atmos techs have a lot to do with gas mixing and the crystallizer,
they rarely get the opportunity to set up working life support systems
outside of repairing the ones that get blown up. Custom shuttles will
frequently start with no air, and unless the design settled upon is an
open floor plan, it will have several independent chambers that cannot
so easily be profused with a proper airmix by just opening a canister.
Furthermore, if the air in a custom shuttle gets messed up, a proper
scrubber and distro network is a significantly less tedious method of
rectifying the problem than cleaning the air manually with portable
scrubbers and pumps.
Scientists, it can be argued, with their access to RPDs through
ordnance, have similar opportunities to atmos techs, even though the act
in and of itself is not exactly part of their duties. But compared to
the other job content they could be working with after they've completed
most of their gameplay loop, custom shuttle construction is a
substantially more active endeavor. And I know how much people complain
about late-game science content just being sitting around at a console
and making gamer gear. Roboticists can have a part to play in this too.
They can put their mech RCDs to a use other than 2D topdown Fortnite,
and with the shuttle database upgrade, they can help interested cyborgs
get in on the action.
Cargo is yet another department known for having significant amounts of
downtime during a considerable number of rounds. If every other
department has gone through their initial rounds of departmental orders,
and there isn't an active need for cargo to order lots of one thing or
another, cargo techs have little to do besides mail (at least on the
days where there **is** mail to deliver). Usually, if cargo techs do, in
fact, do something as a department when not presented with more pressing
duties, they order guns and other contraband. As funny as this is,
there's not a lot of variety in how this behavior manifests. With custom
shuttles, cargo can use their free time to plan, and execute, a unique
collective expression of design sensibilities, not limited by the size
and shape constraints of the cargo bay itself.
## Changelog
🆑 Y0SH1_M4S73R (with special thanks to Vect0r, whose original PR
inspired the implementation of these changes)
add: Shuttle blueprints, the tool used to construct and modify custom
shuttles. Print a set at a science, engineering, or cargo techfab after
researching Shuttle Engineering, or craft a crude set from the crafting
menu.
add: Shuttle blueprint database upgrade for engineering cyborgs,
printable from the Exosuit Fabricator after researching Shuttle
Engineering. A version of shuttle blueprints designed for use by
cyborgs.
add: Shuttle frame rods, usable to construct custom shuttles. Hand-craft
by using 5 rods on 1 titanium sheet, or by printing them at a science,
engineering, or cargo techfab after researching Shuttle Engineering.
add: Custom shuttle flight control and navigation boards, printable from
a science, engineering, or cargo techfab after researching Shuttle
Engineering.
add: Shuttle engine boards can be printed from a science, engineering,
or cargo techfab after researching shuttle engineering.
add: The shuttle engine supply pack is no longer locked behind the
purchase of the Build Your Own Shuttle kit.
add: Shuttle Construction Starter Kit goodie pack, containing a set of
shuttle blueprints, flight control and navigation console boards, and
two engine boards, can be purchased from cargo for 1200 credits.
Requires aux base access to purchase.
refactor: Shuttles now keep track of what areas are underneath each of
their individual turfs, so that the areas left behind on movement are
consistent with what they were beforehand.
refactor: Shuttle ceilings now place themselves down as baseturfs,
instead of only appearing if the turf above is open space.
/🆑
---------
Co-authored-by: vect0r <71346830+Vect0r2@users.noreply.github.com>
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
Co-authored-by: necromanceranne <40847847+necromanceranne@users.noreply.github.com>
## About The Pull Request
Closes#89617
Prior to progression traitor some items were only available with a
minimum number of (normally 25) players in the round.
These items were:
- The dual esword
- Noslip shoes
- The ebow
- Holoparasite
- Sleeping Carp
- Contractor Kit
- Maybe a couple of others that I forgot to write down
When we moved to a progression system this concept was merged with
reputation; under 20 players your reputation would advance more slowly
thus making these "dangerous" items less obtainable and also serving as
a sort of scaling factor on rewards (with fewer players the secondary
objectives are easier to complete, so the reward is commesurately
lower).
Now that we have removed secondary objectives this doesn't really make
sense any more, so now reputation simply advances at a rate of one
second per second all the time, but that leaves the old population locks
in question.
So... I just recoded items that are only available when there are enough
players
(This iconography simply vanishes once the pop level is reached).
Note that this is based on "players who have joined" (roundstart +
latejoin), not "players who are online" or "players who are alive".
Once an item becomes available it will never stop being available, but
it only becomes available based on people who are playing and not
watching.
Currently the only items I applied this to (with a value of 20 players)
are:
- Dual esword
- Sleeping Carp
- Spider Extract (the spider antagonist usually requires like 27
players)
- Romerol
It isn't applied to anything else.
## Why It's Good For The Game
Reputation isn't really a tool used to designate how dangerous an item
is any more (if it ever was) and resultingly it doesn't make any sense
to slow its gain based on population.
Some items though we maybe still don't want to show up in a "low pop"
round because they'll create an overall unsatisfying experience, so we
should be able to remove those items from play.
## Changelog
🆑
balance: Traitor reputation now advances at a fixed rate, not dependent
on current server population.
balance: The dual esword, sleeping carp scroll, spider extract, and
romerol vial cannot be purchased if fewer than 20 players have joined
the game.
/🆑
## About The Pull Request
Fixes#89458
Adds a config for auto-deadminning admins who ready up before the round
starts, or click join game after.
The deadminning happens as soon as the button is pressed, not when a job
is selected or the round starts. I figure it's better to do it straight
away since both have opportunities for metainfo to be posted in admin
chat. Before there's admins messing with dynamic config / plotting
events etc. and during the round there's basically everything that gets
posted to admin logs.
I've had to add a typecheck to the auto_deadmin proc, since the lobby
menu technically happens on the centcom Z-level, and there's a pref for
ignoring deadminning on centcom Z, so it checks to see if the admin is a
new player mob.
Changed the old config from auto_deadmin_player to auto_deadmin_always
to make it less deceptive.
Was suggested a pref could be added to do this. I can do that if people
want it maybe, but it's not in this PR at the time of posting it.
Is now a pref
<img src="https://i.ibb.co/211sBMYd/Deadmin-Prefs1.png">
<img src="https://i.ibb.co/r20Srbw4/Deadmin-Prefs2.png">
I dunno if the latejoin proccall is in the right spot in the click
sequence thing I can move it if people want.
## Why It's Good For The Game
Admins spawning themselves on station is very important for both
shenanigans and troubleshooting. It's annoying to have to click readmin
every time and I'm too lazy to figure out how to perms escalate my way
into disabling that config every round (Though I have tried).
This PR is marginally more likely to convince Timber to turn that off
than cussing him out in adminbus.
## Changelog
🆑
admin: Added a new config to force admins to deadmin when readying up or
latejoining the round.
/🆑
previous system was weird, you had to add a comma separated list in the
channel tag in TGS itself. this is much more intuitive. also it should
not break older configs
🆑
config: Added support for multiple chat channel configs for channel
announcements.
/🆑
## About The Pull Request
Pre-discussed with @Watermelon914, this PR removes Secondary & Final
Objectives from all Traitors, rather than just midround ones. It also
removes all of the surrounding supporting code.
Randomly assigned Primary Objectives still exist, I just used the
ability to rewrite mine to take the screenshot.
In terms of final objectives, the surrounding items that were available
still exist but don't necessarily have sources.
If anyone has good ideas for readding these in some other form it can be
done in future PRs.
It also allows all traitors to buy the Contractor kit, previously
limited to midround traitors which lacked secondary objectives, because
now all traitors lack secondary objectives.
This essentially limits all traitors to a maximum of 20 TC (16 if they
spawn with an uplink implant). Currently I don't foresee that they
strictly need any additional way of gaining TC during a round as 20 is
quite sufficient, but it may take some time to adjust and get used to it
after such a long time of having access to more. If we need to adjust
the starting value or add a slow drip of more points over time or
something, that can be done in followup PRs.
This also removes the ability to recreate your uplink added by my
beautiful wife in #74315
This was part of the progression traitor design document, but ultimately
probably a bad idea as it essentially made traitors impossible to
properly disarm. You will once more just need to carefully protect your
uplink.
**This does not remove the threat/progression system**.
Like midround traitors, all Reputation requirements on gear are now
simple timelocks, most of which will have elapsed by the time 30 minutes
have passed.
**Finally** this PR also adds Romerol to the traitor uplink for 25 TC
and 30 minutes of reputation, as a treat (and because I removed the
final objective that previously granted it).
## Why It's Good For The Game
We've tried this system for a long time (3 years last month!) and while
I think it had a lot of promise, enabled some cool moments, and also
solved several of the problems it set out to solve, overall I think some
of the behaviours it has encouraged in players have been overall
negative for the game.
While the _game systems_ are fine, even quite fun and cool (especially
final objectives) I am of the opinion that having them in the game
creates a net negative purely in the way that they react with players'
_brains_, creating incentives towards behaviour we don't actually want
people to pursue.
While it's hard-to-impossible to prove any of this with hard data, there
has been a prevailing feeling for some time among many (though certainly
not all) people that the simple fact of _having_ a constant drip-feed of
objective available to players leads directly to less interesting
antagonist play. While certainly nobody is _forced_ to do secondary
objectives you are directly and quite strongly rewarded for doing so,
doing so efficiently, and doing so in a way which makes sure that nobody
(alive) sees you do it. This leads to a tendency to play defensively and
try to maximise the number of tasks you can complete in one round, which
also has a knock-on effect of generally minimising the number of people
you attempt to interact with in a round (unless you are killing them).
Even people who _intend_ on doing some more interesting gimmick can fall
into this trap, as "having more tools" is always useful for anyone who
is intending on any kind of plan at all, but then executing on the
secondary objectives again incentivises you to lay low, not interact
with anyone, be efficient, and then reduces the time you are spending
doing the thing that's your actual plan for the round. Removing the
ever-present temptation to fish for extra TC leaves "doing whatever your
actual plan is" as the sole thing to optimise.
Final Objectives too have created unfortunate psychological effects
between crewsided players and other antagonists. Because of the _threat_
(no matter how remote, Final Objectives have always been tuned to be
appropriately rare) that leaving any antagonist alone will cause them to
snowball by acquiring more power, it starts to feel foolish to respond
to any threat with less than the maximum possible level of force even if
they seem relatively innocuous in the moment. This even has an effect on
other non-progression antagonists, as traitors are the most common
antagonist type and how people treat them is going to be their default
level of reaction to most other station threats.
While there has always been the promise of expanding the system with
novel and exciting objectives that leverage appearing mid-round to do
something unique, we've taken very little advantage of that over time.
Most objectives we have added that didn't boil down to "kill someone,
with a twist" have been somewhat unsuccessful, serving either as ways to
get yourself arrested and killed for no reason or ways to get free
telecrystals by doing something the crew don't really care about
stopping you from doing. The option still exists to add more roundstart
objectives to traitors, if someone suddenly has a great idea that would
fit in this space.
The ideal outcome of making this change is a slight relaxation of crew
attitude towards feeling like their only option after catching an
antagonist that isn't sandbagging is to permanently remove them from the
round (although it's fine to do this still in many scenarios), and a
broadening of traitorous activity which is not purely focused on
collecting as many checkboxes as possible and might give people more
time to roleplay with other players, not worrying that this time could
have been more efficiently spent pursuing a different secondary goal.
I don't anticipate or desire that this will prevent traitors from
killing anyone (or even stop them from killing people they don't have a
specific objective to kill), I just want to remove the FOMO from
people's minds.
Also this gives us something to talk about at the coder townhall meeting
on the 22nd.
## Changelog
🆑
del: Misplaced or stolen traitor uplinks can no longer be recreated
using a radio code and special device, guard yours carefully or buy a
backup implant.
del: Roundstart traitors can no longer take on additional objectives in
order to earn additional Telecrystals and fast-forward any unlock timers
on items. They also cannot earn the ability to complete a Final
Objective.
balance: Roundstart traitors can now buy the Contractor Kit from their
traitor uplink, rather than only midround traitors.
add: Traitors can buy Romerol for 25 TC, after 30 minutes of time has
passed in a round.
/🆑
## About The Pull Request
Adds an off-by-default config option to optionally disable TTS audio on
whispered speech.
### Ignore the Wallening. It's an old branch and I like to be nostalgic
of what could've been.
https://github.com/user-attachments/assets/f97aad31-9a83-421f-a3f0-0c0e54256664
## Why It's Good For The Game
We're trying to claw back as much performance as possible from our TTS
engine and there's literally no reason to play TTS audio if nobody but
the person speaking into the radio is going to hear it. Requested by the
host. Config is off by default.
## Changelog
🆑
sound: Adds an off-by-default config option to optionally disable TTS
audio on whispered speech.
/🆑
## About The Pull Request
- makes area-based shy-ness for drones config
- reduces the cooldown on touching machines as a shy drone from 1 minute
to 20 seconds
## Why It's Good For The Game
This was admin issues solved by codebase, no one plays drones anymore
and those who do - complain that they're not fun because of the heavy
restrictions imposed upon them.
If I remember correctly - the playtime restriction on our servers is 20
silicon hours? or 10 silicon hours? It's a config thing I can't check.
This means it shouldn't be a problem with ban evaders and such.
Area restrictions are odd because drones can't get more air from atmos
and they can't make power from SM, which is in their laws.
If a drone is messing with your SM then kill it, or ahelp if it keeps
coming back?
For context:
```
"1. You may not involve yourself in the matters of another being, even if such matters conflict with Law Two or Law Three, unless the other being is another Drone.\n"+\
"2. You may not harm any being, regardless of intent or circumstance.\n"+\
"3. Your goals are to actively build, maintain, repair, improve, and provide power to the best of your abilities within the facility that housed your activation."
```
## Changelog
🆑 grungussuss
server: drone area restrictions are now config
balance: drones now take less time to become "un-shy" of something after
it's been touched.
/🆑
## About The Pull Request
This adds plenty of useful stuff regarding byond-tracy, altho mostly
focused on the [Paradise
fork](https://github.com/ParadiseSS13/byond-tracy).
- Adds two new config options **(THEY ARE DISABLED BY DEFAULT)**
- `ALLOW_TRACY_START` gives admins with +DEBUG the "Run Tracy Now" verb,
which will allow them to start profiling with byond-tracy mid-round.
- `ALLOW_TRACY_QUEUE` gives admins with +DEBUG the "Toggle Tracy Next
Round" verb, which will initialize byond-tracy during world init the
next round (in the same way as passing `-params tracy` or defining
`USE_BYOND_TRACY`)
- If byond-tracy fails to initialize, the error will be logged and
available to view for the whole round.
- If `MC_TAB_TRACY_INFO` is defined, information about byond-tracy now
appears in the MC tab - if it's running or not, if it errored (and what
the error is), why it's running, if its queued for next round, etc.
- byond-tracy is now properly shut down when the world shuts
down/reboots, minimizing the risk of data loss or crashing
- More info regarding byond-tracy init is sent to `world.log`
## Why It's Good For The Game
Profiling is super helpful, and this should make things quite easier
## Changelog
No user-facing changes
## About The Pull Request
Extremely simple PR that edits the defaults for the new config options
added in #86886 - this restores the default behaviour that was in place
before #86886; human authority is disabled but easily restored to TG
norms by uncommenting the associated line in the config.
This doesn't impact any of the TG servers directly since they're all on
TGS and have static config files, but this does avoid downstreams being
blindsided by their configs mysteriously breaking and test instances
having behaviour change. I spent an embarrassing amount of time trying
to figure out what *I* broke the past day, only to realize it was an
upstream issue breaking configs all along, and I strongly suspect I
won't be the only one.
## Why It's Good For The Game
No impact on the TG playerbase directly, this is just for the sanity of
developers and downstreams that use static configs. More time spent
being productive, less time spent wondering if your PR buggered up
spawnin and humanized everyone.
## Changelog
🆑
config: altered coded defaults for human authority, no impact on TG
/🆑
## About The Pull Request
Before there were two settings for human authority:
`ENFORCE_HUMAN_AUTHORITY` and `ENFORCE_HUMAN_AUTHORITY_ON_EVERYONE`
The first, if enabled, would not let non-humans be heads of staff unless
they had a specific var on their job set to TRUE.
The second, if enabled, would simply ignore that var and reject the
non-human anyways.
This PR replaces both of those settings with a single one,
`HUMAN_AUTHORITY`. You can set it to one of four settings:
* "OFF": human authority will be turned OFF. Non-Humans will be able to
be heads of staff.
* "HUMAN WHITELIST": human authority will be turned OFF, HOWEVER; if a
job has its new `human_authority` variable set to
`JOB_AUTHORITY_HUMANS_ONLY`, then whoever picks that job will be forced
to be human.
* "NON-HUMAN WHITELIST": human authority will be turned ON. However, if
a job has its `human_authority` variable set to
`JOB_AUTHORITY_NON_HUMANS_ALLOWED`, a non-human can become that job.
This is what we have now, it works the same as if
`ENFORCE_HUMAN_AUTHORITY` were turned on. This is also what I've set as
the default value.
* "ENFORCED" human authority will be turned ON. Non-Humans will never be
able to be heads of staff. This is what
`ENFORCE_HUMAN_AUTHORITY_ON_EVERYONE` used to do.
You can also now set the `human_authority` variable through
`jobconfig.toml`!
## Why It's Good For The Game
Allows more configuration options for downstreams, and lets keyholders
and headmins have more options over how to set up human authority.
## Changelog
🆑
config: Both human authority settings were combined into a singular one,
allowing for more flexibility
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Changes map votes to be based on a persistent tally count.
Tallies for maps are cached between rounds and are added to by map
votes.
When a map is chosen, and it wasn't the only valid one, the tallies for
said chosen map will be reset.
Refactors map vote handling and moves it from SSmapping to SSmap_vote.
Rock the Vote has been removed as a result of this refactor.
## Why It's Good For The Game
Makes it more likely that all maps will be played over the course of a
server instead of always being truly random.
Removes some clutter off of SSmapping.
🆑
refactor: Map Votes are now carried over between rounds. When a map vote
is actually a contest, the winning map will have its votes reset.
/🆑
## About The Pull Request
This pull request aims to fix the wiki manuals. Currently the wiki
manuals just show "You start skimming through the manual..." because of
a bad link (http://www.tgstation13.org/wiki instead of
http://tgstation13.org/wiki) which is fixed with this PR, but the issue
does not end there. Because BYOND uses trident for its `browse()`
function, a lot of Javascript and HTML elements do not function
properly, disallowing the removal or blocking of hyperlinks which break
the book entirely if they are clicked.
Therefore, as a temporary solution (until BYOND 516 is released with
webview2) when the user opens a book they are prompted with the
following:
Although not the best solution, it makes the books have a function again
and are usable.
Fixes https://github.com/tgstation/tgstation/issues/77315.
## Why It's Good For The Game
Makes books work again so new players can use them to be guided to the
wiki resources.
## Changelog
🆑
fix: fix wiki manuals by making them open wiki page on browser
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
This pull request fixes the link you get redirected to when you click
the "Rules" button on the top right of the game. Before it redirected to
http://www.tgstation13.org/wiki/Rules but the correct link is
http://tgstation13.org/wiki/rules (the www part is the problem).
## Why It's Good For The Game
Makes the rules button direct you to the correct link, making it easier
for someone to view the rules of the server.
## Changelog
🆑
fix: fixed link for the rules button
/🆑
## About The Pull Request
Fixes several errors to spelling, grammar, and punctuation.
## Why It's Good For The Game
## Changelog
🆑
spellcheck: fixed a few typos
/🆑
## About The Pull Request
I've a few gripes with start points and the gateway delay. First of all,
there's no way to discriminate peaceful away locations that do not need
a with a 30 minutes timegate from the rest. Places like the beach and
the museum hardly have anything OP that could tip the scales.
Second, none of the awaystart landmarks have identifiers of their own,
which means all awaystart landmarks from all away missions are linked
under the same destination point datum. This is hardly an issue in the
current state where only one map is ever loaded and all maps have only
one way in that directs you to one of several locations at least until
the gateways are linked, but it's nevertheless something that I have to
take care of, since the config requires it.
## Why It's Good For The Game
See above.
## Changelog
🆑
config: Added a config for specific gateway delays so locations like the
beach and the museum don't have to take 30 minutes to become available
like the rest.
/🆑
## About The Pull Request
Added a missing entry to game_config.txt
Fixed this entry being an integer, not a float
## Why It's Good For The Game
Config can be used to modify the speed at which the traitors progress.
It was missing from the example config.
## Changelog
🆑
config: Added an entry for TRAITOR_SCALING_MULTIPLIER, disabled by
default
/🆑
## About The Pull Request
Sets `integer` to false.
Also a tidbit about the `skew_loot_weight` proc, though loot lists with
uneven weights all tend to add a value to all entries so it isn't an
issue.
## Why It's Good For The Game
The config isn't an integer.
## Changelog
N/A
## About The Pull Request
Title. It's an exponent that multiplies weights of random spawners.
For example, if the exponent were 0.8, and the spawner has a natural
99.9% chance to spawn a donk-pocket and a 0.01% of a vial of
adminodrazine, after calculations it'd be roughly 99.6% vs 0.4%.
## Why It's Good For The Game
This can give admins/keyholders more control over random spawners.
~~However, most of the random spawners are maploaded things so an admin
would've to get to edit the config quite fast before SSatoms initializes
to witness the most out of it, but I'm just ranting.~~
## Changelog
🆑
admin: Added a config that regulares random spawners weights.
/🆑
## About The Pull Request
As title says
## Why It's Good For The Game
Important for server operation
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com>
## About The Pull Request
Make events frequency configurable.
Fix runtime when no events were drafted to be picked from.
## Why It's Good For The Game
No runtimes good.
No need to change frequency in code.
🆑
fix: fix runtime when no events were drafted to be picked from
config: make events frequency configurable
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
- Fixes `vote_delay` not being a thing. I broke this two years ago but
there's no bug report associated.
- Admins can now reset the vote delay (to let people vote again
instantly)
- Admins can now end the current vote immediately (rather than
cancelling)
- Custom multi and custom single combined into one vote
## Why It's Good For The Game
Makes voting a bit easier to use, both for admins and for coders adding
new votes.
## Changelog
🆑 Melbert
admin: Custom Single and Custom Multi votes are now combined into one
vote
admin: Admins can now end votes instantly, rather than cancelling them
admin: Admins can now reset the vote cooldown
fix: Vote cooldown actually applies now
/🆑
Do not merge this without coordinating with your server's host.
## About The Pull Request
Slightly refactors the way we handle IP intel.
You can still use the old data stored in the database.
Adds the ability to automatically reject connections determined by
config flags.
## Why It's Good For The Game
We used to have IP intel to check for VPNs, although it was disabled due
to being bad and unhelpful.
This refactor should make it much more manageable for hosts and admins.
## HOSTS BEWARE
This adds a new SQL table `ipintel_whitelist`
Look at the schema!
## Changelog
🆑
admin: The return of IPIntel
/🆑
---------
Co-authored-by: MrStonedOne <kyleshome@gmail.com>
Co-authored-by: oranges <email@oranges.net.nz>
## About The Pull Request
Fixes#82440
This PR just creates a new macro, `LOWER_TEXT()` (yes the irony is not
lost on me) to wrap around all calls of `lowertext()` and ensure that
whatever we input into that proc will be stringified using the `"[]"`
(or `tostring()` for the nerds) operator. very simple.
I also added a linter to enforce this (and prevent all forms of
regression) because I think that machines should do the menial work and
we shouldn't expect maintainers to remember this, let me know if you
disagree. if there is a time when it should be opted out for some
reason, the linter does respect it if you wrap your input with the
`UNLINT()` function.
## About The Pull Request
After months of preparation, and further months of work, I am finally
done. Please bear with me, as this is a massive refactor, but I have
already atomized everything I could. This is now ready for review.
General
- The hilbert hotel slimes are now a subtype instead of a varedit.
- The `use_mob_ability` subtree now also accepts non cooldown abilities.
If set_behaviours is set up properly, mobs won't keep continously
triggering it as if it were a 0 second cooldown action. The alternative
would have been turning the slime abilities into cooldown abilities.
- Wrestling off a slime now signs up to the `COMSIG_ATOM_ATTACK_HAND`
signal, instead of being part of attack_hand.
- Adds datum/ai_controller/controller as a fourth, optional argument to
`/datum/ai_behavior/find_hunt_target/valid_dinner()` to make it possible
to access blackboard keys.
- Slimes no longer attack windows if they would accidentally move into
them (when the conditions are met), since random walk behaviour ignores
tiles they can't go in. It was also not worth to keep. Did you know this
was the sole override of `ObjBump()`?
- Examine was made less snowflaky/bespoke. Also added a new element:
`/datum/element/basic_health_examine`, which is a simple bespoke element
that prints out a custom message based on how damaged the basic mob it
is attached to is.
- Slimes only perform knockdown instead of paralysis, as they can attack
more often now, and paralysis is not that fun.
- LAssailant has been removed due being archaic code. To befriend a
slime, you have to spawn a monkey with the slime console, or feed them a
sheet of plasma. Simple grabbing the monkey or stuffing them in
disposals do not work anymore. Slime console spawned monkeys will have a
visible status effect, with pheromones coming off them to make this
clearer.
Actions
- Feeding, reproduction and evolution is no longer a verb.
- Slime feeding is no longer an action button. You have to use right
click, or as previously, mousedrop. Slimes can always unbuckle from mobs
they are attached to.
Hunger
- Instead randomly changing the starvation and max nutrition values
while growing up, evolution costs 200 nutrion. This makes the code more
readable, and behaviour more predictable, while still giving the
intended time between evolving and splitting. As a result, I could also
turn these into defines.
- Added a component that handles doing an effect over time while buckled
to a mob, until the mob dies or you get unbuckled.
- Slimes gained nutrition is no longer randomly multiplied by the damage
config value, but rather gain nutrition equal to twice the damage dealt.
You'll have to eat one monkey to evolve, just as before.
- Slimes do not heal passively. They only heal from eating. It was a
rather miniscule value that did not have much effect.
- Slimes generate electricity from hunger threshold, instead of the
random amount of hunger threshold + 100.
Environment
- Slimes take 15 damage from cold every second, instead of using a
complex formula (that also decreased the damage up to a point?).
- Slimes still heal from burn damage, but this is now set on the damage
coefficient list.
- Slimes instead of getting stunned by the cold, freeze in an ice cube.
BZ instead of setting them unconscious, calls the stasis status effect,
allowing you to safely stash your hungry slimes for later. They also no
longer slow down from the cold, as they are already slowed down by the
damage they get. Conversely they no longer get a speed up from a random
amount of temperature. I could be convinced to readd this either as part
of the basic sensitive component, or a similar one.
AI
- Removed the attacked_stacks system. Slimes will just perform regular
retaliation if you hit them in a harmful manner.
- Slimes now use the pet orders component. They will interrupt their
feeding when given a command by their master.
- Slimes have their own subtrees. I tried to replicate as much as I
could from the old code, dividing ancient code artifacts and intentional
stuff, so there might be some weirdness.
- Slime speech has been almost fully reduced to basic blorbing, as you
can not even understand them anymore, and most of them require the slime
to loop through all of their surroundings.
- Discipline does not have stacks either. Disciplined baby slimes have a
chance to clear their attack and hunt blackboard keys. All slimes will
stop feeding on the target otherwise.
- Since discipline is not a stack, rabidity instead gets removed at a
10% chance per disciplining.
- Slimes faces are a bit more randomly picked now.
## Why It's Good For The Game
- We want to convert all simple animals to basic mobs. Old slime code
was also very strange, and had some systems that have been replicated by
components.
- Slimes fully paralyzing you is not fun at all. Knockdown should give
you a fighting chance when a slime would like to eat you.
- Slimes slow down from the heavy damage they get from the cold, so I
don't think they need extra slowdown, nor do they need to speed up from
warmth, as they are already fast.
- Slimes turning into an icecube instead of becoming paralyzed from the
cold is more fun for the slimes, as they can break out for a few
moments. It is also funny.
- Slimes entering proper stasis from BZ is not just a visual indicator
of a slime that is safe to approach, but also keeps the slimes's hunger
value in check, allowing it to not starve while stopped. They can also
look around and blorble, instead of staring at a black screen, if player
controlled.
- The attack_stack and discipline_stack behaviours were rather
overcomplicated, and the xenobio mains I talked with didn't even know it
was a thing, so I argue it needed simplification.
- The bespoke friendship system of slimes was also too complicated.
Slimes slowly gained levels of trust, and at certain levels commands
costed friendship, and other levels, they did not. The binary friend/not
friend system that everything else in the game uses is much more
sensible.
- Using right click for feeding is much more sensible than using an
action, and then picking someone from a dropdown.
- Slime speech was very soulful but not only did it loop through
everything in sight, you couldn't even understand it unless you spoke
slime. Maybe it can be readded later in a different form.
- Slime's passive healing was miniscule, and having them rely on feeding
is more interesting.
also
fixes#81463
## Changelog
🆑
refactor: Slimes are now basic mobs. Please report any strange
behaviours!
balance: Slimes only stun you for two seconds when they shock you, the
rest of the duration is a knockdown.
balance: Slimes are not stunned from the cold, but rather, get frozen in
a freon icecube. BZ also puts them in complete stasis, instead of making
them unconscious. Their speed is likewise unchanged by temperatures.
balance: Slimes do not passively heal, they instead rely on feeding.
fix: Slimes can use the buckling screen alert to unbuckle and stop
feeding, along with clicking on the mob they are riding
/🆑
## About The Pull Request
This PR adds two new config options for quirks:
- *Flag* `DISABLE_QUIRK_POINTS`
- When enabled, disables quirk points balancing.
- When enabled, players can select positive quirks without first
selecting negative ones.
- When enabled, the quirk points balance visually hides itself on the
Quirks page.
- *Number* `MAX_POSITIVE_QUIRKS`
- Limits the maximum quantity of positive quirks which players can
select using the Character Preferences page.
- I ported this from the old `MAX_QUIRKS` define.
- When set to `0`, players won't be able to select any positive quirks,
and they won't appear on the Quirks page.
- When set to `-1`, players will be able to select any quantity of
positive quirks.
- When commented-out or undefined, the default is `6`.
- When set to `0` or `-1`, the positive quirk balance visually hides
itself on the Quirks page.
## Why It's Good For The Game
There is some downstream repositories asking for the quirks system to be
configurable. Additionally, I always find myself tweaking these values
on my own private servers and I thought it would be nice to share my
edits. Usually I was simply commenting-out sections of this code in
order to get the same result, so it helps to have an official way to
disable quirk points.
## Changelog
🆑 A.C.M.O.
config: Added two new config flags for quirks, DISABLE_QUIRK_POINTS and
MAX_POSITIVE_QUIRKS.
/🆑
## About The Pull Request
Recently, I chatted with others about how few station traits are rolled
on a round by round basis - about 59% of the shifts go without either
positive or negative traits for example - and how the mild most of these
traits are (not a bad thing per se), which results in an underwhelming
feature, despite the more interesting bits of it. So, after sharing
opinions, I've decided to make this PR to increase the rolls and odds a
bit.
EDIT: After reading comments and taking some time to think this
thoroughfully, I've decided to push the probabilities back a little in
favor of a simple budget system for station traits, to allow for smaller
things to only count as half a station trait. This mean smaller traits
won't necessarily stop "better" ones from rolling, or at least allow for
plentier permutations of traits that do not affect the round TOO much.
I've also reduced the weight of the glitched pda beeps trait from 15 to
10, the same of scarves, wallets and colored assistant jumpsuits.
## Why It's Good For The Game
I believe the current odds of station traits to be a smidge low, and
that the lack of any sort of cost-budget for station traits to hurt the
rarer, more interesting traits (and the feature in general) if the more
common, milder ones take just as much space. It's totally within the
spirit of the feature to have small, niche traits, though they can get
quite boring pretty fast on their own, so what I'm saying is that their
cost should stay low so that other traits can roll.
## Changelog
🆑
refactor: Introduced a simple budget system to station traits, so that
smaller things only count as half a trait, for example.
balance: Increased the odds and maximum number of station traits that
can be rolled each shift.
/🆑
## About The Pull Request
Adds an option to the respawn config which forces you to pick another
character (slot) before you respawn.
## Why It's Good For The Game
Just an idea i'm throwing out there, not necessarily pushing for it to
be enabled on any servers.
Respawning as an alternative character can be a good way to make people
less frustrated at dying, particularly if paired with the cooldown
config that already exists:
"Oh shucks, I died and got my head cut off and got absorbed and got
spaced by some changeling. I won't be able to finish my project or
whatever. At least in 15 minutes I may be able to join as my botanist
character to try something else rather than having to wait an hour and a
half for the round to tick over."
Also nice for downstream support.
(Obviously you can just, *ban* people who respawn as the same character,
use an honor system, but codifying it seems better than not.)
## Changelog
🆑 Melbert
config: Adds a config option for player respawning that enables
respawns, but forces you pick a new character.
config: "NORESPAWN" has been replaced with "ALLOW_RESPAWN 0". Unlimited
respawns is "ALLOW_RESPAWN 1" and character limited respawns is
"ALLOW_RESPAWN 2".
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Job configs would get reset by ResetOccupation and not loaded
afterwards. This fixes that.
## Why It's Good For The Game
Bugfix
## Changelog
🆑
fix: Fixed job configs not being loaded properly.
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com>
## 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.
/🆑
