Gump return values - a warning!

[Yukiko]

As you all know I am struggling through upgrading the Distro's crafting system. In many crafting systems the crafter can make a deed for an item, a fireplace for example. Since the developers were kind enough to give us ObjType values as high as 0xFFFFFFFF I thought I would be cute and have the deed's ObjType values in the 0xDEEDXXXX range. So I set all of our deed's ObjTypes with the prefix 0xDEED00XX. I don't forsee having anywhere near to 65,535 deeds (0xFFFF in hex) so that gave us plenty of room to grow.

So I am going along adding items to the various skill's crafting cfg files. After which I start testing the scripts. Everythink is going along swimmingly until I try to craft a deed. I won't go into the technical details about the error messages I was getting but suffice it to say the scripts were not reading the deed info from the particular craft cfg file. I spent 3 days changing, testing, changing and testing again but nothing I did fixed the issue. I was on the verge of scrapping this months long project and letting the Distro sit with the crafting system it has.

Then ThisIsMe offered to look at the problem. Anyone who has seen his gumps knows he is THE gump guru. And I don't say that just because he is my son. Anyway, he took maybe 15 minutes to find the problem which I will reveal but first, let me explain just briefly that when you decide what to craft the crafting gump returns the ObjType number of the item you want to craft when you click on the "make item" button. So ThisIsMe decided to see what the gump was returning and he found that the maximum value a gump can return is 0x7FFFFFFF or decimal 2,147,483,647. So when I clicked on a deed, because my deed ObjTypes were higher than 0x7FFFFFFF the gump was returning an erroneous number and out the window went my cute deed numbering system.

So the take-away is make absolutely certain that ANY value returned by a gump does not total more than 0x7FFFFFFF (2,147,483,647 decimal).

Note: I do not know if this is due to a client limitation or if the Core is limiting this value. I suspect it is client side because I cannot see any reason the Core would impose a limit but I will leave this to our great Core developers to investigate.

[Yukiko]

The mystery has been solved.

The maximum value for a signed integer is 0x7FFFFFFF. An unsigned integer can be as high as 0xFFFFFFFF but eScript's language definition limits it to signed integers and so this is a limitation of eScriipt. Turley says he does not know why Tomi gave us a maximum ObjType range of 0xFFFFFFFF as eScript cannot handle that anything above 0x7FFFFFFF.

I bet he just forgot that eScript has that limitation but we will have to wait for Tomi to weigh in for the real reason.

[Yukiko]

Hmmm. I just tested this. I just defined an object with the ObjType of 0xFFFFFFFE and was able to type .create 0xFFFFFFFE and create the object. So someone must have changed the eScript language to handle those numbers above 0x7FFFFFFF.
I guess the limitation is the client and not eScript after all