[PharaohsPaw]

No worries - I've been out of the whole loop for a while now, the new CS:GO sort of sparked my interest again. Maybe it'll be different this time. (I keep telling myself that haha)

I think that's the same one (bug) I saw the other day.

[PharaohsPaw]

Originally Posted by KawMAN You don't need that line PHP Code: new Handle:csgo_strnm_version = INVALID_HANDLE;

KawMAN thanks for this, it fixed the compile warning.

Updating version etc.

[fightarena]

!! Huurraa i have waiting for plugin like that, thanks.

[Baron Rojo]

works thank you very muck

[PharaohsPaw]

Just a quick heads-up:

This plugin still works correctly after the 9/14/2012 update -- ie it still intercepts the canned Next Map message and shows the map that SM is going to switch the map to next.

Valve did, however, make some changes related to mapcyclefile/mapgroup with the 9/14/2012 update. I don't quite have a handle on what all they changed yet -- I'm basically having to guess/test/etc. since they didn't bother to TELL us in the update news announcement -- but one thing I know for sure is mapcyclefile (the CVAR) is now hidden/locked. That may not be a bad thing, not sure yet.

[cssBOT]

there was no mapcyclefile cvar in 1.18.0.3 or do you mean the command line?

I really don't think it matters, map cycle control seems to be borked under cs:go period right now.

[cssBOT]

P.S. New cvar in 1.19.0.0 that may be relevant to your plugin:
"nextlevel","0 ",,,"GAMEDLL",,,"NOTIFY",,,,,,,,,,,,,,"If set to a valid map name, will trigger a changelevel to the specified map at the end of the round"

[PharaohsPaw]

There WAS a mapcyclefile cvar in 1.18.0.3, and there still IS one as of the 9/14 update. It is hidden, meaning you have to use sm_cvar to access or set its value.

Valve may be trying to discourage its use to avoid "confusion" -- confusion they caused by going to this mapgroup system and still having a mapcyclefile cvar that parts of the dedicated server still uses. But it IS still there and it IS still used. Sourcemod still uses it too, unless you configure your maplists.cfg to not use mapcyclefile for anything.

Now, regarding that nextlevel cvar --

It doesn't make a lot of sense to manipulate that cvar if doing so is going to force a map change at the end of the round, rather than the end of the map, as the cvar description states. Even if it doesn't change the map at round end as the description states, deciding WHEN it would be appropriate to set nextlevel could be rather complicated. What if some other plugin changes it? All of this leads to more code and maintenance of that code, or cases you can't handle, or at least not without more code and time put into it.

WHY BOTHER WHEN IT IS A LOT SIMPLER TO JUST REPLACE THE CANNED MESSAGE???

Since what SourceMod thinks the next map is supposed to be is what you're going to get for the next map anyway, all this plugin needs to do is intercept the CS:GO server's canned message and replace it with one that says what SM thinks the next map is supposed to be.

I usually run cvarlist after an update too. Just keep in mind, that doesn't always show you everything that's really there (and really USED)...

[PharaohsPaw]

LOL now that I think about it, I bet this whole mapgroup thing is a leftover/side effect of using an L4D-type engine, where campaigns were used.

[PharaohsPaw]

Just a quick call-out and thank-you to Nextra who has had some good ideas on things that could be done for and added to this plugin -- he may be coming out with one of his own in a separate thread.

I've been thinking about adding a CVAR to have just a plain Next Map: message (like the stock one, but with the correct next map) and Nextra's idea of giving an option to block it altogether is a good one too.

I've got a few things I'm working on right unfortunately but I'll get these things done soonish. Please feel free to check out Nextra's work also if he posts his in a separate topic.

Thanks for the coding examples Nextra -- I'd ++ you if there was karma