* Allows Export of your Preferences JSON File (#75014)
## About The Pull Request
Hey there,
This was spoken about in #70492 (specifically
https://github.com/tgstation/tgstation/pull/70492#issuecomment-1278069607),
and I have been waiting for this to be implemented for some time. It
never got implemented, so I decided to code it myself.
Basically, **if the server host doesn't disable it**, you are free to
export your JSONs as a player, right from the stat-panel. It's a pretty
JSON on 515 versions, too!
It's right here:
Here's what the prettified JSON looks like on 515.
There's a cooldown (default to 10 seconds) between exporting your
preferences.
#### Why is this config?
It's because in the past, a server host could always just file-share the
.sav or .json or whatever to the player, but they would have to do the
explicit option of actually bothering to make the files accessible to
the player. In that same line of logic, the server operator will have to
explicitly make the files accessible. This is mostly because I'm not
sure how good `ftp()` is at being a player function and wanted to have
some sort of cap/control somehow in case an exploit vector is detected
or it's just plain spammed by bots, so we'll just leave it up to the
direct providers of this data to elect if they wish to provide the data
or not.
## Why It's Good For The Game
Players don't have to log into Server A to remember what hairstyle they
loved using when they want to swap to Server B! That's amazing actually.
I always forget what ponytail my character has, and it'll be nice to
have the hairstyle in a readily accessible place (after I prettify the
JSON for myself).
It's also more convenient for server hosts to make player data like this
accessible if they really want to, too.
If we ever add an _import_ feature in the future (which would have to be
done with a LOT of care), this will also be useful. I wouldn't advise it
though having taken a precursory look at how much goes into it while
trying to ascertain the scope of this PR.
## Changelog
🆑
qol: The game now supports export of your preferences into a JSON file!
The verb (export-preferences) should now be available in the OOC tab of
your stat-panel if enabled by server operators.
server: Exporting player preferences is controlled by a configuration
option, 'FORBID_PREFERENCES_EXPORT'. If you do not wish to let clients
access the ftp() function to their own preferences file (probably for
bandwidth reasons?) you should uncomment this or add it to your config
somehow.
config: Server operators are also able to set the cooldown between
requests to download the JSON Preferences file via the
'SECONDS_COOLDOWN_FOR_PREFERENCES_EXPORT' config option.
/🆑
* Allows Export of your Preferences JSON File
---------
Co-authored-by: san7890 <the@san7890.com>
* Config Flag to Save Generated Spritesheets to Logs (#74884)
## About The Pull Request
I was helping someone debug some weird bug with spritesheets a bit ago,
and I didn't like having to manually comment out all of the `fdel()`
stuff in order to help visualize what the potential issue might have
been with the spritesheets on either their DM-side generation or their
TGUI-level display. I decided to add a compile-time level flag that will
automatically copy over any generated spritesheet assets (css and pngs)
to the round-specific `data/logs` folder for analysis when a developer
should need it.
I also had to switch around some vars and make a few new ones to reduce
how copy-pasta it might get and ensure standardization/readability while
also being 0.001 times faster since we benefit from the string cache
(unprovable fact).
## Why It's Good For The Game
It's incredibly useful to see the actual flattened spritesheet itself
sometimes when you're doing this type of work and you keep getting odd
bugs here and there. Also saves headache from having to clear out the
temp `/data/spritesheets` folder every time you comment shit out, as
well as having an effective paper trail for A/B testing whatever
bullshit you've got going on.
## Changelog
Doesn't affect players.
* Config Flag to Save Generated Spritesheets to Logs
---------
Co-authored-by: san7890 <the@san7890.com>
Adds a config-optional endgame chat message (#72860)
This basically does what we do for roundstart announcements, but for
round end.
With a delay between a round ending, the server rebooting, and a new
round starting, sometimes it feels like players would be more likely to
catch a roundstart when they know the previous game has just ended, and
not a few moments before the next one starts.
This idea was suggested to me several times by many people who don't
have good connections to servers and keep missing roundstart because
they just aren't given enough time to get on SS13.
I also included Round ID in this, so people who know what time they've
played a round can also now easily see which round it was, if they
wanted to go back to look at the logs for any reason they have.
🆑
config: There's now a config-optional announcer for a round ending.
/🆑
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Add config to validate admin discord commands with discord links and admin ranks (#73818)
This adds a config to secure discord chat commands used by admins.
When enabled it compares the discord id the chat command came from with
the linked discords db to find their ckey, then checks they have the
correct admin rights.
The check automatically self disables if the db is down or if legacy
admin ranks are enabled. (There is no config for discord account linking
or i'd just use that.)
Moved non-admin discord commands out of the admin modules folder and
into the discord modules folder.
Deleted some defunct shit. There was a global list and admin only notify
command that was used by nothing.
There was a whole discord config section that was used by nothing.
* Add config to validate admin discord commands with discord links and admin ranks
---------
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
* Adds a config option for warning clients about older builds (not just older versions) (#73549)
## About The Pull Request
MSO was being tsundere about this and it seemed useful, so here we go
## Changelog
🆑
config: Added a warning build config setting, you can now lightly
repremand but not block clients with older builds but fine major
versions
/🆑
* Adds a config option for warning clients about older builds (not just older versions)
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Sends a toast notification when initializations complete. (#72465)
## About The Pull Request
Initialization is significantly slowed down by the presence of clients,
though when testing features, you need to join the server. I've been
told that some devs (particularly Mothblocks) are alt-tabbed out of
Dream Daemon while doing dev work, meaning that they are liable to miss
initializations completing, causing an effective slowdown in the dev
cycle. Mothblocks said it would be nice if there was a way to produce a
desktop notification when initialization completes.
I originally intended to add a function to rust_g that would produce a
Windows toast notification with a button allowing you to immediately
launch Dream Seeker. However, I couldn't find a reliable way to detect
if the OS version was Windows 7 or earlier, so running this function on
such an OS would cause a rust panic (which I was told is only a problem
because MSO probably still uses Windows 7).
Fortunately, PowerShell scripts can access the necessary .NET APIs to
produce toast notifications on Windows 10, while also failing more
gracefully than crashing the host process. So I recreated the
functionality I intended in PowerShell.
Toast notifications will only be sent on Windows, if the
TOAST_NOTIFICATION_ON_INIT config flag is enabled, AND there are no
clients on the server.
**Note for downstreams:** If you want the toast notification to have
your downstream's icon, copy it, scale the copy down to 16x16, and
either rename it "tg_16.png" or change that path in the call to
`world.shelleo` to the name of the new file.
Video Demo:
https://user-images.githubusercontent.com/12720844/210492033-963923d7-a1de-4326-9c9f-4f0c0b71d1a5.mp4
## Why It's Good For The Game
This isn't really a line item in the Dev Cycles Initiative, but even if
Mothblocks was exaggerating the benefits, it would still be a
significant speedup in the dev cycles.
## Changelog
No player-facing changes.
* Sends a toast notification when initializations complete.
Co-authored-by: Y0SH1M4S73R <legoboyo@earthlink.net>
* Adds support for non-science techwebs (+Config) (#71070)
## About The Pull Request
This is an expanding of
https://github.com/tgstation/tgstation/pull/69708
Adds a config to not connect machines to a techweb at the start of a
round
Adds the ability to multitool a server to get its techweb in its buffer,
which can then be used on machines to sync them.
Adds support for some machines to not cry when they don't have a techweb
linked to it, in case they actually don't.
If the config to not have machines connected to the science server is
enabled, research servers will make their own techwebs instead. This is
barebones though and would need more work if this option is used.
For misc stuff:
- I replaced checking ``GLOB.machines`` for research servers, to instead
check ``SSresearch.servers``, where we can use ``as anything``.
- Removed unused vars on the RD server control
- I renamed the operating computer's .dm file to remove the capitalized
letter from it. It's now operating_computer instead of Operations.
## Why It's Good For The Game
This is adding support for 2 different cases that can be used in the
future:
1. Off-station roles, we can make roles like Oldstation have their own
techweb so they don't ruin science's efforts, or use their advanced
research to get things we don't want, or even possibly have some
blacklist webs for ghost roles (like teleporters) so that way we don't
need to have this dance where we have to give them a very specific
amount of materials for them to do things while not being able to get a
teleporter and leaving. I heard discussions that people wanted this a
while back, and one of the main things preventing this from happening is
the lack of support. Hopefully this is encouragement to make it a
reality, because I think it would be a really cool expansion of ghost
roles and a good way to prevent them from messing with the round in
progress.
2. Downstreams who want to do different things with Science. Personally
I made this PR with voidcrew(shiptest) in mind and think this would make
their lives easier. I didn't expand too much on this because I'm leaving
up mostly to the downstreams to figure out what they want to do with
these systems.
## Changelog
This generally isn't really player facing, since most of the changes
would only come into effect if the config is enabled??
🆑
fix: Research servers now only show servers connected to their techweb.
/🆑
* Adds support for non-science techwebs (+Config)
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* kill skyrat_wiki var
* OPTIONAL COMMIT: Comment "Tidying"(?) and Description improvements
* config i hope i did these right
WIKIURLSKYRAT IS OBOSLETE AND REMOVED
* hnhbg
* Rocking The Boat, er, Map Vote (#69561)
* Rocking The Boat, er, Map Vote
Hey there,
A while ago, I spooke (typo intentional) to some other people. One frustration I heard was the fact that people would sometimes sneak through map votes during the very start of a shift, during a high-paced portion, or just as a meme. People in OOC would then flood the vote, putting in any given station. However, if a vote happens 10 minutes in- and the round goes for 70 minutes and not many of the original players are around, then it's not particularly fair to those who have to play next shift on a map they bemoan.
So, we can rock the vote! If a player isn't particularly chuffed with the hand they are given, they can poll the players to see if they want to change the map as well. If rocking the vote goes through, huzzah, you get the ability to vote for the map again. If it doesn't go through: tough luck. You can rock the vote one time per shift by default, and server operators can change the amount of times you can call to rock the map vote at their discretion. Calling to rock the vote either successfully or non-successfully counts as a "call", and when that limit is exceeded: no more calls.
Does this mean that we will only rotate between two maps because pissants will keep rocking the vote until they get what they like? Maybe? I still see people bemoan getting Tram or shit the bed over IceBox, but I think enough people get sick of bread-on-butter to take the server where it need to go. If operators don't really like seeing only two maps play, they can always adjust the config to ensure it doesn't happen.
* makes the grammar grammar
it would be "Rock the Vote vote" otherwise
* Rocking The Boat, er, Map Vote
Co-authored-by: san7890 <the@san7890.com>
* Cadaver spawner fixes (#69544)
fix: Fixed a runtime preventing nonhuman cadavers from spawning properly.
config: Cadaver spawners will no longer yell at you when morgue_cadaver_other_species_probability is blank.
config: morgue_cadaver_disable_nonhumans will now properly disable nonhuman races! (It was reversed, woops.)
* Cadaver spawner fixes
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
* Allows non-human bodies to spawn in the morgue at roundstart (#68867)
Adds a configurable probability for the cadavers in the morgue to spawn as nonhuman species.
* Allows non-human bodies to spawn in the morgue at roundstart
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
* Removes log_cloning (#66912)
Right now there is only 1 source of cloning: pod cloning-- and pod cloning is exceedingly rare. I don't think this warrants its own file anymore with the death of regular cloning a few years back.
* Removes log_cloning
* Removes log_cloning
Co-authored-by: dragomagol <66640614+dragomagol@users.noreply.github.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
* Adds MC initialization stages. Earlier stages can fire while later ones init. Fixes tgui chat reconnection banner showing during init. (#66473)
* Adds MC initialization stages. Earlier stages can fire while later ones init.
Removes TICK_LIMIT_MC_INIT config for barely doing anything to speed up init and being inconvenient to work with if fires and inits can happen at the same time.
* Adds MC initialization stages. Earlier stages can fire while later ones init. Fixes tgui chat reconnection banner showing during init.
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
* Gives traitor logging its own config flag (#66148)
Co-authored-by: tattle <article.disaster@ gmail.com>
* Gives traitor logging its own config flag
Co-authored-by: dragomagol <66640614+dragomagol@users.noreply.github.com>
Co-authored-by: tattle <article.disaster@ gmail.com>
* Changes what appears for urgent ahelps to supportmins. (#64748)
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Changes what appears for urgent ahelps to supportmins.
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Amortize the cost of creating preference assets by caching them per git revision on production, reducing best case init times by ~20 seconds (#63503)
Preference asset creation, which while consistently created in early assets, can be requested at any time before then and often is, currently takes about 15 to 25 seconds to produce. Because of extremely hard to reproduce BYOND icon bugs, most of this is done on the same tick.
Lowering the cost of initialization itself is very tricky. Some of it we can theoretically optimize, such as creating humans for antagonists, others we can't, such as the raw cost of icon blending.
Furthermore, adding new icons later down the line would just increase this initialization time even more.
Instead of optimizing the asset creation, which is an uphill battle, this instead chooses to amortize the cost by caching preference assets created per git revision. This means that preference assets will be created, with their long delay, only once whenever the code changes.
This is done on a config, defaulting to on so that production needs no changes, as the whole point of these being made at runtime at all is that it keeps assets/art styles consistent, and PRs making subtle bugs that break preference generation in some way is not uncommon. On development, your git revision will stay the same until you commit, no matter what code changes you make.
* Amortize the cost of creating preference assets by caching them per git revision on production, reducing best case init times by ~20 seconds
* Fixing another conflict :)
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Fixed spelling of possession, separate, and cemetery (#63203)
Just fixes some spelling for gangs. I also fixed misspellings for "posession" to "possession". Fixed "seperate " to "Separate" Fixed "Cemetary" to "Cemetery"
* Fixed spelling of possession, Separate, and Cemetery
Co-authored-by: Doctor Pope <84367152+Dr-Pope@users.noreply.github.com>
* Allows players to send more visible adminhelps when no admins are on, which'll definitely alert admins
* db portion sorted out
* now it really is
* should work about fine
* one last touch
* well, one more
* also botched comment
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Useroth <37159550+Useroth@users.noreply.github.com>
* Adds logging for all Silicon rather than just Laws (#62500)
I find stuffing everything in game.log is a real problem when you need to actually find useful information about what happened to a specific Silicon. It's hard to tell what happened to Silicon throughout a round, even when crossreferencing attack/game logs, so having a Silicon log for all the information related to them would be really useful.
For example, a Cyborg can spawn unlinked on Robocop, go Janitor and crowbar someone to death with a Robodoctor AI. When looking through logs, an Admin can easily assume it was a rogue Engineering cyborg who disobeyed their laws to kill someone.
This also isn't adding a whole new log file, more than it is just renaming the law log file to silicon and adding more useful things into it, so it isn't logging bloat (if that's even a concern)
* Adds logging for all Silicon rather than just Laws
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* Add support for multiple MOTD in config (#61589)
## About The Pull Request
Changes "motd.txt" from being hardcoded to being a list of files which are read sequentially.
CC @ MrStonedOne for config changes
## Why It's Good For The Game
On production, our MOTDs contain several individual sections:
- Active Trial Admin threads
- General game information
- MRP specific information
I want to automate number 1, I want number 2 to be shared among all servers, and I want number 3 to be shared among all MRP servers.
* Add support for multiple MOTD in config
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Give admins the ability to put a popup notice for players in tickets (#61010)
Admins can now give players a popup if they are not responding to tickets.
Popup is cleared when player replies or ticket is resolved/closed.
As more and more of the chat screen is made irrelevant, new players read it less and less.
This means that a lot of new players are ignoring ahelps, which is something I've encountered myself.
* Give admins the ability to put a popup notice for players in tickets
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Adds new config flag to mirror logging of suspicious failed logins to its own file.
* Update IsBanned.dm
Co-authored-by: Timberpoes <silent_insomnia_pp@hotmail.co.uk>
Co-authored-by: Gandalf <jzo123@hotmail.com>
* Drastic Lag Mitigation Subsystem: SSlag_switch (#59717)
Requested by oranges and inspired by the upcoming event. A new subsyetem, non-processing (for now), aimed at providing some toggle switches that can be flipped as a last ditch effort to save some CPU cycles by sacrificing some non-critical mechanics. Below you can see each individual toggle.
Screenshot of the admin panel:
image
Surely there are more opportunities for toggles I missed, but adding new ones is not very difficult at all.
Why It's Good For The Game
Better performance during extreme pop, I hope.
Changelog
cl
code: Introduces the Lag Switch subsystem for when a smoother experience is worth trading a few bells and whistles for. Performance enhancement measures can be togged by admins with the Show Lag Switches admin verb or enabled automatically at a pop amount set via config.
config: Added a new config var: number/auto_lag_switch_pop
* Drastic Lag Mitigation Subsystem: SSlag_switch
* mirrored the changes to the modular file
Co-authored-by: Wayland-Smithy <64715958+Wayland-Smithy@users.noreply.github.com>
Co-authored-by: Useroth <37159550+Useroth@users.noreply.github.com>
* Add $reset directive to config processor for setting a config entry to default value
* Update game_options.dm
Co-authored-by: Bobbahbrown <bobbahbrown@gmail.com>
Co-authored-by: Gandalf <jzo123@hotmail.com>
* Port: fixes of SStimer subsystem from RU SS220 Paradise (#59718)
Unobvious problem spot
#define BUCKET_POS(timer) (((round((timer.timeToRun - SStimer.head_offset) / world.tick_lag)+1) % BUCKET_LEN)||BUCKET_LEN)
With tick_lag equal to 0.1, 0.25, 0.5, rounding of division is normal. But at other values it may be shifted either more or less due to the specifics of floating-point storage and processing. Numbers 0.1, 0.25, 0.5 have blank mantissa, unlike others which lead to numbers such as 245.0000004 when divided.
PS: tick_lag is rounded to the first two decimal places.
Fixes
Rewrote the circular doubly linked list to a regular doubly linked list, because it could cause timers to loop infinitely.
Fixed re-creation of a bucket if the timer does not have a callback.
Added debug stat indicator RST to MC SStimer.
Added optional ability to log dump all timers on crash.
Fixed subsystem logic when a bucket position is misplaced due to division and rounding inaccuracy. The system now captures such rounding errors and restores the correct timer position.
References
[RU] SS220 Paradise port process from TGstation and fixes:
ss220-space/Paradise#5ss220-space/Paradise#10ss220-space/Paradise#26ss220-space/Paradise#32ss220-space/Paradise#37
Contributors
@ semoro: fixes
@ Bizzonium: port
Changelog
cl Semoro and azizonkg
fix: Ported fixes of SStimer subsystem from RU SS220 Paradise
config: Added a new config var: flag/log_timers_on_bucket_reset
/cl
* Port: fixes of SStimer subsystem from RU SS220 Paradise
Co-authored-by: Aziz Chynaliev <azizonkg@gmail.com>
* Implements a new auto-tagging system for ID card which adds a config to auto-flag them as an intern. (#58236)
About The Pull Request
ID cards when equipped will check the player's living hours if the USE_LOW_LIVING_HOUR_INTERN flag is set. If their living hours is less than the first of the following (checked in order from 1st to 3rd until a valid value is found):
Config USE_LOW_LIVING_HOUR_INTERN_HOURS
Config USE_EXP_RESTRICTIONS_HEADS_HOURS
Hardcoded 15 hours
Then their ID card is tagged as Intern Assignment, unless they're a Head of Staff in which case they become an Assignment-in-Training.
PDAs, Wallets and Tablets also update any ID cards they hold, so equipping a PDA, Tablet or Wallet will also update any ID cards inside it.
This occurs automatically, even if the card does not belong to the owner. This only occurs when the user's assigned_role is a station job.
* Implements a new auto-tagging system for ID card which adds a config to auto-flag them as an intern.
Co-authored-by: Timberpoes <silent_insomnia_pp@hotmail.co.uk>
* Sets up ambition logging baseline framework
* That's one line, how did I write it
* Have to rewrite all the logs!
* I don't know what I'm doing anymore
* I think this is the last thing
* Log ambition is now added to config
* Ambition flag now correctly checks for the ambition flag
* Okay /here/ we go
* No more lowercase ckeys in admin chat
* Admin actions are now logged too
* Adds logging to uplinks, spellbooks, and the codex ciatrix (#56450)
* Initial logging
* Bugfix and adds uplink logging to config file
* Another bugfix
* Adds logging to uplinks, spellbooks, and the codex ciatrix
Co-authored-by: TemporalOroboros <TemporalOroboros@gmail.com>
* Added the SQL logging.. waf
* I dont know why CI does not like my sql......
* I think i fixed the sql....
* Attempt #1 to make linter happy
* Shhh linter, it will be over soon
Just breath into this cloth... ignore the chloroform smell.
(Add a Preprocesser statement, to make the SpacemanDMM linter ignore the SQL code in a mob atom obj, that causes it to trigger its hard coded test for stoplag.
This only does not trigger on other SQL, as there is hard coded exception in SpacemanDMM that ignores the other objects. the better fix would be to update SpacemanDMM to add this into the exclusion. but this change at least allows the PR to be merged finally)
Co-authored-by: MissFox <github@aesir.org.uk>
