![]() |
Re: I don't like this!
i mailed Alfred about bots and such;
he replied! Quote:
|
Re: I don't like this!
Well, as far as his answer to #2...
bot.h file... Code:
//=============================================================================// Code:
//=============================================================================// EDIT: Opps, you also have to add... void BotStartFrame(void); ...after line 38 of sdk_client.cpp in the dlls\sdk folder and add this... BotStartFrame(); ...at the very end of the "void GameStartFrame( void )" function in that same file (sdk_client.cpp). botman |
Re: I don't like this!
nice work botman:D.
P.S any news from valve about the plugin interface for bots from first impressions it seems like all the engine functions will need to be written into the plugin for a working bot:(. |
Re: I don't like this!
i just hope that valve will make a better answer then botman has, although its very nice to see how you can just use 2 files for a bot in your mod. I don't think this 'sollution' will be very fruitful.
*Edit: Actually reading the response from nr 3, i don't think we should expect real support for bots @ plugins soon. Though, it would be great if they would make it easier for us (or even, possible). |
Re: I don't like this!
I have mailed Alfred again; with some sort of request if he *might* have a chance to give us some more info, or some hope about any developments for bots in plugins...
Quote:
|
Re: I don't like this!
Are you sure you can't hook it anymore? What if you hooked the interfaces, and allowed new interfaces to still go through?
|
Re: I don't like this!
You can still hook "CreateInterface" if you want to (at least until the next Steam update wipes out your custom server.dll file).
Once you have hooked "CreateInterface", you can intercept requests from the game DLL code (old server.dll) to the engine. These requests will all be wanting engine interface function pointers. If you simply return the engine interface function pointers to the game DLL code, the game DLL code will bypass your hook DLL (because the function pointers point to the engine code). You will have to substitute YOUR version of these function pointers for the engine's function pointers and pass those back to the game DLL code so that the game DLL code will call your version of the functions. This is the same as it was in Half-Life1, where you had to recreate all of the engine functions and pass the game DLL code your version of those engine functions). This is where the difficult part comes. You have to maintain a list of ALL possible versions of the engines interface function definitions (i.e. if the engine has gone through 5 different versions of the IGameEventManager interface function, your hook code would need to support all of those versions to be compatible with different MODs). If you only wanted focus on a single MOD (say CS), you would only need to support whichever version that MOD required (updating as necessary when the MOD updates or the engine updates). Even after doing this, you STILL don't have access to player origins and angles, because this information isn't stored in the Half-Life2 engine like it was in Half-Life1. This data is now stored in the CBaseEntity class (which you don't have access to without doing some mucking around with pointers to PrivateData). Like I said before, if the engine is handling collisions, then some of this data is passed from the game DLL code to the engine (the origin for example), but rotation (angles) is not used in player collisions (since HL1 and HL2 use axis-aligned bounding boxes for player collision). So even if the game DLL code is telling the engine what the origin of players is, the game DLL code might not be telling the engine what the rotation (angles) currently is (since the engine doesn't need this). Other clients, obviously DO need this, so somewhere the CBaseEntity data has to be replicated from the server game DLL to all client. Perhaps intercepting this mechanism will allow you to get at the data you need. botman |
Re: I don't like this!
sounds like a big project to come , just to get bots working for HL2 as 'we' want it.
I got an answer from Alfred: Quote:
i sincerely hope that the document he is talking about, is sufficient for us. |
Re: I don't like this!
I have been looking at the same sort of issue for other reasons and I'm not sure why you would need to hook the game DLL.
There must be something obvious I'm missing but when you call createfakeclient it gives you an edict and through that edict I would think you can access the csdkplayer info. The problem I see is that to access it you need to understand the csdkplayer class which means you need the class definition for this which pretty much then requires the entire game.dll to be compiled into your server plugin. And even this isn't enough since you now need to go through the the game.dll code you added and make sure any local calls to interface functions in this code use the real interface functions into the real game.dll (since the engine won't call yours). So am I totally off base here ?? I can't believe Valve would make it this hard, but I can't see how you can do anything without full access to the csdkplayer class. |
Re: I don't like this!
the problem also is, to run the command to make players move, which are game dll specific. So even if you could gain acces, you should somehow find a way to run this function.
I saw a 'hack' about this, so you can acces cBaseEntity or something, but its ugly as hell. |
All times are GMT +2. The time now is 06:17. |
Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.