Intermittent savefile errors and corruption

ID:147820
 
Nov 10 2003, 8:26 pm (Edited on Nov 11 2003, 9:54 pm)
The saving system I'm using works perfectly, except for this intermittent error. Occasionally, when I load a savefile, I'll get an error about a missing savefile directory. I had the good chance to reboot the game (rather than close the DS window, which is what I was usually doing) just before this happened, and I saw this error:

runtime error: Failed to write variable owner to savefile saves/crispy.sav. The value being written was (/client). proc name: Write (/mob/person/player/Write) source file: player.dm,283 usr: Shadow (/mob/person/player) src: Shadow (/mob/person/player) call stack: Shadow (/mob/person/player): Write(saves/crispy.sav (/savefile)) Shadow (/mob/person/player): save() Shadow (/mob/person/player): Logout() runtime error: Cannot read null. runtime error: Cannot execute null.(). Reconnecting... BYOND(334.839) BUG: missing savefile directory .0 (cd=/shadow/.0/contents) runtime error: cannot append to list proc name: Read (/mob/person/player/Read) source file: player.dm,272 usr: Shadow (/mob/person/player) src: Shadow (/mob/person/player) call stack: Shadow (/mob/person/player): Read(saves/crispy.sav (/savefile)) Crispy (/mob/login): selectchar() Crispy (/mob/login): Login()

And it doesn't load the character properly. It does seem to get partially there, though; I'm logged into the character, but at a black screen and with most (or possibly all, I'm not sure) of the vars at their defaults.

The errors occur on the .=..() parts here:

mob/person/player Read(savefile/F) .=..() //ERROR var {last_x;last_y;last_z} F["last_x"] >> last_x F["last_y"] >> last_y F["last_z"] >> last_z var/newloc=locate(last_x,last_y,last_z) if (!Move(newloc)) world.log << "[src] failed Move() to [last_x],[last_y],[last_z]; setting loc directly" loc=newloc Write(savefile/F) .=..() //ERROR F["last_x"] << x F["last_y"] << y F["last_z"] << z

I've never seen these errors before, and I'm frankly stumped as to the cause of them. Anyone?

[Edited to close tags properly. Whoops. =) ]</<></<></<>
Nov 11 2003, 10:20 am
I'm curious why it's .=..(), I always see people using it and have no idea why(haven't bothered to look yet :| ). The DM Guide uses ..() when overwriting Read and Write though, so maybe it isn't needed in this case. O.o
Nov 11 2003, 9:57 pm
In response to Jnco904
The built-in var "." is the default return value of the current proc. So it's taking the return value of the parent proc (..()) and assigning it to the current proc's return value.

It isn't really needed here since Read() and Write() don't return anything, but by now I just do it automatically. It shouldn't hurt; if it does, that's a very wacky BYOND bug. =)

I'm still confused about this, does anyone have an answer?
Nov 12 2003, 9:38 am
In response to Crispy
I was gonna post something else, but then I relized it...

You aren't giving the default procedure the paramiters.

Use ".=..(F)"
Nov 12 2003, 7:44 pm
In response to Yota
That can't be it, because the arguments default to the ones passed to the current proc. Quoted from the reference?

<code>.. proc Format: ..(Args) Returns: The return value of the parent proc. Args: The arguments to pass to the parent proc. This defaults to the arguments to the current proc.</code>

I guess I could try that, but it really shouldn't make a difference.
Nov 13 2003, 9:51 am
In response to Crispy
How does that handle then, sometimes a re-defined procedure may be made with different paramiters.
mob/proc/MyProc(Hi)
  return Hi

mob/player/MyProc(Wee,Hello)
  return ..()

^^ What gets passed to the default procedure there?
Nov 13 2003, 10:37 pm
In response to Yota
The first argument to the proc, I would guess; I'm not entirely sure about that one. I do know that you don't have to specify the arguments in the call to ..(), though; I've done it many times without problems.
Nov 14 2003, 11:51 am
In response to Crispy
Are you actually using the return value? If you are, I would just use return() or atleast specify the arguement just to be sure that isn't the problem. Did you mean to have a directory named .0? If so is that even a valid directory name? I'm sorry if I'm way off track, but I figured I'd throw some suggestions your way. :)
Nov 14 2003, 3:55 pm (Edited on Nov 14 2003, 4:17 pm)
In response to Jnco904
I removed the return value, explicitly passed the savefile back to the parent proc, and added a half-second delay before the mob is deleted and after it's saved. It seemed to help a little, but I was soon getting "orphan savefile buffer" errors and such.

