Inactive Savefiles

ID:175525
 
Apr 10 2003, 12:30 pm
Recently, with all the new users joining Zeta, we have well over 260Mb's of .sav files. I was wondering if there was anyway possible we could code some type of script, to delete inactive .sav files, for instance:

If a .sav file is un-accessed in 30 days, it will delete that .sav file. Everyone I have asked this question seems to have no idea which direction to point me, so I thought I'd take it to the experts.


RaeKwon
Apr 10 2003, 3:48 pm
RaeKwon wrote:
Recently, with all the new users joining Zeta, we have well over 260Mb's of .sav files. I was wondering if there was anyway possible we could code some type of script, to delete inactive .sav files, for instance:

If a .sav file is un-accessed in 30 days, it will delete that .sav file. Everyone I have asked this question seems to have no idea which direction to point me, so I thought I'd take it to the experts.

This is a problem best addressed from the beginning, but I don't think it's too late to fix. You should probably add something to your save proc like this, in the root directory ("/") of the savefile:
F["timestamp"] << world.realtime
You might need to alter your character selection routine to accommodate this, because it would be common to list all directories in F.dir; just skip over "timestamp" when you do so.

Then whenever you want to loop through to check on savefiles, which I suggest you actually only do once a month or so, do this:
proc/PurgeOldFiles()
  var/access
  for(var/filename in flist())
    var/savefile/F=new(filename)
    F["timestamp"] >> access
    if(!access)
      // no timestamp--give it one
      F["timestamp"] << world.realtime
      continue
    access=world.realtime-access   // elapsed time
    if(access>2.592e7)  // 30 days = 25,920,000 ticks
      del(F)
      fdel(filename)

Lummox JR
Apr 10 2003, 3:57 pm
In response to Lummox JR
Lummox JR wrote:
RaeKwon wrote:
Recently, with all the new users joining Zeta, we have well over 260Mb's of .sav files. I was wondering if there was anyway possible we could code some type of script, to delete inactive .sav files, for instance:

If a .sav file is un-accessed in 30 days, it will delete that .sav file. Everyone I have asked this question seems to have no idea which direction to point me, so I thought I'd take it to the experts.

This is a problem best addressed from the beginning, but I don't think it's too late to fix. You should probably add something to your save proc like this, in the root directory ("/") of the savefile:
F["timestamp"] << world.realtime
You might need to alter your character selection routine to accommodate this, because it would be common to list all directories in F.dir; just skip over "timestamp" when you do so.
Then whenever you want to loop through to check on savefiles, which I suggest you actually only do once a month or so, do this:
proc/PurgeOldFiles()
>   var/access
>   for(var/filename in flist())
>     var/savefile/F=new(filename)
>     F["timestamp"] >> access
>     if(!access)
>       // no timestamp--give it one
>       F["timestamp"] << world.realtime
>       continue
>     access=world.realtime-access   // elapsed time
>     if(access>2.592e7)  // 30 days = 25,920,000 ticks
>       del(F)
>       fdel(filename)

Lummox JR

Alright, I'll give it a try in a bit and let you know how it worked.

RaeKwon
Apr 10 2003, 4:22 pm
In response to RaeKwon
I think you might want to try deleting old files manually before you implement this system. Unless each file is 2MB's each, its going to be a little unpleasent when you run PurgeOldFiles() for the first time.
Apr 10 2003, 5:15 pm
In response to DarkView
DarkView wrote:
I think you might want to try deleting old files manually before you implement this system. Unless each file is 2MB's each, its going to be a little unpleasent when you run PurgeOldFiles() for the first time.

Heh! That's for sure. I almost added more to the proc that would keep track of when PurgeOldFiles() was run last, and only do it every week or so, but then doing it daily shouldn't be bad after a month.

But if he's got 260MB's of savefiles, then there's definitely a problem already: The files are storing the character icons, and possibly other extraneous information. Couldn't hurt to shore that up too.

