I keep Debug Mode on to get more information during run times, but this one doesn't give too much information. I'm not entirely sure why it occurs, but it goes on for a while and then, at least in one instance, crashed Dream Daemon itself.

Could it be extremely old save files? Or is the above flawed in some very real way?

I keep Debug Mode on to get more information during run times, but this one doesn't give too much information. I'm not entirely sure why it occurs, but it goes on for a while and then, at least in one instance, crashed Dream Daemon itself.

Could it be extremely old save files? Or is the above flawed in some very real way?

Well, i found this a while ago in an old demo i once used for a game, i hope it would be some use to you.

You defined a var, F which isn't the problem, otherwise it wouldnt have compiled. the new() proc is fine but the var thats being created with new() could be anything. So if you showed me what it is, I'll take a look at it and go from there.

It's very old code, but the weird thing is that this is happening to keys on which people have never joined the game. I changed the code around a bit for the loading, but it seems it's still sticking around;

client/New()var/savefile/F = new(Import()) // This is now the line that gives the error.if(F) F["usr"] >> mob //read the player's mob ..()

Your old implementation (the one from the DM Reference) was better. <_<; Anyway, try adding in debug info, as it should technically work. Looks like you're not getting a correct value from Import(), try and check what it is:

var/savefile/F = src.Import()if(F)

src << "isfile([isfile(F)]) value:{[F]}"else src << "no savefile"

If all is well, you should get an output like this:isfile(1) value:{savefile_name_or_path}"
Not sure about how isfile() actually handles this, it should detect this file like any resource file and return 1 (if all's well) but for the other value, it can be normal to get a path to the BYOND program directory's cache folder.

Here is said debug information for the past twenty minutes. It's weird. The 'isfile(1) value:{36649.sav}' are all legitimate log ins, and you'll notice that we get 'isfile(1) value:{}' just before the procedure crashes.

Weird indeed, it's a resource file but it seems it may be invalid. Do you have access to the savefile in question that triggers this (ie get the physical file manually and check it out instead of trying to get it from Export())? Perhaps indeed it's an old one generated some time ago, and is corrupted in one way or another. You could verify its contents by quickly using the savefile's ExportText() proc.

Unfortunately, I do not, and I no longer suspect old save files to be the case simply because these keys are not ones which have had access to the game, nor saved a file inside of it. That was clarified to me yesterday when someone who was having trouble logging in could not connect to the game with a key they had just recently made.