UO:SA Prompt

[tigah]

Was anyone able to get the Prompt System (Packet 0xC2) working (Used for engraving bags, renaming rune books and stuff). The SA Client seems to ignore that packet, maybe they're using gumps now?

[maximus3]

i cannot say how the technical background is, but the new SA client uses the old gumps again.

[Wyatter]

They use old prompts packet Just send one stub gump in 3D - SingleLineTextEntry. Find this gump in lua in interface.uop and examine it's format And one more - prompts have TYPEID Not two serials as in RunUO )

[tigah]

Ah ye i already noticed this little bugger. I sent its gumpID and got a nice little window with an ok, clear and cancel button. But i couldn't use any of them beside the clear button. I guess that was because i didn't fill in the parameters correcty?

In the Lua i found this

TEXTENTRY (sender object id) (user object id) (text entry id) (messageTid)(IsUnicode (1 = yes, 0 = no)

i guess i have to "tie" this somehow to the Prompt request? And do i send C2 before the gump or after it?

[Wyatter]

You send C2 in 2D and 3D both. In 2D you send cliloc message, in 3D you send this stub gump You have 6 text vars. "TEXTENTRY" - just title var. Sender Object ID - it's not really gump serial, on OSI gumps and prompts use the serials of the their parent objects (mobiles, items). Unfortunately, in RunUO some stupid monkeys decided to use autoincremented serials instead of right serials. User Object ID - it's the serial of your mobile, sometimes it equals to Sender ID (virtues gumps, help gumps, etc.). Text Entry ID - all OSI gumps and prompts have some ID - RunUO sends in 0xC2 just serial and serial (again these monkeys!). You have to send promptID and serial instead of two serials. MessageTid is your cliloc message in 2D. It overrides base cliloc message in this stub gump. IsUnicode - final variable, client must know what prompt type you want to get. If 1 = you need 0xC2 response, if 0 = you need 0x9A response (ascii). You have not to do something with gump response. Just send all variables and you will have an answer (0xC2 or 0x9A). You will get promptID and serial. Now just have to do some work in packethandlers to add some checks for your prompts.

[tigah]

aaaah thanks, i will try that *g*

[tigah]

It works (finally) But i got some final questions on that topic
I used an incrementing counter for this Message(GumpID) thingie. Looks like it has to start with 0 (Client complains about Missing Cliloc if you dont). But i had to avoid 0x1 (same error). Is this correct or is still something wrong?

Unfortunately, in RunUO some stupid monkeys decided to use autoincremented serials instead of right serials.

ye its a shame you never fixed it ;D (We're still using a modified RunUO-RE Core ^^

[Wyatter]

It works (finally) But i got some final questions on that topic
I used an incrementing counter for this Message(GumpID) thingie. Looks like it has to start with 0 (Client complains about Missing Cliloc if you dont). But i had to avoid 0x1 (same error). Is this correct or is still something wrong?

Do you mean messageTID variable? It's not incrementing.
For example, runebook rename book prompt:
var1: "TEXTENTRY" - standard var
var2: runebook.Serial - sender serial
var3: player.Serial - user serial
var4: 0x2C - OSI typeid for this prompt
var5: 502414 - cliloc message
var6: 1 - request for Unicode prompt response
Client will answer with 0xC2: prompt = 0x2C; serial = runebook.Serial;

ye its a shame you never fixed it ;D (We're still using a modified RunUO-RE Core ^^

It's a pity you use old version It takes a lot of time to fix such runuo's mistakes I call it 'Bitter Legacy'

[tigah]

Ah that was the missing link Now it works perfektly. Is there a reference to the 0x2C in the lua scripts or is this something you just have to know? (I guess they just used a value based on the packet type here)