## About The Pull Request
Was just scrolling through the Paradise github since they seem to have
more work done for 516 to see if there's anything I can port over, found
this and thought why not.
Ports parts of https://github.com/ParadiseSS13/Paradise/pull/25105
Specifically, updaing all hrefs to use the internal ``byond://``, and
adding it to grep.
## Why It's Good For The Game
More work towards 516.
## Changelog
Nothing player-facing.
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>
## 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
<!-- 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>
## About The Pull Request
On the tin, we just record the `type` of the item that the human may be
holding while they try and commit suicide with it. Useful for knowing
what people are:
A) killing themselves with
B) trying to kill themselves with
i just think it's neat data
## Changelog
doesn't matter
## About The Pull Request
Closes#79969
In administration, things shouldn't be _required_ to have unique names.
I think that searching by ckey/key in logs should still work fine but I
can see the value in having the mob tag (which is also exposed in places
like `debug.log`, and in public spots too like `hallucinations.html`)
being added with all this data for even more trimming if you wanna find
all the rule-breaking stuff someone does as a very specific mob.
Anyways, the player details datum tracks both the name as well as the
mob tag in an associated list that we can access in order to do work
with it in stuff like the player panel.
We do this by the following
* Rework the player details list to be associated, as well as updating
all instances of the proc that sets this list.
* Make the code for handling duplicates a bit more explicit so it
actually works.
* Make the formatting in the player panel better as well.
* Also add the mob tag information to wherever we might need to log it
via a new proc `key_name_and_tag()`
* Also adds this information to the per-player player panel
## Why It's Good For The Game
Better administration tools, should be more helpful when it comes to
filtering as well as post-mortem cross-comparison for coders in order to
find out exactly _which_ mob was problematic when looking at debug.log
or whatever you may have.
```txt
[2023-11-28 01:25:37.434] GAME-SAY: San7890/(Katie Yossarian) (mob_2759) (DEAD) "deez nuts" (Primary Tool Storage (138,140,2))
[2023-11-28 01:25:39.478] GAME-SAY: San7890/(Katie Yossarian) (mob_2759) (DEAD) "as big chungus" (Primary Tool Storage (138,140,2))
[2023-11-28 01:25:40.617] GAME: *no key*/(Katie Yossarian) (mob_2759) *no key*/(Katie Yossarian) is no longer owning mob Katie Yossarian(/mob/dead/observer) (Primary Tool Storage (138,140,2))
[2023-11-28 01:25:40.618] GAME-ACCESS: Mob Login: San7890/(Katie Yossarian) was assigned to a /mob/living/carbon/human
[2023-11-28 01:25:40.624] GAME: San7890/(Katie Yossarian) (mob_2760) Client San7890/(Katie Yossarian) has taken ownership of mob Katie Yossarian(/mob/living/carbon/human) (Primary Tool Storage (138,140,2))
[2023-11-28 01:25:42.305] GAME-EMOTE: *no key*/(chasm lobstrosity) (mob_88) chitters. (Lavaland Wastes (126,178,3))
[2023-11-28 01:25:42.435] GAME-SAY: San7890/(Katie Yossarian) (mob_2760) "i hate it here" (Primary Tool Storage (138,140,2))
[2023-11-28 01:25:43.058] GAME-COMPAT: ADMIN: San7890/(Katie Yossarian) admin ghosted.
```


this was taken over three rounds ignore discrepancies
i'm rather fond of having this information in the per-player panel
because otherwise you need to
A) scroll through the F6 window until you find your match
B) pull up three different VV windows
## Changelog
🆑
admin: The Player Panel should now contain the unique mob tag associated
to a certain mob that a player might inhabit at one time, which is
stored on their player details datum on their client (which is
guaranteed to always exist).
admin: The "Old Names" details of a player is now visible in their own
personal per-player player panel.
/🆑
## 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>
* 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>
## 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.
* 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
* Begins refactoring admin pms, with a focus on runtime safety and ease of understanding
There's more I want to do here, mostly with spans and cleaning up sone
logic flow to be easier to understand
The primary thrust of it is making explicit any assumptions we make about values
This is important because this is sensitive code, and runtimes are not acceptable, since they both leak information and could lead to dropped ahelps, which is almost worse.
I'm also splitting the proc up into subsections, in an attempt to make it easier to reason about and work with
As a side effect of this, some operations need to be done more then once to avoid potential debugger escalation.
Related to this, I'm also no longer directly passing around client references through the procs. I instead pass the result of a pretty basic proc into each, to avoid issues with sleeping and such.
Oh, and I fixed a bug that made it impossible to reply to remote ahelp
responses. I hate this place.
* Converts all uses of the linkify span to a macro. One of these doesn't have a closing span, not sure if that's a bug or a feature
* Cleans up more logic embedded inside data, since this is critical code
Changes the backup for replying to someone who logs out, instead of
using the first person to send something to the ticket as our backup, we
use the recipient's ckey.
* some cleanup
* Converts a few more things over to the pattern
Reorganizes and deocuments sends_adminpm_message to be less hard to
track/read
* Cleans up a hanging proc that needed filtering
* Does a passthrough over tgs, makes stealthmin keys actually unique
* cleanup, screed at the top of the file
* cleanup, comments, etc
* Thanks trash, I can in fact not spell
* ok yeah I really can't spell
* updated comment to explain how code works
* messsage -> message spellcheck
* Nullchecking prevention
if for whatever reason someone in the future adds code that lummox says can sneakily allow for Logout() to execute between this and the last time client was checked, this could potentially runtime without nullchecking
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* put logging procs into their own files
* Moving more procs into their own files
* Moving talk
* The last of the logging
* ticks shuttle.dm
Co-authored-by: tattle <article.disaster@gmail.com>