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?

Any hint on how to investigate further in this problem?

Give me a while bro, and I'll look at OSI's current logs. I know they introduced a NEW gump packet (compressed data in the packet instead of raw gump info). Prob just a few adjustments unless it uses the new packet for the return of that. In that case, I'll have to look into someone adding the new packet to POL on the dev team (I suck at compression stuff, so don't look at me, lol ).

Ok, thanx for the answer, I'm happy to hear that probably they changed the packet instead of removing the send gump result part when the gump is closed by server request

Any news about this problem?

As of right now, this is on the back burner. We will try to get 96 out the door before adding something like this. Hopefully, it won't be a lot longer, hehe.

Yeah? :!: :?: :?: :?: :!: :?:

MuadDib wrote:As of right now, this is on the back burner. We will try to get 96 out the door before adding something like this. Hopefully, it won't be a lot longer, hehe.

Thanx for the answer

Lagoon wrote: 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.

This doesn't seem to be a general ML problem though, maybe only with
newer client versions. At least in ML Client 5.0.1h, it still seems to be working
fine.

Xandros

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...

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

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()

A simple one with no hassles is Folko's UOLog. Its in the post here http://forums.polserver.com/viewtopic.php?t=407

just update the clients.cfg with the extra values for the 5.x clients with the ones that are posted by MuadDib in that post.

Thank you very much, I'll give it a try and post results...

Edit: Tested 4.0.0l, 5.0.1h and 5.0.2b clients. Only 4.0.0l, when 0xBF (0xD subcommand) packet (CloseGump) closes the gump and then send a 0xB1 (GumpReply) packet back to the server with the result asked in the 0xBF. 5.0.1h and 5.0.2b clients Only close the gump and don't send any packet back to the server. So this functionality seems to be broken in those clients... The only other option is that it must be activated somehow, since Xandors says his server receives the GumpReply packet from 5.0.1h
Do you send some packet to activate features on the client? which UOFeatureEnable value to you use? What do you use for Account.set_uo_expansion(string)?
by the way, the tool is great, thanx

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:
And the called script that will display the gump data looks like
this:
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

Oh, now that makes sense, I was starting to feel the unlucky man of the situation
Thank you for testing and for the hint, it seems like my scripts need a rewrite