NEW STEAM: Failure on detecting round, how do YOU do it?

[stefanhendriks]

Well, i got word from Alfred that this is unique to the round-start function code in CS. So i'll take that code, as its only needed for round-start

[Pierre-Marie Baty]

BTW, this thread rather belongs to the SDK coding forum since it's HL specific, no ?

I'm moving it there.

[Terran]

@stefanhendriks:
I'm not sure if I understood correctly. You are using Alfreds or PMBs code?

[KaCaT]

Below is the code that I'm using to detect a new round in CS 1.6 (adapted from statsme):

extern float g_fTimeNewRound;

void BotClient_CS_TextMsg (void *p, int bot_index)
{
 static bool bWillRestart;
 if (state == 0)
 {
  state++;
  return;
 }
 else if (state == 1)
 {
  bWillRestart = FALSE;

  if (strncmp("#Game_C", (char *)p , 7) == 0) // "Game Commencing!"
   g_fTimeNewRound = gpGlobals->time + 3.07;
  else if (strncmp("#Game_w", (char *)p , 7) == 0) // "The game will restart in ..."
   bWillRestart = TRUE;
 }
 else if (state == 2)
 {
  if (!bWillRestart)
   return;

  g_fTimeNewRound = gpGlobals->time + atoi((char *)p);
 }
 state++;
}

void BotClient_CS_SendAudio (void *p, int bot_index)
{
 if (state == 0)
 {
  state++;
  return;
 }
 else if (state == 1)
 {
  if ((strcmp((char *)p, "%!MRAD_terwin") == 0) || // "Terrorists Win!"
   (strcmp((char *)p, "%!MRAD_ctwin") == 0) || // "Counter-Terrorists Win!"
   (strcmp((char *)p, "%!MRAD_rounddraw") == 0)) // "Round Draw!"
  {
   g_fTimeNewRound = gpGlobals->time + 5.07;
  }
 }
}

in StartFrame()

if (g_fTimeNewRound && (g_fTimeNewRound < gpGlobals->time))
  {
   g_fTimeNewRound = 0;
   // New round detected, do what you want to do now

[Pierre-Marie Baty]

wow... does StatMe really do that ?? it's ugly

[stefanhendriks]

i got code from Alfred (of Valve) , he replied to my 'angry' mail at the hlcoders list...

he said that code is always called at round start (as i show above), so i rely on that.

And yes, that statsme code is very ugly.

[botmeister]

I don't like any of the methods, they are all ugly and inaccurate options to choose from. This is not my opinion, I before reading this, I did extensive tests to see if I could find a good solution, I explored each of the options mentioned and they all have problems.

At this point, the statsme code is the only code that will work most of the time, and possibly all the time.

All the other methods do not work 100% and some probably don't even work at all, like the HLTV message detection because the HLTV message is sent at regular intervals during a round and not just during a round start. I gave up on that method quickly.

The RoundTimer message is sent ONLY when there are players in a game. This may work fine for some plugins, but is of no use to plugins that require knowing when a round started no matter if there are players in game or not. Also, because the round start is detected only when the round ends, you should also check for "worldspawn" to detect a fresh mapload or first round after the server started. The problem with "worlspawn" is that there is a delay from that activity to when the round actually starts, so your timing may be off by a few seconds.

In each case, multiple messages will be detected, meaning your code will detect multiple round starts for every round start! This can lead to problems. For example, knowing when the round actually started is not accurate. If you stop your bots from moving until after the roundstart delay, your bots will be stuck for a few seconds after the delay passed depending on when the last round start message was detected.

It's just damn UGLY!

I'll keep searching for a good solution. Does anyone know how to monitor the roundtimer? That's the time telling you how much time is left in the round. I don't think this will help by itself, but it may be part of a foolproof solution.

This is what you get for hacking into someone else's code.

[Pierre-Marie Baty]

@botmeister : don't forget that we are hooking the date when the messages are being SENT, not the date at which clients receive them. And such messages are all sent in a row in the same frame, for each client in the game. Thus you won't be triggering the round start several times but only ONCE provided all you do is raising a boolean flag that you will check later on in StartFrame.

Also, as I explained, ServerActivate() DOES raise this flag too and since ServerActivate is the LAST function to be called before the first StartFrame(), I can hook map changes and server restarts like this as well. I don't find this "ugly", I find this very neat instead...



...RoundTime is not sent when no players/bots are in game ? Sure, but nevermind for me, my code does strictly nothing when there are no bots or players in game. Anyway, as soon as a player will join, the round will immediately restart. So...

[botmeister]

Originally Posted by Pierre-Marie Baty

@botmeister : don't forget that we are hooking the date when the messages are being SENT, not the date at which clients receive them. And such messages are all sent in a row in the same frame, for each client in the game. Thus you won't be triggering the round start several times but only ONCE provided all you do is raising a boolean flag that you will check later on in StartFrame.

OK, but for some reason in my tests the messages are being delayed, perhaps my code has a problem. No matter, I won't be considering the roundtime option anyway because it is not universal (requires players in game) and I don't want to deal with multiple messages if I don't have to.

Also, as I explained, ServerActivate() DOES raise this flag too and since ServerActivate is the LAST function to be called before the first StartFrame(), I can hook map changes and server restarts like this as well. I don't find this "ugly", I find this very neat instead...

OK, I'll try ServerActivate(), that sounds like a good solution to the worldspawn delay. For it to work it has to get called on each map start, even if the same map is reloaded, and if the map is loaded manually using commands from the server console or from a timeout. Are you sure it will do this in every case?

I have to correct myself. The HLTV message check actually DOES appear to be the very best solution. I missed the obvious, and it's what Stephan's function points out, you have to look for a message that looks like this:

Message_Begin
MessageType: 125
MessageDest: 9
WriteByte : 0
WriteByte : 0
Message_End

This form of message appears to be sent only once after a round ends. The in round messages have nonzero values for each byte, although more tests are needed to confirm this. So using it, along with the ServerActivate() function hook (as PMB points out) should give us a fool proof and universal method of detecting a round start.

...RoundTime is not sent when no players/bots are in game ? Sure, but nevermind for me, my code does strictly nothing when there are no bots or players in game. Anyway, as soon as a player will join, the round will immediately restart. So...

Yes, I agree the RoundTime solution may work for you, but it won't work for some other plugins. In your case, you may want to detect a roundstart only if there are bots in a game, so you could even check to see if the messages are being sent to bots or not. However, the tests I did gave me a long delay from when the last message was sent and when the round actually started, but if you don't have this same problem, then the problem may be with my code. In any case, I still like the HLTV message solution best

[Pierre-Marie Baty]

Regarding ServerActivate(), yes, it is called everytime a new map boots in. Actually a new map means a new server ; each time you change level (even in single player with level transitions), or force a level restart, in whatever manner you want, you will force a call to ServerDeactivate() immediately after the last StartFrame() in which the command was triggered, and a call to ServerActivate() immediately before the first StartFrame() of the new map.

<facultative>
Why I'm reluctant to using HLTV messages is that HLTV is an "external" application using a not-so-well defined protocol, that changes very often. And the purpose of HLTV messages is not for notifying players of a round change, actually if this code is specific to a round change in CS it's pure coincidence ; and on the contrary, notifying clients of a change in the round timer is exactly the point of RoundTime messages...
</facultative>