0000548: Vote system honors MapList regardless of SV_MapRotation state.

Notes
(0002114) DevilHunter (reporter) 2011-08-11 05:17	This SHOULD be accepted. However, I have yet to be on a server when such a thing happens. Does sound annoying enough to be worked on.

(0002230) cq75 (reporter) 2011-10-09 00:49	Has there been any interest in adding this? This feature could be really helpful.

(0002266) Vicious Pariah (reporter) 2011-10-21 01:55	This is my first post, so here goes. I completely agree with this. I believe that there is a better gain to working on this. I do not believe that the system that is currently used is very efficient, and Tiger hits on that subject pretty well. I would like to add more to this, however. I believe that would be a necessary change for people (like me) that host Cooperative or Survival servers using wads that use secret maps (ie. Doom 2, Heretic, Ultimate Doom, etc.). The purposes for using the "callvote map" and "callvote changemap" commands are probably pretty well known, so I will skip that part of my post. Servers that have these two commands enabled and happen to be of Cooperative and Survival gamemode are at an automatic disadvantage. Why? Because most (if not all) server hosts that host megawads with secret maps will not enable the maplist. Now, for those of you that don't understand how the Map Rotation list currently works, it is pretty straightforward, with one single cvar, Sv_MapRotation. This value can be 0 (false) or 1 or greater (true). I believe that there is a side effect that happens when you set the Map Rotation to be true; that when the cvar is enabled, a "whitelist" - maps in the MAPLIST will be whitelisted, so that players will be able to vote for these maps using the "callvote map" and/or "callvote changemap" command - and a "blacklist" - maps that are not in the MAPLIST will be blacklisted, so that players will NOT be able to vote for thse maps. This blacklist is extremely useful to disallow players from voting maps, such as credmap, in servers. However, since enabling the cvar will enable the maplist, a problem is presented to these particular server hosts (myself included): the order of the maps in the Map Rotation list matter. If you set a MAPLIST as the following: MAP01 MAP02 ... MAP15 MAP16 ... MAP30 MAP31 MAP32 The maplist will advance to MAP16 from MAP15 no matter what, if I remember correctly. However, if you have a MAPLIST as the following: MAP01 MAP02 ... MAP15 MAP31 MAP32 MAP16 MAP17 ... MAP30 You may think to be fixing the problem; of course, MOST people would want to use the secret exit on MAP15. But this produces an unusual side effect, doesn't it? If you try to use the normal exit now, you will automatically advance to MAP31, no matter what. You could also try doing a MAPLIST of MAP01-MAP30 without the secret maps, but then that would not solve the problem of not being able to use both the normal exits and secret exits. There's three possible solutions to this that I have created in my mind. One of them is Tiger's. I will start with his. 1.) Create the Map Rotation such that it works as it does currently, but enable the blacklist no matter what the value of Sv_MapRotation is. This solution will work, and I think might be the easiest. But would it be the most efficient choice? I know why Tiger made this suggestion, however; it may be far easier to implement this than to do the other two I am about to post. In fact, I think this solution is the way to go for the fact that it solves the problem. However, there's two other methods that I would still like to point out, and one can judge for themself which one is the "better" choice: 2.) Instead of choosing 1.), make a separate cvar that deals with blacklisting. I believe that the blacklist was not always implemented and I am not sure why it got implemented the way it did. I suppose it was simplest. However, Tiger's solution leaves out the possibility that someone--we don't know who, or how often this could happen--might want to disable the blacklist altogether. In this case, a separate cvar might be the dominant choice, as opposed to keeping the blacklist enabled permanently. When the cvar's value is 0, then the blacklist will not be enabled. However, when the cvar's value is 1, the blacklist WILL be enabled, and players will NOT be able to call a vote for maps that are not in the MAPLIST. Note that this cvar would not be affected by the value of Sv_MapRotation. There is a third option, however; and it follows the same, current blacklisting system. 3.) Instead of permanently enabling the blacklist, or even creating a cvar for it, just make it so that players can use secret exits and normal exits as it would normally without a Map Rotation list, using a MAPLIST. I am not even sure if any of these 3 solutions (or a different one, for that matter) has been used (and implemented) in 98e. But I do not believe so, so I am going to post these up. Feel free to make any suggestions or comments regarding my post or this issue. I think that feature could be really useful and should be looked at.

(0002346) Minigunner (reporter) 2012-01-09 04:45 edited on: 2012-01-09 04:48	The MAPINFO in the PWAD (or skulltag.pk3 if playing an IWAD) should check for a SecretNext property, then put the defined secret map in a special whitelist, if it isn't in the maplist already. Then, after finishing the secret map(s), the normal exit should override the maplist and go to the defined next map. The list will resume from there. If someone votes for the secret map, and it is not in the maplist but is in the "Secret" whitelist, it should fail as if it is blacklisted.

