MantisBT - Zandronum
View Issue Details
0001438Zandronum[All Projects] Bugpublic2013-07-29 20:352018-09-30 22:25
Monsterovich 
Dusk 
normaltweakrandom
closedfixed 
1.1.1 
3.03.0 
0001438: "Connection type" option player kick
Client has been kicked by reason: User info change flood.
1.Go to Multiplayer
2.Quickly toggle connection type
3.You are pwned from the server!
No tags attached.
has duplicate 0001471closed  Connection Type will kick you out the server. 
has duplicate 0001975closed  Changing Update Rate causes a kick 
has duplicate 0002141closed  Changing tics per update in the menu will kick you out of servers for user info flood 
child of 0002197closed Dusk Rebuild Zandronum menus for MENUDEF 
Issue History
2013-07-29 20:35MonsterovichNew Issue
2013-07-30 17:31ArcoNote Added: 0006846
2013-07-30 18:00DuskNote Added: 0006847
2013-07-30 18:04DuskPriorityhigh => normal
2013-07-30 18:04DuskNote Edited: 0006847bug_revision_view_page.php?bugnote_id=6847#r3823
2013-08-01 13:56WatermelonNote Added: 0006877
2013-08-01 16:05DuskNote Added: 0006886
2013-08-19 03:44Blzut3Relationship addedhas duplicate 0001471
2014-06-14 17:45WatermelonNote Added: 0009324
2014-06-14 17:45WatermelonStatusnew => feedback
2014-10-29 19:47DuskRelationship addedhas duplicate 0001975
2015-01-12 21:09LeonardNote Added: 0011368
2015-01-14 15:27fulecoNote Added: 0011374
2015-01-14 16:12DuskNote Deleted: 0011374
2015-03-29 23:33DuskRelationship addedhas duplicate 0002141
2015-04-01 03:56WatermelonNote Added: 0011964
2015-04-01 03:56WatermelonStatusfeedback => needs review
2015-04-01 17:15MonsterovichNote Added: 0011972
2015-04-01 17:20MonsterovichNote Edited: 0011972bug_revision_view_page.php?bugnote_id=11972#r6885
2015-04-01 17:26MonsterovichNote Edited: 0011972bug_revision_view_page.php?bugnote_id=11972#r6886
2015-04-01 19:49DuskNote Added: 0011973
2015-04-01 20:49Torr SamahoNote Added: 0011974
2015-04-01 20:50Torr SamahoStatusneeds review => feedback
2015-04-02 13:08WatermelonNote Added: 0011980
2015-04-02 13:08WatermelonStatusfeedback => needs review
2015-04-02 18:26Torr SamahoNote Added: 0011981
2015-04-02 18:31Torr SamahoStatusneeds review => feedback
2015-04-28 18:22DuskRelationship addedchild of 0002197
2015-04-28 18:22DuskAssigned To => Dusk
2015-04-28 18:22DuskStatusfeedback => assigned
2015-04-28 18:23DuskNote Added: 0012180
2015-04-28 18:23DuskTarget Version => 3.0
2015-05-26 00:30DuskStatusassigned => needs testing
2015-06-13 16:46WaTaKiDNote Added: 0012685
2015-06-13 16:47WaTaKiDStatusneeds testing => resolved
2015-06-13 16:47WaTaKiDResolutionopen => fixed
2015-06-13 16:47WaTaKiDFixed in Version => 3.0
2018-09-30 22:25Blzut3Statusresolved => closed

Notes
(0006846)
Arco   
2013-07-30 17:31   
Non-issue. This was implemented for a reason.
(0006847)
Dusk   
2013-07-30 18:00   
(edited on: 2013-07-30 18:04)
It happens if you toggle any of the options... fixing this would require changing the menu to only send the changed options after the menu is closed. Would this really be worth such a fix?

(0006877)
Watermelon   
2013-08-01 13:56   
I don't know how realistic this is, but an option would be to change the code to where any changes are sent to a local buffer, and the buffer is deployed when the menu is closed.
(0006886)
Dusk   
2013-08-01 16:05   
That sounds interesting.. would need the ability to merge two bytestreams but sounds doable.
(0009324)
Watermelon   
2014-06-14 17:45   
Still the same in 2.0?
I think a buffer was added for this (could be wrong)
(0011368)
Leonard   
2015-01-12 21:09   
Quick update, this still happens in 2.0 and not only in the multiplayer menu as pointed out in this ticket but also in the new "network options" menu.
I think this should be fixed with the same method used in the player setup menu (saving to temporary cvars)
(0011964)
Watermelon   
2015-04-01 03:56   
This is a really annoying bug now, I'll need to fix this for another ticket.

Is a temporary "cvar" storage okay? Any ideas on the best way to go about this?
(0011972)
Monsterovich   
2015-04-01 17:15   
(edited on: 2015-04-01 17:26)
> Any ideas on the best way to go about this?

> I think this should be fixed with the same method used in the player setup menu (saving to temporary cvars)

Yes, it's better to send all client info to the server after player closed the network options menu.

Also, there's another problem: UDP packetloss. This is very annoying, for example, in player setup menu: zandro sometimes doesn't change player class. But this should be an another ticket.

(0011973)
Dusk   
2015-04-01 19:49   
Re packet loss: it's an issue in general and I think the ideal solution would be packet dupping. But currently the packet format is in a state where this is not feasible to implement..
(0011974)
Torr Samaho   
2015-04-01 20:49   
Quote from Watermelon
Is a temporary "cvar" storage okay? Any ideas on the best way to go about this?

Just do what menu_name, menu_color, menu_skin, etc. are doing in m_menu.cpp/m_options.cpp.

Quote from Dusk

Re packet loss: it's an issue in general and I think the ideal solution would be packet dupping.

Can you elaborate what you mean with packet dupping?
(0011980)
Watermelon   
2015-04-02 13:08   
Quote
Just do what menu_name, menu_color, menu_skin, etc. are doing in m_menu.cpp/m_options.cpp.


What are your thoughts on a temporary "config" that is deployed based on its differences to the server?

I bring this up because after thinking about it... I'm worried that eventually we'll have to do the temp cvar storage all over the place and eventually either have to do this anyways, or end up with a ton of workarounds with temporary cvar storage.
(0011981)
Torr Samaho   
2015-04-02 18:26   
Before we migrate to ZDoom's new menu code I wouldn't invent any new mechanisms that are related to the menus in any way. The userinfo change handling based on the menu_* cvars has been working perfectly fine for many years. So there is no immediate need to get rid of it.
(0012180)
Dusk   
2015-04-28 18:23   
This was taken care of when I reimplemented the hold-back on userinfo changes.
(0012685)
WaTaKiD   
2015-06-13 16:46   
spam changing settings in network options/player setup no longer result in getting kicked from the server, so this is fixed