DOE: Locations Extension

[dulux-oz]

Hey just wondering if you've found a solution to the 'gp' =/= 'GP' issue yet? It pretty much makes the shops unusable because the party sheet distributes coins as uppercase currency (even if you set the campaign currency as lowercase abbreviations). So in order to use the shops you need to reset the currency in the treasure tab on the character sheet back to lowercase (so the shops will recognize it) every time you get treasure from the party sheet.

Also the decimal rounding on item prices in shop inventories is pretty unsightly (i.e. a weight of 0.2 will read in the shop as 0.2000000098023 lb)

The gp =/= GP issue is actually symptomatic of a larger issue relating to currency conversion. Yes, we all know that 1gp is the same as 1GP, but to a computer they are as different as $1 being the same/different as 1gp.

I am working (slowly) on a new Extension (called the DOE: WMC - Weights, Measurements & Currencies) that will solve this issue and thus all the issues around currency-conversion, giving change, etc - but I kept getting dragged off onto other things that other people want done "now".

The rounding issue is also being worked on - its an issue with the way computers store fractional numbers, and thus integral to the FG Engine. Still, we'll see what we can do.

TL;DR: its coming, but people are just going to have to be patient - I'm only one guy and there's only 24 hours in a day (and, for the record, my health isn't 100% at the moment - my issue, but it effects my productivity ).

[Kelrugem]

TL;DR: its coming, but people are just going to have to be patient - I'm only one guy and there's only 24 hours in a day (and, for the record, my health isn't 100% at the moment - my issue, but it effects my productivity ).

Oh, get well soon. I wish you a good recover

[Ampersandrew]

The rounding issue is also being worked on - its an issue with the way computers store fractional numbers, and thus integral to the FG Engine. Still, we'll see what we can do.

Hmm, I'd rather say it's a symptom of the implementation chosen. Your answer ignores both fixed point representations and rational number implementations either of which is a much better format for currency. Someone back in the day decided these values were floating point and this is the consequence. You may have guessed, but I don't really like floating point numbers. There are lots of applications where they are a sub-optimal solution. Currency happens to be one of those applications.

TL;DR: its coming, but people are just going to have to be patient - I'm only one guy and there's only 24 hours in a day (and, for the record, my health isn't 100% at the moment - my issue, but it effects my productivity ).

Sorry to hear that, get well soon.

[dulux-oz]

Hmm, I'd rather say it's a symptom of the implementation chosen. Your answer ignores both fixed point representations and rational number implementations either of which is a much better format for currency. Someone back in the day decided these values were floating point and this is the consequence. You may have guessed, but I don't really like floating point numbers. There are lots of applications where they are a sub-optimal solution. Currency happens to be one of those applications.

Yes, but the decision to use Floats, etc, was not made by me, but is "hard-wired" into the FG-Engine - which we don't have access to (the gut of, that is) hence it taking a while to come up with a decent solution.

[Andraax]

Try using this:

function round(num, numDecimalPlaces)
  local mult = 10^(numDecimalPlaces or 0)
  return math.floor(num * mult + 0.5) / mult
end

[Ampersandrew]

Try using this:

function round(num, numDecimalPlaces)
  local mult = 10^(numDecimalPlaces or 0)
  return math.floor(num * mult + 0.5) / mult
end

I haven't tried it, but I don't think that will help. It is more likely that the problem is that 0.2 is not representable exactly in this floating point representation. You will likely end up with 0.2000000098023, which is the closest this floating point representation can get to 0.2

This needs a fix in the output layer. The real underlying problem is that lua doesn't have an integer type. Actually, I have no idea what the problem is :-)

It's also possible that lua has been compiled with single precision floating point numbers here. Anyway, I'm sure Dulux-Oz is aware of all this and taking it into account while looking for a "decent solution".

[Moon Wizard]

Yes, the Lua engine uses floating points internally for all numbers (and thus that is what the Lua scripts have to work with), which is the root of the situation.

Regards,
JPG

[Andraax]

Seems to work:

	local nTest = 1 / 6;
	Debug.console("Before round: " .. nTest);
	nTest = round(nTest, 2);
	Debug.console("After round: " .. nTest);

Runtime Notice: Reloading ruleset
Runtime Notice: s'Before round: 0.16666666666667'
Runtime Notice: s'After round: 0.17'

[Intruder]

The solution Andrax listed is the method I have used for the problem of rounding.
The capitalization problem was resolved by having the routine ignore case.

Total Currency is first loaded into the extension and converted to copper,
then the transaction is conducted.
Then the resulting copper is consolidated to fewest coins using platinum as a base,
then reinserted into the record sheet.

The resulting vendor accurately transacts any exchange, giving proper change in return.
I have been using this for over 6 months with good results.

As the extension belongs to Dulux, I have not given the code to anyone.
I do not know what effect this code will have on other extensions, but expect
that Dulux will figure that out before incorporating it into his extension.

[Bidmaron]

Intruder, he encourages people to modify his stuff and give him code in his extension threads. If you have the fix, I think he'd love to incorporate it.