Lummox JR
Apr 10 2003, 5:24 pm
In response to Lummox JR
It's not hard to get 260 megs of savefiles when you're saving information for the number of "people" who play DBZeta.
Apr 10 2003, 5:25 pm
In response to Lummox JR
You just inspired me to (attempt to) make a password style save system like in the old NES days. Naturally it will never allow people to see or enter the passwords, it will just save it too a .sav and load it when needed.
Hopefully it will work out so that the average save file is only a text string of 1kdjkgi3909asdfuio-oiuweroiuasdf932-asdoifuasfdfasdfX
Now I just need to figure out how they worked it so well in Metroid...
Apr 10 2003, 5:33 pm
In response to DarkView
DarkView wrote:
You just inspired me to (attempt to) make a password style save system like in the old NES days. Naturally it will never allow people to see or enter the passwords, it will just save it too a .sav and load it when needed.
Hopefully it will work out so that the average save file is only a text string of 1kdjkgi3909asdfuio-oiuweroiuasdf932-asdoifuasfdfasdfX
Now I just need to figure out how they worked it so well in Metroid...

To do that you basically just need a very very limited information set. In Metroid that amounts to a bunch of bit flags: Which items have and haven't been collected, which doors have been shot out for good, which bosses defeated. Also it needs to know what area Samus was last in; as I recall there are only 4 or 5 of those, and if 4 it can be done with 2 bits.

Lummox JR
Apr 10 2003, 5:43 pm
In response to Lummox JR
What about things like how much ammo and health you have? Just something like how color bands on resistors work could do. Color 1=first number, Color 2=second number, Color 3=amount of zero's. Just as long as big numbers dont need to be very specific.
Apr 12 2003, 9:54 am
In response to Garthor
Garthor wrote:
It's not hard to get 260 megs of savefiles when you're saving information for the number of "people" who play DBZeta.

It now exceeds 400 megs of space. o.0

RaeKwon
Apr 12 2003, 10:11 am
In response to RaeKwon
RaeKwon wrote:
Garthor wrote:
It's not hard to get 260 megs of savefiles when you're saving information for the number of "people" who play DBZeta.

It now exceeds 400 megs of space. o.0

RaeKwon

omg!
Apr 12 2003, 10:46 am
In response to Lummox JR

To do that you basically just need a very very limited information set. In Metroid that amounts to a bunch of bit flags: Which items have and haven't been collected, which doors have been shot out for good, which bosses defeated. Also it needs to know what area Samus was last in; as I recall there are only 4 or 5 of those, and if 4 it can be done with 2 bits.

You also want to add a checksum or players should have no problem comming up with garbage codes :).
Apr 12 2003, 10:53 am
If you're just looking for a short term suggestion (and you have access to the host computer), just open up explorer, go to your saves directory, and choose View -> Details. Click on the Date Modified tab so it sorts by those, and delete all the ones whose modified date is 30 days or older.
Should only take a few seconds to find that one and select the rest before it... so this isn't a really lengthy or hard solution.

Still, it'd be better to code this sort of thing into the game, like Lummox suggested.

-AbyssDragon
Apr 13 2003, 9:05 pm
In response to RaeKwon
RaeKwon wrote:
It now exceeds 400 megs of space. o.0

You need to do some damage control.

One of the reasons your savefiles are so huge is that--I recall from another post in which someone was using some hand-me-down code--you use custom icons. Now I love custom icons and would encourage you to, if anything, use more of them. But they have to be used carefully.

The mistake you made was to create the icon and forget about it. It's easy enough to make, but the problem is clear when you introduce savefiles into the mix: The file gets saved with the icon in it, which is a lot more information than you really need; it's easier to re-create the icon from a set of colors when the character is loaded. During a save, the icon should be removed.
mob/Write(savefile/F)
  ..()
  F.Remove("icon")
Now it's my guess that you probably have no way of telling who chose which colors for their characters. You should have saved that information from the start, but it's too late to get it back now. The optimal solution from this point is to reset all icons and force players to redo them, just once, under a new system that stores only the colors.
mob
  var/red
  var/green
  var/blue
Of course if you have more than one set of colors used for an icon, you might need hair_red, aura_blue, etc. Now here's how you'd use those vars:
mob
  Read(savefile/F)
    ..()
    if(isnull(red))     // if no color data was saved (old savefile format)
      ChooseColors()    // ...force a color change; ask for new colors
      Write(F)          // ...and save the changes
    ApplyColors()       // use loaded colors to build the icon
Eventually pruning out the old files will kill all the files that already have icons (and by the way, you can make the old icon visible as a frame of reference when picking colors again), and forcing a reset of the colors when the color vars are null will cause new icons to be created that won't be saved--instead the colors you set will be saved. In the end you'll have a much smaller set of files.

Lummox JR