Forums » Suggestions
Errors.log
When developing 3 party plugins and reporting API issues, or reporting bugs, or in-game issues,, we're sometimes asked for more information than we can generally provide.
Also, for our own reference purposes.
I suggest the following:
1) errors.log should create with date/init time in the filename
2) errors.log should have alt name as a prefix
3) errors.log should use gzip compression
4) maximum log retention of n files
5) errors.log isn't an errors log, it's actually a full log, so don't call it errors.log
Therefore: Remen-yyyy.mm.dd.hh.mm.ss.log.gz
Or some variation thereof.
Also, for our own reference purposes.
I suggest the following:
1) errors.log should create with date/init time in the filename
2) errors.log should have alt name as a prefix
3) errors.log should use gzip compression
4) maximum log retention of n files
5) errors.log isn't an errors log, it's actually a full log, so don't call it errors.log
Therefore: Remen-yyyy.mm.dd.hh.mm.ss.log.gz
Or some variation thereof.
can't you just use the systemnotes files to do what you need?
Uhh. No.
Errors.log is the game log file, not a database/save file.
systemnotes are written atomically and are not well suited to incremental or transactional data.
I think you are confused about what I am asking for.
I do not want something I can write to. I want the current errors.log file to be more persistent across client runs, and to have a nomenclature that is easy to reference.
Errors.log is the game log file, not a database/save file.
systemnotes are written atomically and are not well suited to incremental or transactional data.
I think you are confused about what I am asking for.
I do not want something I can write to. I want the current errors.log file to be more persistent across client runs, and to have a nomenclature that is easy to reference.
Remen please remind me, what O/S are you running? I ask because about 10 years ago I had written a simple program to grab the data out of the errors.log and copy it to a sub directory and rename it with beginning and current timestamp in the file name. I dunno if that'd help you, but I could likely dig it up.
99% of the time Windows 10. On rare occasion, Linux and/or Android.
I can write a wrapper script, and would love to see yours... but my preferred option would be for the devs to make it common across the platform for everyone.
I can write a wrapper script, and would love to see yours... but my preferred option would be for the devs to make it common across the platform for everyone.
+1, though compression seems like a needless complication. It's not like we're stuck in the 90s with sub-gigabyte drives. Limiting the number of files retained should be sufficient.
3,4) deletion/compression -> logrotate
5) aye, but renaming dosnt provide anything beside ruining current setups
2) altnames/prefix -> not really a good idea, VO starts before you associate it with a char. so you'd induce coupling.
1) if you are on linux and want to separate errors.log per VO instance, then use this. I created it cause i liked to have 1 log per instance of VO. This should work with multi instances as well.
#!/bin/bash
cd ${HOME}/.vendetta
date_part=`date +%Y-%m-%d_%H-%M-%S`
dest_file="error_logs/${date_part}__errors.log"
mkdir -p error_logs
touch ${dest_file}
ln -f -s ${dest_file} errors.log
./vendetta
5) aye, but renaming dosnt provide anything beside ruining current setups
2) altnames/prefix -> not really a good idea, VO starts before you associate it with a char. so you'd induce coupling.
1) if you are on linux and want to separate errors.log per VO instance, then use this. I created it cause i liked to have 1 log per instance of VO. This should work with multi instances as well.
#!/bin/bash
cd ${HOME}/.vendetta
date_part=`date +%Y-%m-%d_%H-%M-%S`
dest_file="error_logs/${date_part}__errors.log"
mkdir -p error_logs
touch ${dest_file}
ln -f -s ${dest_file} errors.log
./vendetta
Compression: multiplatform support for .gz was meant to include smaller filesystem devices like android tablets, etc. Plus, compressed support is relatively expected for logging devices now. At least I didn't ask for Common Log Format! :-D
I only threw some suggestions out; The actual underlying request was for persistent logs with unique names.
Putting reasons out for why something won't work based on VO internals seems counter productive. I've seen people blather on about why something won't work only to have Ray or Inc look at a proposal and solve it in seconds because they are more intimately aware of how the system works than any moderately-well-informed user.
Again, YES, I realize we can wrap the game and achieve the same results. This is true for a lot of things. I'm asking that a method be solved by the devs that can be supported natively and applies to all users commonly.
Thanks for everyone's feedback.
I only threw some suggestions out; The actual underlying request was for persistent logs with unique names.
Putting reasons out for why something won't work based on VO internals seems counter productive. I've seen people blather on about why something won't work only to have Ray or Inc look at a proposal and solve it in seconds because they are more intimately aware of how the system works than any moderately-well-informed user.
Again, YES, I realize we can wrap the game and achieve the same results. This is true for a lot of things. I'm asking that a method be solved by the devs that can be supported natively and applies to all users commonly.
Thanks for everyone's feedback.