First of all, I understand there's the $loadmethod$ funtion, and it has two values, but how are thing saved? Nowhere can I find this explained, not even in the 4.0 Tutorial.

I made a very simple test to learn what can be saved:

-------------------
if flag "Name" not set then
print "What is your name?"
enter next command into "Saved_Name" string variable
set flag "Name" on
-------------------
print "Your name is #Saved_Name#"
-------------------

How do I use $loadmethod$ to record:
If the flag "Name" is set?
The name of the player in #Saved_Name#?

And what kind of stuff can be saved (variables, flags, anything quest.x)?

You don't need to worry about what is saved - everything is saved when you save a game.

In your example, if the player saves the game after entering their name, then the next time they load that game (from their QSG savegame file) the Saved_Name string variable will contain their name, and the "Name" flag will be set.

You use $loadmethod$ to determine whether the player loaded the game from scratch, or if they loaded from a QSG savegame file. This used to be useful in your game start script - you could check this function to determine whether to show a long intro sequence. It's not really needed now though, as from v4.0 the game start script only runs when the game is run for the first time - it does not run again when loaded from a QSG savegame file.

yah, but Alex, I ran my test, entered my name, then saved game as a qsg file. I even compiled the program into a CAS file for extra precautions. I opened the saved qsg file (not the asl or cas file) and it started with the "what's your name" question. This should not've happened considering the flag was already turned on... right?

