[Steell]

Originally Posted by Powerlord From what I understand of the SourceMod vote API, this would involve a lot of extra work. The way it works now: Create vote menu. Send it to everyone via VoteMenuToAll When vote is finished, collect results (via normal VoteEnd callback or advanced callback). Change instantly for rtv, or set the next map. The way it'd have to work to present vote menus with a choice randomized: Split the players on the servers into random groups. Create a separate vote menu for each group. Send one vote menu to each group of people using VoteMenu. When each vote is finished, collect results (using advanced callback). Store the election results from each vote menu somewhere. Somehow figure out when all of the vote menus have been processed. Tally the votes from each of the individual votes. Change instantly for rtv, or set the next map. As you can see, the latter is considerably more complex, and SourceMod wasn't built to do it.

The way I would do it:

1. When populating the vote menu, add an option with an info string of "RANDOM" and a display string of "PLACEHOLDER".
2. In the VoteHandler callback, if the action is MenuItem_Display, change the text of the menu item to a random item in the vote (if the info string == RANDOM). Store which random item was selected for that client in an array.
3. When the vote is over, get all the clients who voted for the random item, look up what their items were in the array, and then add those votes to the votes for the real item.
4. Calculate the winner normally.

However, using this will break SourceMod's sm_voteprogress_hintbox cvar, since it will only display "PLACEHOLDER." In fact, no matter which method is used, the vote progress indicators will be broken. Because of that, I'm probably never going to build this into the main trunk of UMC (maybe I'll experiment with it a little).

[Steell]

Originally Posted by r3dw3r3w0lf Isn't the Map Rate plugin unapproved because of errors?

Hmm, looks like it just became unapproved recently. When I was working on the UMC3-beta, it was definitely still approved.

[Powerlord]

Originally Posted by Steell The way I would do it: When populating the vote menu, add an option with an info string of "RANDOM" and a display string of "PLACEHOLDER". In the VoteHandler callback, if the action is MenuItem_Display, change the text of the menu item to a random item in the vote (if the info string == RANDOM). Store which random item was selected for that client in an array. When the vote is over, get all the clients who voted for the random item, look up what their items were in the array, and then add those votes to the votes for the real item. Calculate the winner normally. However, using this will break SourceMod's sm_voteprogress_hintbox cvar, since it will only display "PLACEHOLDER." In fact, no matter which method is used, the vote progress indicators will be broken. Because of that, I'm probably never going to build this into the main trunk of UMC (maybe I'll experiment with it a little).

Ugh, you're going to be going by the menu item's name rather than its value and abusing the translation system to do it? :/

Oh well, at least it'll be experimental and not trunk.

[Steell]

Well it's easier than having to manage multiple vote menus (which I'm not even certain SM can do) IMO.

Also, although changing the display text at the time of a vote is most commonly used for translations, I wouldn't say that it was only designed for that purpose.

EDIT: Although if I went with his second request:

Originally Posted by .:{EK}:. SQUALL Note: you do not have to list the map in the first slot, you can just put it as: 1. random (please select for me i am lazy) 2. de_dust2 3. de_inferno 4. de_italy 5. de_militia and then the plugin will choose a random number 2-5 for that player.

Then I wouldn't even have to bother with renaming the menu item, and instead at the start I would just make an array with the size of MAXPLAYERS filled with random integers from [first menu item index] to [last menu item index] inclusive.

[Steell]

I know several of you have mentioned votes interfering with your game (preventing weapon changing with the number keys). Although I have added a few features to help with this issue (sm_umc_endvote_delayroundend, vote warnings, etc.) there was one feature asked a while ago that when a vote starts, a menu doesn't appear until the user types "vote" in chat.

Well, I've been thinking about that feature, and I realized that Valve has a menu system in place that requires you to press ESC in order to see the menu. In fact, HL2DM uses these menus by default (and actually can only use these menus).

So, my question now is: would you guys like to have a cvar to enable these Valve-Style (ESC) menus? Naturally it would default to your standard Radio (normal) menus, but for those of you who want users to be able to control when their menu appears, do you think this is a good solution?

[petro_f]

Steell, you ignored my question? Why? (post #1070)

Steell, ты игнорировал мой вопрос? почему?

[lamasniu]

Originally Posted by Steell I know several of you have mentioned votes interfering with your game (preventing weapon changing with the number keys). Although I have added a few features to help with this issue (sm_umc_endvote_delayroundend, vote warnings, etc.) there was one feature asked a while ago that when a vote starts, a menu doesn't appear until the user types "vote" in chat. Well, I've been thinking about that feature, and I realized that Valve has a menu system in place that requires you to press ESC in order to see the menu. In fact, HL2DM uses these menus by default (and actually can only use these menus). So, my question now is: would you guys like to have a cvar to enable these Valve-Style (ESC) menus? Naturally it would default to your standard Radio (normal) menus, but for those of you who want users to be able to control when their menu appears, do you think this is a good solution?

This could be rather interesting for we have been getting the same type of feedback from many of our regular players. So long as we are able to still show messages to the server letting them know that voting will comence, it is then up to the players to partake in the voting process, rather than it be imposed to them, thus avoiding the weapon switching issue.

Also to add I shall be going through your suggestions for AudioEmu & I with regards to the voting system allowing the repetition of maps been played when ever they are selected instead of been excluded if they have been played previously. We shall get back to you with our findings with regards to that issue, which to be frank is our main bone of contention as of now.

[MjrNuT]

Originally Posted by Steell I know several of you have mentioned votes interfering with your game (preventing weapon changing with the number keys). Although I have added a few features to help with this issue (sm_umc_endvote_delayroundend, vote warnings, etc.) there was one feature asked a while ago that when a vote starts, a menu doesn't appear until the user types "vote" in chat. Well, I've been thinking about that feature, and I realized that Valve has a menu system in place that requires you to press ESC in order to see the menu. In fact, HL2DM uses these menus by default (and actually can only use these menus). So, my question now is: would you guys like to have a cvar to enable these Valve-Style (ESC) menus? Naturally it would default to your standard Radio (normal) menus, but for those of you who want users to be able to control when their menu appears, do you think this is a good solution?

Yes, I would welcome such an implementation. I think that would go a long way.

[Steell]

Originally Posted by petro_f Steell, you ignored my question? Why? (post #1070)

I must have missed it earlier. If you are referring to what umc-echonextmap does, then yes I can make those messages stay on the screen longer.

[Steell]

Originally Posted by lamasniu Also to add I shall be going through your suggestions for AudioEmu & I with regards to the voting system allowing the repetition of maps been played when ever they are selected instead of been excluded if they have been played previously. We shall get back to you with our findings with regards to that issue, which to be frank is our main bone of contention as of now.

Well, allow me to elaborate for a bit here.

Each module stores it's own list of previously played maps. It updates this list at the start of each map, by grabbing the name of the current map, and the current map group (this is grabbed from umc-core).

Now, the issue is when UMC does not know what the current group is. Whenever UMC runs a vote / sets the next map, it also knows that group the map belongs to. However, there are situations where UMC cannot keep track of what group the next map will be. For example, if someone does "sm_map" or "changelevel" to change the current map, how is UMC to know what map group the user is intending to change to? The same goes for to sm_setnextmap command.

However, AudioEmu has pointed out that he was getting repeated maps when doing votes:

Originally Posted by AudioEmu I've tested by using sm_umc_mapvote to vote for maps. I know that the map the server starts on won't be tracked by UMC, so I've used that command to change it for testing purposes. The server defaults to badwater, so I vote for goldrush, then frontier, then goldrush again. My config is set to exclude the last 6 maps umc set, so goldrush -> frontier -> goldrush should be stopped because I was using a umc command to change them, no?

In this case, UMC should be able to keep track of which group is being played. I've done extensive testing and I can safely say that this should not be happening in version 3.0.1.

So this leads to two possibilities:

1. The umc-votecommand.cfg file is in the wrong place, which would explain why it's ignoring the setting of 6 for number of previous maps to be excluded.
   
   Or, the more likely:
   
2. You are not on version 3.0.1. Based on the fact that you're not seeing debug output from the umc-core.smx which I posted, I think for some reason SM isn't loading the newer version. Which is why I asked the following:

   Originally Posted by Steell That's really weird, I tested that .smx and it's logging debug information for me. Can you try giving your server a restart? I'd say try unloading and reloading umc-core, but sometimes that can do weird stuff since all the other modules depend on it. EDIT: Also, can you do an "sm plugins list" and tell me what SourceMod is reporting as the version of UMC (the debug build I attached above is 3.0.2).

   EDIT: Can't forget option 3:
   
3. It's still a bug and I'm still an idiot.

I hope this helps you guys out.