|
Axe Software Forums
Quest Developer Forum Not again...
|
Author | Topic: Not again... |
Mega |
posted 14-10-2001 01:59 GMT
I tried to solve this one on my own. I really did. But it just won't woooooooooooooooooooooooooork!!!!!!!!!!!!! Basically, the long and short of it is, I wrote a function (not a command) called Resolve, which was meant to accept an object parameter (a real name or an alias) and convert it into the actual object name so it can be interacted with. Simple, right? Well, for some reason, when I invoke the function, it runs TWICE when it should only run once, and doesn't do what it's supposed to. I've tried everything I could think of, declared tons of useless variables to try to control the code's sequence, and it just won't do what I want!! If someone could recommend a better way to accomplish this, or tell me where I'm once again going wrong, I'd be much obliged. ' Created with QDK 3.02 define game <firstGame> startscript { afterturn {
end define define type <openable> action <startup> { action <close> { action <look> { end define
define room <outside gate> define object <gate> indescription <You are standing> define room <inventory> end define define room <south courtyard> end define define function <Resolve> end define define text <intro> end define define text <win> end define define text <lose> end define |
Mega |
posted 14-10-2001 02:43 GMT
Correction: The function is supposed to convert it to the DISPLAYED name, not the ACTUAL name. The reason for this is, once again, the door thing; if the 'door' object is aliased 'closed door' and I type 'look door', it says 'no such object'. Only typing 'look closed door' had the desired effect -- sometimes... |
MaDbRiT |
posted 14-10-2001 10:08 GMT
Flippin 'eck Mega, that's a whole lot of code you've written there :-) Here's my way of writing / using a 'resolve function that does what I think you want it to - I've mercilessly hacked your posted code so that there's just enough left to see it in action.
quote: I'm not promising this code is perfect or bug free, but it seems to work in my limited testing and it is a whole lot smaller! Al |
MaDbRiT |
posted 14-10-2001 10:20 GMT
Oh yes.. I only 'reworked' the code that deals with 'look at' the gate object in the above, you'd need to make your own arrangements for dealing with your user commands like 'open & close', these can still use 'resolve' though and it was that function I was trying to demo here. :-) Al
|
Mega |
posted 14-10-2001 18:30 GMT
That did it!!!! Many thanx!!!! There were a few little kinks to work out, but now it's running exactly as it should. I'd still like to know why the hell the function was running twice in a row, though :-) |
MaDbRiT |
posted 14-10-2001 18:41 GMT
Mega wrote
quote: I think because your code which is a command then runs the 'look' command with the normal option. One iteration for the original, one for the 'exec' ... I used a 'toggle' variable in my code to prevent that. Al |
Mega |
posted 14-10-2001 19:32 GMT
Actually, no you didn't. Add the following line to the very beginning of your resolve function: msg <starting resolve> Now run it. The message will print about four times, at least. What the hell is going on?! Functions are only supposed to execute when you call them!!! |
MaDbRiT |
posted 14-10-2001 22:41 GMT
quote: Oh yes I did... the LOOK procedure is the thing being run twice, my 'toggle' is intended to make that do different things on each iteration. Agreed 'prevent that' was a bad choice of words, what I should have written was 'prevent the second call from having an adverse affect on the game.' Using exec <look> inside the Look procedure means the look proc gets called twice. As the look procedure calls the resolve function in three different places it follows that means more than one call to the function will usually be made. It will probably be two calls, but more are possible. Therein is the reason a 'msg <whatever>' in the top of the function is printed repeatedly. Remember that the function is called every time the code '$resolve$' is processed. In the case of looking at the iron gate, this is twice. So as the function is being called from the procedure more than once on some occasions it is only being called when asked for by the code :-) Because functions are fast, and as written mine doesn't actually print anything, I didn't bother to assign the result of the call to the function to a variable, just let the code re-evaluate the function whenever required. Had I assigned the result of the first call of $resolve$ to a variable and made my tests against that, the code would not need to call the function again. As the repeated calls don't show (or matter) unless you have the function printing things to the screen (in which case it ought to be a procedure) I didn't bother about it overly much. :-) Al |
MaDbRiT |
posted 14-10-2001 22:55 GMT
Oh yeah.. In point of fact Mega, the code above is entirely dependent on the 'look proc' being called twice and the 'toggle' controls that. First call (by direct user command) uses the 'resolve' function to establish just what object the player wants to manipulate, it then sets the toggle and calls 'exec <look at #lookthing# ;normal>. Because on checking the toggle it is set, this time through the code actually performs the 'look' function - calling '$resolve$' again where needed. After performing the actions - it resets the toggle and the sequence is over. Without the toggle to check the code would either not work at all - or loop indefinitely.
|