## About The Pull Request
Hello friends, I've been on a bit of a lighting kick recently, and I
decided I clearly do not have enough things to work on as it is.
This pr adds angle support to static lights, and a concepting/debug tool
for playing with lights on a map.
Let's start from first principles yeah?
### Why Angled Lights?
Mappers, since they can't actually see a light's effect in editor, tend
to go off gut.
That gut is based more off what "makes sense" then how things actually
work
This means they'll overplace light sources, and also they tend to treat
lights, particularly light "bars" (the bigger ones) as directional.
So you'll have two lights on either sides of a pillar, lights inside a
room with lights outside pointing out, etc.
This has annoying side effects. A lot of our map is overlit, to the
point that knocking out a light does.... pretty much nothing.
I find this sad, and would like to work to prevent it. I think dark and
dim, while it does not suit the normal game, is amazing for vibes, and I
want it to be easier to see that.
Angled lights bring how lights work more in line with how mappers expect
lights work, and avoids bleedover into rooms that shouldn't be bled
into, working towards that goal of mine.
### How Angled Lights?
This is more complex then you'd first think so we'll go step by step
Oh before we start, some catchup from the last time I touched lighting
code.
Instead of doing a lighting falloff calculation for each lighting corner
(a block that represents the resolution of our lights) in view we
instead generate cached lightsheets. These precalculate and store all
possible falloffs for x and y distances from a source.
This is very useful for angle work, since it makes it almost totally
free.
Atoms get 2 new values. light_angle and light_dir
Light angle is the angle the light uses, and light_dir is a cardinal
direction it displays in
We take these values, and inside sheetbuilding do some optional angle
work. getting the center angle, the angle of a pair of coords, and then
the delta between them.
This is then multiplied against the standard falloff formula, and job
done.
We do need some extra fenangling to make this all work nicely tho.
We currently use a pixel turf var stored on the light source to do
distance calculations.
This is the turf we pretend the light source is on for visuals, most
often used to make wall lights work nice.
The trouble is it's not very granular, and doesn't always have the
effect you might want.
So, instead of generating and storing a pixel turf to do our distance
calculations against, we store x and y offset variables.
We use them to expand our working range and sheet size to ensure things
visually make sense, and then offset any positions by them.
I've added a way for sources to have opinions on their offsets too, and
am using them for wall lights.
This ensures the angle calculations don't make the wall behind a light
fulldark, which would be silly.
### Debug Tool?
In the interest of helping with that core problem, lights being complex
to display, I've added a prototyping tool to the game.
It's locked behind mapping verbs, and works about like this.
Once the verb is activated, it iterates over all the sources in the
world (except turfs because those are kinda silly), outlining and
"freezing" them, preventing any future changes.
Then, it adds 3 buttons to the owners of a light source.
The first button toggles the light on and off, as desired.
The third allows you to move the source around, with a little targeting
icon replacing your mouse
The second tho, that's more interesting.
The second button opens a debug menu for that light
There's a lot here, let's go through it.
Bit on the left is a list of templates, which allow you to sample
existing light types (No I have no idea why the background is fullwhite,
need to work on that pre merge)
You can choose one by clicking it, and hitting the upload button.
This replaces your existing lighting values with the template's,
alongside replacing its icon and icon state so it looks right.
There are three types as of now, mostly for categorization. Bar, which
are the larger typically stronger lights, Bulb, which are well, bulbs,
and Misc which could be expanded, but currently just contains floor
lights.
Alongside that you can manually edit the power, range, color and angle
of the focused light.
I also have support for changing the direction of the light source,
since anything that uses directional lighting would also tie light dir
to it.
This isn't *always* done tho, so I should maybe find a way to edit light
dir too.
My hope is this tool will allow for better concepting of a room's
lights, and easier changing of individual object's light values to suit
the right visuals.
### Lemon No Why What
Ok so I applied angle lights to bars and bulbs, which means I am
changing the lighting of pretty much every map in the codebase.
I'm gonna uh, go check my work.
Alongside this I intend to give lighting some depth. So if there's room
to make a space warmer, or highlight light colors from other sources, I
will do that.
(Images as examples)
I also want to work on that other goal of mine, making breaking lights
matter. So I'll be doing what I can to ensure you only need to break one
light to make a meaningful change in the scene.
This is semi complicated by one light source not ever actually reaching
fullbright on its own, but we do what we must because we can.
I'm as I hope you know biased towards darker spaces, I think contrast
has vibes.
In particular I do not think strong lights really suit maintenance.
Most of what is used there are bulbs, so I'm planning on replacing most
uses with low power bulbs, to keep light impacts to rooms, alongside
reducing the amount of lights placed in the main tunnels
**If you take issue with this methodology please do so NOW**, I don't
want to have to do another pass over things.
Oh also I'm saving station maps for last since ruins are less likely to
get touched in mapping march and all.
### Misc + Finishing Thoughts
Light templates support mirroring vars off typepaths using a subtype,
which means all the templates added here do not require updating if the
source type changes somehow. I'd like to expand the template list at
some point, perhaps in future.
I've opened this as a draft to make my intentions to make my changes to
lights known, and to serve as motivation for all the map changes I need
to do.
### Farish Future
I'm unhappy with how we currently configure lights. I would like a
system that more directly matches the idea of drawing falloff curves,
along with allowing for different falloffs for different colors,
alongside extending the idea to angle falloff.
This would make out of engine lighting easier, allow for nicer looking
lights (red to pink, blue to purple, etc), and improve accessibility by
artists.
This is slightly far off, because I have other obligations and it's
kinda complicated, but I'd like to mention it cause it's one of my many
pipedreams.
## Changelog
🆑
add: Added angle lighting, applies it to most wall lights!
add: Adds a lighting prototyping tool, mappers go try it out (it's
locked behind the mapping verb)
/🆑
---------
Co-authored-by: MMMiracles <lolaccount1@hotmail.com>
## About The Pull Request
Foam is crummy at high load rn, both because it runs on a low priority
background subsystem, and because it wastes a bit of time.
Let's reduce usage (while speeding up a bunch of other stuff too), and
give it more cpu generally.
[Optimizes reagent processing
somewhat](d409bd4afc)
Turns out most of the cost of foam is the reagents it carries, and the
varying effects they have
I'm doing my best here to optimize them without touching "user space"
too much
That means doing things like prechecking if we're gonna spawn on top of
an existing decal (from glitter, flour, etc), and using that same proc
to also avoid spawning on unacceptable turfs (I had to convert
inheritance to a bitflag system to make this work, but I think that's ok
since we want it imparative anyhow)
It's actually nice for code quality too, since it lets me clean up code
that was using raw locates and weird var pong.
god I wish I had implied types man
[Optimizes foam spreading in its most accursed aspect, reagent
copying](5cc56a64ad)
Holy shit reagent code is a lot.
I'm doing a bunch of small things here. istype in init -> typecache,
removing procs that are called once and loop over a list we JUST looped
over (ph and the caching for reactions in particular)
I am mainly trying to optimize copy_to here, since that's what foam
spams
As a part of this, I removed a pair of update_total and handle_reactions
calls that were done on the reagents we are copying FROM
I have no god damn idea why you would want to do that, but if anything
is relying on the copy proc modifying the source, then that code
deserves to break
Speaking of, I cleaned up handle_reaction's main filter loop a lot,
removed a lot of redundant vars and changed it from a full loop w
tracker vars to an early exit pattern
This meant using a loop label, which is unfortunate, but this is the
fastest method, and it does end up cleaning up the code significantly,
Which is nice
Oh also I made the required_other var function even if there is no atom
attached to the reaction, since I don't see why it wouldn't
This last bit is gonna get a bit esoteric so bear with me
Failing calls (which are most of them) to handle_reactions are going to
be fastest if they need to check as few reactions as possible
One reagent in a reaction's required list is marked as the "primary",
and thus gets to trigger checking it.
We need all the reagents to react anyhow, so we might as well only check
if we have one particular one to avoid double checking
Anyhow, in order to make most calls the fastest, we want these reactions
distributed as evenly as possible across all our reagents.
The current way of doing this is just taking the first reagent in the
requirements list and using it, which is not ideal
Instead of that, lets figure out how many reactions each reagent is in,
then divy reactions up based off that and the currently divvied
reactions
This doubles the reagent index count, and takes the most common reagent,
water, from 67 reactions to I think like 22
Does some other general cleaning in reagent code too, etc etc etc
[Fixes runtimes from the forced gravity element being applied more then
once](941d067611)
I feel like this element should take a trait source or something to make
them potentially unique, it's too easy to accidentally override one with
another
[Removes connect_loc usage in atmos_sensitive, replaces it with direct
reg/unreg](de1c76029d)
I only really used it because I liked the componentization, but it costs
like 0.2 seconds off init alone which is really stupid, so let's just do
this the very slightly harder way
[Micros foam code slightly by inlining a LinkBlockedWithAccess
call](744da3694c)
This is in the space of like 0.05 seconds kinda save so I can put it
back if you'd like, the double loop just felt silly
[Changes how foam processes
slightly](ee5e633e32)
Rather then treating spreading and processing as separate actions, we do
both in sync.
This makes foam fade faster when spreading, which is good cause the
whole spread but unclearing foam thing looks silly.
It also avoids the potential bad ending of foam spreading into itself,
backwards and forwards. This is better I promise.
[Bumps fluid priority closer to heavy eaters, moves it off
background](811797f09d)
Also fixes a bug where foam would travel under public access airlocks.
## Why It's Good For The Game
Saves a lot of cpu just in general, from both init and live.
In theory makes foam faster, tho I'd have to test that on live at
highpop to see if I've actually succeeded or not. Guess we'll see.
## About The Pull Request
Adds a new 7 point positive quirk, "Spacer Born". Totally not inspired
by The Expanse, don't look at the branch name.
You were born in space, rather than on a planet, so your physiology has
adapted differently.
You are more comfortable in space, and way less comfortable on a planet.
Benefits:
- You are slightly taller. (No mechanical effect)
- You take 20% less damage from pressure damage.
- You take 20% less damage from cold environments.
- You move 10% faster while floating (NOT drifting, this is zero gravity
movement while beside a wall).
- You drift 20% faster (Drifting through zero gravity, untethered to
anything)
- While in space (z-level-wise, not turf wise), you lose some disgust
overtime.
- While experiencing no-gravity for an extended period of time, you will
start regenerating stamina and reduce stuns at a very low rate.
- If you are assigned to shaft miner (or the map is Icebox), you are
awarded with a 25% wage bonus (hazard pay).
Downsides:
- While on a planet (Yes, this includes Icebox and planetary maps), you
gain gravity sickness:
- Passive accrue disgust (slightly lessened on Icebox) (Capped at low
levels)
- Choking, after extended periods (disabled on Icebox)
- Slower movement
- Weaker stamina (disabled on Icebox)
- Suffocation from extended periods (disabled on Icebox) (Lungs aren't
adapted)
- Mood debuff
(Effects not final)
## Why It's Good For The Game
I'd figure I throw my hat in with the Positive Quirk Curse.
This is a quirk that improves your ability in a niche circumstance (low
gravity / dangerous pressure), with some downsides that are only
generally in effect if you play a few roles (or it's Icebox).
Because of this I think it'll provide an interesting niche, where Spacer
Born engineers are slightly better than their counterparts due to their
origin (moving faster in space without a jetpack, withstanding
pressure). However, at the same time, if the mining outpost sustains
damage and needs repairs... suddenly your buff over your cohorts
disappears, and you have to brave somewhere hostile to your body.
Ultimately, the goal of the quirk is to encourage people to approach
situations a bit differently.
Or take it as a challenge and play shaft miner.
## Changelog
🆑 Melbert
add: Adds a new 7 point positive quirk, "Spacer Born". You were born in
space, and as a result your body's adapted to life in artificial
gravity, making you much more effective and comfortable in lower
gravity. However, travelling planet-side is quite a chore, especially if
you're assigned to work there.
add: Adds a chemical: Ondansetron, created by Oil + Nitrogen + Oxygen +
Ethanol catalyst. A powerful Antiemetic (lowers disgust).
/🆑
## About The Pull Request
Removes all of the duplicate global lists for specific machine types
where the only thing they do is store all machines of that type.
Adds machine tracking to SSmachines in the form of a list for all
machines, and then an associative list for machines by their type.
Previously we have machines in multiple global lists, such as airlocks
being in GLOB.doors, GLOB.airlocks, GLOB.machines.
This makes that not a thing, and also means that iterating through
GLOB.machines looking for a specific type is no longer as expensive.
## About The Pull Request
This PR refactors mind language holders into non-existence
As a result, `update_atom_languages` is no longer necessary
Mind-bound languages are transferred via `/mind/proc/transfer_to`
Species changing no longer deletes and re-creates the mob's language
holder, allowing them to keep any languages they have.
Species languages are sourced from `LANGUAGE_SPECIES` now, meaning they
are removed when they change species. If the mob is not a human with a
species datum, these are effectively just atom level languages.
Makes a bunch of unit tests to ensure language transfer over certain
events works as intended
## Why It's Good For The Game
Mobs with minds having two independent language holders results in a
good few bugs, and simply doesn't make sense when we have sources
(`LANGUAGE_MIND`).
Instead of tracking two language holders, we can simply use sources
better and only track one.
This means that the language holder you start with is your language
holder, period. It doesn't get deleted or re-instantiated or whatever.
## Changelog
🆑 Melbert
refactor: Refactored language holders, making species changes not delete
all of your known languages
/🆑
## About The Pull Request
Rebalances the smuggler satchels that were randomly replaced around the
station.
Now only two are spawned, down from 10
## Why It's Good For The Game
Though I think these are cool, currently with 10 spawning roundstart
they feel like they are everywhere, especially if you are walking around
with t-ray vision. The smugglers satchel is powerful item, powerful
enough to be in the traitor uplink. It makes inventory management a lot
easier, as you essentially have another backpack in your backpack. I
feel like this is a fine reward for being lucky or actively looking for
them, but with how they are currently, you can pretty much guarantee
your chances of getting 5 with a t-ray scanner and a couple minutes of
walking around, invalidating the inventory system. Now if you want this
reward, you have to make a choice to look for one, with the knowledge
that you still may not find it.
## Changelog
🆑 Seven
balance: Only 2 smugglers satchels will spawn on the station at
roundstart, down from 10
/🆑
## About The Pull Request
Basically, the organ equivalents of prosthetic limb and quadruple
amputee.
These replace your organs with absolutely terrible cybernetic
counterparts which also have absolutely no resistance against EMPs.
### ADDITIONAL FUN
Surplus organs are so awful that if surgically removed while not EMPed
nor failing, they *explode*!
## Why It's Good For The Game
More character customization, and more suffering for hardcore random
players.
## Changelog
🆑
add: Added two new quirks, prosthetic organ and tin man. Essentially,
they replace organs with bad bad not good cybernetic counterparts.
/🆑
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: carlarctg <53100513+carlarctg@users.noreply.github.com>
## About The Pull Request
This was one of the tradeoffs for removing other, more consistent
sources of languages, and was requested by Melbert among many others.
This does go against my wanted goal of decreasing the risk of
eavesdropping by other players through just magically knowing a
language, but it is an expensive quirk and it is in their medical
records, which makes it better than language encryption keys or silicon
just innately knowing them.
This also limits Bilingual to only roundstart languages (+Uncommon),
rather than being randomly selected from a list (that had very useless
ones like monkey, podpeople, and beachbum). This is mostly just for
modularity, I didn't want to make it look terrible code-wise and thought
this may be the optimal way to handle it.
This is also me going back on
https://github.com/tgstation/tgstation/pull/71773 - which I had closed
myself.
## Why It's Good For The Game
If we're gonna keep the Bilingual quirk, it might as well be something
players can choose the language of, it's their character and they should
be allowed to decide how their character is, and it is my fault that
this stupid compromise of "getting a random language" was made in the
first place. It never should've happened.
It now actually limits it to roundstart-only languages, so there's no
way you can spy on people who prepare in advance through becoming
podpeople, or monkeys, etc.
## Changelog
🆑
balance: Bilingual quirk now lets you choose your language between ones
given to roundstart species.
balance: Foreigner and Bilingual are now mutually exclusive languages.
/🆑
## About The Pull Request
Fixes#76310
`sound_override = TRUE` makes it so that no sound is played for the
announcement since "TRUE" isn't a sound file, but that might be bad code
let me know
## Why It's Good For The Game
Sending the message over the radio makes the AI "speak" it, so TTS plays
from AI at the same time as the VOX sounds, which makes the announcement
sound bad for the AI and anyone around them. This turns it from being
sent over the radio to an announcement so that TTS doesn't apply. It
also just makes more sense having the VOX announcement sent as an
announcement rather than just a normal radio message.
## Changelog
🆑
qol: AI VOX messages are sent over announcement instead of radio
fix: AI VOX messages work properly on multi-Z stations
/🆑
## About The Pull Request
This adds a new element for movables that grants turfs they're in
traits, changes lava and the chasm component to check for traits
instead, ditto for turf slowdown. It also implements another trait that
prevents wet floor from slipping people, as well as some other changes
(feel free to opine on them really):
- Tables and conveyor belts now stop turf slowdown, much like catwalks,
as I imagine people walking on them are not really touching the floor.
(I'd include protection against lava too... until they melt, but that'd
mean finding a way to have these objects burn in the first place, and
lava code is still stupid despite a years old refactor I did)
- Tables also stop slippery turfs from slipping (bananas, soaps etc.
still apply). I wish there were a way to make some objects slippery by
coating them in water vapor or splashing water/lube, but that's outside
the scope of this PR.
- Fixed an edge case in which a mob standing on a lava turf would be
left permanently visually on fire if the lava is changed to another kind
of turf.
- Removed unused code from stone tiles.
I'm going to include these traits in that global list for admin-added
traits... tomorrow perhaps. 💤
## Why It's Good For The Game
Replacing some hard-coded mechanics with easier to use traits and an
element, which I also need for the submerge element PR.
## Changelog
🆑
refactor: Replaced hardcoded "safeties" for lava, chasms and ignoring
turf slowdowns on catwalks with traits.
balance: much like catwalks, tables and conveyors also disable turf
slowdowns.
balance: slippery turfs won't slip you when walking on a table.
fix: Fixed an edge case in which a mob standing on a lava turf would be
left visually but permanently on fire if the lava is changed to another
kind of turf.
/🆑
## About The Pull Request
Hey there,
A pretty bad bug (#76226) got through, but it was fixed pretty quickly
in #76241 (cf92862daf). I realized that if
we were testing all the away missions, that this could theoretically get
caught and not happen again. Regardless, unit testing gateway missions
has been on my to-do list for a while now, and I finally got it nailed
down.
Basically, we just have a really small "station" map with the bare bones
(_teeny_ bit of fluff, maploading is going to take 30 seconds tops
anyways let me have my kicks) with a JSON map datum flag that causes it
to load all away missions in the codebase (which are all in one folder).
Just in case some admins were planning on invoking the proc on
`SSmapping`, I also decided to gate a `tgui_alert()` behind it because
you never can be too sure of what people think is funny these days (it
really does lock up your game for a second or so at a time).
I also alphabetized the maps.txt config because that was annoying me.
## Why It's Good For The Game
Things that break on production could(?) be caught in unit testing? I
don't know if the linked issue I mentioned above would have been caught
in retrospect, but it's likely to catch more than a few upcoming bugs
(like the UO45 atmospherics thing at the very top) and ensure that these
gateway missions, which tend to be the most neglected part of mapping,
stay bug-free.
This is also helpful in case someone makes a new away mission and wants
to see if stuff's broken. Helps out maptainers a bit because very, very
technically broken mapping will throw up runtimes. Neato.
## Changelog
Nothing that players should be concerned about.
Let me know if there's a better way to approach this, but I really think
that having a super-duper light map with the bare basics to load up
gateway missions and then all nine-ish gateway missions can sequentially
load during init. I can't think of a better way to do it aside from some
really ugly `#ifdef` shit. Also also, it has the added benefit of being
a map that will always load your away mission without touching a single
shred of config (and it's not likely to break if you follow sane
practices such as making your own areas)
## About The Pull Request
[Removes the pretense of relative multiz
levels](0293fdc2bd)
Our multiz system does not support having a z level that is only
connected one way, or which goes down backwards or anything like that.
That's a fiction of the trait system, the actual backend has never
really supported this.
This pr removes the assumptions we were making backend around this, and
uses that to save cpu time.
I am also converting multiz_levels from an assoc list to a pure one,
which saves significantly on access times and cleans up the code
somewhat.
Also I'm making the get_below/get_above procs into macros, for the sake
of cpu time.
[Converts the starlight disease to use BYOND's directional defines
instead of our
own](7d698f02d9)
To some extent spurred on by
https://github.com/DaedalusDock/daedalusdock/pull/298, tho it was known
before
## Why It's Good For The Game
Faster multiz code, faster init, etc etc etc
## 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
Gives duffelbags their proper slot count
They inherited this from backpacks, but I sorta just forgot about that
[Creates "levels" of locked objects, uses that to make locked duffels
work](c613c00f62)
[c613c00](c613c00f62)
Turns locked into something that holds defines, this makes life a lot
easier.
Requires a lot of boilerplate because of how many uses of these procs
there are and all the passthrough and shit.
Adds a few outfit subtypes to avoid this class of failure in future.
Renames the args in a few but not all touched procs, one thing at a time
Closes#76407Closes#76430 Had the lock check in the wrong place
Closes#76441 GOD I HATE TK SO MUCH
Wrote half the pr without glasses so if it's weird gimme some grace
yeah?
## Changelog
🆑
fix: Fixes some fuck with duffelbags, them not holding enough + issues
with spawning gear in them (job shit and all)
/🆑
## 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
The second layer of tram does not need its own relay, it is like 10 feet
max above the first.
Feels wrong in game, mappers tend to just sneak these off in corners, it
sucks.
Shouldn't need to do it.
Instead, tcomms z levels will be filled based off the z stack, rather
then just the layer itself.
Adds a list/helper to make this more efficient/more easily duplicable
## Why It's Good For The Game
Matches what people expect better, removes redundant map bits, better
vibes.
## Changelog
🆑
balance: Tcomms now works across connected (vertically) zlevels. No more
hunting in maint for the relay.
/🆑
## 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
Unused vars have 0 memory cost, and the ref and list lookup here is
REALLY expensive, for both init and foam spreading.
## Why It's Good For The Game
Saves 0.2s off a station flood on meta, and 0.17s off init. More time in
other qdel heavy areas
Pulled off #76104 for the sake of cleanliness
<!-- 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
[Reduces timer insertion cost by
80%](c9e5b285ed)
Timer name generation involved a LOT of string shit, some in ways where
the string only existed for a moment.
This costs a good bit of time, and can be reduced with only minimal
impacts on the end product, so let's do that. Includes a compile flag to
flip it back if we ever have trouble in future.
This is about 0.1s off init, since we do a lot of timer stuff then too
[Removes STOPPABLE flag from QDEL_IN, moves it to a bespoke
macro](e7a5d7f2a7)
Its a waste most of the time, tho I would LOVE to analyze at compile
time to work out if we care
## Why It's Good For The Game
I like it when we don't spend all of our cpu time just setting the name
var on timers. that's good and not bad.
This saves time fucking everywhere. 15% off explosions, 0.1 seconds off
init, bunch of time off foam. it's just good.
Cherry picked out of #76104 since that was too cluttered (sannnnnn)
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
## About The Pull Request
The issue was map verification calling build_cache, which uses the
define which enables/disables init values on sleep. We avoid this by
using a var on map datums and using that to enable the init value
modification only when we are actually loading stuff.
Also fixes a bug in clear_tracked_initialize() where it being called
with no values lead to bad values/potentially overriding initialized on
accident.
Also also I forgot how for loops worked so this would not have worked
regardless
## Why It's Good For The Game
Code should like, function
## About The Pull Request
The old system was... ok, but the stack trace was unfortuante, and the
potential to double remove was silly.
Let's use a list of source, value instead, to block overremovals and
properly support different load states
## Why It's Good For The Game
Prevents a bug a goodhearted bagilmin showed me where shuttles would
randomly just fail to load.
Calling clear twice should not be a failure
## Changelog
🆑
fix: Maps loaded post init will no longer randomly enter a failed state.
Hopefully.
/🆑
## About The Pull Request
I'm surprised none else got this already, constant null var reads
because the stack datum isn't created unless the subsystem is active.
Annoying
## About The Pull Request
Typo fixes. Further and fixes MetaStation's default name to match the
JSON.
## Changelog
🆑 LT3
spellcheck: Fixed a few typos
/🆑
## About The Pull Request
https://github.com/tgstation/tgstation/assets/7501474/a2d83ce8-eba1-42d9-a1f8-9d73f7c40b21
Adds shuttle events! Stuff can now start to happen outside the shuttle,
either benign or spicy (but usually just fun to watch)!
## Why It's Good For The Game
The shuttle escape sequence is an important part of the game, uniting
about every player surviving player. Recently, #71906 has made the
escape sequence more forgiving as well as more interesting by
conditionally doubling the playing field. The area outside the shuttle
is still mostly empty though, except for the few people being spaced,
daredevils and the occasional epic space fight.
This PR adds adds some space events to spice up the outside of the
shuttle! This both gives people something too look at, making the escape
sequence feel less static and more lively, as well as give people a
reason to go outside and get the full experience of ~being decapitated
by a meteor~ swimming with the fishes!
<details>
<summary>Shuttle Events</summary>
**Friendly carp swarm**
Spawns a group of carp that flies past the shuttle, completely friendly
unless provoked.
**Friendly meteors**
Spawns a lot of strong meteors, but they all miss the shuttle.
Completely safe as long as you don't go EVA
**Maintenance debris**
Picks random stuff from the maintenance spawn pool and throws it at the
shuttle. Completely benign, unless you get hit in the head by a toolbox.
Could get you some cool stuff though!
**Dust storm**
Spawns a bunch of dust meteors. Has a rare chance to hit the shuttle,
doing minimal damage but can damage windows and might need inflight
maintenance
**Alien queen**
One in every 250 escapes. Spawns a player controlled alien queen and a
ripley mech. RIP AND TEAR!! Really not that dangerous when you realize
the entire crew is on the shuttle and the queen is fat as fuck, but can
still be fun to throw people around a bit before being torn to shreds.
**ANGRY CARP**
Once in every 500 escapes. Spawns 12 normal carp and 3 big carps, who
may just decide to go through the shuttle or try and bust through the
window if you look at them wrong. Somewhat dangerous, you could stay
away from the windows and try to hide, or more likely shoot at them and
weld the windows
**Fake TTV**
Lol
**Italian Storm**
Once in every 2000 rounds. Throws pasta, pizza and meatballs at the
shuttle. Definitely not me going off the rails with a testing event
**Player controlled carp trio**
Once in every 100 escapes. Spawns three player controlled carp to harass
the shuttle. May rarely be a magicarp, megacarp or chaos carp. I can't
honestly see them do anything other than be annoying for 3 seconds and
die
There are some other admin only ones: a group of passive carps going
directly through the shuttle and just being little shits, and a magic
carp swarm
</details>
Events are selected seperately, there isn't a crazy weighting system,
each just has a chance to run, and multiple could run at once. They also
don't immediately trigger, so people can get settled a bit, and to make
sure just waiting out the more dangerous ones is still a valid strategy.
## Changelog
🆑
add: Adds shuttle events! If shuttle escapes weren't exciting before
(doubtful), they definitely are now! I'm joking it's mostly an
atmosphere thing.
admin: Adds an admin panel to interact with shuttle events, under the
Events tab: Change Shuttle Events
fix: Objects spawned in hyperspace will properly catch hyperspace drift
/🆑
There's a few things I'd like to do later (another PR) (honestly anyone
can do them because I suck at follow-ups), because this is too big as
is:
- Hijack triggered shuttle events
- More events (got a lot of cool suggestions, but I'm putting most of
them on hold)
- Maybe stration announcements if some more dangerous ones get added
- Structures appearing next to the escape shuttle???
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Currently you can put cargo's budget card into your PDA, go into NT Pay
and send over the budget to any pay token you want including yours. This
just adds a check to ensure you aren't using that kind of card as
withdrawal source.
## About The Pull Request
Simply as it is. Every job _can_ have a minimal character age and will
not let underages to occupy for it.
Can be configured in config. Disabled(all zeros) by default.
## Why It's Good For The Game
Good for RP downstreams.
## Changelog
🆑 SuperDrish
add: Minimal Job Age requirments added. Disabled by default.
/🆑
## About The Pull Request
Signals were initially only usable with component listeners, which while
no longer the case has lead to outdated documentation, names, and a
similar location in code.
This pr pulls the two apart. Partially because mso thinks we should, but
also because they really aren't directly linked anymore, and having them
in this midstate just confuses people.
[Renames comp_lookup to listen_lookup, since that's what it
does](102b79694f)
[Moves signal procs over to their own
file](33d07d01fd)
[Renames the PREQDELETING and QDELETING comsigs to drop the parent bit
since they can hook to more then just comps
now](335ea4ad08)
[Does something similar to the attackby comsigs (PARENT ->
ATOM)](210e57051d)
[And finally passes over the examine
signals](65917658fb)
## Why It's Good For The Game
Code makes more sense, things are better teased apart, s just good imo
## Changelog
🆑
refactor: Pulled apart the last vestiges of names/docs directly linking
signals to components
/🆑
## About The Pull Request
Lemon guy was a bit too late in reviewing #75732 because it got already
merged by someone else, and I too hadn't managed to make some adjustment
to that PR in time.
This PR applies suggested changes, turns a simple proc into a macro, and
makes it so that also waddling, squeaky shoes and swivel chair sounds
don't running when moved by conveyor belt.
This doesn't stop squeaking from happening when other
conveyor-belt-moved objects or mobs cross its tile. That'd be hacky and
I'm not here to fight sfx-spamming machines.
## Why It's Good For The Game
These are changes that should have been included in #75732 but couldn't.
See that PR for the general idea.
## Changelog
🆑
fix: waddling, squeaky shoes and swivel chair sound effects no longer
run when moved by conveyor belt.
/🆑
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
Adds a few new quirks so allow for some more individuality from players!
~~They're set to 0 right now for TM purposes.~~ No TM, thus spoke
Melbert.
To-do:
- [x] Bilingual - Random extra language
- [x] ~~Mutated - Random mutation~~
- [x] Big Hands (fetish content???) - Big hands trait (can't use guns)
- [x] Soft-Spoken - Whisper permanently
- [x] Clumsy (not a packet dropper) - Clumsy trait (clown shit)
- [x] ~~Paroled Convict - Spawn with a tracking implant + prisoner
armband.~~
- [x] ~~Fashionista (headmins made me do it) - Lets you pick a scarf
roundstart.~~
- [x] The more the merrier.
## Why It's Good For The Game
Small changes at the cost of a negative quirk or two are a fun way to
develop the story. It's fun! These aren't game breaking and might lead
way to some interesting interactions!
## Changelog
🆑 Chadley
add: Adds some new quirks!!
add: Adds the bilingual quirk, which gives a new random language.
add: Adds the big hand quirk which stops the usage of most guns.
add: Adds the soft spoken quirk which forces you to whisper.
add: Adds the clumsy quirk enabling the clumsy trait.
/🆑
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
[Improves the documentation of DCS lists, removes old list of callback
docs that no longer
apply](c3821d9f5f)
[Adds a second signal register to decal rotating, adds a trait to
objects under a tile. STOP DIRECTLY READING HIDDEN LISTS I SWEAR TO
GOD](6b3f97a76a)
[Removes direct reads of the timer list, they were redundant
mostly](14fcd9f8a6)
[Please stop directly reading/modifying the traits list to ensure your
dna rot follows the
brain](ec0e5237ec)
[Marks internal datum lists as well internal with
_](57c6577ff6)
[57c6577](57c6577ff6)
Does the same to _clear_signal_refs() in hopes of keeping people from
touching it
## Why It's Good For The Game
They pissed me off.
Users should not be touching these lists, especially in ways that make
assumptions about their structure and are thus prone to breaking if that
ever changes.
Most of these are close to zero cost changes, using a wrapper to solve
the problem, or just yeeting it
Two aren't, Decals with a direction have gained a second signal register
on init, and things that sit underfloor (cables/pipes) now get a trait
when inserted there.
This should have a minimal impact on memory/init time, bugging
@Mothblocks about it just in case
Before, long ago, if a `\ref` was reused on something that was deleted
the same tick, the old associated list based queue would cause the new
item to "override" the old one, keeping the list from duplicating.
To make ssgarbage faster, we moved the queue to a normal list of lists
some time ago, but now if something qdeletes, gcs, then something gets
assigned that same `\ref`id, then that thing also gets deleted, all
within the same tick, it will attempt to hard delete it multiple times
needlessly because it doesn't detect the ref reuse.
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
More or less a triviality, currently footstep/wheelchai sounds are
played even when the mob is moved by a conveyor belt, or riding the
tram. This PR puts an end to that.
To clarify, this doesn't stop these sounds from being played if you're
walking/running/rolling along or against a belt, or inside the tram.
But more than that, I made this PR because, afaik, we don't have a good
way to tell if a given movement proc chain was caused by a move loop or
not, and I need one for something I'm working on. This is more of an
implementation and reason for this PR to be made.
Tested, no issue. Waiting for a review, specially from @LemonInTheDark,
since they're the mind behind the movement loop code. Hopefully I'm
right saying what I said.
## Why It's Good For The Game
This fixes a consistency issue (if it can be called such) and the lack
of a simple way to tell if a movable is being moved by a move loop
outside of its own code.
## Changelog
🆑
fix: Being moved around by conveyor belt or tram no longer play
footsteps and wheelchair sounds.
/🆑
## About The Pull Request
fixes the flaky test reports for cockroaches being stuck in the spatial
grid (which mothblocks seems to have closed all of)
cockroaches get deleted when they die, so theres a spurious unit test
failure where if a cockroach is on a tile in grid cell A and moves to a
lava tile in grid cell B, they will get killed when lava.Entered() is
called, then deleted, and when /atom/movable/Destroy() is called we try
to take them out of grid cell B (because their loc is the lava tile) but
they were never added to that cell yet because their movement never
finished, so that doesnt do anything. THEN moveToNullspace() is called,
that movement finishes before the first movement, and then in
Moved(old_loc = lava turf) we try to remove it from grid cell B which
again doesnt work, and then the first movements Moved(old_loc = original
turf) is called where we can actually remove them from the correct grid
cell, except we cant because in exit_cell() we subtract
`old_target.important_recursive_contents[channel]` from the cells
content lists, and since the target is deleted by this point it doesnt
have important_recursive_contents. so the fix here is changing this so
it subtracts `old_target.important_recursive_contents?[type] ||
old_target` instead, which works if the target is deleted.
also fixes some Entered() overrides that dont call parent and improves
documentation on spatial grid defines
## Why It's Good For The Game
fixes it without needing the change_loc() setter
## About The Pull Request
I was using the step_x procs when I should have been using get_step_x
and Move()
This was causing some mob behavior to not properly respect things like
gravity or potentially entered/exited signals.
Also ensures we pass direction into Move consistently, and deletes a
function that was meant to like, use step_to but with directions? Was
never actually used properly
I forgot to properly respect the "don't change dir" flag
Closes#75673🆑
fix: Mobs will fly around space... less
/🆑
## About The Pull Request
Lol
## Changelog
🆑
fix: fixed TTS volume changes not working
/🆑
Co-authored-by: TiviPlus <572233640+TiviPlus@users.noreply.com>
## About The Pull Request
It's easier to parse, and makes more sense when you read it. This way
I'll never have to add yet another case to my parser for someone
changing where a space goes or something.
Moves qdel into its own category cause the old name looked ugly (yell if
this is dumb)
Added a bitfield to entries pulled from categories, adds a new flag that
enables pretty printing json lists.
## Why It's Good For The Game
IMPROVES my workflow
## Changelog
🆑
server: del logging is now done by outputting to a json file again, but
this time we're using ACTUAL json and not just a big text string with
newlines and shit
/🆑
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
## 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>
## About The Pull Request
Fixes the "bad index" runtime that shows up on 80% of rounds.
The issue is that during dynamic maploading, the initialization of
objects is split over several ticks. However, before the initialization
is complete, an object's smoothing groups is still in its string form
(as per [the smoothing group
optimizations](https://github.com/tgstation/tgstation/pull/71989)).
Thus, code later down the line attempts to read from this string, and
errors.
It would be expensive to check all nearby neighbors every time in any
place in this code, so instead we defer icon smoothing if there are any
initializations currently in progress. Because this only happens for
dynamic loading, the stuff being loaded dynamically is usually small,
and icon smoothing already has a somewhat visible delay for shuttles,
this delay doesn't matter.
## Changelog
🆑
fix: Fixed an issue where objects on something that loaded dynamically,
like shuttles, would not be smoothed.
/🆑
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>
