The real magic is in specifying the conversion of units in this line:
Gold-weight times exchange-rate specifies a cash-value.If you don’t do that, Inform starts barking at you.
Very cool and interesting.
Today, since I’ve been obsessively beating my head against this problem for a few days now, I decided to focus solely on filling in the (much needed) prose descriptions. I’ve gotta get 'em done sometime, right? LOL … been putting it off, but also regularly visualizing what the environment of the game looks like. As such, it seems to be going fairly well.
I’ll give this method a try tomorrow tho, for sure. If I can’t get it to work, I’ll likely just stick with a purely gold economy, as converting it to cash really isn’t an important part of the game. Just a neat … detail, I guess. And, frankly, during the California gold rush there were numerous small mining towns that operated on a gold basis anyhow, so it’d be historically accurate to do so.
I’d just figured that the gold-to-cash conversion would be a pretty simple task. Who knew it’d cause me such headaches LOL oh well. I’m only just learning Inform 7 this month. 
You could just do it all in real numbers too, but then you don’t get different types.
Yeah, and you’re back to the number displaying as $3.2… this whole mess came about because I suggested using a multipart unit to force the trailing zeroes to display.
There are built in phrases for saying real numbers, so that’s not really an issue.
They cut off a final 0 in a dollar amount formatted as $n.nn (i.e. using real numbers only, it prints out as $3.2 instead of $3.20, even when telling it to display to two decimal places)
That’s why I was trying to set up a “kind” with a specified format, which led to insane numbers being calculated.
I’m gonna try that $n.nn/oz method tomorrow. Writing prose today for all my locations. 15 done, 14 to go. 
Oh you’re right. Sorry, I didn’t test it before posting here. I’d say this is another bug. Anyone know if it’s been reported?
There should also be separate phrases for printing to X decimal places and X significant digits.
[rant]Can I be mean and say something like, “Read the whole thread before posting?”[/rant]
I mean that in the nicest way possible.
Whatever dude. It was mentioned only once before and I already apologised. No one has mentioned whether the bug has been reported yet, did you read the whole thread?
Now now folks, play nice. It’s been chill in this thread so far 
Haven’t tested that $/oz code yet, still. A bit braindead today. :
Also still need to write prose (descriptions) for 14 more locations, several NPCs, and a bunch of things (scenery, backdrops, useful stuff)
AND! My brand new synthesizer gets here tomorrow, so that’s gonna distract me for awhile, I’m sure. LOL
Losing confidence in my ability to get this gorram game done in time for this year’s IF Comp. But, like the rules/suggestions say, it’s better to hold off and not submit than it is to submit an hurried, unfinished, untested game.
Anyhow, it’s my first full Inform 7 project. I may have gotten a bit overambitious (again) 
I didn’t think that the trailing zeroes issue with real numbers was a bug–I would generally expect 3.20 to display as 3.2 when printing a real number.
Is the idea that saying “say 3.20 to two decimal places” should force printing two digits after the decimal point? The current behavior seems consistent with the docs; WwI §15.4 says that “[1.235 x 10^-7 to 3 decimal places]” produces 0.0, which does imply that you won’t get trailing zeroes even if it would be required to fill out the decimal places.