Logs' JSON should be standardized (lets just refactor logs ;)

[Chief-Engineer]

Description

The JSON info paired with logs is extremely inconsistent and should be standardized to some extent. Some logs will have info that no other type of log will, but there's a lot of information that almost every log has. When log viewers are able to make use of the JSON data for filtering, it'd be extremely useful for them to be consistent.

This is possible to some degree by just being more consistent with the existing system, and I'll likely do that if we get a way to use the data for filtering, but if we make major changes it'd be better to update logs before putting work into the filtering system.

Refactoring the log format entirely may better serve the goal of this better than modifying the existing system.

Information logs should have

• Tools: What things were used in the creation of the log?
• Direct cause: What thing most directly resulted in the creation of the log? This will often be a player, but may be something like a remote signaler.
• Cause player: Which player most directly resulted in the creation of the log? It may be ideal to provide this by referencing earlier causal logs in a chain whenever "direct cause" isn't a play until getting to a point where "direct cause" is a player.
• Fault: What is at fault for the log being created? Typically this will be the same as "cause player". An item being sabotaged is an example of when it would be a different player, it would be the player that sabotaged the item.
• Subject: Who/what is the log acting on?
• Action: What is actually happening and what changed?
• Supplemental info: It would be very useful to have access to item specific information like the contents of pills, beakers, air tanks, etc. in every log where they appear, especially for searches, but it'd probably be very difficult to do this without saving lots of data into logs that would rarely be used in each log. Types of searches this would be useful for:
  • When did player X first have something with potassium in their possession?
  • Which logs contain items with both chlorine and fluorine?
  • Did player X ever have possession of an ID with captain access? If so, which ID and when?

Possible fields

This list was made before "Information logs should have", which I added about a week after making this issue.

• Actors: List of entities directly responsible for the logged action. In most cases this will be a single entity, but there may be cases where there are multiple.
• PlayerActors: List of players "directly" responsible for the logged action. In most cases this will be the same as Actors, but sometimes, particularly with triggers/remote signalers, a chain of events can form where the player would not fit the description of actor well, but could still be passed through the events to be recorded in the log.
• Tools: List of entities used by the actors. In a hit log, the item used to hit would be a tool. In a wire pulse log, the multitool would be the tool. There is probably a better name for this. There may be a better way to store this, like with each actor, but being able to filter by tool needs to be considered.
• Subjects: List of entities directly affected by the logged action. In most cases this will be a single entity, but there may be cases where there are multiple.

Additional thoughts

There's a lot that needs to be considered here:

• Connecting Data: Having a standardized way to describe the solutions in a container that's involved in a log would be useful, but some logs involve multiple containers so admins need a way to tell which solution is in which container.
• Filtering: Admins should be able to filter based on as many criteria as possible. For example, for logs containing both plasma and water reagents. Filtering shouldn't rely entirely on searching string descriptions of the log.
• Flexibility: A wide variety of actions need to be logged, the system should be flexible enough that future logs can be integrated without issues.
• Human Readability: Data that is easy to filter is not necessarily easy to read. After applying filters, admins shouldn't need to read each log's entire json to determine what the log is saying. Text summaries can be specified for each log, but with the amount of information include in the log data, it'd be ideal if the text descriptions were made in a way that'd allow admins to configure them while browsing them. For example, admins could choose to have each mention of a solution container in the logs they're viewing show the contents, or each mention of a damageable entity show its current health.

[juliangiebel]

Web logs already makes use of the json for adding the player name and "not yet implemented" linking to player pages.

The text search indexes the json instead of just the message already (which is a bit wack but it works)

I agree with this issue though

[Chief-Engineer]

I knew that weblogs could access the data but didn't realize it also looks in it during the search