United Bot philosophy and roadmap

[botman]

We could always say we support UT2k3 and then drop it later if needed, but you might want to spend some time investigating the other desired engines (Quake III Arena, BF1942, etc) to see if external bots can be created for those as well. If you don't, you might wind up only supporting the Half-Life engine after finding out that all the others just don't allow for easy enough integration of a C++ bot.

EDIT: Time for a new thread?

botman

[botmeister]

Originally Posted by botman

We could always say we support UT2k3 and then drop it later if needed, but you might want to spend some time investigating the other desired engines (Quake III Arena, BF1942, etc) to see if external bots can be created for those as well. If you don't, you might wind up only supporting the Half-Life engine after finding out that all the others just don't allow for easy enough integration of a C++ bot.

EDIT: Time for a new thread?

botman

There should be a whole forum for this project imo.

Personally, I'm bothered by the approach in general because it is not general enough.

It appears that very few games intentionally provide the kind of support we need. Even if all the games mentioned are capable, the list is still small, and a new release can easilly knock a game permanently off the list.

Is there another way?

I'm thinking perhaps we can get to a game engine through other means that may be more generic. For example by doing some serious hacking into the dll's and capturing network messages.

One possibility is to build a client side bot that sits on the server side. The bot would emulate a human player.

I realize hacking binaries and/or building a client side bot are not new ideas which have serious problems of their own, but I mention it to demonstrate there are alternatives and to see if anyone can think of something that we could use more universally.

The one advantage we do have is that our bot can sit on the same machine as the game engine and client, giving it access to all the game binaries and other resources. I'd focus on this important advantage to look for a solution.

The line of thinking I'd look at is to commit blasphemy and emulate what the cheat programmers do 8D I've seen some amazing cheats for HL based games that sit on the client side. If the cheat programmers can get good access to the game from a remote client machine, we ought to be able to do even better with local access.

We have to be very creative here, and the normal way of doing things may not be good enough. As they say, it's time to think outside the box, let's get crazy and throw some wild ideas around for at least a moment or two.

[Onno Kreuzinger]

Originally Posted by botmeister

One possibility is to build a client side bot that sits on the server side. The bot would emulate a human player.

I realize hacking binaries and/or building a client side bot are not new ideas which have serious problems of their own, but I mention it to demonstrate there are alternatives and to see if anyone can think of something that we could use more universally.

The one advantage we do have is that our bot can sit on the same machine as the game engine and client, giving it access to all the game binaries and other resources. I'd focus on this important advantage to look for a solution.

The line of thinking I'd look at is to commit blasphemy and emulate what the cheat programmers do 8D I've seen some amazing cheats for HL based games that sit on the client side. If the cheat programmers can get good access to the game from a remote client machine, we ought to be able to do even better with local access.

We have to be very creative here, and the normal way of doing things may not be good enough. As they say, it's time to think outside the box, let's get crazy and throw some wild ideas around for at least a moment or two.

i thougth about that too, when first reading this thread, and i think it could even work for steam/vac servers, but i doubt that cheating death and other anti cheat software would like this aproach. and since the code sharing / opensource of the UB would allow to copycat the interfaces it could acctually be used to make very bad things. allthough not easy to imagine, one could make very weird things like running bots on the client which could be used to help the player playing on that pc. the hl server would not be able to to tell the difference.

or i'm i to paranoid...

cheers

[botmeister]

[QUOTE]
i thougth about that too, when first reading this thread, and i think it could even work for steam/vac servers, but i doubt that cheating death and other anti cheat software would like this aproach. and since the code sharing / opensource of the UB would allow to copycat the interfaces it could acctually be used to make very bad things. allthough not easy to imagine, one could make very weird things like running bots on the client which could be used to help the player playing on that pc. the hl server would not be able to to tell the difference.

or i'm i to paranoid...
[QUOTE]

Don't forget everything will sit on the same machine, so there's no opportunity for real cheating by remote clients unless a network protocol was specifically built to allow such a thing. It would also have to be installed on the server by the server operator (or someone hacking into the server). This can be done if someone wanted to do such as thing using the methods we're now using already, so in short whatever interface we come up with won't make much difference to the cheaters because they already have full access to the server side interface.

Cheating Death and so on (including VAC) would not be able to detect the going on's of such an interface just as they do not detect the current methods we use for inserting our server side plugins. The current methods we use are useless as cheats because remote clients have no access to the interface.

[FrostyCoolSlug]

I like this idea, it seems that rather than calling them 'plugins' you should call em 'modules' which can (possibly) be loaded and unloaded dynamicly (just simple things like Weapons usage, unload one module and load another), so its something like

Game Engine <--> 'Wrapper' <--> Main Bot Dll <--> Modules.

Someone mentioned a few posts back about using 'Hack style hooking', personally, i think this is a great idea. Its just the difficult part would be preventing things like VAC going nuts :p

I used to do a lot of work for the anti-cheat community, so i've read and tested things like the OGC source (Note: I did this locally, and not on public servers. Dont call me a cheat).

Although i dont concider myself an experianced C++ coder (in fact, i'm trying to work out htf classes work properly, other than that, i'm quite proficiant) I've assisted in developing an IRC Daemon called 'InspIRCd' which is coded in C++ and is modular. I'd like to assist in this project in some way, even if i'm just a beta / alpha tester.

Thanks

I'll spend some time reading over Botman's HPBBot source

[botmeister]

@$3.1415rin I agree we need a new forum for all this to separate out all the "threds" going on in here. We may need a council vote. I think you make 4 who are in agreement so far?

[Pierre-Marie Baty]

OK, since a majority in the council already agree, I've set us a new forum and done some cleanup in this monster thread to separate it into different topics.

Let's try to be a little better organized now

[FrostyCoolSlug]

nice job, will make life easier

[botmeister]

Great job PMB!

[botmeister]

Question:

Is it worth building the United Bot now, for Half-Life with the ability to work later with other engines should it ever become possible?

The reason why I'm bringing this up now, is that POD 2.6 mm is starting to fill the role that the United Bot was to fill - a common bot that we all can work on together.

It seems to me, fixing up POD is a good idea in the short term, but would it not be better in the long term to build the United Bot even if it ends up only for Half-Life?