|
Axe Software Forums
Quest Developer Forum Some sort of status variable bug
|
Author | Topic: Some sort of status variable bug |
Tyrant |
posted 04-11-2001 17:26 GMT
I think I encountered yet another bug with status variables in QDK 3.03. Remember when I asked about making runchance (a numeric variable) equal a random of either 1 or 2? Well I noticed that the contents of runchance are also the contents of another numeric variable of mine. Here is the code I have so far of the not-so-complete battle system: (Note- I know I have lots of status variables, but I will need lots of conditions in order to make my battle system work. This is the way I like to do it, and it works.) ' "Game Name" define game <My Game> define synonyms define room <test> define room <death> define procedure <battleproc> define procedure <death> define timer <gametime> define text <intro> end define define text <win> end define define text <lose> end define define selection <battlemenu> When the contents of %runchance% become either 1 or 2, the variable %sp% has the same contents. To test this problem, I added runchance to the list of variables, and made it's initial value a number, such as 7. When I played the game, the SP variable showed up with 7 as it's value. What's wrong?
|
Tyrant |
posted 04-11-2001 17:36 GMT
Oh yeah, and I just fixed the minute and hour problems as I just noticed them now. FROM: define variable <minutes>
define variable <minutes>
define timer <gametime>
define timer <gametime>
|
Computer Whizz |
posted 04-11-2001 20:31 GMT
Right, I have no idea what the problem is with the first post is (I didn't look into it frankly!) but the second one shouldn't really be <variable; +1> it should be more like <variable; %variable% + 1> where-as you put <variable; %variable% ; +1> you should only have one ; in a <>. Computer Whizz |
Tyrant |
posted 04-11-2001 21:18 GMT
Ah, that's the problem (with the 2nd). I figured it was ALMOST right the first time, but it didn't work, so I thought I figured out the problem and changed it without testing. Thanks for the input. To anyone out there, I still need the first question answered. |
Pikaflare |
posted 05-11-2001 12:33 GMT
I don't know if this makes a difference. But: set numeric <runchance; $rand(1;2)$>
set numeric <runchance; $rand(1; 2)$>
Don't know if that helps. |
Computer Whizz |
posted 05-11-2001 01:10 GMT
Well, in my test with Quest 3.02 (haven't installed the upgrade yet!) I turn up with SP being 1 when runchance is 1..... but SP is 0 if runchance is 2!! I'll have a look into the code for you.... and will LOOK as if I'm doing something - but am really waiting for MaDbRiT to reply! Computer Whizz |
Computer Whizz |
posted 05-11-2001 01:36 GMT
Right, first is first!! if not ( %status% = 1 ) then set numeric <status; 0> Why are you saying "if status = 0 set it to 0" ? Because I don't think you'll be changing it to 3 if you can't DO anything with it!! As status can only do poison anyway - if you try to use it for anything else the player will lose the previous ailment... eg: player get's poisoned... waits... player get's scared.... (player see's that he is CURED of poison...) WOOOPPPEEEEE!!!! Just thought I'd point that out first... On to the problem. It is somehow connected to you saying this: Computer Whizz |
Tyrant |
posted 05-11-2001 02:58 GMT
First off, about the status thing. Each number in the status variable represents a status effect. 0 = Nothing wrong Injury, mind trauma, and sickness only affect you while in battle, therefore you are cured after battle. When you are poisoned, however, you continue to lose HP while simply walking around and doing actions, which is the reason why Quest sets status to 0 if the player isn't poisoned (aka- if status is NOT equal to 1). HOWEVER, after carefully thinking about it, I feel I should change it. The player should continue to have any status effects after battle, then those could carry over to the next battle if you haven't cured it yet. Anyway, could we be seeing a QDK 3.04? This seems to be quite a serious bug, especially for games like the ones I make. |
MaDbRiT |
posted 05-11-2001 11:44 GMT
Hi C.W. I've been a bit too busy lately to get seriously 'stuck in' to the problem - but it seems at first impression it is likely to be more a Quest 'bug' than a coding issue. While I'm more than happy to stick my oar in on coding issues, I'm powerless where bugs are concerned. :-( Al |
Computer Whizz |
posted 05-11-2001 19:45 GMT
No Tyrant - my point is this: When in battle the player is poisoned then the variable is set to 1, and he looses life.... If however he is fighting a monster that incurs a DIFFERENT status effect (let's say sickness) then the variable is RESET to 5 (or whatever number it is) and so the player is CURED of poison. And again if the player get's any different effect put on him! What you should do is have 5/6 different status variables, or have one variable like this: "1,0,0,0,0,1" so that it checks to see if one of the numbers are positive and so does THAT status effect - or who knows, you COULD have it so that you use string's and have it SAY "POIS,MIND,SICK" and have it check for the WORDS! I'll probably go with the string one - but I see no way for the one variable in your demo to work!! MaDbRiT - yup, it sure looks that way... I'm sure Tyrant will be waiting with baited breath for Quest 3.04 to come out (god damn it - another 1 meg download!!). Alex - well, if you could look into this further then we'll ALL be a bit happier. Computer Whizz - stop writing rediculous stuff.... you need to get drunk out of this galaxy before you perform a speech tomorrow >>>> NOW GO!!! Computer Whizz |
Tyrant |
posted 06-11-2001 02:28 GMT
C.W., I definately see where you're getting at now. I had thought of that, but I figured that would be too many status variables, but string variables would work... therefore I'll probably add the option of having multiple status effects. This is my first game with this battle system, so it will keep on improving as games go by as I will be using this in lots of my RPGs, but with changes for each game. |
Computer Whizz |
posted 06-11-2001 19:11 GMT
Well..... no-one can get it COMPLETELY right with their first go! I just thought that that was an important part of the game - I wouldn't mind if you kept it like that because I personally don't like poison and would rather get hit by something else to get rid of it - not only that but I could search out the one with the cheapest antidote and use that instead ;) Computer Whizz |
Alex |
posted 07-11-2001 18:07 GMT
Try this for size... http://www.axeuk.com/quest/quest304patch.zip . It's the current build of Quest 3.04 (build 3.0.107) which fixes this status variable confusion. Let me know if it works.
|
Tyrant |
posted 07-11-2001 21:39 GMT
Alex, As far as I know, the new build (3.04) does, indeed, fix the status variable problem. Thanks for the beta! I'll let you know if I run into it, or any other bug again. |
Alex |
posted 07-11-2001 23:07 GMT
Cheers. If there are no further bugs I'll probably release 3.04 properly soon, although there's a possibility that Quest 3.1 might be ready by then. |
Computer Whizz |
posted 08-11-2001 01:13 GMT
Is anyone else finding that development has "Hastened" a little? I mean every day I come in here and a new Quest has been released (well - sorta). I've already downloaded quest upgrade to 3.02, then 3.03, now that 3.04 replacement (I like that a bit better then the CONTINUOUS installing program as an upgrade - perhaps you could release a self expanding zip file or something!). Anyway, I think I'll wait until you release quest 3.2 or something before totally upgrading ;) Computer Whizz |
Tyrant |
posted 08-11-2001 03:33 GMT
C.W., why not just upgrade when a new beta is released? You don't need to restart a new game from scratch every time you upgrade or something like that. Simply take a few moments to download, then continue coding as usual. On a side note, is there anything you (Alex) can tell us about what to expect in 3.1? MIDI looping, background color changes, etc.? |
Alex |
posted 08-11-2001 14:11 GMT
MIDI looping and background colour changes are two of the new features, plus MOD playback, EXE file shelling with parameters, easier access to object properties and easier disambiguation. Plus QDK adds support for libraries to add their own interface bits. |
Computer Whizz |
posted 08-11-2001 14:42 GMT
Easier access to object properties??? I think they are very easy already..... maybe you could do it somewhat like VB like : Computer Whizz |
Alex |
posted 08-11-2001 18:57 GMT
Close - in Quest 3.1 you can access properties using #objectname:property# rather than $objectproperty(objectname;property)$ which is rather cumbersome. |
Computer Whizz |
posted 08-11-2001 19:43 GMT
And to SET them? Computer Whizz |
Alex |
posted 08-11-2001 21:00 GMT
Setting them is done in the same way (I think the syntax is simple enough). |
Computer Whizz |
posted 09-11-2001 02:04 GMT
oh, yeah - right! It's that "property <object;property = whatever>" .... I forgot that for a moment there!! I guess I'm going to be a bit lacking in the ASL language since my brains full of ideas on how to do my VB coursework!! Computer Whizz |
babydragon |
posted 11-11-2001 03:38 GMT
Thanks alex, that patch helped a lot with status variable problems... |