Movetogoal and walkmove

Discuss Artificial Intelligence and Bot programming.
Post Reply
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Movetogoal and walkmove

Post by Cobalt »

Never worked with these built ins too much. When they move the bot for example, are they using the setorigin command to shift the bot to the desired location?

Im trying to find a way to move the bot without using setorigin, and seems most of the old bot legacy code out there seems to use setorigin to do it. The new spawnclient () for bots in darkplaces does not work well with any kind of movement code that uses setorigin, and it winds up keeping the bot facing the same yaw direction all the time. LH has told me that its best to use .movement_x , _y to move the bot, with the spawnclient because of what is now going on in sv_playerphysics since the bot is really using the same player physics the player would use in that new code. He also said NO animation code is needed, so I guess the engine takes care of all the bot animations?
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Movetogoal and walkmove

Post by Spike »

spawnclient spawns an entity that acts like a client.

give it movetype_walk, set your intentions within PlayerPreThink, and it'll move exactly like a player.
your existing player code will do all the animations.

basically the only difference between a bot and a real player is that a bot is too stupid to make its own decisions - you need to set the various player inputs yourself, namely v_angles, movement, button0, button2 (and other buttons if your mod uses them).

angles is getting reset because you've not set v_angles, basically. You're expected to set .movement, but you don't have to.
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Movetogoal and walkmove

Post by Cobalt »

Thanks Spike. I ran into a post on this site where someone had same kind of problems with the yaw never changing for the bot, and the post said it was a fix something like:

//self.angles = self.v_angle = spot.angles;

For the putclientinserver () function. Sounds like maybe what you are sugguesting? I tried it , no matter whaere I put it, does not help.

whats srange is when I use a movement code that moves the bot with setorign, this bug is constant. When its using another movement method that seems to use .velocity to move the bot, he always faces the right direction. The only other way he changes yaw is when he is under attack, and thats some special code I put in involving a .turn vector that marks the spot the damage occured, and the bot then turns to that location...otherwise he probably would just get killed and not fight.

Can you elaborate more on how to fix the v_angle ?



Spike wrote: angles is getting reset because you've not set v_angles, basically. You're expected to set .movement, but you don't have to.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Movetogoal and walkmove

Post by Spike »

