Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
Fizgar
Magician


Joined: 07 Feb 2002
Posts: 333
Location: Central Virginia

PostPosted: Sun Apr 25, 2010 12:46 pm   

3.16b Gauge Limits/BUG
 
Edit in progress
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: 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
Reply with quote
Dumas
Enchanter


Joined: 11 Feb 2003
Posts: 511
Location: USA

PostPosted: Sun Apr 25, 2010 10:55 pm   
 
Must be one long edit.
Reply with quote
Fizgar
Magician


Joined: 07 Feb 2002
Posts: 333
Location: Central Virginia

PostPosted: 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
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: 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
Reply with quote
Fizgar
Magician


Joined: 07 Feb 2002
Posts: 333
Location: Central Virginia

PostPosted: 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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: 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
Reply with quote
Fizgar
Magician


Joined: 07 Feb 2002
Posts: 333
Location: Central Virginia

PostPosted: 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
Reply with quote
Martaigne
Wanderer


Joined: 05 Jan 2002
Posts: 88
Location: Atlanta, GA

PostPosted: 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.
_________________
Unwritten Legends
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Martaigne
Wanderer


Joined: 05 Jan 2002
Posts: 88
Location: Atlanta, GA

PostPosted: 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.
_________________
Unwritten Legends
Reply with quote
Fizgar
Magician


Joined: 07 Feb 2002
Posts: 333
Location: Central Virginia

PostPosted: 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
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net