Use Regex to be smarter.
<!-- 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
Public logging finds ckeys via regex to remove them from lines now. Not
used for player say, at the moment. Not needed there either, as ckeys
are only used by key_name() and thats passed down as a string. rather
than just edit every instance of the proc, ill just regex them out by
adding identifiers into the ckey blocks in logs and snip them that way.
<!-- Please make sure to actually test your PRs. If you have not tested
your PR mention it. -->
## Why It's Good For The Game
Public logs are little more private. We want them only to have
characters, no keys.
## Proof Of Testing
<!-- Compile and run your code locally. Make sure it works. This is the
place to show off your changes! We are not responsible for testing your
features. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
refactor: public logging uses regex for cases of mechanics now.
/🆑
<!-- 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. -->
<!-- By opening a pull request. You have read and understood the
repository rules located on the main README.md on this project. -->
Co-authored-by: Waterpig <49160555+Majkl-J@users.noreply.github.com>
* Moves as many db related date/time operations to the db side to avoid byond bugs with dates and times.
* Update blackbox.dm
* SQLtime to ISOtime
---------
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
Co-authored-by: SpaceLoveSs13 <68121607+SpaceLoveSs13@users.noreply.github.com>
* Adds handy define that enables the most common configuration of reftracking (#82860)
## About The Pull Request
This shit has confused people too many times, let's give them an easy
pathway to use reftracking
Also split the separate logging bit into its own thing
* Adds handy define that enables the most common configuration of reftracking
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
<!-- 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
Gives the players a redacted version of the logs, ckeys filtered out for
public logging purposes.
<!-- Please make sure to actually test your PRs. If you have not tested
your PR mention it. -->
## Why It's Good For The Game
You can prove your cases in ahelps and appeals, reports, easier.
## Proof Of Testing
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
admin: added public log folder, and logging.
/🆑
<!-- 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. -->
<!-- By opening a pull request. You have read and understood the
repository rules located on the main README.md on this project. -->
---------
Co-authored-by: projectkepler-RU <99981766+projectkepler-ru@users.noreply.github.com>
Co-authored-by: Waterpig <49160555+Majkl-J@users.noreply.github.com>
* Handles Log_Globally Being True When Log Type is LOG_VICTIM (#72643)
## About The Pull Request
Victim procs would cause a [runtime, click on me for a link to the
runtimebus
entry](https://runtimes.moth.fans/runtime/Invalid%20individual%20logging%20type%3A%20524288.%20Defaulting%20to%204096%20(LOG_GAME).%20(code%2F__HELPERS%2Flogging%2F_logging.dm%3A120)_______%2Fproc%2F_stack_trace)
when you tried to put a victim log in globally. This was the runtime
error for future reference, via
https://tgstation13.download/parsed-logs/manuel/data/logs/2023/01/06/round-197717/runtime.condensed.txt
-
```
The following runtime has occurred 3155 time(s).
runtime error: Invalid individual logging type: 524288. Defaulting to 4096 (LOG_GAME). (code/__HELPERS/logging/_logging.dm:120)
proc name: stack trace (/proc/_stack_trace)
source file: stack_trace.dm,4
usr: 0
src: null
```
`524288` is the bitflag for `LOG_VICTIM`.
I added in a custom error message for passing in LOG_VICTIM without
adding log_globally just so that we can pick up on it faster without
having to look up the bitflags. I think I prefer it failing loudly as
opposed to just returning, so that people can much more easily pick up
on this behavior being a wrong one. The pattern across the codebase
prior to this PR was pass in log_globally as false along with LOG_VICTIM
in the args to `log_message()`, so I decided to enforce doing that in
this PR. Alternative fix could be to just early return on LOG_VICTIM,
but that would leave a larger footprint and might be better suited for a
different PR, preferably after this one at least gets all of our ducks
in a row.
## Why It's Good For The Game
runtimes bad, actual logging of important stuff good.
apologies if i screwed up how LOG_VICTIM is meant to be used, but
something is definitely wrong and should be addressed. i'm pretty sure
victim logs are only done in addition to a proper log that gets sent
globally, and this is good just for visibility?
## Changelog
Nothing that players would notice.
* Handles Log_Globally Being True When Log Type is LOG_VICTIM
Co-authored-by: san7890 <the@san7890.com>
* Increases the list nesting by one on log entries for the mass insert log
* Updates the name of the time column because of course I had to get it wrong :)
* Adds a new config entry for SQL game log bundle query size
Also adds documentation to existing config entries that don't currently appear in any default entry files on the repo.
* Adds a new config file for database-related configs for Skyrat
* Adds a `add_log_to_mass_insert_queue` proc to handle bundling insert queries into bigger, less frequent queries
* Modifies log_message() to utilise the new add_log_to_mass_insert_queue() proc
* Actually makes the MassInsert() call asynchronous, to completely remove the freezes
* Adds code to handle sending all unsent logs to the database before the subsystem is shutdown, to reduce the loss of logs at the end of a round