Spike wrote:set your intentions within PlayerPreThink
Spike wrote:angles is getting reset because you've not set v_angles
or in other words, the engine does self.angles = self.v_angle (z isn't a direct assignment, read docs on angles vs v_angle) some time between PlayerPreThink and PlayerPostThink.

you need to set self.v_angles inside playerprethink. set it to the value of self.angles for all I care, but if you don't, self.angles will be set to self.v_angles anyway, regardless of the value you have in there, hence why its looking in some stupid direction.

setting v_angles inside putclientinserver only does it at spawn, it'll keep looking the wrong way for the rest of the match as its angles will constantly get clobbered. you can't just set it one time and expect it to magically be correct for every other single frame when the intended value is changing each and every frame.
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Movetogoal and walkmove

Post by Cobalt »

Ah, clear now.

Thought I had tried pasting the entire old prethink, think and post think into the player prethink, think and post think - respectively, but there was a problem I cant exaclty recall. It might have been that I left in the self.nextthink = time + xx; lines now that I think of it. My lack of understanding how they relate to the engine with the player physics is my weakness.

The legacy code also has an animaiton think, which I had drasticly reduced to what it is now, just some frame + 1 type commands that I noticed are needed else the bot dont animate...but I suspect that once I get the thinks to the player think locations where they belong, then they will animate automaticly? I know from experimenting with putting a .nextthink = time + xx; into any of the 3 playerthink locations, a real player client will stop moving , but seems physics still happen...so I will have to try again putting the bot thinks into the corresponding playerthink locations, and now delete the nextthinks, and hopefully that will get them working. Thanks ! :D
Spike wrote:
Spike wrote:set your intentions within PlayerPreThink
Spike wrote:angles is getting reset because you've not set v_angles
or in other words, the engine does self.angles = self.v_angle (z isn't a direct assignment, read docs on angles vs v_angle) some time between PlayerPreThink and PlayerPostThink.

you need to set self.v_angles inside playerprethink. set it to the value of self.angles for all I care, but if you don't, self.angles will be set to self.v_angles anyway, regardless of the value you have in there, hence why its looking in some stupid direction.

setting v_angles inside putclientinserver only does it at spawn, it'll keep looking the wrong way for the rest of the match as its angles will constantly get clobbered. you can't just set it one time and expect it to magically be correct for every other single frame when the intended value is changing each and every frame.
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Movetogoal and walkmove

Post by Cobalt »

Ok, this turned out weird. Tried the v_angle fix in lots of different spots with no success. This is what seemed to fix it when placed in the code that moves the bot:

Code: Select all

// NEW
self.v_angle_y = vectoyaw(self.goalentity.origin - self.origin);

// OLD
self.ideal_yaw = vectoyaw(self.goalentity.origin - self.origin);
ChangeYaw ();

Also what I suspect may have been happening is the old legacy botthink routine was kind of top heavy being designed in 1999, that the new think / frametime when called in the new dp_playerphysics was happening much earlier than the nextthinks that still were in some spots in the old code, so there was conflict for fluid movements because the old code used 2 modes for moving the bot in the event its progress in the game was behind. So when we did real physice in the new dp code, we were interupting whatever was going on in the botthink if we effected variables it was using. Havocbot for example calls the bot think each frame right at the top of the new physics...and I dont believe I saw it set a .think to the actual bot itself, rather it takes everything from the playerpost, and pre thinks and directly in the new physics. I have kept my old .think assignment so it runs independently from everything else still, so what I did was check for when the think times-out, then make sure we are still doing the right think, and reschedule it. Also the bot animation still has to be done with a seperate call, I guess thats because my think is outside of the player physics frame? this is what it looks like near the top of sv_plyerphysics:

Code: Select all

if (clienttype(self) == CLIENTTYPE_BOT)
{
//self.v_angle = normalize(self.movement - self.origin);
self.v_angle_z = 0; // let the engine handle roll with physics
if (self.fixangle)
	{
		self.v_angle = self.angles;
		self.fixangle = FALSE;
	}
bprint (self.goalentity.classname);
bprint ("\n");
if (time > self.nextthink)
{
self.think = BotThink;
self.nextthink = time + sys_ticrate + 0.12;
if (! self.deadflag && self.bot_action == BOT_MOVING)
BotAnimationThink ();
return;
}		


So I have it returning and not even doing the rest of the physics check if we are beyond the current think. Seems to be working ok, gives the bot a decent smooth looking move using the havocbot move code that I am testing with. Any comments Spike or anyone else? Thanks.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Movetogoal and walkmove

Post by Spike »

...

No other botclient uses thinks for AI.
There's a reason for that.
Changing thinks or nextthinks utterly ruins any player animations (as well as lightning/nail attack rates).
Its easier for them to create and use their own timers inside PlayerPreThink. Whether you move with .movement or movetogoal, I really recommend that you do not use thinks inside your bot AI, doing so makes everything much more complex (unless of course your bots don't use the player model/frameset, of course, in which case it doesn't really make any difference either way).
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Movetogoal and walkmove

Post by Cobalt »

Hmm. Well we do have a female player model seperate from the other, its frames are a match for the pain and attact etc frames for the player, but we do have to set it up to use its own seperate model or course. The other thing I had to do was make the new player model supplied with the mod a seperate file, [now called bot.mdl] else we cant get the auto file dl from the server with DP to work, as it will use the old player model. The new player model in the mod (which is now bot.mdl) merely is the old player model ecxept it has some new skins. There were empty slots in the code for player3 and player4 models, but no player3 or 4 model files supplied. Point about the nail attacks is understood, I have already seen that and not known why til now...and the lg now that I think of it kind of seems weaker, but have not had much time to test.
Spike wrote:...

No other botclient uses thinks for AI.
There's a reason for that.
Changing thinks or nextthinks utterly ruins any player animations (as well as lightning/nail attack rates).
Its easier for them to create and use their own timers inside PlayerPreThink. Whether you move with .movement or movetogoal, I really recommend that you do not use thinks inside your bot AI, doing so makes everything much more complex (unless of course your bots don't use the player model/frameset, of course, in which case it doesn't really make any difference either way).
Electro
Posts: 312
Joined: Wed Dec 29, 2004 11:25 pm
Location: Brisbane, Australia
Contact:

Re: Movetogoal and walkmove

Post by Electro »

You shouldn't need ANY specific models/animations for bots only if you want them to do everything like players.

Automatic downloading works off anything that's trying to precache and isn't found (as far as i'm aware).
So just make sure you precache the female mdl.
Benjamin Darling
http://www.bendarling.net/

Reflex - In development competitive arena fps combining modern tech with the speed, precision and freedom of 90's shooters.
http://www.reflexfps.net/
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Movetogoal and walkmove

Post by Cobalt »

Heya, I was gonna pm ya anyway! Yea, dunno why they are not auto-animating and I have to use the old code that pretty much checks for a weapon, and calls a corresponding start frame and then frame + 1. I guess its cause I am leaving the old .think as BotThink, and not calling just a flat out () void / think function from the existing player physics ? Kinda lazy for now to cut n paste everything over I guess....it more or less means an overhaul to all the current routines that call from the default ctfbot BotThink...so I likely will hold off on doing that until I understand ALL the code better.

I experimented today with seeing if I can change the bots pitch (v_angle_x) a bit - had him (not by intent) doing a backstroke in the water :lol:

Then I actually thought he probably looks kinda normal if he is in waterlevel of > 2 and has a v_angle_x of about -90 which I think puts him on his stomach. Thats how the player model ought to look anyway when its got a velocity....having the head point in the direction you are swimming to. When you stop moving, then, the model ought to rever back to the default standing position till you move again. LH's new physics are neat for this, cause you will drift to the bottom if you are not moving x or y. I was gonna ask you if you wanted to make some new swim frames.....for uwater movement...hah. Next thing you know, I will say we ought to have a movetype_swim. I already got the air bubbles code done for when he gasps.


10-4 on the precache....thats how I know it to work too.


Electro wrote:You shouldn't need ANY specific models/animations for bots only if you want them to do everything like players.

Automatic downloading works off anything that's trying to precache and isn't found (as far as i'm aware).
So just make sure you precache the female mdl.
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: Movetogoal and walkmove

Post by Cobalt »

Starting to work on this issue some more. I have a ' bot auto-repair' entity that looks at each bot every so often and if its no longer thinking, it assigns a new nextthink, and using .message string, we store the function the bot last executed there by hard coding it, and the auto-repair entity will tell us what the last function it executed before the freeze was. Seems the most popular is playerpostthink() and playerprethink().

Now as you say, the reasons why I have to use the old legacy animation code IS because I am still calling the old BotThink() as its assigned
in the old code. I have combined the new QC extension file dp_extensions.qc and sv_playerphysics.oc into one for simplicity sake, and can take advantage of the new area to control the physics, which is working. In Havoc Bot, he is detecting if a bot is looking at the new physics, and if so, he merely calls BotThink() and that pretty much takes care of it. Not sure if I like they way the bots behave in that mod , as they sometimes seem to be too quick, unless its a setting I missed. But they way I have it now, is we check if time > self.nextthink in that same spot, and if so, set nextthink, and assign think to be BotThink ()...else if nextthink > time we call the animaiton , which seems to work decent, except for those freezes in the playerthinks mentioned above. Is this because the bot always thinks in those locations? If so, when I assign the nextthink -
depending on whats going on, will those playerthinks be effected by the new nextthinks or the BotThink() we are setting in the new physics code?


Spike wrote:...
No other botclient uses thinks for AI.
There's a reason for that.
Changing thinks or nextthinks utterly ruins any player animations (as well as lightning/nail attack rates).
Its easier for them to create and use their own timers inside PlayerPreThink. Whether you move with .movement or movetogoal, I really recommend that you do not use thinks inside your bot AI, doing so makes everything much more complex (unless of course your bots don't use the player model/frameset, of course, in which case it doesn't really make any difference either way).
Post Reply