ok, here is the deal, changing numeric variables, that's easy. It's also easy to increment (add) or decrement (subtract) those numeric variables. Here is what I want to do that I just can't seem to grasp. Let's say we have a numeric variable, we will call it health. Then let's say we have another numeric variable, which we'll call cures used. I want "cures used" to be incremented by 6% of "health" every time "health" is changed. How do I accomplish this?

That's very complex, and hard to do. I don't know if Quest supports percentage increments. You'll have to ask Alex

Alright my math might be a little off here but let's give it a try you want...

Status Variable "Health" = 100 (Current/Full)
Numeric Variable "Cures_Used" = 6%(Health)

And everytime "Health" changes, you want "Cures_Used" to change to reflect an increase equal to 6% of the new value of "Health"

This seems pretty simple math of...

(%Health% / 100) * 6 + "Cures_Used" = "Cures_Used"

Quest doesn't do math all on one line and has to split it up into operations, like you do when you do it in your head basically, well, most people. After thinking about it like that, it's just a simple matter of going into qdk and telling it to do it.

I made two status variables, Health & Cures_Used. When our health status variable changes, it's script tells it to set a new numeric variable called "Cures_Div" with a value of %Health%(whatever our Health variable is equal to) divided by 100, this gives us the value of 1% of our total health. Now we set another new numeric variable called "Cures_Sum" to have a value of %Cures_Div% multiplied by 6, thus setting "Cures_Sum" to 6% of our current health value. Finally we increment our "Cures_Used" status variable by a value of "Cures_Sum" or + 6% of current health.

Realistically, in a scenario where a character repeatedly loses health without gaining any back, this would result in diminishing returns, the "Cures_Used" would always be incremented by less and less unless the character is healed. To counteract this, since I don't know if it's what you were planning for, you would want to do the same math as here but against a characters maximum health to always be guaranteed the same percentage, of course, it would change if the maximum health changed.

For those not in the know about Quest's ability to use simple mathematical functions such as +, -, *, and /, I highly suggest you read the manual. It will start making sense a couple times through, and honestly, isn't very long at all. Here's the code straight from QDK, it should be inserted alongside anyother status variables defined in your define game block.

	define variable <Health>
		type numeric
		value <100>
		display <Health: !>
		onchange {
			set numeric <Cures_Div; %Health% / 100>
			set numeric <Cures_Sum; %Cures_Div% * 6>
			inc <Cures_Used; %Cures_Sum%>
		}
	end define
	define variable <Cures_Used>
		type numeric
		value <0>
		display <Cures Used: !>
	end define

Edit you wanted Cures_Used to increment, not just be equal to 6% of health, ok i'll revise this quickly.

ok, "i think I'm dead" that is a little complicated, but I think I understand what you are saying, thank you. I will test it and see if it works like i expect it to.

Ok, I understand how in most games, you only want a whole number. But in this game (trying to make it as realistic as possible, trust me) I need it to stop rounding the numbers when it displays them as a status variable. Isn't there any way to get it to display the status variable up to 2 decimal places, i.e. "You currently carry 22.53 bottles of heal." I know I may be reaching on this one, but if that's not possible, I think I have a way around it, i could simply display two seperate variables, one for full bottles and one for partial bottles, but it needs to stop rounding up. 23.65 = 24 (basic math) but I want it to equal 23 full bottles, and then the other status variable can handle the rest, does this make any sense?

As far as I know, Quest doesn't natively support this.

It would be nice if Alex added an option to turn on or off the rounding.

There may be a way around this, it would involve using two seperate variables, one for bottles filled, and one for filled amount of the current bottle, but I'm thinking it might depend on when Quest actually does the rounding up. If Quest never does the mathematical work of finding the remainder after dividing by 100(the .53 or whatever), then there really is no way to process that information.

Another way to possibly get around this problem would depend on wether or not Quest will round a number down if it's decimal value is below .50. If Quest does this, which honestly I've never tried otherwise I'd know, would be to divide the 1% into something to see if it came out as either 0 or 1, if it was rounded down to 0 then you could alternately try to divide it by 2/4/8/whatever to determine wether to add .50/.25/.125 respectively.

Now that I wrote all that out, I think there's a much easier way to do it. I'll think about this a little more and make a few math tests/examples to try and figure this out.

One thing you could possibly try is doing the maths with string variables rather than numeric variables. Numeric variables are stored as integers, which is why they'll get rounded. I'm not saying string variable maths will definitely work, but it's something to try.

Naw, just gives you a pretty little string variable with a value of "health / 100". I'm trying to throw together a number parsing function real quick, we'll see.

Number Parsing won't work because Quest won't save numbers with a decimal/period in them into strings.

It does however store the whole string with decimals/periods into the #quest.command# and #quest.originalcommand# strings. It would be nice if we the users could somehow create our own magical variables that aren't held to the same standards as others.

It's ridiculously aggrivating to come up with a million different ways of working around Quest's limitations only to find another one is in place for no reason.

How about releasing a build that doesn't parse periods(and anything following them) out of the text buffer before storing it into variables.

What would be nice if Quest gave you the option of selecteing whether you want it stored as an Integer data type or a Single data type. You programmers will know what I mean

number 1. God, people don't know maths nowadays *shakes head*

Number 2. ITID - why not just leave the numbers without deviding by 100 and then "move the decimal point" across 2 (or introduce it into the string response) and then that'll do!

Number 3: Alex, couldn't you just get a free maths parser off the net to do more complex maths stuff (like equations etc on the same line, and also squares and cosine functions.... I have a .dll stored from the net which is supposedly freeware and does this.... dunno though).

Number 4. Maybe a double feature would be a good idea, having numeric and dnumeric variables allowing people to get more specific results easier without moving the decimal all over the place.

I think I may have found a free maths parser, after a bit of hunting. Alex, if you'd like to try it out, I can email it to you.
What these forums really need is a file upload function (like vbforums.com has)

Alex, just wondering if you had seen my last post. I posted this just to bring it up.