Can't open save?

Page: 1 2
ID:141730
 
Nov 28 2008, 7:45 am
Code:
mob/verb/show_world_sav()
    var/savefile/S = new("saves/world.sav")
    usr << S.ExportText("")


Problem description:

When I try to open a previously modified save with that verb, it will return nothing. Is it possible that the save is already being accessed and can thus not be opened again? Otherwise, it would have to delete itself for some mysterious reason.
Nov 28 2008, 7:49 am
Doesn't ExportText() require a valid directory to export from? "/" at the least, I think.
Nov 28 2008, 9:44 am
In response to Xooxer
Xooxer wrote:
Doesn't ExportText() require a valid directory to export from? "/" at the least, I think.


ExportText proc (savefile)
See also:
ImportText proc (savefile)
Format:
savefile.ExportText(path=cd,file)
Args:
path: the path to export
file: optional file to write to
Converts all or part of a savefile to a human readable text format, similar in syntax to DM. If no file is specified, the savefile text is returned as a text string instead of being written to a file.

The following example shows how to export and later import a savefile. The user's mob is written into a directory with the same name as their ckey and the result is written to a text file.

Example:
 
[file2text(txtfile)]



Taken from the refrence, so yeah, it does.

Nov 28 2008, 10:19 am
In response to Xooxer
"/" works, thanks!
Nov 28 2008, 10:44 am
In response to CIB
Ok, here I have another one

        var/savefile/World = new("saves/world.sav")
        World["GMList"] << GMList


GMlist is of type list. This will somehow write to a list called "." but not modify the list "GMList" at all. Any idea what this "." thing is and what might be causing it?
Nov 28 2008, 11:06 am
In response to CIB
What are you trying to do?
Nov 28 2008, 11:27 am
In response to Xooxer
I'm trying to write GMList to the save. When exporting the text from the save, it will contain a field called "." holding the data that should be written to the field "GMList".
Nov 28 2008, 11:31 am
In response to CIB
Almost sounds like you're not exporting the whole savefile, just the current directory, which would mean . is referring to GMList. Can you pull the list back out with World["GMList"] >> GMList ?
Nov 28 2008, 11:36 am
In response to Xooxer
Yep, that's it. According to the reference, the path argument defaults to the current directory. If you're not including an explicit, or relative, directory after writing to the savefile (which I assume changes the current directory to the one written, so cd=GMList now, which is reflected by the fact that the current directory variable (.) refers to the contents of the GMList.) then it's going to use the current known directory, which is now GMList.
Nov 28 2008, 11:39 am
In response to Xooxer
Pulling back from GMList will load the actual GMList field, not the "." field, thus restoring GMList back to the save's state.
Nov 28 2008, 11:40 am
In response to CIB
"." isn't a field, it's a variable that refers to the current directory in the svefile. In this case "."="GMList".
Nov 28 2008, 11:46 am
In response to Xooxer
OK, so just, where do I specify that path?
Nov 28 2008, 11:48 am
In response to CIB
In the ExportText() proc. You could probably just move up one level, "../" should do it.
Nov 28 2008, 11:56 am
In response to Xooxer
Sounds reasonable, but using the path ".." or "../" instead of "/" will not change anything. Also, I'm only using ExportText for debugging, the actual problem is the data written to ["GMList"] not being readable from there again. I'll try changing the order in which things are saved and see if changes anything.
Nov 28 2008, 12:01 pm
In response to CIB
There is no problem. Don't change anything. The problem is you're using ExportText() incorrectly in this situation. Your saving system is fine. It's your debug that's wrong. It's a problem of not first verifying your debug code is working as expected. Test your tests before using them to test your game. :P
Nov 28 2008, 12:01 pm
In response to CIB
Interesting. Whichever list I save first, gets written to . or the current path itself, as you pointed out, while the rest will get written properly. Maybe I should specify the writing paths differently, something like "./GMList" instead of just "GMList"?
Nov 28 2008, 12:02 pm
In response to CIB
NO. "." is also changing with each save. It *is* the current directory, not a directory itself.
Nov 28 2008, 12:05 pm
In response to Xooxer
Well, duh. There doesn't seem to be anything wrong with my test. Changing the order will not only make another list appear to be written to the current directory, it will also fix the bug I had with that list, when I'm not using ExportText at all.
Nov 28 2008, 12:08 pm
In response to Xooxer
I know, I'm just saying that whichever list I save first, it will get written to the current directory instead of the given subdirectory, which I want to avoid.

Also, that current directory appears to be the top-level directory, otherwise it would change depending on the field I'm writing to first. Also, there doesn't seem to be a higher-level directory, since "../" does not work.
Nov 28 2008, 12:11 pm
In response to CIB
... Your posts thus far have made it pretty clear that your tests are not correct, because you're expecting them to return something they won't, because you're not seeing that the current directory is the directory you just saved, and that the default path argument is the current directory. The savefile's cd variable is changed when you saved the list. ExportText() uses cd as the default value of the path argument. When you save, the current directory changes. Changing the order of saving should have no effect here on the savefile itself. You never mentioned any bugs without the ExportText() calls.
Page: 1 2