Let the revolution begin!!!

[Zacker]

Fantastic work Botman! Nice to see that you are still kicking ass

[stefanhendriks]

dr00l dr00l dr00l!!!!

i am gonna read the source and try it myself aswell. I am eager to see how close iw as myself...

[stefanhendriks]

I took a look at the code...

botman congrats! you succeeded in the theory i had in mind as well (as the little snippet in 'i don't like this'). Congrats!

Actually i was thinking that i had to do a lot more copying of code for WriteUserCmd and such, but it seemed it was not that much after all.

The bot will crash in HL2DM for now, but thats a fault at valve, but no worries, they have fixed it (got confirmation from alfred) and will be updated on a next steam update of HL2DM

I am gonna change this lovely code... perhaps i can even get it to work for my ITM project...

one question though:
i see you use the gameinfomanager to let a bot change team. I assume this is on purpose? Because a bot should *actually* try to join the game via usercommands? (or some sort of 'menuselect' thingy?).

[botman]

I'm not sure about the best way to select a team. I notice that there is a client-side cvar now (something like cl_team or some such sillyness) that teamplay_gamerules.cpp uses to select the player model. That stuff may only be used by HL2DM and/or TF2.

I don't know how to get plugin entities to set client-side cvars yet.

I did notice that weapon select is now done as part of the cmd structure (instead of sending a text command with the weapon name that you want to switch to). Just set the proper bit in the cmd structure and do the WriteUsercmd() like you do for movement.

Obviously, there's still LOTS of stuff to do, but hopefully we can help each other out and get a nice "empty" bot template going for the Source engine.

botman

[stefanhendriks]

yes, i also noticed that on the weapon part The cl_team thing is something odd for me too. I also noticed that the chooseteam(2) code does not work properly, the argument you pass is somehow overwritten by autoteambalance or something alike (i bet it is game dll specific code, so the argument you give is not used at all).

I am now investigating this piece of code, via the server interface:

	float fPitch = pBot->fIdealPitch;
	float fYaw   = pBot->fIdealYaw;

	// PROCESS AIMING
	engine->CrosshairAngle( pBot->edict, fPitch, fYaw );

i hope it works well, i just saw my bots walking backwards with a yaw of 180... and a pitch of 180... when this is the same as in HL1, i think we can copy/paste a lot of code. But i am not sure yet..

[stefanhendriks]

noticed:

* you can change team to any one you want, the argument is a bit different: 1 = spectator, 2 = terror, 3 = counter-terrorists

* my bots keep walking backwards, even when forward speed is set to 200. Even when removing the crosshairangle and such.

EDIT:
in addition to the second point. It seems 'forward move' is related to something. When i use -200 , my bots walk (on the T side) forward. THe same bot walks sideways in de_cbble.

perhaps you need to link this with pitch/yaw things. I did not look into this yet.

[Jerry]

Originally Posted by stefanhendriks

noticed:

EDIT:
in addition to the second point. It seems 'forward move' is related to something. When i use -200 , my bots walk (on the T side) forward. THe same bot walks sideways in de_cbble.

perhaps you need to link this with pitch/yaw things. I did not look into this yet.

Maybe the bot uses the orientation of the map .

[@$3.1415rin]

nice work, next week i'm back at my normal PC

they still use normal angles in source2 ? 0°-360° or whatever ? I mean, calculation is based on radian, i.e. 0-2Pi, so why not that ?

[stefanhendriks]

@asp, why do it the hard way or the more human way?

[stefanhendriks]

ok, i had a little bit more time to fiddle around:

- the forward speed is somehow relative to the map. I did not yet figure this out. However, when i tried using IN_FORWARD (for buttons) only, it did not work either. Also a combination of 'forwardspeed=200' plus the IN_FORWARD bit, did not work either.

I tried figuring out this relative computing of the speeds, but i think its like this: The game dll itself has code to let clients move around the map; they also rely on 'forwardmove' and 'sidemove' and such. I do not see some computing there; though i have to admit i did not do a very indepth search.

Perhaps the engine itself handles movement for fake clients differently?

- edit:
also not luck with the crosshair function, despite what kind of pitch or yaw i pass through there... :S

- edit 2:
about the crosshair thingy; i think this is due the fact that the plugin sets info first, and then the game dll. Meaning the game dll overwrites the crosshair info? (fixme!)