Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
ChangeTeam not logged in siege #945
No worries, understood.
Would overhauling the logging system be out of the question if I was to commit something like that?
These logs are seriously dated in their format (breaking up rounds with "\n-------------\n" ect) and the lack of a plugin api makes it sometimes the easiest way to interface with the server.
I don't mind committing some time to reworking the logs with more meaningful things and removing unnecessary stuff if it's something that would be accepted.
Not sure if there's a valid reason we're sticking to the old quake 3 log format, or just nobody got to revamping it.
There has been talks about it. Issue is there are several programs used to scan the console + logs for information. Changing the format in any useful way would make these programs useless.
Perhaps this should be brought to a community discussion at JKHub. If the decision is made to adopt a new format we can start talking about how it would look like.
I think data/event oriented logging (non-informational) should be moved to an external stream ideally. I'd suggest prefixes for discriminating, but then you open the can of worms called "multi-line messages".
Yeah that was my concern....
Instead of forcing a change like that then, we could always introduce a new log format, that can be turned on or off via a cvar. So it can be used in conjunction with the old format or replace it based on the server operators requirements.
Then perhaps overtime mods would update to support the new format and in a few years the legacy log format could be totally removed?
I think part of the reason for it is because of the way team switching and such works in siege.
Yes it is not good to avoid the log, but at the same time, but it could lead to log spam.
Legacy mods will unfortunately never go away, including base too. Since the majority of mods used are not maintained or are closed source that becomes an issue.
That's true, so I guess the best course of action is to add a new log format that can be used in tandem.
UserInfoChanged, results in log spam this shouldn't be half as bad as that. I'd rather have a little spam and the information and none at all to be honest.