explanation on the changelevel issue

[[NvT]_KaszpiR_]

does this "feature" of changelevel was form the very beginnign or it showed up since cs 1.6?

[Pierre-Marie Baty]

there has always been issues with changelevel, by the fact that it's not a game command but an engine command. But it seems it's gotten worse with CS 1.6 as far as the random crashes are concerned.

I think it may come that now in CS 1.6 it's not the engine but Counter-Strike itself that holds the repository of the entity list. The CS developers did that to speedup all the entity-related operations and take load away from the engine. Hence changelevel may have the engine clean up its own entity list, but NOT the Counter-Strike DLL -----> entities out of sync ----> crashes.

[botmeister]

Originally Posted by Pierre-Marie Baty

when the time limit is reached it's the GAME DLL which decides of the level change, not the engine. The game DLL thus tells the engine about the level change, by calling ServerDeactivate() properly, followed by a new ServerActivate(). Then the engine executes the level change, *upon GameDLL command* (and not by itself). Since the game DLL calls them in the engine, our bot DLL can hook them.

Were it the engine only, that decided to change maps, not only the server would be shutdown abruptly (because the game DLL wouldn't even be told), but we couldn't even hook it since nothing from the process passes through the bot DLL.

Pierre, we ought to be able to get something that's not ugly to work for this.

I don;t have my head fully wrapped around the problem yet, so please bare with me if I ask you a few silly questions.

With a CHANGELEVEL command, it seems the server will autokick all the bots out and on next round they won't automatically respawn unless your bot code does this. The problem is knowing how many bots to respawn and what the status of each bot was (eg skin, skill, ect)

Correct?

Some assumptions:

a. CHANGELEVEL is the only way to change a map without knowing in advance.

b. All other methods to change a map can be trapped in advance.

c. We can always reliably detect when a new map has loaded.

My first question:

Why won't this work?

On each new map detection, you should be able to scan through your bot list, and for each bot that is flagged as "spawned" but is missing, you respawn it. I am assuming that your bot code will keep all the needed details inside your bot list structure.

[Pierre-Marie Baty]

it's not that simple... first I think if I recall well that the bots structures are reset completely at ServerActivate to free all the bad pointers that may remain in them. Then, there is a LOT of code everywhere else that relies on this flag to determine if a bot is present or not, and if so, make it do things. If this flag is on and the bot is not here, my guess is that you'll have more crashes than anything else.

[botmeister]

How about you create a new secondary structure that holds the essential information for respawning bots.

If the a new map is loaded using a "safe" method, then set a flag in the structure (or somewhere) which indicates that bots do not need to be respawned - I'm assuming the old bot code will respawn all the bots correctly.

After ServerActivate clears everything (but not the secondary structure if the bots are to be respawned) and our special flag says that the bots should be respawned, then do so using the info contained in the secondary structure.

The structure can be updated from whatever changes the original structure (addbot, kickbot) not sure, because this part could be full of spaghetti.

What do you think?

[Pierre-Marie Baty]

I think I'm done with podbot at the moment.
I've been reopening RACC again and there's a lot of work still left to do

Hope you understand


Certainly in a few months I'll be wrapping my head around it again, but right now... I'm just recovering from a podbot overdose.

[SoUlFaThEr]

go do that man.......its Burger King and you deserve a break this month

[botmeister]

Don't blame ya, you've done shit loads of work, so a break is in order