Zugg Software :: View topic

Novice Joined: 26 Apr 2006 Posts: 34

Im wondering 2 things.
1. Is there a way i can make zmud ignore commas when capturing data for variables?
ie you check you bank balance, and it is displayed as 123.456.789
zmud wont put that in a %d variable, as its got commas, and i cannot think of a way to make it dro the comma and go 123456789
i only tried to sub it though, to no luck.
if this is something that gets rather complicated ill just live without, but it would be helpful.

2. Ive noticed that when i do really simple things that involve large numbers, zmud tends to crap out in the math department.
i use a trigger to capture a point pools readout, i know what it caps out at, and instead of using gauges, i use the status window, so ill see
points: 10000000 (100%)

when 10m was as far as the point pool normally regenerated up to, that was fine, but it seems that now that i can go to 40m it breaks after 15
and i start getting lines that look like this
points :18000000 (-52%)
or
40000000 (-48%)
the number in parenthese seems to be random once the calculations break.

to get the % though i was multiplying the number by 100

my trigger looked like this
cpoints :current points
mpoints :max points
perpoints: points in percentage
(notes there. hehe)
#var cpoints %1
#math pointsper (@cpoints*100/@mpoints)

i played with this a little, and i noticed that basic math via #math tended to drop decimals... i noticed this moreso with smaller numbers, when trying to convert hp or sp into a gauge back in the older days when gauges were harder to write... seems like its really easy now adays...

anyway, i tried rewriting the equation to process the math in different orders, to no avail...
It seems like once i break 11 decimal places, zmud just cannot keep up? is this something within zmud itself, or are there other math commands that can keep up.

Novice Joined: 26 Apr 2006 Posts: 34

Hmm i noticed the %float thing in another post, but i dont need it showing the decimals so far down the string.
ie
#math pointper (%float(@cpoints)*100/@mpoints)
and i get lines like
15.246231245342
....
way too many numbers...
bleh i feel so stupid sometimes...
And while i have found a way, that if i divide the max by 100 before dividing the current amount into it, it can work, and this does do what i want, too bad it will crap out above 1 billion
i guess short of %float, #math just cannot handle numbers above a certain point... strange indeed

And since i forgot last time, thank you for the help.

okay i managed to solve the first one, i started messing with %replace, and it would drop everything past the comma, instead of just the comma, so i put it into my point thing, and it did exactly what i wanted it to do for the money thing, but not the point thing, so after looking at it that way for a minute, i finaly got it to ignore commas...

now if i could just drop the decimal and anything past it after getting the percentage... for the points

SubAdmin Joined: 18 Nov 2001 Posts: 5182

First use %n to capture numbers with commas and autmatically remove the commas.

Second, zMud uses 32 bit integers for math, that means that 31 bits are used for the value and 1 bit is used for the sign. The max value is therefore 2^32-1. The use of %float gets around this but causes some inaccuracy in the calculations. You can use %norm to help cover these inaccuracies and you can use %format to display the decimal places you want. The use of accurate integer math within the restrictions presented require the introduction of some inaccuracy. For example you are already in the habit of multipling by 100 first to obtain a value that is accurate to 2 decimal places. However at higher values you achieve the same accuracy by first dividing your mpoints variable by 100. Mathematically these 2 statements are equal: @cpoints*100/@mpoints=@cpoints/(@mpoints/100). I used to use a series of #IFs checking the size of given values in order to use the correct variation for many formulas.

Novice Joined: 26 Apr 2006 Posts: 34

Awesome, i wish i had seen those things before. would have saved me alot of headache.
2 lines of code with fancy stuff...(assuming this works, i used 3 lines of code to do this, but the third line was #math powper (@powper*100) ... hehe

#math pointper %float(@cpoints)/@mpoints*100)
pointper= %format(0,@pointper)

compared to
#math mpo (@mpoint/100)
#math pointper (@cpoints/@mpo)

simpler is better, and for %s at such a high amount of points, a little inaccuracy wont hurt i suppose... especially if it takes more then 100k points to change the %

And the %n thing is exactly what i needed, thank you SO much on that :)