FL_FAKECLIENT issue fixed
 

We were able to fix the issue with the Official Counter-Strike Bot's use of FL_FAKECLIENT causing problems with 3rd party bots.

As a test, we ran a server with both POD-bots and CSBots at the same time.

This fix will appear in a future Steam update (probably next Wednesday, the 21st).

I apologize for any inconvenience this may have caused.

-Mike

Re: FL_FAKECLIENT issue fixed
 

the official csbot was released?

Re: FL_FAKECLIENT issue fixed
 

Now that is good news!!! See, all was needed was to get rid of that stupid flag and keep track of who is a bot and who is not one layer higher (as a bool flag in CBaseStuff instances for example). AFAIK the engine does not use FL_FAKECLIENT at all, anyway ; it's only a convenient bit that was put there for bot makers to flag their bots.

Now the bad side of this is that I can drop completely my "bot stub" project that would have made all the old bot DLLs work in CS 1.6 :( Bah, no problem - gives me more time to do other stuff, w00t!

Nice work Turtle !

Re: FL_FAKECLIENT issue fixed
 

Excellent news!

Actually, I thought the flag was not all that convenient because you'd have to reset it on each frame.

The old bots won't work all that great if they buy things using the menu select commands, so a buy menu translator could still be built if you wanted to do that.

Anyhow, it's great that there's now some communication between us and the official bot developer :)

Re: FL_FAKECLIENT issue fixed
 

The FL_FAKECLIENT flag is used by the engine to optimize network traffic. For example, "fake clients" (ie: bots) do not need to be sent various network messages.

So, it was important that we fix this issue, because the workaround of using another bit could cause extraneous network traffic for 3rd party bots.

-Mike

Re: FL_FAKECLIENT issue fixed
 

lol, so even our 'fix' , 'bugs' something ;)

great work! :)

Re: FL_FAKECLIENT issue fixed
 

Is it avered that the network traffic actually increased when not using FL_FAKECLIENT ? I find that curious because in our bot code we already put a lot of check on engine functions to be certain not to call them for bots ; for example, ClientPrintf(), ClientCommand() and such simply return if the calling entity is a bot.

Currently my bots do not use any bit at all, neither FL_FAKECLIENT nor the (1 << 27) we called FL_THIRDPARTYBOT. I keep track of them internally, and I'd like to know if I should put the FL_FAKECLIENT flag back or not.

Re: FL_FAKECLIENT issue fixed
 

I would think there would still be some engine internal network traffic that would attempt to be sent to clients (for things like spray logo decals, for example). The engine internal traffic might not always come from game DLL function calls. The engine always used to use the FL_FAKECLIENT field to determine if a client didn't have a network connection. Older versions of the engine would crash when network packets were attempted to be sent to fake clients, but I think Alfred (or Leon) at Valve went through all of the places where network messages could be sent and made sure that the engine didn't attempt to sent network traffic to clients that didn't have a network connection.

If things seem to run fine (without crashing) when you are NOT using FL_FAKECLIENT, then you probably don't need to worry about adding it back in, but if you start getting a lot of complaints about increased network lag on servers running lots of bots, you might need to add it back. A simple test would be to create a server with 20 bots and see if your loopback network connection suddenly has a lot higher latency. Turn on the 'netstat' thing to see network load ("netstat 3", I think it is).

botman

Re: FL_FAKECLIENT issue fixed
 

One we post the fix to Steam, I would recommend you revert your code back to using the FL_FAKECLIENT bit.

-Mike

Re: FL_FAKECLIENT issue fixed
 

I do wonder why there is an explicit check on the FL_FAKECLIENT. I assume the engine does something like:

perhaps it would be more efficient to check only on a real client. Therefor you eliminate all other faulty placed bits. Of course you can use these bits later for other purposes, but this whole 'message sending between (fake/real)clients' seems to me like a problem that should not even exist? 9_9