fakeclientless bots

[MarD]

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:

:Bodyguard4FollowW
00D6: if  0  
00DF:   actor $Bodyguard4_For_Player driving
004D: jump if false ££Bodyguard4FollowPlCarStart
0005: $Bodyguard4_OffbikeTimer =  0.0  \\ floating-point values
0170: $Bodyguard4_Z_Angle = player $PLAYER_CHAR z_angle 
00D6: if 0 
0030:   $Bodyguard4_Z_Angle >= 67.5  \\ floating-point values 
004D: jump if false ££Bodyguard4FollowSW
00D6: if 0 
0032:   112.5 >= $Bodyguard4_Z_Angle  \\ floating-point values 
004D: jump if false ££Bodyguard4FollowSW
0054: store player $PLAYER_CHAR position to $Bodyguard4_X_Pos $Bodyguard4_Y_Pos $Bodyguard4_Z_Pos
0009: $Bodyguard4_X_Pos += 1.6  \\ floating-point values 
0009: $Bodyguard4_Y_Pos += -1.0  \\ floating-point values 
00A7: car $Bodyguard4_Bike drive_to $Bodyguard4_X_Pos $Bodyguard4_Y_Pos $Bodyguard4_Z_Pos 
0002: jump ££Bodyguard4FollowSpeed0

I use the Barton Waterduck Mission Builder. I found a patch on the internet that allows me to downgrade my GTASA to v1.00, so I'm gonna do that n' see if I can mod GTASA.

[The_Hard_Mission_Guy]

This Code looks totally alien to me 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

[DrEvil]

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, HL2M(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 HL2M interface would load the bot dll and initialize the HL2M 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.

[Brainz]

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...

[DrEvil]

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.