I decided to delete my savefile to see if that made any difference, and it definitely seemed to help at first; except then the player's location, name, and most other properties weren't saved properly, which messed up the savefile quite a lot.

I've tried repeatedly logging in and out on a new, fresh character after deleting my savefile, and it works perfectly - UNTIL I pick up an item, at which point it fails to save correctly. I'll obviously have to mess with this a bunch more.

Jnco - Thanks for the help; random suggestions are much better than no suggestions. =) I think the .# subdirectories (where # is a number) are created automatically by Write()'s default action.

EDIT: Just got this error when logging out after picking up an item. I had no problems before picking up the item.

<code>runtime error: Failed to write variable owner to savefile saves/crispy.sav. The value being written was (/client). proc name: Write (/mob/person/player/Write) source file: player.dm,273 usr: Crispy (/mob/person/player) src: Crispy (/mob/person/player) call stack: Crispy (/mob/person/player): Write(saves/crispy.sav (/savefile)) Crispy (/mob/person/player): save() Crispy (/mob/person/player): Logout() Connection closed. runtime error: BYOND BUG: bad obj runtime error: BYOND BUG: bad obj runtime error: BYOND BUG: bad obj runtime error: BYOND BUG: bad obj runtime error: BYOND BUG: bad obj</code>

(The "bad obj" error is repeated indefinitely until a "<code>BYOND Warning: further proc crash messages are being suppressed to prevent overload...</code>" message occurs)

Then there's a bunch of missing savefile directories in the savefile, and some nice matching "missing savefile directory" errors to go along with them.
Nov 14 2003, 4:44 pm (Edited on Nov 14 2003, 5:00 pm)
In response to Crispy
The obj probably had a potty mouth. :)

Somehow your saving system is trying making directories out of illegal characters(number and symbols). We just have to find out where or why it does this. Do you have any list variables on your mobs that contain a number or symbol?

*Edit
I just found out containing illegal characters is ok, but starting a directory with them isn't. I would have changed "contain" to "start with" but you can't declare a variable to start with one anyway. This may be harder to find than I thought. :P
Nov 14 2003, 8:54 pm
In response to Jnco904
I found the problem! The fact that it only occurred when I'd picked up an item was the key. =)

You see, I have this nifty on-screen inventory system. Each inventory slot is a separate object, which is added/removed to the client's HUD when the player displays/hides their inventory. Each item has a var which refers to the inventory slot object that it's contained in. But here's the killer; each inventory slot object has a var which refers to the client. Neither the inventory slot var or the client var were defined as tmp, so BYOND was actually attempting to save the player's client to the savefile - which it obviously can't do. =)

Thanks everyone!
Nov 14 2003, 9:03 pm
In response to Crispy
Neat, I think seeing this error fixed here will help me with a feature I'm about to include in my current project. Advanced thanks to you. :P
Nov 29 2003, 6:00 am
In response to Crispy
If I may, I'll also thank you in advance! This sort of problem occured a lot on the games I've been working on. This pointer regarding tmp vars might just be the key to that problem.

Once again, I thank thee!

Nov 29 2003, 5:01 pm
In response to Mart2J
Glad to see this thread is doing something useful apart from displaying my own idiocy and wasting server space. =D
Nov 30 2003, 6:03 am
In response to Crispy
Crispy wrote:
Glad to see this thread is doing something useful apart from displaying my own idiocy and wasting server space. =D


Idiocity? Like I thought about that little detail myself... It's not something you always take into account... tmp vars, who would have thought...

In my case, it won't be easy to find which var in particular causes the problem on one of my projects, although I spotted the problem on my second project.

Oh well... *grabs bug-hunting gun*
Nov 30 2003, 11:18 pm
In response to Mart2J
Mart2J wrote:
Idiocity? Like I thought about that little detail myself... It's not something you always take into account... tmp vars, who would have thought...

Well, I should have known better, having run into situations involving vars-that-should-be-tmp-but-aren't before. =)

Oh well... *grabs bug-hunting gun*

Good luck!