(0002347) Qent (updater) 2012-01-09 05:35	I think that, regardless of what other features get in, votes should always be limited to the maplist.

(0002507) Vicious Pariah (reporter) 2012-01-21 16:21	I tried reproducing the second part of Tiger's reproducibility section in his post and tried reproducing the results using my own example, but I had no luck. Can someone confirm this? If the MAPLIST works as intended already, there will be no need to have this feature.

(0003111) TIHan (reporter) 2012-04-02 05:20 edited on: 2012-04-02 05:41	It seems as though secret levels are already honored even though they are not in the map list. Exiting secret levels also go to their proper next map no matter the map rotation. This means the maprotations are not advanced on secret exits. That was one big reason why this feature got brought up. ATM, I don't see any other good reason to have this feature. The only one I can think of is if in custom pwads their nextmaps are seemingly all over the place, but the admin should know about that before hand and he can set up the maplist accordingly. Edit: I think I may have found a good reason. So, secret levels are honored, right? Well the secret level that you are on, its nextmap is not honored, as this will go back to the next map in rotation instead of the map specified. This problem we can handle in two ways: 1. We could use the feature suggested here. 2. We honor the secret level's nextmap ONLY if the secret level was gotten to by a secret exit on the previous map. Using the first way, also this suggestion, there could be some badness for levels that have end games depending on how we handle end games. Perhaps end games are special, and will treat the game as a MapRotation even if its disabled. The second way I can also see some danger as someone could put an endgame as a secretlevel's nextmap...

(0003163) TIHan (reporter) 2012-04-07 06:17 edited on: 2012-04-07 06:52	Added. 'https://bitbucket.org/TIHan/tst/changeset/d87f4ef79073 [^]' This is my attempt at implementing this suggestion. Very little code was involved here. The only thing I'm worried about is ubiquitous language.

(0003506) TIHan (reporter) 2012-04-30 03:56	Marking this as needs review as there is a lot of support for this suggestion. I believe Tiger tested a build I sent to him and said that it worked as intended with sv_maprotation true and false.

(0009623) Torr Samaho (administrator) 2014-06-21 16:01	I couldn't use the patch itself (letting MAPROTATION_IsMapInRotation return true if there are no maps in the rotation just asks for trouble), but I changed the effective behavior as requested:'https://bitbucket.org/Torr_Samaho/zandronum-stable/commits/50f0bdd1137419094ca72807b82f5d379a50345e [^]'

(0009975) Arco (updater) 2014-07-15 23:50	Works as intended in v1.3 140710-1509.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	Vicious Pariah
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2011-08-03 08:22	Tiger	New Issue
2011-08-11 05:17	DevilHunter	Note Added: 0002114
2011-10-09 00:49	cq75	Note Added: 0002230
2011-10-21 01:55	Vicious Pariah	Note Added: 0002266
2012-01-09 04:45	Minigunner	Note Added: 0002346
2012-01-09 04:48	Minigunner	Note Edited: 0002346	View Revisions
2012-01-09 05:35	Qent	Note Added: 0002347
2012-01-21 16:21	Vicious Pariah	Note Added: 0002507
2012-04-02 04:20	TIHan	Assigned To	=> TIHan
2012-04-02 04:20	TIHan	Status	new => assigned
2012-04-02 05:20	TIHan	Note Added: 0003111
2012-04-02 05:20	TIHan	Status	assigned => feedback
2012-04-02 05:41	TIHan	Note Edited: 0003111	View Revisions
2012-04-07 06:17	TIHan	Note Added: 0003163
2012-04-07 06:52	TIHan	Note Edited: 0003163	View Revisions
2012-04-30 03:56	TIHan	Note Added: 0003506
2012-04-30 03:56	TIHan	Status	feedback => needs review
2014-06-21 16:01	Torr Samaho	Note Added: 0009623
2014-06-21 16:02	Torr Samaho	Assigned To	TIHan =>
2014-06-21 16:02	Torr Samaho	Target Version	=> 1.3
2014-06-21 16:02	Torr Samaho	Assigned To	=> Torr Samaho
2014-06-21 16:02	Torr Samaho	Status	needs review => needs testing
2014-07-15 23:50	Arco	Note Added: 0009975
2014-07-15 23:50	Arco	Status	needs testing => resolved
2014-07-15 23:50	Arco	Resolution	open => fixed
2014-07-15 23:50	Arco	Product Version	=> 1.2
2014-07-15 23:50	Arco	Fixed in Version	=> 1.3
2018-09-30 21:36	Blzut3	Status	resolved => closed

Relationships