'home' command fails

[lokkje]

One night I log off, leaving one of my creators to his own devices. The next morning I get a message saying "i broke my workroom", and when I try to "home makaela" I get this:

Code: [Select]

--- ChaosRealmReborn
2011.06.26-17.01,12
*Value being indexed is zero.
Object: /secure/daemon/players at line 723

'<fake>' at /secure/save/creators/l/loki (/<driver>) at line 0
'cmdAll' at /secure/save/creators/l/loki (/lib/command.c) at line 231
'cmd' at /secure/cmds/builders/home at line 55
'unguarded' at /secure/sefun/sefun at /secure/sefun/security.c:104
'apply_unguarded' at /secure/daemon/master at line 606
'CATCH' at /secure/daemon/master at line 606
'<fake>' at /secure/cmds/builders/home (/<driver>) at line 0
'(: <code>($1), "makaela" :)' at /secure/cmds/builders/home at line 55
'GoHome' at /secure/cmds/builders/home at line 24
'GetHomeRoom' at /secure/daemon/players at line 723
Trace written to /log/catch

--- ChaosRealmReborn
2011.06.26-17.01,12
**Value being indexed is zero.
Object: /secure/daemon/master at line 608

'<fake>' at /secure/save/creators/l/loki (/<driver>) at line 0
'cmdAll' at /secure/save/creators/l/loki (/lib/command.c) at line 231
'cmd' at /secure/cmds/builders/home at line 55
'unguarded' at /secure/sefun/sefun at /secure/sefun/security.c:104
'apply_unguarded' at /secure/daemon/master at line 608
Trace written to /log/runtime

Now I have no idea what he did, and neither, apparently, does he. Can anyone help me solve this issue? The workroom is working perfectly now, and I get this error when I try to access any other workroom via the home command, except my own. I'm at a loss as to what to do to fix this. Any help is, of course, much appreciated!

[Nulvect]

Alright, let's run through this.

• Open up /secure/daemon/players.c in ed or your favorite text editor if possible.
  
• Go to line 723. In ed, you just type 723 to go there.
  
• "*Value being indexed is zero" indicates an array or mapping is zero, or unset, at a place it's being used, so look for some [square brackets].
  
• I see this: ret = tmpmap["homeroom"];
  
• Ok, let's see how tmpmap is set... look upwards until you find tmpmap = something.
  
• The line directly above it: tmpmap = GetPlayerData(name, "Paranoia"); Note that "Paranoia" is being passed literally for some reason.
  
• Let's find this function. In ed, you can search by turning on line numbers (type set number) and doing this: g/GetPlayerData/p
  
• I find it on line 628. It returns a variable called "ret", so let's find how "ret" is assigned by starting from the bottom of this function and going up.
  
• We've got these lines:

Code: [Select]

   unguarded( (: LoadPlayer(gplayer) :) );
    ret = GetPlayerVariable(val);
    RestoreObject(SaveFile);
    return ret;


• The 'val' variable is "Paranoia", still not sure why. It's important to note that this daemon is loading the player's save file into itself. This just gives it access to all the variables you'd have in, say, player.c. So now we look for the GetPlayerVariable function.
  
• This function is right above the one we were in. There are two places where it returns. The first one:

Code: [Select]

   if(member_array(val,variables(this_object())) == -1){
        //write("No such player variable exists.");
        return ret;
    }


• This could certainly be it. So 'val' is still "Paranoia" - it's a variable name. If this variable doesn't exist, it will return 'ret' before ever setting it, so it will be 0.
  
• The second return is this:

Code: [Select]

   ret = fetch_variable(val);
    return ret;


• I had to look up fetch_variable(). It just returns the value of the variable named in its argument, still "Paranoia". So Paranoia could exist but be 0 for some reason.
  
• A search in the daemon reveals no Paranoia variable. I find the player.c file in the mud's /lib/ dir and run a grep (from a command line) on all files in that directory like so:

Code: [Select]

$ grep Paranoia *.c
creator.c:    if(ret && GetParanoia("inventory_monitoring"))
creator.c:    if(GetParanoia("move_monitoring")){
interactive.c:private mapping Paranoia = ([]);
interactive.c:    Paranoia = (["homeroom" : user_path(GetKeyName(), 1)+"workroom"]);
interactive.c:mixed GetParanoia(string str){
interactive.c:    if(Paranoia[str]) return copy(Paranoia[str]);
interactive.c:mixed SetParanoia(string str, mixed val){
interactive.c:    Paranoia[str] = val;
interactive.c:    return copy(Paranoia[str]);
interactive.c:    if(ret && GetParanoia("inventory_monitoring")){
interface.c:    if(this_object()->GetParanoia("cursefilter")){


• Looks like it's in interactive.c and holds, among other things, the "homeroom" value that we were looking for way back on line 723 of /secure/daemon/players.c.
  
• Taking a quick look in interactive.c shows me that the Paranoia = (["homeroom": ... line is inside create(). So it should be getting set automatically every time you log in.
  
• So you should check and make sure you still have that variable in your /lib/interactive.c file. Ask your creator if he changed anything in that file, /secure/daemon/players.c, or the home command itself. Ask him how he was changing his workroom. Try using the call command to run GetParanoia("homeroom") on him and yourself (call me->GetParanoia("homeroom") I believe).
  

I hope this helps you with your immediate issue and your debugging processes in the future. Note that this was done with Dead Souls 3.1a11, things may be slightly different on other versions.

[Raudhrskal]

Paranoia modes are things that you can turn on to be notified when, for example, someone else is "sneaking" some nasty invisible object into your inventory.

But yeah, sounds like a problem in his player savefile, having dropped that variable.

In such case, you probably could somehow set it on him manually, by editiong the .o in worst case (backup first!).

Orrrrr... make the actual code more robust, but checking if the mapping is valid, and if it's not making some error-handling ordefault-fallback code execute instead of erroring out.