[Antixianos]

Is there a way to configure RTV timelimit?

[wickedd]

Originally Posted by Antixianos Is there a way to configure RTV timelimit?

Read the first post.

[Antixianos]

Originally Posted by wickedd Read the first post.

I should have specified: I'd like to set the time limit in a config file instead of having to type it in console everytime I play.

[wickedd]

Who said you have to type it every time you play?

[Antixianos]

Originally Posted by wickedd Who said you have to type it every time you play?

My server is a Listen Server so it is restarted everytime I play the game. Hence, the value reverts back to the default every new time.

[fysiks]

Originally Posted by Antixianos My server is a Listen Server so it is restarted everytime I play the game. Hence, the value reverts back to the default every new time.

That is what amxx.cfg is for. There's no reason it wouldn't work on a listen server.

[Doc-Holiday]

Originally Posted by fysiks That is what amxx.cfg is for. There's no reason it wouldn't work on a listen server.

Or setting the map change config to the server cfg and put it there

[Antixianos]

Originally Posted by DynamicBits Console Commands Note: These commands should be typed in the console of a client with the appropriate access level. They don't belong in a config file.

I don't understand. The first post clearly says the rockthevote commands don't belong in a config file.

I thought "cvar" meant something along the lines of console variable (set before game like mp_timelimit) while a command was something executed during in game (sv_restartround 1). I'm no coder though.

[fysiks]

Originally Posted by Antixianos I don't understand. The first post clearly says the rockthevote commands don't belong in a config file.

I totally forgot about this . . . However, after just looking through the code more thoroughly, I see that it is supposed to save all the information to a file and restore the settings every time a map starts. I don't see why that wouldn't work on a listen server. Do you have a mapvault.dat in your amxmodx/configs folder?

Originally Posted by Antixianos I thought "cvar" meant something along the lines of console variable (set before game like mp_timelimit) while a command was something executed during in game (sv_restartround 1). I'm no coder though.

Cvar means Configuration Variable. IMO, almost all of those would be more appropriate as cvars since they are actually configuration variables, but that is my opinion.

[cameron0620]

Originally Posted by urban_ninja Heres a common problem that been eating me with map votes. Some people tend to vote for a map and leave the server after their vote wins. This screws up a fair vote considering people that stay get their map they wanted overthrown in a close vote thanks to a guy or 2 voting something else who's no longer playing. I propose the idea to add a feature where admins can revoking a players voting rights who shits on a fair vote.

Originally Posted by urban_ninja It seems everyone has ignored this idea.

You need to realize that code executes in pieces. Once the voting function is complete and the next map is chosen, who voted for which map is irrelevant. To log who voted for which map and then add check cycles for whether people disconnect or not and which maps they voted for would add tons of overhead.

Not to mention that once a vote is completed many players accept the chosen map as the new map and make the choice to stay or not. Your method would mean that the next map would not actually be set until the map itself changes because as people leave the new map would change. I don't see that as fair on the people who see the results of the vote and decide to stay because that is the map they want to play.

The people that choose to leave after the vote obviously don't want to play the map that was voted for and in my opinion the fact that they leave shouldn't effect what map the players who choose to stay have to play.

The only way I see what you are asking for working is if a check was added to do a recount of the results only if someone leaves who voted for the winning map. Even that adds lots of overhead because who voted for what map would have to be saved after the voting function had completed and then rechecked when a player disconnects. On top of that, if a player disconnecting changes the results of the vote then the plugin would have to redisplay a message to remaining players explaining what happened and what the new map would be. If a second player disconnects changing the vote again, then even more messages would need to be displayed confusing players.

^^ This is all speculation on how the plugin code functions based on how I would write it without actually reading the code itself. It seems like that requested function would require a huge rewrite and more resources. I also think it would add uncertainty as to what the next map would actually be and whether or not players should stick around after a vote.

The idea has merit, but as I see it, the implementation would be more problematic than the problem it would solve.