I'm telling you Alex, the code above is all there is to it. A very simple conditional statement followed by a print variable statement. I've rechecked my code, and everything is right. I just retyped my code to make doubly sure. Still, no dice... ? :{ Ok, I even added a conditional to say if flag is set then print..., just in case that had to be defined. Still no dice. Screw it, here's my full code (Flag name/variable name changed when I retyped. Also extended a bit):

' Created with QDK Pro 3.53

define game <>
asl-version <350>
gametype singleplayer
start <Test Room>
game info <Created with QDK Pro 3.53>
end define

define synonyms
end define

define room <Test Room>
description {
clear
if flag <Name_Run> then msg <I know your name is #Name# already!>
if not flag <Name_Run> then {
msg <What is your name?>
enter <Name>
msg <Your name is: #Name#>
flag on <Name_Run>
}
if ask <Go again?> then goto <Test Room>
}
end define

define text <intro>

end define

define text <win>

end define

define text <lose>

end define

Only code in the Start Script is not repeated when loaded. In your example the player is asked the question outside of that, which will be repeated.

Can't see anything wrong with the code...

Then again, 'not' is a funny one.
Instead of having two if's, try putting the other part in the "else" part of the conditional.

S1aY3R wrote:Only code in the Start Script is not repeated when loaded. In your example the player is asked the question outside of that, which will be repeated.

That makes no sense to me, S1ay3r. What you're telling me is that every part of a large game must be included in a startscript for it not to be repeated then? How about flags, etc. throughout a large game? There'd be no code in define rooms and define objects then, since it all would be in define game (if I'm understanding you correctly, else...). Plus if I put "flag not on" in startscript, which will cause it to process first and turn flag on when player enters name, then when Quest reads the room script, it will process the "flag on" script without a break. That can't be it.

Is there concurrence with S1ay3r's synopsis?

By the way, I'm testing on 3.53 still, because I'm having problems with 4.0 trial-version as mentioned in other post, and I won't use it until problems are understood and/or solved.

Instead of having two if's, try putting the other part in the "else" part of the conditional.

I do my best to stay away from "Else" statements, since some of my conditionals can get rather deep. I've found that by making it logically simple and easy for me to read, that I'll have fewer screw-ups. Plus, this can't be the problem, which I'm sure you know. Quest understands my code as is.

I just tried using an "Else" statement, using the else statement in define game, not using else statement but using startscript... nothing worked. My program runs fine, just doesn't save anything. Still need help...

It seems my cell phone is cutting off lines, because the ends of most paragraphs are missing. Judging from what I could read it looked like you were asking a completely different question. What I said before is completely irrelevant to the situation at hand. It looks to me like your code should work.

I agree, as far as my knowledge goes on this subject, but it doesn't. I really need this figured out before I finish my game. I don't want to program thousands of lines of code to find out Quest can't save my game correctly. Any other ideas? Has anyone duplicated my code and tried it?

Actually - I think it's the way Quest loads up files etc..

It appears to load up the game and put you in the start room - THEN load up the saved data..

On Q4 you load it up and it asks for the name - save it, and then load it up and you get asked the question again... after clicking the 'no' though it immediately produced the "I already know your name is: jon" and appears to seem like it's loaded the data from the file. As if the first question was never asked.

Tr0n is correct - it's a bug in Quest.

Quest is first initialising the game, and then applying the data it loads from the QSG file. Unfortunately, as part of initialising the game, it initialises the start room, which then causes the flag check script to be run. This happens before Quest has actually loaded the data from the QSG file.

If you remove the "clear" script command you will see that it completes loading the QSG file after it has asked you the question.

I will add this to my "to do" list.

That sounds logical.

I had lots of things going on with my KQ5 game that I have already submitted. My beta-tester gave me some good tips on how to stop procedures from running when you restart the game.

I can't remember how it's done off the top of my head but if you care to review the code, my game is available....

Ok. Thanks. Steve, thanks for your help. I currently don't have access to the internet, except here at the library, and there's a time limit. If you could supply a brief example, if time permits, I'd appreciate it. I'll look into your code in short bursts from time to time.

Alex, when would the change be made. Any idea? I still have awhile to go on my game.

Also, most likely I'll be getting a new computer that'll probably have Vista on it. I saw on the Quest page that it's Vista compatible. Is it fully compatible then?

And if I skip out on 4.0 for now, does my Quest savings roll over to the next version of Quest 4.x, or even 5.x?

What sort of changes will you be making?

I don't know when I'll be releasing the next version of Quest. There will probably be a v4.01 released fairly soon, as I have had a few bugs reported which it would be good to fix before ploughing on with a more major version.

I tested Quest and QDK on a beta version of Vista and they worked correctly, apart from some minor display problems. I'll be doing more testing on the final version of Vista in the near future.

Yes, you will still be entitled to purchase Quest Pro 4.x at the upgrade price if you are a registered user of Quest Pro 3.x. I don't know what the situation will be if/when Quest 5 comes along - I haven't made any decisions about that at all yet.

There will probably be a Quest 4.1 release in a few months' time, though again I've not made many decisions about what will be included in that (apart from having better compatibility with screen reading software such as JAWS).

Rephrase: To fix that problem, what existing features are likely to be implemented differently, as opposed to entirely new features?

I haven't looked into it fully, but it should hopefully just be a matter of not launching the start room before the QSG load has finished.

Grrr... I had worked out a way to clean up the main event loop of Geas, that depended on a particular assumption, then I noticed that there was ONE way that assumption could fail, and then I checked it against the runner, and found that Quest doesn't even handle the case consistently.

Not quite sure what you mean - what's not consistent? What assumption did you make that could fail?

Thanks for the response Alex. It's exciting to watch Quest grow. Glad to be a part of it. Thanks.

My assumption was that the "read ASL / CAS file & initialize game state" was entirely non-interactive.

Variables within an object property evaluated at load-time? No problem. What if it contains a function call? That could potentially do anything (like call 'ask', 'enter', or 'select')! Testing... functions are loaded after all the game / rooms / objects are evaluated. No problem. What if...

Where this failed was that an ASL file could have something like

define object ...
    examine <$getobjectname(...)$>
end define

where the argument to the getobjectname is ambiguous in terms of objects defined above it. That will cause it to show a disambiguation prompt at load-time.

What's really strange is that if you type "restart", then it won't run those functions, even though it does reload the file. (It'll put a "!" in the examine property.)

Interesting. The intention is that reading an ASL/CAS/QSG should be non-interactive.

The specific bug that we're talking about in this thread occurs because when Quest loads a QSG, it:

1. reads the original ASL/CAS
2. it then applies the QSG data

Now when performing action 1 above, it (erroneously) calls up the ASL/CAS start room, thereby causing any "script" tag ("When the player enters the room" script) to be run. If this contains an interactive script command, it will halt the loading process until the player answers.

The fix for this will be for Quest to not launch the ASL/CAS start room when it is loading a QSG.

You bring up an interesting question regarding object tags that include function calls. This will require separate investigation. I think it is obscure enough not to cause significant problems for most games, and those games that do want to call a function from an object tag should be doing so within a script anyway - in your example, the "examine" tag should be something like

examine msg <$getobjectname(...)$> 

This will avoid problems with Quest trying to evaluate the function when loading the game.

Alex, are you saying that it's only the Start Room which causes the malfunction? Are you saying that data (flags, variables, etc.) in any other room besides the Start Room shall be saved? Does this mean that a saved game runs the Sart Room everytime it's loaded up?

I'll test my question on my own game, since the Start Room doesn't have any data to save. But answer my questions anyways since I might not get to my game before you answer.

The problem is that, as far as distribution formats go, anything not explicitly illegal is valid, and must be supported.

(And I take a strict definition of "illegal". If the runner will load it, it's legal.)

If the Quest runner allows that code, whether it should have been written to use a script, then Geas will be written to get the same result.

Alex, are you saying that it's only the Start Room which causes the malfunction? Are you saying that data (flags, variables, etc.) in any other room besides the Start Room shall be saved? Does this mean that a saved game runs the Sart Room everytime it's loaded up?

All the data is saved, the problem is the order in which it's loaded.

You only get the problem because of the script in the Start Room. If the script was in a different room, you wouldn't get the problem.

Ok. Yeah! I'm still yet to check how the save command works with my game, but if what you say is completely true, and I'm sure it is, then I can easily work around that. Thanks!

This problem is now fixed in Quest v4.01, which will be released soon.

There were in fact two bugs here:

1. Quest was launching the start room as part of the QSG loading process, as previously discussed. This no longer occurs; instead Quest simply launches the player's current room at the end of loading the QSG.
2. When a property or flag was applied as part of the start room's "when the player enters the room" script, that data was not written to the QSG file.

Both of these problems have now been addressed for v4.01.

Totally cool!