Hello out there. I ran into some problems trying to create a money kind where I could change the dollar amount during play. Even putting [vTotalPrice] in a say statement causes an error. This is the code:

Ottawa is a room.
vHasCustomer is a truth state that varies. vHasCustomer is false.
Price is a kind of value. $10.99 specifies a price.
A thing has a price. The price of a thing is usually $0.00.
After examining something for sale:
say "It can be yours for [the price of the noun]."
Definition: a thing is free if the price of it is $0.00.
Definition: a thing is for sale if it is not free.
vTotalPrice is a kind of thing. The price of vTotalPrice is $0.00.
Every turn when vHasCustomer is false:
If a random chance of 1 in 2 succeeds begin;
call taxi service;
end if.
To call taxi service:
say "You call a taxi.[line break]";
now the price of vTotalPrice is $25.00;
say "The cost of the taxi ride will be [vTotalPrice]";

The errors are as follows:

Problem. In the sentence ânow the price of vTotalPrice is $25.00â , it looks as if you intend âthe price of vTotalPriceâ to be a property, but âa vtotalpriceâ is not specific enough about who or what the owner is.

and:

Problem. You wrote âsay âThe cost of the taxi ride will be [vTotalPrice]ââ, but âvTotalPriceâ is used in a context where Iâd expect to see a (single) specific example of a sayable value, not a description.

I tried everything I knew for several hours, Hunted for solutions here and on Google with no luck.

I need to store a dollar amount in a variable for calculations later in the game.

I think the compilation problem is that you have said âvTotalPrice is a kind of thing,â but thereâs only one vTotalPrice, so you should say just âvTotalPrice is a thing.â Thatâll create a specific offstage thing called vTotalPrice, which you should be able to manipulate as you want.

However, Iâm not sure why you need vTotalPrice to be a thingâif all you need to do is store a dollar amount, you can make a variable holding a price like this:

vTotalPrice is a price that varies.

And then you can directly set vTotalPrice instead of âthe price of vTotalPrice.â (Note that if vTotalPrice is a thing, â[vTotalPrice]â will print its name rather than its priceâif you make it a price you wonât have that issue.)

I need to add 15% gratuity to vTotalPrice. When I do this: ânow vTotalPrice is vTotalPrice times 1.15;â, it gives me an outrageous dollar amount. It should be $28.75 but the answer is in the thousands.

Price is a number that varies. Price is 25.
to say gratuity of (n - a number):
say "[n times 0.15]".
To say plus tip of (n - a number):
say "[n + (n times 0.15)]";
When play begins:
say "The bill is [price] plus [gratuity of price], so [plus tip of price] total.";

The bill is 25 plus 3.75, so 28.75 total.

Iâm bad with math, but Inform can do it. Now the trick is getting values instead of to-say phrases, which may involve the bug @matt_weiner details below.

Thatâs not something youâre doing wrongâitâs a bug in multiplying multipart units by real numbers. More here; reported http://inform7.com/mantis/view.php?id=2075. zarf had a workaround here but I think ultimately that OP decided it was better to forget about cash value in their gameâwhich is not what Iâm recommending here! But you might want to check that out.

I will take Mattâs proposed solution and change the dollar amounts to real numbers. Once done, Hanonâs way of computing the percentage will work like a charm.

Or you could just make prices into real numbers like Hanon did! One thing about that is that youâd have to write something to make sure it prints $4.20 instead of $4.2 when necessaryâI think in the other thread I linked I posted some code to do that but Iâm not sure how well it works.

Also if youâre using the real numbers solution you probably want to make sure to write â[price to two decimal places]â, in case you ever have to leave a tip on 23.25 or something else that doesnât multiply to an even number of cents. Iâm not sure how that might interact with whatever you might use to print trailing zeroes, if thatâs an issue!

I donât have I7 on this computer so this is a shot in the dark, but:

Price is a kind of value. $9.99 specifies a price with parts dollars and cents (optional, preamble optional).
To decide what real number is (P - price) as a value:
decide on the dollars part of P plus ((the cents part of P) divided by 100.0).
To decide what real number is the fractional part of (R - real number):
decide on the remainder after dividing R by 1.
To decide what number is the integer floor of (R - real number):
decide on (the floor of R) to the nearest whole number.
To decide what price is (R - real number) as a price:
let D be the integer floor of R;
let C be ((the fractional part of R) times 100) to the nearest whole number;
decide on the price with dollars part D cents part C.
To decide what price is (R - real number) percent of (P - price):
let P2 be P as a value;
let P2 be P2 times (R divided by 100);
decide on P2 as a price.
When play begins:
say 115 percent of $1.75.

See if this works? Sadly I canât test it myself so this may not work at all. But itâs based on WIÂ§15.15.

Wow. Thanks for the code. I tried Danielâs code but it gives double the 15%. So 15% of $25, Danielâs code gives $7.50 instead of $3.75.

Anyways, I fixed my problem by hardcoding the percent values into variables. I only needed to calculate 15% on 6 different dollar values, so now the percents are hardcoded.

If a working solution shows up, I will definitely use in my game.

If you want to spend time to tweak your code, it would be greatly appreciated as I could use it for other calculations (such as calculating sales tax on a purchase).

Just donât spend too much time since I got my game to work with hardcoded values.

Looks like itâs an integer/real-number problem: this works for me:

To decide what real number is (P - price) as a value:
decide on the dollars part of P plus ((the cents part of P) divided by 100.0).

Does the Inform documentation have information about âoperatorâ precedence? Coming from other languages, it seems backwards that âdivided byâ binds more loosely than âthe cents part ofâ.

Iâm not sure how well itâs documented, but operator precedence in Inform is kind of a mess IMO. Graham has said that by design â6 - 4 / 2â is different from âsix minus four divided by 2â: âArithmetic symbols obey the usual mathematical rules, but English doesnât.â

Things get pretty unpredictable, to me, and I find the safest thing is to put in lots of parentheses if Iâm in any doubt.

YepâŚyou should be able to say â$12.34 times 1.5â, but that gives wildly incorrect results. Itâs a known bug thatâs been around for several years now.