|
Fizgar Magician
Joined: 07 Feb 2002 Posts: 333 Location: Central Virginia
|
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Sun Apr 25, 2010 4:47 pm |
If you plan on editing your post, leave the original intact so others can see it and explore the situation.
|
|
_________________ EDIT: I didn't like my old signature |
|
|
|
Dumas Enchanter
Joined: 11 Feb 2003 Posts: 511 Location: USA
|
Posted: Sun Apr 25, 2010 10:55 pm |
Must be one long edit.
|
|
|
|
Fizgar Magician
Joined: 07 Feb 2002 Posts: 333 Location: Central Virginia
|
Posted: Mon Apr 26, 2010 2:15 am |
Sorry about the long delay. My internet decided to die as I was editing. It just now came back up. As for leaving the original intact. I didn't leave as much information as most would have probably liked so rather than get 5 posts saying more info needed I went this route.
I'm trying to set up an exp tracker for a mud i'm messing around on and the last level will cost 7200000000. Large numbers seem to break the gauges.
1.Open untitled session
2.Create a new button
3.Select Gauge from the type drop down box.
4.Set colors however you want. (You want something that will let you see small changes easily)
5.Enter a MAX VALUE of 7200000000
6.Set the value to anything you want.
(My gauge stays full no matter what the VALUE is set to.)
7.Now set the MAX VALUE to 72000000.
8 Now play with the value field and the gauge should seem to work fine.
In my tests 2147483647 seems to be the largest MAX VALUE I can use in a gauge and still have it work correctly. Change the MAX VALUE to 2147483648 and my gauge fills solid no matter what the value. I think I have a way to still do what I want to do floating around in my head, but I wanted to fix the post first.
Is this a limit we are stuck with, something messed up on my end, or just a bug? |
|
_________________ Windows Vista Home Premium SP2 32-bit
AMD Athlon Dual Core 4400+ 2.31 GHz
3 GB RAM
CMUD 3.34 |
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Mon Apr 26, 2010 2:48 am |
Some parts of CMud are using 64-bit integers. Some parts of CMud are using 32-bit integers. There may or may not be some parts that are in the latter category but which are intended to use 64-bit integers. I think buttons are stuck in the middle category, rather than being something intended for an upgrade.
|
|
_________________ EDIT: I didn't like my old signature |
|
|
|
Fizgar Magician
Joined: 07 Feb 2002 Posts: 333 Location: Central Virginia
|
Posted: Mon Apr 26, 2010 5:55 am |
Ok so I just tried to put my workaround plan into action and CMUD fell flat on it's butt.
Code: |
#if (@Class8ExpNeeded > 2147483647) {#var Class8ExpNeededGauge @Class8ExpNeeded/100} {#var Class8ExpNeededGauge @Class8ExpNeeded} |
This was the start of my plan. The value of @Class8ExpNeeded is set using #switch and a number of expressions which reference a variable that stores the current level of class 8. So let's say @Class8ExpNeeded is set to 7200000000. Being greater than 2147483647, 7200000000/100 should be executed. The result that should be 72000000 is actually returned as -13899345.
I went to the command line and typed #eval 7200000000/100 and #math class8expneededgauge 7200000000/100 both of which spit out 72000000. as it should. However with @Class8ExpNeeded still set to 7200000000, #eval @Class8ExpNeeded/100 and #math class8expneededgauge @Class8ExpNeeded/100 both now return -13899345.
I was gonna set up a sort of dual stage button that would fine tune it's self once in an acceptable range. With this 32-bit/64-bit integer problem showing it's ugly head again I think this plan is trashed.
Hopefully Zugg can chime in with great news that this is something he is aware of and is planing to fix in a future release. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Mon Apr 26, 2010 4:21 pm |
CMUD does not "store" 64-bit integers (well, it kind of does because CMUD stores all values as strings). It only uses 64-bit math for intermediate calculations. Also Gauges do not support 64-bit values because those are handled by a 3rd party visual component that is only 32-bit. Gauges will probably never allow 64-bit values, sorry.
I might be able to fix the problem with retrieving the variable value as a 64-bit number so that @varname/100 would work, so I'll look into that. |
|
|
|
Rahab Wizard
Joined: 22 Mar 2007 Posts: 2320
|
Posted: Mon Apr 26, 2010 4:39 pm |
The problem is that variables cannot actually hold 64-bit integers. If the variable is of type Auto, it will store "7200000000" as a string, not an integer. If that string needs to be converted to an integer value, you get 32-bit overflow. So, while you can do math with values greater than 32-bits, you can't store such values in an integer variable. I don't recall whether Zugg intends to change that.
[edit] ninja'd |
|
|
|
Fizgar Magician
Joined: 07 Feb 2002 Posts: 333 Location: Central Virginia
|
Posted: Tue Apr 27, 2010 12:24 pm |
I got my fingers crossed that you will have great luck and little trouble in getting variables to handle 64-bit numbers. Having the gauges not support 64-bit values won't be a huge loss if that works out well.
|
|
_________________ Windows Vista Home Premium SP2 32-bit
AMD Athlon Dual Core 4400+ 2.31 GHz
3 GB RAM
CMUD 3.34 |
|
|
|
Martaigne Wanderer
Joined: 05 Jan 2002 Posts: 88 Location: Atlanta, GA
|
Posted: Tue Apr 27, 2010 1:44 pm |
I have a similar issue with my exp tracker for Unwritten Legends, so I have have a workaround for it by using a variable that contains an expression that evaluates to what the gauge finally displays.
|
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Tue Apr 27, 2010 8:54 pm |
Turns out this had nothing to do with how variables were saved. They were being properly converted to 64-bit integers. The problem was the "Divide" routine in the runtime code. It was doing a 32-bit divide instead of using 64-bit. The reason literals like (7200000000/1000) would work is because this is optimized by the CMUD compiler and evaluated at compile time by the parser, and the CMUD parser was properly handling the 64-bit math. When using (@varname/1000) then the division was occurring at runtime instead of compile-time and the runtime routine was using 32-bit.
So, fixed for the next version. |
|
|
|
Martaigne Wanderer
Joined: 05 Jan 2002 Posts: 88 Location: Atlanta, GA
|
Posted: Tue Apr 27, 2010 11:36 pm |
I'll be damned. I always thought this was a 32-bit math thing too. Had I realized it was a bug I would have reported it long ago.
|
|
|
|
Fizgar Magician
Joined: 07 Feb 2002 Posts: 333 Location: Central Virginia
|
Posted: Wed Apr 28, 2010 6:17 pm |
Great job Zugg! Thanks!
|
|
_________________ Windows Vista Home Premium SP2 32-bit
AMD Athlon Dual Core 4400+ 2.31 GHz
3 GB RAM
CMUD 3.34 |
|
|
|
|
|