How difficult and resource intensive would it be to create something akin to Valve's Source Demo system? I believe how it works is it records all actions taken during the tick and dumps it in the .dem format for later replay and depending on the demo type you can either go about the game world as a floating camera or 'stick' to a certain player.
Reason for this being the ultimate logging tool for being able to investigate more nuanced things from an administrative standpoint that would be next to impossible to log properly.
Aight, seems like itd be a lot easier to do if there was some catchall for proc calls though.
| |
Can't you just use the "try" and "catch" keywords for debugging?
try and catch keywords See also: Error proc (world) throw keyword EXCEPTION macro exception The try and catch keywords are used for error handling. Any code that runs inside of a try block will, if an error happens or the throw keyword is used, stop executing and jump to the matching catch block. (This is also true of indirect proc calls. If you call a proc from inside a try block, any errors in that proc will be sent to the catch.) For every try there must be a catch, even if it does nothing. The catch block takes an optional value that can receive the error. Example: var/a = 2 Because the value in the catch keyword is optional, you can simply use the catch keyword alone. It is also not necessary to include any code under the catch keyword, if the error is meant to be ignored. (However, it is not usually a good idea to ignore errors.) The throw keyword is used if you want to throw an error deliberately. When you use throw, the error thrown does not have to be an /exception datum, but can be anything you like. | |
I'm not necessarily wanting this for bug logging, more for administrating of players. Turns a he said she said that's ambiguous from the existing logging to an admin being able to just watch the event.
| |
Oh, makes more sense now. Babysitting cameras, pretty much.
Yeah, you can experiment with the replay camera. I'm not sure how well it would turn out. The only method I can think of is like I mentioned. You would have to make a log file per player, and then record EVERY (movement, proc calls, verb calls, text being outputted, commands that were inputted, etc. Basically -almost- every line of code in your game would be recorded) and ALL actions (with their corresponding variables) to a log file. Then you would have to read that log file and convert the text into paths/procs/verbs/variables using things like text2path(), params2list(), call(), etc. Keeping note that EVERY action needs to be time-stamped so you can replicate the actions exactly as they happened (that way it doesn't replay one player doing something ahead of the other player). All of this work for babysitting is pretty petty though. I'm sure trying to find a solution that would prevent problems would be more efficient in the long-run (as with experience "moderating" DB Zeta/DBO 1 rips has personally shown). | |
Well outside of the babysitting aspect it can also allow for players to download a compressed version to watch previous rounds if they wish.
| |
Outputting text to a log file isn't the hard part. It's the outputting the text into a replay. I don't see why you can't do this, but I don't see how you can achieve this in-game with great efficiency either. So you'll need a second environment.
Unless someone else has another method. Maybe some sort of webclient/dream-seeker javascript mojo and create a bot /datum that will set it's eye locked onto every individual player, and then using said webclient/dream-seeker javascript mojo record video of the player from the time they join to the time they leave, and then save that video as the player's name and time-frame. Like "Maximus_Alex2003 06-29-15 1:21PM to 5:36PM.mp4" | |
That webclient mojo sounds pretty interesting, i'll look into that.
| |
More effective? Maybe. I don't see any instance where something would be next to impossible to log properly via text as long as you're logging all of the details (vars, mobs, clients, values, etc.).
Essentially you could just create a text record of what is going on, and then replicate that with text2path(), params2list(), call(), world.time and any other relevant proc/vars.
Do you want the replay function to function real-time? Probably not. Make a separate environment specifically only for the replay and pass the text file you generated previously to that. Do you want this to be on some fancy shmancy huge project like SS13? Probably not. You're calling/doing a lot of things for a long period of time in a game like that. The text file would probably reach unnecessary MBs. Just log everything in detail.
Something like this would make a good kill-cam (since we're only talking about taking time-of-death and subtract X time like 20 seconds or even lower like 5 seconds before time-of-death (and then clear the text log-of-actions since anything before is irrelevant. You can even then save this chunk of text as it's own replay to replay various different times/events) if you output the results in a separate map element with screen_objs. I guess you could do the same for your bug-testing, but you'll have to keep a log anyways for when something goes wrong and it requires a replay, but then take that time-of-wrong and subract either time or call()s/vars until you get to the start of whatever went wrong.