Bot running speed

[Neoptolemus]

Hi all,

Sorry if this has been dealt with before, but I have a weird issue with bots not running as fast as me. Even if I set their forward speed to the maximum value (or even an arbitrarily high number like 1000), they still run slightly slower than me, even if we're both carrying the same gun.

Is there something else I need to do to match their speed to mine? Perhaps something to do with their interval value or the fake client setup?

Unfortunately, googling the problem just brings up pages and pages of speed hacks and other CS 1.6 cheats

[The Storm]

You should always get the maximum speed value from the engine and not set hardcoded numbers. How actually you get it?

Always use pEdict->v.maxspeed of the bot for the RunPlayerMove() function.
Also you need to use the SetClientMaxspeed callback and write this code inside:

void pfnSetClientMaxspeed(const edict_t * pEdict, float fNewMaxspeed)
{
    ((edict_t *) pEdict)->v.maxspeed = fNewMaxspeed;
    RETURN_META(MRES_IGNORED);
}

This should fix your speed issues. Also beware that the code I pasted is from E[POD]bot and it might have minor difference from the one in HPB_bot but you get the idea.

[Neoptolemus]

Hi Storm,

It's weird, but I copied your code exactly, and made sure that the bot's speed was set to pBot->pEdict->v.maxspeed but they're still slightly slower than me when running in a straight line and carrying the same weapon. There is nowhere else in the code where this value is manipulated, so as far as I can tell it should be set correctly.

[The Storm]

Okay, how are you calculating the msec value for the RunPlayerMove function?

EDIT:
I checked out the HPB_bot msec value calculation and it seems wrong. Use the following value as the last argument of the RunPlayerMove() function:

gpGlobals->frametime * 1000.0f

Do not store it's value in a variable or if you do, make sure you update the value each time before you pass it to RunPlayerMove().

EDIT 2: Or just leave it as currently and fix it's calculation. This code is wrong:

// adjust the millisecond delay based on the frame rate interval...
      if (msecdel <= gpGlobals->time)
      {
         msecdel = gpGlobals->time + 0.5;
         if (msecnum > 0)
            msecval = 450.0/msecnum;
         msecnum = 0;
      }
      else
         msecnum++;

      if (msecval < 1)    // don't allow msec to be less than 1...
         msecval = 1;

      if (msecval > 100)  // ...or greater than 100
         msecval = 100;

It should become

// adjust the millisecond delay based on the frame rate interval...
      if (msecdel <= gpGlobals->time)
      {
         msecdel = gpGlobals->time + 0.5;
         if (msecnum > 0)
            msecval = 450.0/msecnum;
         msecnum = 0;
      }
      else
         msecnum++;

      if (msecval < 1)    // don't allow msec to be less than 1...
         msecval = 1;

      if (msecval > 255)  // ...or greater than 255
         msecval = 255;

First try the second option that I posted. If does not work try the first one.

[Neoptolemus]

Originally Posted by The Storm

I checked out the HPB_bot msec value calculation and it seems wrong. Use the following value as the last argument of the RunPlayerMove() function:

gpGlobals->frametime / 1000.0f

Not quite, frametime is in seconds and RunPlayerMove expects milliseconds as the last parameter, so it's gpGlobals->frametime * 1000.0f

To be honest I have no idea what the HPB_Bot code is even doing if it's really as simple as just the delta in milliseconds between the last frame and the current frame. It looks like it's trying to calculate the frametime in milliseconds independently, averaged over half-second intervals? Seems like an odd approach when you have gpGlobals->frametime just there begging to be used.

Even that or your second suggestion doesn't seem to help however, they're still slower than me. Consider this a conundrum masquerading as a mystery. Seems like it has to be the max speed value that's not set correctly, I'll do some more digging.

[The Storm]

Yes, you are right. I will now correct my answer. It's been long time and I'm going on memory...

Anyway could you send me your code with some easy way to test what is wrong? There is really no other stuff I can think of that can affect the move speed.

[Neoptolemus]

I did some more testing, I output the bot's max speed and current speed (length of pEdict->v.velocity), and my max speed and current speed every frame.

The really bizarre thing is that our v.maxspeed values are both 250.0, and when running together our v.velocity was 250.0 as well (except for a few frames where I managed to hit 260.0, possibly running at an angle?), yet I still easily overtake the bot while running behind them. What the heck?!

Will tidy up some other stuff I've been working on and then post the code so you can take a look.


EDIT: I think I might have fixed it. I was previously had vsync turned off as it caused judder when in windowed mode, but I just reactivated it and suddenly I can't overtake the bot. I previously seemed to have a hard cap of 100fps with vsync disabled, I wonder if this was causing a discrepancy between gpGlobals->frametime (which the bot was relying on) and my actual framerate? Ah well, I'll still post some code when I've tidied up a few things. Need to re-implement combat properly.

[The Storm]

Okay then, just one more modification I can suggest that you can test out:

1. Define in bot_t structure the following variable:
float f_previous_command_time;
2. In bot_func.h declare this function:

byte ThrottledMsec( bot_t *pBot );

3. Then in bot.cpp

byte ThrottledMsec( bot_t *pBot )
{
	int newmsec = (int)( (gpGlobals->time - pBot->f_previous_command_time) * 1000 );
	if (newmsec > 255)  // Doh, bots are going to be slower than they should if this happens.
		newmsec = 255;		 // Upgrade that CPU or use less bots!

	return (byte)newmsec;
}

4. Somewhere in BotSpawnInit() function init our new variable like this:

pBot->f_previous_command_time = gpGlobals->time;

5. Then just before RunPlayerMove call do this:

// Adjust msec to command time interval
byte adjustedmsec = ThrottledMsec(pBot);

// save the command time
pBot->f_previous_command_time = gpGlobals->time;

g_engfuncs.pfnRunPlayerMove( pEdict, pEdict->v.v_angle, pBot->f_move_speed,
                                0, 0, pEdict->v.button, 0, adjustedmsec );

This is the code the official CSBot uses. I took from the example bot framework in the HLSDK on github and modified it a bit to pass nice with HPB_bot.
In this way if the RunPlayerMove() call modifies the globalTime it will be considered for the next bot in line. Also is more accurate if you decide to not call BotThink() each frame in order to save CPU.

Note: Beware that the HPB_bot have multiple places that calls RunPlayerMove(). Be sure to do this before each call.

EDIT: Actually yes, if you have some kind of video setting that will cause the msec value to go higher than 255, the bots will be slow. This is too much time between frames. So I guess that you had solved it.

[Neoptolemus]

Thanks, I'll give that a try. I'm running a quad core i7 so my framerate without vsync was hard capped at 100fps (at least that's what it said when I set cl_showfps 1), but for some reason turning vsync on fixed the issue. The problem is that vsync doesn't seem to work properly in HL as my framerate then goes all over the place, but that's a different issue. I'd rather the bots worked properly regardless of vsync, so I'll try your suggestion!

I changed the structure of HPB bot, RunPlayerMove only gets called once now at the end, and various functions modify the bot's X and Y speeds and buttons before it gets called. Code looks much neater now, my BotThink function is only a few lines long

[The Storm]

I always play with vsync off and I have no issues. I don't like CS running on 60fps. Perhaps you have issues with the video drivers?

Anyway I will be going on vacation now, so I will not be around for a while(2 weeks). Anyway keep your progress posted.