[Steell]

Originally Posted by DoPe^ Hey there, i don't know if it's only me, but i got an issue with the RTV part of UMC.. lets say a player types rtv, the server then tells everyone "11 more are required to type rtv bla bla bla." then someone else types it "9 more are required to type rtv bla bla bla." and when the next one does it, it says "6 more" even though the player number on the server havnt dropped.

Thanks for the report. This is a known issue. I will have a fix present in the next version.

[Steell]

Originally Posted by dylstew Sorry to bother you steel but you never answered this(probably because you don't know the answer but I want to be sure:

I asked a while back, but is there anything in the UMC or SourceMod error logs?

[DoPe^]

Originally Posted by Steell Thanks for the report. This is a known issue. I will have a fix present in the next version.

awesome! thanks

[cssBOT]

Ok. Finally got UMC to run for more than 2 days without causing cpu stall by reverting from 3.4.1 back to 3.3.2

Unfortunately Valve update borked 3.3.2. On map change the server doesn't actually restart but dumps all the clients and cycles to the startup map.

Confirmed it's UMC by uninstalling and reverting to SM mapchooser,rtv,nomination,and randomcycle. Server mapchanges and functions fine with SM's.

[cssBOT]

Installed new SM and sdkhooks builds released this morning and now UMC 3.3.2 works again.
sourcemod-1.4.5-hg3542-windows
sdkhooks-2.2.0-dev-hg197-windows

Something wrong with 3.4.1, causes that cpu race condition on random map changes.

[Steell]

Originally Posted by cssBOT Installed new SM and sdkhooks builds released this morning and now UMC 3.3.2 works again. sourcemod-1.4.5-hg3542-windows sdkhooks-2.2.0-dev-hg197-windows Something wrong with 3.4.1, causes that cpu race condition on random map changes.

That's certainly odd. You're the only one reporting this issue unfortunately. If I were you, I'd try building the UMC 3.4.1 source yourself and see if that solves your issue.

If you don't know how to do that, then I will try to get a fresh build available for you with a checksum so you can confirm that things are not getting corrupted between here and your server.

[Steell]

Originally Posted by cssBOT Ok. Finally got UMC to run for more than 2 days without causing cpu stall by reverting from 3.4.1 back to 3.3.2 Unfortunately Valve update borked 3.3.2. On map change the server doesn't actually restart but dumps all the clients and cycles to the startup map. Confirmed it's UMC by uninstalling and reverting to SM mapchooser,rtv,nomination,and randomcycle. Server mapchanges and functions fine with SM's.

Originally Posted by cssBOT Installed new SM and sdkhooks builds released this morning and now UMC 3.3.2 works again. sourcemod-1.4.5-hg3542-windows sdkhooks-2.2.0-dev-hg197-windows Something wrong with 3.4.1, causes that cpu race condition on random map changes.

I've taken a look at your logs, and there is something really strange happening:

L 08/22/2012 - 18:59:18: [umc-randomcycle.smx] SETUP: Hooking intermission...
L 08/22/2012 - 18:59:19: [umc-rockthevote.smx] RTV will be made available in 30 seconds.
L 08/22/2012 - 18:59:39: [umc-randomcycle.smx] SETUP: Hooking intermission...
L 08/22/2012 - 18:59:40: [umc-rockthevote.smx] RTV will be made available in 30 seconds.
L 08/22/2012 - 18:59:58: [umc-randomcycle.smx] SETUP: Hooking intermission...
L 08/22/2012 - 19:00:00: [umc-rockthevote.smx] RTV will be made available in 30 seconds.
L 08/22/2012 - 19:00:19: [umc-randomcycle.smx] SETUP: Hooking intermission...
L 08/22/2012 - 19:00:20: [umc-rockthevote.smx] RTV will be made available in 30 seconds.
L 08/22/2012 - 19:00:51: [umc-rockthevote.smx] RTV is now available.
L 08/22/2012 - 19:00:59: [umc-randomcycle.smx] SETUP: Hooking intermission...
L 08/22/2012 - 19:01:01: [umc-rockthevote.smx] RTV will be made available in 30 seconds.
L 08/22/2012 - 19:01:32: [umc-rockthevote.smx] RTV is now available.
L 08/22/2012 - 19:02:52: [umc-randomcycle.smx] SETUP: Hooking intermission...
L 08/22/2012 - 19:02:53: [umc-rockthevote.smx] RTV will be made available in 30 seconds.
L 08/22/2012 - 19:03:24: [umc-rockthevote.smx] RTV is now available.

There are a lot of sections like this where RTV is being made available constantly. But more important is the "SETUP: Hooking intermission..." log, which appears in other places, often right before a map change:

L 08/22/2012 - 19:56:30: [umc-randomcycle.smx] SETUP: Hooking intermission...
L 08/22/2012 - 19:56:30: [umc-core.smx] ---------------------MAP CHANGE: gg_fy_funtimes---------------------

If you were not constantly re-installing or reloading UMC, then there is something wrong with your SourceMod installation that is causing it to do that.

[schwarz]

L 08/25/2012 - 10:04:14: [umc-core.smx] ---------------------MAP CHANGE: deathrun_iceworld_v2fix---------------------
L 08/25/2012 - 10:04:14: [umc-endvote.smx] Unable to create end of map vote time-trigger, trigger time already passed.
L 08/25/2012 - 10:04:15: [umc-endvote.smx] Unable to create end of map vote time-trigger, trigger time already passed.
L 08/25/2012 - 10:04:15: [umc-rockthevote.smx] RTV will be made available in 30 seconds.
L 08/25/2012 - 10:04:15: [umc-endvote-warnings.smx] Successfully parsed and set up 11 vote warnings.
L 08/25/2012 - 10:04:15: [umc-playercountmonitor.smx] Min Players: 0, Max Players: 34
L 08/25/2012 - 10:04:15: [umc-playercountmonitor.smx] Server will begin watching for inproper number of players in 240 seconds.
L 08/25/2012 - 10:04:17: [umc-endvote.smx] End of map vote will appear after 658 seconds
L 08/25/2012 - 10:04:17: [umc-endvote-warnings.smx] First time-warning will appear 10 seconds before the end of map vote.
L 08/25/2012 - 10:04:17: [umc-endvote.smx] Map vote timer successfully updated.
L 08/25/2012 - 10:04:46: [umc-rockthevote.smx] RTV is now available.
L 08/25/2012 - 10:05:53: [umc-endvote.smx] End of map vote will appear after 660 seconds
L 08/25/2012 - 10:05:53: [umc-endvote-warnings.smx] First time-warning will appear 10 seconds before the end of map vote.
L 08/25/2012 - 10:05:53: [umc-endvote.smx] Map vote timer successfully updated.
L 08/25/2012 - 10:08:15: [umc-playercountmonitor.smx] Server is now watching for inproper number of players.

Type nextmap , it show [SM] pending vote
SM 1.4.5 and metamod 1.8.8

I tested it with SM 1.4.4 = works nextmap but crash menu admin , after I updated 1.4.5 then fail nextmap

thanks

[rediem]

I'm getting crashes on nextmap now too, no errors in log, started happening when I restarted the server...

[cssBOT]

Originally Posted by Steell I've taken a look at your logs, and there is something really strange happening: There are a lot of sections like this where RTV is being made available constantly. But more important is the "SETUP: Hooking intermission..." log, which appears in other places, often right before a map change: L 08/22/2012 - 19:56:30: [umc-randomcycle.smx] SETUP: Hooking intermission... L 08/22/2012 - 19:56:30: [umc-core.smx] ---------------------MAP CHANGE: gg_fy_funtimes--------------------- If you were not constantly re-installing or reloading UMC, then there is something wrong with your SourceMod installation that is causing it to do that.

I guess I confused things by commenting about two issues at once. The logs I posted were showing errors occurring with UCM 3.3.2 after the valve update. Apparently it was SM based as they (SETUP: Hooking intermission...) went away when I updated SM on 8/23 to 1.4.5-hg3542-windows

The cpu race condition problem I posted logs before. It was also documented by another poster. You suggested disabling the map commands module first and reverting to 3.3.2 here: http://forums.alliedmods.net/showpos...postcount=2815
So I did, and I'm just giving you the feedback that for sure 3.4.x causes the condition and 3.3.2 does not. I also know of one other GG server running UMC and coincidentally it's running ver 3.3.2. I don't know the owners or why. I was wondering perhaps if it may had anything to do with when the mapvote is triggered. I have it configured so GG calls umc-votecommand when the game ends and people vote during the chat time. Could perhaps randomcyle be interfering?