0001438: "Connection type" option player kick

Notes
(0006846) Arco (updater) 2013-07-30 17:31	Non-issue. This was implemented for a reason.

(0006847) Dusk (developer) 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 (developer) 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 (developer) 2013-08-01 16:05	That sounds interesting.. would need the ability to merge two bytestreams but sounds doable.

(0009324) Watermelon (developer) 2014-06-14 17:45	Still the same in 2.0? I think a buffer was added for this (could be wrong)

(0011368) Leonard (developer) 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 (developer) 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 (reporter) 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 (developer) 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 (administrator) 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 (developer) 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 (administrator) 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 (developer) 2015-04-28 18:23	This was taken care of when I reimplemented the hold-back on userinfo changes.

(0012685) WaTaKiD (updater) 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

**Issue Community Support**
This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	WaTaKiD Leonard Monsterovich
Opponents:	No one explicitly opposes this issue yet.

Issue Community Support

This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.

Supporters:

WaTaKiD Leonard Monsterovich

Opponents:

No one explicitly opposes this issue yet.

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	View Revisions
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	View Revisions
2015-04-01 17:26	Monsterovich	Note Edited: 0011972	View Revisions
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