My guess is:
1- they send a new updated gump (that shows up above the old one)
2- then they send the close command to the old gump

You can attach a packet analyser or use Razor to register the communication packets and analise the data to see how the trick is done
 
Cant be the first option hehe. Because if you drag the gump it will show the old one in the back. Anyway tomorrow i will try that way
 
Theres no onresponse.


To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

That gumps updates and doesnt ''blink'' like i said.
[doublepost=1539295219][/doublepost]Kal Xen

@Voxpire !
 
It may just be a case of not calling mobile.CloseGump() before you create and send the new one.
You remove the gump instance from the user's NetState manually.

For gumps that do close before being sent;
When a gump packet is small enough to be sent faster than your ping, you usually won't get flickering.

Take my NotifyGump in Vita-Nex: Core for example that animates at 10 FPS, it consists of very minimal gump entries (a background and an alpha region) until it reaches its last frame, where it will render the message and any buttons. It is not very susceptible to flickering, but you can notice it if it animates during a world save pause, because the underlying timers do not tick during a save.

SuperGumps always send a close request before they are sent to the client like traditional gumps.

TL,DR;
1. Keep your gump designs as limited as possible, with as few entries as necessary to reduce the compiled packet size.
2. Players with higher pings will more often see flickering with gumps.
 
Back