Astral Sorcery

Astral Sorcery

63M Downloads

Ridiculous log spam

thephoenixlodge opened this issue ยท 8 comments

commented

Currently whenever I load into my creative structure building world my log is being spammed with the following at a rate of about 10 times per second:

[13:56:27] [Server thread/WARN] [Astral Sorcery]: Failed to load AstralSocery Progress data!
[13:56:27] [Server thread/WARN] [Astral Sorcery]: Erroneous file: ded05476-6356-4fa1-aecc-39bf13105bc7.astral

This is causing quite a bit of lag on this world. I understand it seems to be the result of a corrupted file, which I should be able to just delete, but spamming that much seems a bit excessive and unnecessary

commented

Well, i need to access the player's progress for multiple reasons quite often.
For debugging/information reasons i then print the warning/error seen above to inform that the progress is lost or could not be loaded for whatever reason.
Purging and letting the file recreate itself solves this... You have to re-gain your progress afterwards though.
If this is an issue that consistently happens and can be recreated, please let me know.

commented

Well, i guess i'm gonna close this. - Unless there's a problem that the player research file 'guaranteed' corrupts after a certain course of actions, i'm uncertain what to do.
Will include a built-in 1-file backup system similiar to Thaumcraft's .thaum & .thaumback at some point.

commented

Ok, so how should i adress this best?

The obvious solution is to broadcast this into chat...
So:

  1. For all users VS. only for the user that's affected VS. for all operators
  2. Once at first occurance VS. At least X seconds between each message

The thing that i'd like to avoid here is just moving the "spam" over from console to ingame :|

commented

Well really the problem is that the corruption is only mentioned in the console - the player has no way of knowing it's happened just from ingame, especially if they haven't done anything with the mod. So you end with log spam leading to lag, without indication that that's what's happening. Combine this with the bug in the vanilla launcher, which prevents the log from showing for non-%appdata% instance locations, and you've got an issue that'll be invisible to curse/twitch based players using the native launcher

commented

Here's my proposal:
1- File should be kept in memory, no reopened 10 times a seconds
2- in case of failure, file should be automatically reset
3- upon file reset, a message is sent to the related player (and eventually to all players that are OP or creative)
4- upon file reset, a backup of the file might be kept (through if the error persist it'll cause other issues)

commented
  1. The File is kept in memory after reading it - or rather the useful data the file contained. If it is the process of reading the file that's crashing, what am i supposed to do?
  2. If a read fails your whole progression gets automatically wiped...? I don't think thats a great idea.. What if the file isn't actually corrupted and the data is intact, but the reading process got stopped/interrupted by the filesystem?
commented
  1. keep a default file in memory and overwrite when you need to save. In other words, try to recover from the incident instead of repeating it every tick or so.
  2. the file is already broken when the mod tries to read it, it's better to wipe than kill the server resources with log spams and constant file access. If it's a read error, you can make a backup first so we can send yout he faulty file for investigation.
    If you can't read the file, there's no reason you can write either, so you will only loose progression until the server admin fixes the permissions issues. To be fair, if that happens, chances are the map itself is unreadable, so your player progression is the less of our concern ;).
commented

A built-in backup file handling has been added and it'll attempt to recover through that. If that's not possible it'll copy both files to .lerror files, deletes the old files and resets progression with an empty, 'already loaded' progression which gets written to the player progression file immediately afterwards. The player and currently logged-in operators are informed about this and the console will log its problems regarding the progression load extensively.

I guess this should adress this a bit better.
If anyone of you finds a course of actions after which progression-loss is guaranteed to happen, PLEASE let me know.. Since losing your progression is.. well... not great.