MantisBT - Zandronum |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0001438 | Zandronum | [All Projects] Bug | public | 2013-07-29 20:35 | 2018-09-30 22:25 |
|
Reporter | Monsterovich | |
Assigned To | Dusk | |
Priority | normal | Severity | tweak | Reproducibility | random |
Status | closed | Resolution | fixed | |
Platform | | OS | | OS Version | |
Product Version | 1.1.1 | |
Target Version | 3.0 | Fixed in Version | 3.0 | |
|
Summary | 0001438: "Connection type" option player kick |
Description | Client has been kicked by reason: User info change flood.
|
Steps To Reproduce | 1.Go to Multiplayer
2.Quickly toggle connection type
3.You are pwned from the server! |
Additional Information | |
Tags | No tags attached. |
Relationships | has duplicate | 0001471 | closed | | Connection Type will kick you out the server. | has duplicate | 0001975 | closed | | Changing Update Rate causes a kick | has duplicate | 0002141 | closed | | Changing tics per update in the menu will kick you out of servers for user info flood | child of | 0002197 | closed | Dusk | Rebuild Zandronum menus for MENUDEF |
|
Attached Files | |
|
Issue History |
Date Modified | Username | Field | Change |
2013-07-29 20:35 | Monsterovich | New Issue | |
2013-07-30 17:31 | Arco | Note Added: 0006846 | |
2013-07-30 18:00 | Dusk | Note Added: 0006847 | |
2013-07-30 18:04 | Dusk | Priority | high => normal |
2013-07-30 18:04 | Dusk | Note Edited: 0006847 | bug_revision_view_page.php?bugnote_id=6847#r3823 |
2013-08-01 13:56 | Watermelon | Note Added: 0006877 | |
2013-08-01 16:05 | Dusk | Note Added: 0006886 | |
2013-08-19 03:44 | Blzut3 | Relationship added | has duplicate 0001471 |
2014-06-14 17:45 | Watermelon | Note Added: 0009324 | |
2014-06-14 17:45 | Watermelon | Status | new => feedback |
2014-10-29 19:47 | Dusk | Relationship added | has duplicate 0001975 |
2015-01-12 21:09 | Leonard | Note Added: 0011368 | |
2015-01-14 15:27 | fuleco | Note Added: 0011374 | |
2015-01-14 16:12 | Dusk | Note Deleted: 0011374 | |
2015-03-29 23:33 | Dusk | Relationship added | has duplicate 0002141 |
2015-04-01 03:56 | Watermelon | Note Added: 0011964 | |
2015-04-01 03:56 | Watermelon | Status | feedback => needs review |
2015-04-01 17:15 | Monsterovich | Note Added: 0011972 | |
2015-04-01 17:20 | Monsterovich | Note Edited: 0011972 | bug_revision_view_page.php?bugnote_id=11972#r6885 |
2015-04-01 17:26 | Monsterovich | Note Edited: 0011972 | bug_revision_view_page.php?bugnote_id=11972#r6886 |
2015-04-01 19:49 | Dusk | Note Added: 0011973 | |
2015-04-01 20:49 | Torr Samaho | Note Added: 0011974 | |
2015-04-01 20:50 | Torr Samaho | Status | needs review => feedback |
2015-04-02 13:08 | Watermelon | Note Added: 0011980 | |
2015-04-02 13:08 | Watermelon | Status | feedback => needs review |
2015-04-02 18:26 | Torr Samaho | Note Added: 0011981 | |
2015-04-02 18:31 | Torr Samaho | Status | needs review => feedback |
2015-04-28 18:22 | Dusk | Relationship added | child of 0002197 |
2015-04-28 18:22 | Dusk | Assigned To | => Dusk |
2015-04-28 18:22 | Dusk | Status | feedback => assigned |
2015-04-28 18:23 | Dusk | Note Added: 0012180 | |
2015-04-28 18:23 | Dusk | Target Version | => 3.0 |
2015-05-26 00:30 | Dusk | Status | assigned => needs testing |
2015-06-13 16:46 | WaTaKiD | Note Added: 0012685 | |
2015-06-13 16:47 | WaTaKiD | Status | needs testing => resolved |
2015-06-13 16:47 | WaTaKiD | Resolution | open => fixed |
2015-06-13 16:47 | WaTaKiD | Fixed in Version | => 3.0 |
2018-09-30 22:25 | Blzut3 | Status | resolved => 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?
|
|
|
|
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. |
|
|
|
Still the same in 2.0?
I think a buffer was added for this (could be wrong) |
|
|
|
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) |
|
|
|
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.. |
|
|
|
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? |
|
|
|
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. |
|
|
|
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. |
|
|
|
spam changing settings in network options/player setup no longer result in getting kicked from the server, so this is fixed |
|