![]() |
fakeclientless bots
I know Halo PC has no fake client support, which means no bots.
Or Does it? Would it be possible to construct a program that intercepts the game's network communication, and creates Virtual Clients, that Halo believes are connected, but are just incarnations of the program? In other words, make a program that tricks the Halo server into thinking that other players are connected, when instead they are just the program? +EDIT: Wrong place again, I think |
Re: fakeclientless bots
Probably possible, but not worth the effort.
|
Re: fakeclientless bots
Heyyo,
People have already spliced singleplayer ai into multiplayer, and gottem them to pop up in the scores on some HaloCE maps, but the AI for Halo definately ain't built for mp, as such, there's only basic bot support on mp. I'm hoping Halo2PC will at least support fake clients if not come with bots. |
Re: fakeclientless bots
Quote:
Either as a stand alone program, or with a packet sniffer type setup. Anyone here good at netcode? And if a basic framework is put together, it could possibly be adapted for other game protocols with no fakeclient suport... If there are any out there. |
Re: fakeclientless bots
So you mean something like the IRC bots? They connect as virtual clients and do the stuff that they are coded for. Well for this you need to know what network protocols the game use and how to open the socket. I don't have expirience in that so maybe someone else can help?
|
Re: fakeclientless bots
Unlikely. It's probably relatively easy to sniff the network data and possibly figure out what is being sent from client to server, but in the end that doesn't really give you much.
Unless your 'virtual client' was a hacked up client of the game or did some heavy reverse engineering it couldn't do much. Your client wouldn't have the map loaded, so you couldn't do raycasts and such needed for a bot to actually 'see' the level. This alone cripples the concept, though there is other things that the game client & server loads that the bot needs. Your virtual client would have to do prediction for all the entities it knows about, which it probably would have no idea how to do. How are the people getting AI into MP ? Does the game have a proper C++ SDK where you can make signifiant modifications? Last I heard it wasn't going to have much more than a map editor and maybe some scripting support. |
Re: fakeclientless bots
So DrEvil I'm interested is it possble to be created a HL bot from the client.dll source code. I mean the bot to connect like a virtual client. It will be better for the coders because the bot will use all the game rules like the players without need to export some special function to get the bot to move correct, to have good hitboxes, and such stuff. Maybe there is way the bot to get the level data in this way ?
|
Re: fakeclientless bots
It's probably possible, and I seem to remember reading somewhere that billdoor was working on client side bots at some point. I don't know where he got with them. There's really no point in doing a client side bot though. You wouldn't be able to run but 1-2 bots because each one would require it to run in an instance of the client. This would waste tons of memory. It's better and easier to do server side bots. If the game doesn't support them, their loss as far as I'm concerned. Client side bots open a huge door for cheating, so it's probably very difficult to do if its even possible.
|
Re: fakeclientless bots
This is possible (atleast with Half-Life), and already was done by one guy with nick "Vasily Pupkin", this bots was called ClientBot, but in 2003 Vasily disappeared from coding (and CS) scene, and close all websites & support to his projects, however, some info & code still can be found on web archive at http://archive.org, (search for clientbot.narod.ru or clientb0t.counter-strike.ru)...
(sorry for my english) |
Re: fakeclientless bots
Thanks for the info guys. ;)
|
Re: fakeclientless bots
Ok searching today in http://archive.org I found that some of the downloads of "Vasily Pupkin" are still alive. i.e. "Half-Life client-side hook source code", "Quake 3 client-side hook source code" and some other tools.
The wab archive wasn't archived them all so I will post here only the alive ones. Half-Life client-side hook source code Updated client-side hook source code for Half-Life engine. It contains all of the exported functions, logging stuff, API calls, menu, hook intercepting and much more. There is also built-in features: autoconnect, antispam, current time, C4 timer and much more. You'll need MS Visual C++ to compile this source. Current version: 1.24 Ready-to-use autoconnector library This is a completed, ready-to-use auto-connector, anti-spammer and other features. Current version: 1.24 Half-Life RCon perl module This is a Perl module that simplifies managing Half-Life remote server via rcon (of course, you must know RCon password). Quake 3 client-side hook source code Uncomplete cgamex86.dll hook module (currently without logging and docs, experts only). DLL wraper generator This small Perl script generates a dll wrapper. It can add logging routines, overwrite default function prefix, search for function prototypes and much more. A nice DLL loader This loader can load a dll without calling LoadLibrary(dll), so the DLL won't be in module list (and can't be detected with process API) and it can be encrypted, etc. As an additional feature, it contains LoadLibrary, GetProcAddress and GetModuleHandle analogs that work with other processes (so you can load a library into another process!). Current version: beta 2 The info for this stuff and the stuff is taked from here. I hope that all this is usefull for someone. ;) |
Re: fakeclientless bots
i believe you want to make a bot like there are bots on Diablo II ( where it can walk for you and gather extra unique stuff)
i don't know programming well, but maybe using the libraries that bame uses could be helpful, netherless it would require a lot of effort to interpret it so bot would recongise the map surroudnings so it could walk. |
Re: fakeclientless bots
After getting a humble idea about this thread , i would comment that :
there is truly a need to develop some sort of a Univeral Interface that would allow the bot to be connected theoretically to any game server by only changning some variables within this super interface ..........OR to create a DLL library or somethin' that would sniff the client-server traffic and decipher it , So that any desired bot can be hooked up in no time , without doing any real programming.. maybe this stays just a vision ......or maybe we shall see such inventions that would save us from the HeLL of SDK programming! |
Re: fakeclientless bots
Heyyo,
There is already work in progress for this dude. Omnibot is a pretty good example. The Unitedbot that is (was?) in creation from some members here on this forum were supposed to also be able to load into any game once configured. I'm sure down the road this will become a more practical idea instead of just a few visionaries. ;) |
Re: fakeclientless bots
that's interesting news but because every game is differently programmed you still need to do some programming for each game engine ,RIGHT?
(referring to omni-bot and united bot) |
Re: fakeclientless bots
Heyyo,
True that it's not all the same, but what they did was create a basic template, and then they just do some engine specific calls to get it to work, and then add onto their basic template some game-specific stuff like objectives. I say this stuff's a great idea. UnitedBot once completed would make life soo much easier for bot authors since there would be the main bot and they just add in their little timbits for each game... a true UnitedBot. ;) |
Re: fakeclientless bots
Well, WELL
Now you make me very curious w00t how would this united bot template look like ? in terms of input , output. I mean , if we consider the bot template as a Black Box , how would we get the input from it and how would we give our Output back to it ? while making sure it stays universal for all game engines. |
Re: fakeclientless bots
Heyyo,
First ya can check one of the threads where PMB announced such a thing... right here: http://forums.bots-united.com/showthread.php?t=3121 If a scroll a few posts down he even released the source code to it. ;) And here's the main discushion of the plans on the UnitedBot: http://forums.bots-united.com/showthread.php?t=1298 So yeah man, read up, good stuff. ;) Now, as for the I/O's of how the source looks? I dunno man, I only know GTA3 Scripting language... someday I might learn C++... but ti'll then? I can only tell ya the basics man, sry, you'll have more luck asking others or even checking the sourcecode. :P |
Re: fakeclientless bots
I can see how it would work in theory, using my knowledge of scripting web pages...
Code:
onevent=event_function(event.property); |
Re: fakeclientless bots
Gta3 has a scripting language ?!0_o didn't know about this one............
anyways , Gonna check out what PMB had posted , thanks man ... maybe I get back to this thread later , HEHE |
Re: fakeclientless bots
Heyyo,
Well I dunno if it is its own scripting language, but from what I heard it was pearl, but then I showed some code to some people and they said it's not pearl... anywho, this's what it looks like: Code:
:Bodyguard4FollowW |
Re: fakeclientless bots
This Code looks totally alien to me:alien: Maybe because I'm a hardcore C++ freak!
It seems that both of us know something that the other one has completly no idea about......HOw ironic ...LOL But I wish you good luck on modding GTA , despite the way(programming language) you choose , under the condition that you get it done:yinyang: |
Re: fakeclientless bots
My bot is essentially what United bot was/is supposed to be. I was excited at the prospects of united bot when it began its conceptual phases so long ago, and when I got done with classes and wanted a project to work on it was clear that United bot wasn't really getting anywhere. By no means is this meant to be disrespectful to the BU team, but there has been all kinds of talk about UB, and very little actual progress toward its realization. For that reason I started my own game/mod independant bot.
Started with ETF, which is a Team Fortress mod for Enemy Territory, then ET, which is same engine different mod. And have since moved to support Quake4, HL2:DM(as much as possible given server plugin limitations), and currently working on the bots for Fortress Forever. Omni-bot has been in constant evolutionary change, as I discover better ways to do stuff and refactor systems as needed. It's not perfect by any means, but it is a mod/bot independant framework. My philosophy from the start though hasn't been to support every FPS game out there, as I am not at all interested in hacking dlls and stuff to try to add bots to a game which doesn't support them already. This is a waste of time and IMO a large reason for the UB lack of progress. That said, a few things I've learned in the 2.5 years of working on Omni-bot. It simply isn't possible to make a bot for a game without some sort of interface layer between the game. Game data has to be translated into bot messages/data at some point, and the only place you have that sort of access is the mod code, or in cases like HL1 you can get most things out of network messages in an intermediate dll between engine and mod. Regardless, there is still an interface layer that is per game, per mod. This isn't a huge deal, as much of the interface code for a single game can be shared. The parts that are different are the parts that are specific to the mod, like the specific weapons, special goals, etc... Originally when I first started Omni-bot I had things set up so that the interface layer requested the proper game to be created. For example, the HL2:DM interface would load the bot dll and initialize the HL2:DM bot support, ETF would load the same dll and initialize it with ETF support, etc... It worked great for a while until it became apparent that this universal dll was not only going to get bloated with each newly supported mod/game, but it was going to be a pain in the ass to deliver updates for seperate mods, basically requiring updates to be simultaneously released for all supported mods, which isn't very realistic when the people working on something do it in their spare time. In addition to this, the universal dll wasn't a very compatible solution considering I was also planning an SDK so that others can add bot support to a new mod or help with an existing one. At that point I decided to split it into per mod dlls. It was a rather simple change, which now results in mod specific dlls that are much easier to manage. omnibot_et.dll omnibot_ff.dll omnibot_hl2dm.dll omnibot_q4.dll, etc... This makes for a much easier to update setup. A client side bot is not a project I would be willing to undertake. It's a prime project that would likely be targeted by the developer to shut down and make incompatible, since if you could implement a client side bot that means there is potential for significant cheating to happen by the same techniques. IMO server side bots are really your only option, and even then only for games that support bots. Currently this includes HL1, HL2, Doom3, Quake4, FEAR and hopefully will by extension mean Prey and ET:QW assuming they release SDKs. Unreal probably could with a TCP communication channel to a seperate bot process. Any deeper hacking than this is IMO not worth it. In the case of Unreal, it not only already has pretty good bots, but implementing bots in Unreal Script is rather easy and it would be a mis-use of resources to attempt to externalize that. I think Unreal is the single game that has bot support way more than any other game, simply because they are easy to do. Most mods for Unreal ship/work with bots. You don't see the same thing with other engines with real source code based SDKs. I don't know what's possible with Halo PC in terms of modding, but I was disappointed to read long ago about its lack of support for bots. Sounds like possibly some figured out how to hack some AI into it, who knows, bots may be possible now. So I guess the point is that a truely universal bot just isn't going to happen unless there was somehow an industry wide bot interface implemented into every game from every developer. Since that is unlikely to happen, our option is to support the few game engines that do support bots. Fortunately these fewer engines are the main ones that most of us care about most, so it's pretty good to be a bot developer. It should get alot better if/when valve fixes the HL2 server plugin interface, giving us a path back into bots supporting mods we dont have the source to. |
Re: fakeclientless bots
would it be possible to split it further into a dual dll system: a mod-independant core dll that has the ai, and a second dll that's mod dependant, acting as a link between engine and ai dll? It'd mean less work for modmakers who want to use the OB (omnibot) framework, and less chance of bugs creeping in.
It may also make it possible, with some work to modify the ai to do other, non-fps related tasks, if the desicion making is done in relative terms, ie "if this: do that", instead of "if you see an enemy, shoot it". I don't know if that makes any sense at all... |
Re: fakeclientless bots
Not really. The 2nd dll you speak of is the interface layer and needs to know about the game/mod to be able to translate stuff into the bots language. It would be worthless splitting that into a 2nd dll. Knowing about the game/mod means being built into the game/mod, or in some cases like HL1 and HL2 server plugins they can interface with the mod to some extent without the mod source. You don't have this option for non Half-life games. A drop in bot dll for mod authors is a pipe dream. I truely believe I have developed pretty near the easiest solution for bot authors and modders wishing for bot support. They add the bot interface to their mod, or in the case of hl1, hl2(when they fix it) the interface can be built in a server plugin or intermediate dll(hl1). The interface gives basic information to the bot. Past that all the bot logic is in the bot dll. It's very easily compatible with both being built into the mod and for use with HL1/HL2 server plugins/intermediate dlls. A 2nd dll provides no benefit at all.
|
All times are GMT +2. The time now is 07:49. |
Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.