 |
 |
|
|
| Author |
Message |
Lagoon
Joined: 05 Mar 2006
Posts: 118
Location: Italy
|
 Posted: Sun Mar 05, 2006 11:52 am Post subject: New clients no more send gump result when closed with 0xBF |
 |
|
I use 0xBF in a lot of script to close open gumps in a client. The function I use is
function CloseDialogGump(who, gump_id, return_value := 0)
var packet_string := "BF000D0004";
packet_string := packet_string + fixPacketLength2(Hex(gump_id), 4);
packet_string := packet_string + fixPacketLength2(Hex(return_value), 4);
return SendPacket(who, packet_string);
endfunction
I use it to have gumps which autoupdate their content.
This works with Age of Shadows clients and Samurai Empire clients, but Mondain's Legacy clients seem to work in a different way. When ML clients receive 0xBF packet they close the gump, but, unlike older clients, pol does not receive the proper packet with the choosen gump selection value so the gump script continues waiting for player choice and it's impossible for me to refresh it or react in any other way to the gump closure. Does anyone know if EA changed the packet sent by client to server when 0BF packet is received? or maybe there's something different in the packet which pol isn't able to manage? I'd like to investigate further and propose a fix for the core if any fix is possible, but I don't have the knowledges to sniff POL packets. Can you suggest me an UO packet sniffer which supports newest clients encryption? or maybe someone with more experience might help? |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Author |
Message |
Xandros
Joined: 17 Feb 2006
Posts: 76
|
| Posted: Tue May 30, 2006 3:22 pm Post subject: |
|
|
| Lagoon wrote: | Interesting, I'll test with that client, thanx 
Edit: tested, it does not work for me. I uninstalled UO, reinstalled it, autopatched till the end (5.0.2b) overwrote client.exe with 5.0.1h version and run it with UOGateway (v. 1.9.1265). I run POL096 core (pol-core-096-2006-05-24-RC-Vestal-Virgin). Nothing changed, my scripts do not receive the return value from the gump closed by script. I have no idea if the problem is related not only to client but to the overall UO installation in some way... |
Here's the function we use...
function CloseGump(who, pid, buttonid := 0)
var packet := CreatePacket(0xbf, MSGLEN_VARIABLE);
packet.SetInt32(1, 0xd0004);
packet.SetInt32(5, pid);
packet.SetInt32(9, buttonid);
return(packet.SendPacket(who));
endfunction
Can't tell you if the return value is correct, we actually never had any
use for the return value, but I can definitely tell you that the server
doesn't wait for the gump input anymore, once we send that the
script goes on with whatever comes next in the code.
Tested with client 5.0.1h, UO patched to 5.0.1h.
Xandros |
|
|
|
|
|
|
|
| Author |
Message |
Lagoon
Joined: 05 Mar 2006
Posts: 118
Location: Italy
|
| Posted: Tue May 30, 2006 3:58 pm Post subject: |
|
|
The function you posted should be in practice like the one I posted... I tryed with your code and it still does not work for me 
So, the only difference between my uo installation is that you blocked autopatch when it finished patching 5.0.1h? It's strange, I can't see how different files and the same client could give different results... I'll reinstall UO again blocking it at 5.0.1h
Thank you for your help, it's a bug which is annoying me, maybe I'm doing something wrong, but I can't see my fault...
To MuadDib: Do you have elements to help me understand if it's something which needs core support or if I'm doing something wrong?
Edit: Ok, I did a lot of tests and here are the results:
* The code I posted to close a gump does not seem to be different from the one posted by Xandros
* The UO installation is not important, only the client (as expected) is important: 4.0.0l client send result back to pol and pol send the result to the script waiting for the gump result. And the result is the one submitted with the closegump function. Client 5.0.1h and older clients (did not have time to check ML clients before 5.0.1h) acti differently, since POL doesn't send the result back to the script. No idea what's different in the packets sent back, I have, as said, no experience in packet sniffers, I'll search for a simple one and try to understand what's happening. Anyway... no idea how Xandros scripts can receive a return value from the gump with 5.0.1h client (I'm not saying you're wrong, I really have no idea  )
* UOFeatureEnable in servspecopt does not seem to change this behaviour, as well as account.set_uo_expansion() |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Author |
Message |
Xandros
Joined: 17 Feb 2006
Posts: 76
|
| Posted: Wed May 31, 2006 6:15 pm Post subject: |
|
|
Lagoon,
I just tested a little bit more and in fact you were right, the server
does not get the response, and the script keeps waiting. The reason why
we didn't notice that, is because we always start an external script to send
the gump in such cases, and this script does nothing else than sending
the gump and returning the return value using an event, if there is one.
To clarify, the corresponding section in the calling script looks about like
this:
| Code: |
while (who.ip)
CloseGump(who, gump.pid);
gump := start_script("misc/custom/startgump", {who, GetPid(), layout_array, text_array});
ev := wait_for_event(5);
if (ev.source == gump.pid)
dialog := ev.result;
//change gump data, or exit the loop, depending on dialog result ...
else //no button pressed
//periodical gump data refresh...
endif
endwhile
|
And the called script that will display the gump data looks like
this:
| Code: |
program StartGump(param)
var who := param[1];
var cpid := param[2];
if (!who.ip)
exit;
endif
var proc := GetProcess(cpid);
if (!proc)
exit;
endif
var res := SendDialogGump(who, param[3], param[4]);
if (!who.ip)
exit;
endif
proc := GetProcess(cpid);
if (!proc)
exit;
endif
var ev := struct{type := EVID_GUMPRESULT, source, result};
ev.source := GetPid();
ev.result := res;
proc.SendEvent(ev);
endprogram
|
This method works, as long as you don't need any return value
when killing the gump. It will of course leave many hanging
StartGump scripts in memory, as you found out they'll keep
waiting for the gump return value, once the gump has been
killed. But it works, and you can easily get rid of the waiting
scripts by inserting a line of code to kill the StartGump script, after
the CloseGump() call. And that is what I will have to do in my
scripts now...
Xandros |
|
|
|
|
|
|
