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.
About The Pull Request
I have received exemption from the freeze by Oranges.
This PR was originally done for Skyrat-tg, as a bounty. Oranges took interest and Skyrat people approved taking it upstream so I did. (original PR Skyrat-SS13/Skyrat-tg#9912 )
Features:
This PR adds "field of view" mechanics, which by default don't do anything.
Once you pick up and wear a gas mask you'll notice a cone behind you.
That cone will hide all mobs, projectiles and projectile effects.
HOWEVER... hidden things in the cone (or for people who are blind or nearsighted) will play a visual effect.
The fov cone shadow density can be adjusted
Technicalities:
Originally a component, but by Watermelon's advice I have made this a datumized behaviour instead. (semi-component) This way it is faster, less memory use etc. Once again a component
People have native fov, which can be enabled by a config, by default it's off. (or by an admin verb)
People have fov traits, which add the fov impairings to you, gas masks do that now. All clothes have a support for possibly applying them.
Moves all things that should be hidden onto a new plane which is just above GAME_PLANE, that was we can efficiently filter them out of clients views.
Being dead or extending your eye view (xenobio console) will disable the FOV mask.
This PR was brought to you by Skyrat paying me aswell as rotational mathematics
Why It's Good For The Game
Oranges approves so it's good.
Changelog
cl
add: Gas Masks now limit your field of view
add: Added field of view mechanics. It's darkness can be tweaked by a pref
add: Blind, nearsighted and fov-limited people will now see sounds as visual effects.
/cl
Just fixes some spelling for gangs. I also fixed misspellings for "posession" to "possession". Fixed "seperate " to "Separate" Fixed "Cemetary" to "Cemetery"
It kept on tripping because the RegEx expression was malformed due to an absence of words in to_join_on_whitespace_splits, which caused it to filter out spaces that were at the beginning or at the end of a message, or if there was two spaces one by the other.
Also prevents people from sending a message that's only spaces in OOC, because that's a little silly.
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)
About The Pull Request
This is a fix for map not load anymore because of security changes
Why It's Good For The Game
Maps are good as they encourage gameplay and differentiate ss13 from a classic MUD game
Changelog
cl
add: unit test for map load
add: directory param to map load + whitelist for data and _maps
add: advertising for mojave sun in tg commit logs
/cl
About The Pull Request
In my personal, subjective opinion; trialmins should not, in fact, be able to read and delete server/box configuration files on a whim.
cl
server: Patches multiple(?) arbitrary file related vulnerabilities
/cl
While helping RaveRadbury debug some issues with enabling Halloween species early via the brute force method of enabling them in the config rather than the gentleman's solution of testmerging a PR that changes the Halloween date, we discovered something dreadful.
Cloth golems cannot be enabled! Infact, any species with a space in the ID cannot be enabled.
It uses the splitter despite VALUE_MODE_FLAG being set. So a key entry like ROUNDSTART_RACES cloth golem would get parsed as cloth = golem, then entered into the config as cloth = TRUE
NEW AND IMPROVED PART HERE
I've re-written how keyed_list config entries are parsed, splitting it into a number of procs to do some discrete block of logic.
Based on feedback from MSO, he expected that VALUE_MODE_FLAG keyed_list entries could have elements overridden. However, this functionality was not present in the code.
I have implemented it. We now support 3 methods of setting VALUE_MODE_FLAGS.
Implicitly enable the config entry: CONFIG_ENTRY config_key_goes_here
Explicitly enable the config entry: CONFIG_ENTRY config_key_goes_here 1
Explicitly disable the config entry: CONFIG_ENTRY config_key_goes_here 0
There have been functionality changes too. Previously, everything before the first splitter was the key and everything after was the value. However, in ambiguous config entries (Such as ROUNDSTART_RACES cloth golem 0) it would be unclear if the intent was (cloth, golem 0) or (cloth golem, 0) or indeed if the intent was (cloth golem 0, 1).
As a result, there is now the following paradigm in place: Everything after the LAST splitter is the value, everything before is the key and a log_config warning is now given explaining the problem and showing how it was resolved.
[2021-10-27 19:48:12.840] WARNING: Multiple splitter characters (" ") found. Using "cloth golem" as config key and "1" as config value.
This warning will trigger if multiple splitters are present for any keyed_list config entry, and will trigger on implicit VALUE_MODE_FLAGS entries that have splitters. The example above is it triggering on ROUNDSTART_RACES cloth golem - It has detected that there is potential ambiguity between (cloth, golem) or (cloth golem, 1), has picked a sensible option for the data type and has warned about it.
The intent is that no config entry should be ambiguous. It should be clear what is key and what is value when dealing with keyed_list config entries.
There's probably more work to do on other config entries to bring them up to this standard, but this is the thing I'm hitting in this PR.
Similarly, I have improved the validation aspect of keyed_list config entries with additional logging in general.
[2021-10-27 19:47:53.135] ERROR: Invalid KEY_MODE_TYPE typepath. Is not a valid typepath: /mob/living/carbon/monkey
I have added a unit test to make sure species IDs do not contain splitters from the two keyed_list subtypes relating to species.
I have added sanity checking to the race config subtypes since we have a big dick global list of all races sorted by ID, so a race not existing will fail validation and output a meaningful config log entry.
I have removed /datum/config_entry/keyed_list/probability from the code as it is unused with the removal of all game modes except Dynamic.
The config change necessitated the renaming of all golem species IDs. Doing so and renaming the clothgolem.ts file to match has fixed the broken cloth golem page too.
## 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.
About The Pull Request
Rewrites the entire preferences menu in tgui. Rewrites the entire backend to be built upon datumized preferences, rather than constant additions to the preferences base datum.
Splits game preferences into its own window.
Antagonists are now split into their individual rulesets. You can now be a roundstart heretic without signing up for latejoin heretic, as an example.
This iteration matches parity, and provides very little new functionality, but adding anything new will be much easier.
Fixes#60823Fixes#28907Fixes#44887Fixes#59912Fixes#58458Fixes#59181
Major TODOs
Quirk icons, from @Fikou (with some slight adjustments from me)
Lore text, from @EOBGames (4/6, need moths and then ethereal lore from @AMonkeyThatCodes)
Heavy documentation on how one would add new preferences, species, jobs, etc
A lot of specialized testing so that people's real data don't get corrupted
Changelog
cl Mothblocks, Floyd on lots of the design
refactor: The preferences menu has been completely rewritten in tgui.
refactor: The "Stop Sounds" verb has been moved to OOC.
/cl
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.
Added a lowercase variable to string, string lists and keyed list configs.
Currently lowercase is only TRUE for keyed lists because they have been working like that since 2018. It might be changed to be FALSE by default but it'll take a while looking at the parsed logs for the config entries.
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
added this so that the value of INTERVIEW_QUESTIONS (and subsequently any other string list) can be overridden without much issue by additional config files.
i also changed the functionality of default on config_entry as it seemed to be counterintuitive to have it be set to the initial value of the config_entry. in my opinion this should be a compile-time default, and so i've refactored the code such that default now contains the actual default, and the config_entry_value is set at intialization.
cl
server: Added configs to disable laggy hard deletes once they lag the server too much.
admin: laggy hard deletes only output once per type path.
/cl
closes#58379
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
Refactors dbcore to work off a subsystem if executed async and limits the maximum amount of concurrent async queries to 25.
This has been tested locally on a mysql docker image and there were no crashes (as long as you didn't run it with debug extools) + data was getting recorded fine.
Why It's Good For The Game
May or may not resolve terry crashes, however, each query creates a new thread which takes up 2mb, preventing the game from using that 2mb. This can lead to ooms if they stack up, e.g. due to poor connectivity. This solves that issue.
maintainer note: this did not actually resolve the crashes, but has value anyway. Crashes were sidestepped fixed by finding out Large Address Awareness works
cl
refactor: Refactors dbcore.dm to possibly resolve the crashes that happen on Terry.
/cl
Adds a 2FA system for admins. When a config is enabled, a database storing your last CID and IP will be checked to see if you have connected through there before. If not, you will not be able to admin until you are verified. Verification is done by opening a website (decided by config), which is tasked with updating the database entry, which will then let you reverify.
MSO wants to implement this as a forum page, but the DM-side is completely agnostic to whatever the implementation is, just that it updates the database. This means that it could potentially be some TOTP stuff, even.
If the database is down, a backup file is checked for your most recent verified connection (IP + CID). If you are on this connection, you will be able to connect fine. If the database is down and you are on a new connection, someone with +PERMISSIONS can manually verify you through the Permissions Panel.
We've had repeated attacks of admins getting their accounts stolen, it's time.
* Beep beep gamemode removal coming through
* More cleaning
* More cleaning
* Clean up station_was_nuked
* Station nuke source
* Remove name
* More unused functions
* Remove antag rep, which was unused in dynamic
* Remove more antag rep stuff, which was UNUSED IN DYNAMIC
* Station goals outside of mode
* Remove setup_done
* Remove player lists
* Move some older procs
* Fix simulations
* Attempt to fix this stupid case sensitive bullshit
* Revert "Attempt to fix this stupid case sensitive bullshit"
This reverts commit 8693c02d67602543d7d4b92130a7a32cd973e5bf.
* ???
* Delete icons/Testing directory
* Move station_goals global definition
SDQL spells are spells that execute an SDQL query. This requires a config flag to be enabled in game_options.txt. When enabled, admins with debug verbs have the ability to open a menu allowing them to define all the relevant vars for the spell, including icons and spell requirements.
It also fixes a bug with superuser SDQL queries always runtime if they try to call a proc.
Co-authored-by: Emmett Gaines <ninjanomnom@gmail.com>
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
Removes all /datum/game_mode except dynamic. Eventually, all of mode and game_mode will be removed, and Dynamic will become an ingrained system. Every single other gamemode was unmaintained at best and poisoned other code at worst. Currently all tg servers run 24/7 Dynamic, so the time to act is now.
* Remove gamemode references from age checks
* Monkey
* Remove heretics
* Remove BBs
* Refactor uplinks and remove clown ops
* Remove nuke ops
* Removes and refactors cult
* Remove extended
* Remove and move out meteors
* Removes wizard
* Remove sandbox
* Remove changelings
* Remove traitors
* Remove revs
* Remove gangs
* Remove changing mode and voting for new gamemodes
* get_candidates signature fix
* Summon ERT and NERD in their own panel
* Remove some old unneeded age_check stuff
* Fix old signatures of get_uplink_items
* Use Extended like config for dynamic.json
* Fix discounted gear
It's the second try! (First: #48456)
Drones are little robots inspired by Keepers from the Mass Effect games. With laws to maintain both the station, and their distance from the matters of others, they were a great ghost role that let you fix up the station when you were otherwise out of the round. They were in the game for quite a while, but were abused. The abusive players completely ignored the laws and did whatever they wanted. Being tiny ventcrawlers, this became a huge issue for admins.
I attempted to bring them back, this time with some gameplay restrictions to enforce their laws a bit better. It seemed to go well, but I required headmin approval, and this all happened near a headmin election, so the project died.
Recently, some people have wanted to bring drones back. So, they gave me a ring, and I started a discussion with the admin team to see what other changes they would want in addition to the previous ones.
Here are those changes:
They can't interact at all when close to another being, living or dead
Their binary chat has been removed to separate them from AI and borgs
They can only hold a whitelist of items necessary to do their job
They can only interact with machines necessary to do their job
The drone satchel is gone, and drones now have built in basic tools
They also can't interact in some blacklisted high risk areas
Finally, you must play 40 hours total as a Silicon role in order to play as a drone
Additionally, the drone dispenser is not mapped, and the drones must be researched to be constructed.
Why It's Good For The Game
Drones are a fun way to pass the time, and this time they have a lot less freedom. You can still perform the basic function of maintaining the station, but not without difficulty and tedium. This will allow other station roles to perform much better than the drones, while still letting them chug along at their slower pace.
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.
Done using this command sed -Ei 's/(\s*\S+)\s*\t+/\1 /g' code/**/*.dm
We have countless examples in the codebase with this style gone wrong, and defines and such being on hideously different levels of indentation. Fixing this to keep the alignment involves tainting the blames of code your PR doesn't need to be touching at all. And ultimately, it's hideous.
There are some files that this sed makes uglier. I can fix these when they are pointed out, but I believe this is ultimately for the greater good of readability. I'm more concerned with if any strings relied on this.
Hi codeowners!
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
Fixes included config files not loading, adds an error to catch future instances, cleans up some code and comments a proc
We were passing a list as a filename, which is never good for file loading
## About The Pull Request
So, there on the downstream we've encountered a problem with the security officer slots jumping to 12 every time the round starts, regardless of what we set them to in the configs.
In the configs it says that you can set the coefficients to 0 to disable scaling, and upon investigation, it seems that all the scaling coefficients suffer from similar problem.
https://github.com/tgstation/tgstation/blob/master/config/game_options.txt#L198
the `min_val` in the config entry datums is 1 on each of them, leading to unexpected behaviour
## Why It's Good For The Game
It fixes certain config values leading to unexpected and unwanted behaviour
Changes the references of borg module (type) to model, adds a file for robot declarations and one for model declarations. Basically trying to make the code layout a little more sane.
Initially changed them to 'configurations' but I prefer model; its meaning is closer to module than configuration and avoids confusion with actual config.
This allows you to set this in config, save having to hardcode it
I also fixed a mistake where only one message was changed in the
messaging from the account linking system
Fixed issue brought up by @Cyberboss wherein the new ``str_list`` config type doesn't properly return true after setting the values and as a result has an erroneous error pop up in the config error log.
About The Pull Request
Ports and improves my interview system that has been previously used in the summer ball and toolbox tournament events. Allows for a 'softer' panic bunker, wherein players who fall below the required living time limit can still join the server and be restricted to filling out a questionnaire. Upon completing the questionnaire, the player may be allowed into the server by an administrator. If the application is approved, they get a notification that they will be reconnected and upon reconnecting will have all verbs as they usually would. If the application is denied the user is put on a cooldown after which they may submit a new questionnaire.
Players who are being interviewed (herein interviewees) have no verbs other than those required for the stat panel to function, as well as a verb to pull up the interview panel. Interviews do not persist through restarts, and the ability to join that is granted by an accepted interview is only valid for the duration of that round.
Open interviews are listed under a new 'interviews' tab for admins, which is VERY similar to the existing tickets tab.
Below is what a player who is flagged as an interviewee will see when they join the server. They can do nothing but respond to the questionnaire or leave.
image
This is what an administrator sees after an interview is submitted, they will also see a corresponding message within their chatbox, and an age-old BWOINK when an interview is submitted.
image
The interviews tab, which is similar to the tickets menu. You can open the interview manager panel to view all active (including non-submitted) interviews, queued (submitted) interviews, and closed interviews.
image
FAQ:
What happens if someone submits an interview when no admins are on? It's treated like adminhelps are, the message gets sent to TGS to be dispatched off to configured end-points (like Discord or IRC), and the user is notified that their interview was handled this way.
Can you configure the questions? Yes, in config/ there is now a interviews.txt file in which the welcome message and the individual questions can be set and modified.
Can this be turned on and off during a round? Yes, it can be toggled like the panic bunker. It requires the panic bunker to be raised in order to function.
Can interviewees have further questions asked to them? Yes, if you admin-pm them, which is possible using regular means or a conveniently placed button on the interview UI, they will be able to respond to the message.
Technical details
To use the interview system you must have the panic bunker enabled, this is an additional setting for the panic bunker. It can be set through the PANIC_BUNKER_INTERVIEW setting in config.txt, or alternatively enabled in-game as prompted during the panic bunker toggling process. It also can be toggled on its own using a verb added for this purpose, Toggle PB Interviews found under the server tab. These new actions are included in the logging for the panic bunker. I have also added a reporting stat to the world topic status keyword, which now reports if the interview system is on using the keyword interviews.
As mentioned above, for server operators, configure the questions and welcome message in config/interviews.txt.
Note to maintainers and those with big brains I had to add a call to init_verbs on the stat panel window being ready because seemingly a race condition exists wherein the add_verb of the 'view my interview' verb doesn't cause a refresh of the tabs (and therefore doesn't show the 'Interview' tab) when running in dream daemon but running it directly from visual studio code properly shows the tab. Adding a init_verbs call directly after adding the verb didn't seem to help.
A note for downstreams
If you don't use the HTML stat panel (which may not be a bad thing) then you will have to do some conversion from the HTML stat panel stuff used here to the old style stat panels. It's pretty trivial, but just be aware of that. You can see how I used to use the old stat panels in my PR from the summer ball, here, which should be helpful.
Why It's Good For The Game
This allows for a softer version of the panic bunker which impedes the flow of malicious players while allowing genuine players a chance to enter a round to gain enough time to not be affected by the panic bunker's restrictions.
Changelog
🆑 bobbahbrown
add: Added the interview system, a 'soft' panic bunker which lets players who would normally be blocked from joining be interviewed by admins to be selectively allowed to play.
/🆑
