Amxbot

[KWo]

Maybe someone is interested to create an amxbot. Since T(+)rget made a new VEXD_UM for AMX 0.9.9b (if You need some info where You can get this unnoficial version of AMX - ask me) , there is some possibility of creating a new bot (as an amx plugin this time).

http://djeyl.net/forum/index.php?showtopic=39110&st=15#

[Pierre-Marie Baty]

Very interesting!!!
Personally I won't use it since interpreted bytecode (like AMX modules) is ~20 times slower than native C/C++ code, but it will certainly bring a lot more users into playing around with bot coding concepts and that cannot do any harm to the bot community !

look, lol, I almost forgot that but I'm still the BU president well, congratulate this dude in the name of the BU president on behalf of the community. , I'm a diplomat now

[T(+)rget]

It should be abit more quicker than older AMX since the plugins are on the JIT system which run 10x quicker than before

Just looking for what kind of natives need to be made up really so people could write a semi decent bot.

I've already taken your can_see and in_view_cone coding since Taz gave me the source to them

Two good things with this is:
1) Bring a lot more users into playing around with bot coding (like you already said)
2) Should be able to work on multiple mods

If I can get hold of the main natives that are required then hopefully someone will work on a simple template design.

I made the Bot score a GOAL on SoccerMod (AMX mini-mod for Counter-Strike) but I was using bounded buttons to control the bot, since I have no time to build a full blown brain for them poor buggers

[Pierre-Marie Baty]

Very impressive stuff... and welcome to Bots United

Can you post the list of "natives" (I assume that by this term you mean direct engine API calls) you implemented already ? A bot coder will then be able to tell you what he finds missing...

[T(+)rget]

Here goes:
native create_bot(name[]);
native remove_bot(id);
native set_bot_walk(id, Float:Yaw, Floatist, Mode);
native set_bot_run(id, Float:vAngles[3], Float:fMove, Float:sMove, Float:uMove, Buttons, Impulse, mSec);

native can_see(ent1, ent2);
native in_view_cone(ent, Float:Orig[3]);

I'm not gonna write everything down it'll be two long

Forward functions: client_kill, client_prethink, client_postthink, server_frame, emitsound, set_model, traceline, entity_think, entity_touch. Also have access to all the progdefs.h values. Texture tracing, infront of player or below.

Then there is all the rest of the stuff from AMX Mod itself, like gmsgs, other forward functions (connect, disconnect etc) etc.

So basically is there any special natives which need making up like the can_see and in_view_cone. With all the above you should be able to build some form of brain.

[Pierre-Marie Baty]

I think that's pretty much all that is needed. Bots could also make use of GetEntityIllum, and hook on TraceLines and Emit(Ambient)Sound.

The main criterium is not whether bots are allowed to issue certain engine calls, but rather how well they hook on others. But I think with AMX's functionality, it's fine...

I'm eager to see the first good AMX bot !


*edit* noticed something. Your native "SetBotWalk" is the hook for WalkMove(), right ? This function is not used by bots but by monsters. You can drop it. Bots rely on RunPlayerMove() exclusively.

[KWo]

@T(+)rget - write simply the link to CVS or the place You have the sources of VEXD_UM and then my colleagues will be able to look into Your code without confusing what are You using in it.

[T(+)rget]

Thx for the valuable input I'll remove set_bot_walk, and add GetEntityIllum and the ambient emitsound as well.

Out of curiousity what does GetEntityIllum exactly do?

[Pierre-Marie Baty]

It retrieves from the engine the absolute illumination value for an entity. This is very useful for bots to adapt a human-like behaviour, like not being able to see an enemy into a dark area. Beware, however, that there is a bug in the Half-Life engine concerning fake clients (bots) and illumination. The HL engine seems to fail to retrieve correctly a bot's illumination, that is why some bot makers use a workaround to get past this issue.

This workaround consists in creating a dummy entity with a small render model, that they set "inside" the bot model while making that entity follow the bot everywhere while it moves. The model used, typically, is "mechgibs.mdl" for it's a small model that fits inside a player's render model. Then, each time they want to know a bot's illumination, instead of calling GetEntityIllum on the bot's edict_t pointer, they call it on that dummy entity pointer instead.

[T(+)rget]

Interesting, I don't particularaly like the idea of having 2 entites roaming around as it does increase server overhead, this technique was used upon players for external camera system. Then again I suppose the server is moving the bot so its not that big a deal.

I'll look into that illumination bug for bots. The joys of coding without having to rebuild a module which can be a pain in the ass at times