Amxbot
 

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#

Re: Amxbot
 

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 :D well, congratulate this dude in the name of the BU president on behalf of the community. w00t, I'm a diplomat now :D

Re: Amxbot
 

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 :D

Re: Amxbot
 

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

Re: Amxbot
 

Here goes:
native create_bot(name[]);
native remove_bot(id);
native set_bot_walk(id, Float:Yaw, Float:Dist, 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.

Re: Amxbot
 

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.

Re: Amxbot
 

@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. ;)

Re: Amxbot
 

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?

Re: Amxbot
 

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.

Re: Amxbot
 

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 :)

Re: Amxbot
 

Can you give me more indepth info about illumination?

If you say bots mainly need this to not see players into the dark places can't this be easily fixed for normal players as you just check the traceline and the player id hit to check there illumination level instead?

I also see a potential flaw with this design unless you cater for nightvision? Also you mention about following a player, that would be a bug within the sound system as well since the bot should roughly know where the player sound has stopped?

I dunno about your gaming style but the big centerid (Enemy) gives away where players are anyhow :D

Re: Amxbot
 

What I mean, is that if you call GetEntityIllum() on a player edict, it works. BUT, if you call GetEntityIllum() on a bot edict, it returns 0. This is why bot coders have to be cautious around this issue. If they want to retrieve a bot's illumination value, they must call GetEntityIllum() on another edict than the bot's own edict. This is why we make dummy entities follow bots around when they walk (since calling GetEntityIllum() on these entities do work).

Anyway, it was an old bug of the HL engine, but perhaps it's been fixed now by the Valve guys. I haven't checked. Can you confirm the behaviour I'm saying here, or does it work differently ?

Re: Amxbot
 

I can confirm 0 for Bots on CS v1.6

I was just trying to workout why you need to get the bots illumination whilst in dark places, obviously bot vs bot with a method which I mentioned would return 0 all the time.

Re: Amxbot
 

Just curious, how is lightlevel stored in a map? I mean, with lightmaps and all.

That might be good for navmeshes.

Re: Amxbot
 

That is for sure a good idea, unfortunately it is never "tied" to the faces. You can have a face split in both with one half illuminated and another one in the dark. That would be quite a big hassle to take that in account :(

Re: Amxbot
 

Ok tried different lightlevels from another 2 sources which is from Entvars and Usercmds both return 0 for BOTS :(

Re: Amxbot
 

I know nothing about bot coding (and any C++ coding) and maybe I shouldn't post here and talking about something I know nothing, but maybe there is somewhere described the list of all HL functions not working for bots (but working correctly for human-players) and the list of all known workarounds made by bot coders to get their bots to work? I'm asking to prevent the situation the new bot coder is trying to open some door already opened by other. Since You guys are as "United" - maybe it's possible to put here some Your knowledge for other people? I'm thinking about something like the info in "wiki" or in some sticky thread like "What You have to know when You are trying to write Your bot for HL..."

Re: Amxbot
 

i thought there was a way to create an entity (temp one) and give it no model. Then you change the position to the bots position and you can read the light info. There was something at the former botmans forums about that.

Re: Amxbot
 

Yes, that's what I was doing too. You don't set it no model though, it must have a model for rendering illumination correctly. Instead you set it a model that fits inside the bot's model (so that nobody can see it). That's what I was doing and what I was telling T(+)rget to do but he doesn't like the fact of having to spawn and move another entity in the game (he thinks about lag issues). Personally I don't think the trouble caused is that big, but not everybody may agree.

Re: Amxbot
 

I thought temorary entities were entities transmitted to the client and never seen again, like the gauss beam, or the lightning from Quake.

Re: Amxbot
 

Can bots utilise pfnAddToFullPack? If so then ok I agree with the following model idea since it'll only be used/seen by the bot and nothing else.

Yes I do worry about lag, but after doing some testing over the past few days it seems event capturing seems to use more cpu or cause lag for some odd reason, maybe its just my system who knows.

Re: Amxbot
 

So be it :P

AMX Bot here we come

Re: Amxbot
 

haha, I wish you good luck guys, you'll soon get the picture of what bot coding really is :D

back on topic: what does pfnAddToFullPack do ? it's one of the functions from the engine interface that I have no clue what it does.

Re: Amxbot
 

Because our colleague seems to be too much busy now, I'll post here what I got from him about it...

Re: Amxbot
 

I still don't get it... oh well, I guess I'll wait for a more complete explanation :)

Re: Amxbot
 

Taken from client.cpp:

AddToFullPack

Return 1 if the entity state has been filled in for the ent and the entity will be propagated to the client, 0 otherwise

state is the server maintained copy of the state info that is transmitted to the client
a MOD could alter values copied into state to send the "host" a different look for a particular entity update, etc.
e and ent are the entity that is being added to the update, if 1 is returned
host is the player's edict of the player whom we are sending the update to
player is 1 if the ent/e is a player and 0 otherwise
pSet is either the PAS or PVS that we previous set up. We can use it to ask the engine to filter the entity against the PAS or PVS.
we could also use the pas/ pvs that we set in SetupVisibility, if we wanted to. Caching the value is valid in that case, but still only for the current frame.

But like I explained to KWo, you can set it inside that function so that for example:

A = a seeable entity

Everyone can see A by default
You can modify the setting so only 1 person can see A

Re: Amxbot
 

Seems AMXBOT is not affected by the latest steam update (because it doesn't use VGUI menu). :)
All POD clones , JoeBot and Realbot - they are affected by it. Probably there is also one bot more not affected by that update - it might be PLBot (but I haven't tested it yet since the steam update). :)