AIPlayer Jump trigger
by Gerald Fishel · in Torque Game Engine · 04/26/2004 (9:45 pm) · 9 replies
Hi all,
Okay, so I've been working on an AI framework, and I have a good part of the planning and pathfinding systems working. The navigation system contains information regarding when the agent should jump, open doors, etc. Now I just need to get the character animation to work with it ;)
I have the basic movement down, so I figure the next thing is to get the jumping to work. I looked through some previous forum threads that say use setTrigger( 2, true ) to jump... setTrigger is no longer a function. However, these old threads also say to use setTrigger( 0, true ) and (1, true ) to shoot. I have shooting working by using setImageTrigger( 0, true ). So I tried setImageTrigger( 2, true ), and it did not have the desired effect. So I traced into the setImageTrigger console function, which calls ShapeBase::setImageTriggerState.
The first line of the function is this:
Upon getting here, mMountedImageList[imageSlot].dataBlock is NULL, so the function exits and nothing else is done as a result of calling setImageTrigger( 2, true ).
From looking at the rest of the code, I gather that I am barking up the wrong tree with this one.
I also looked at the key bindings in the client scripts and found this:
being called to make the player jump when pressing space. But I have no idea how to figure out what exactly this is doing. I don't see mvTriggerCount2 anywhere else.
Anyway... any help on figuring out how to trigger the bot to jump on the current HEAD would be great...
Also, before I spend hours digging through the animation code, does the Torque animation system that the player models use support IK or any other mechanism for dynamic animations, and if so is there any documentation on it, or any pointers where I should begin to look? ;) The initial problem to be solved would be having one of the characters hands reach out to grab a door handle by specifying the location to grab.
Thanks
Okay, so I've been working on an AI framework, and I have a good part of the planning and pathfinding systems working. The navigation system contains information regarding when the agent should jump, open doors, etc. Now I just need to get the character animation to work with it ;)
I have the basic movement down, so I figure the next thing is to get the jumping to work. I looked through some previous forum threads that say use setTrigger( 2, true ) to jump... setTrigger is no longer a function. However, these old threads also say to use setTrigger( 0, true ) and (1, true ) to shoot. I have shooting working by using setImageTrigger( 0, true ). So I tried setImageTrigger( 2, true ), and it did not have the desired effect. So I traced into the setImageTrigger console function, which calls ShapeBase::setImageTriggerState.
The first line of the function is this:
if (isGhost() || !mMountedImageList[imageSlot].dataBlock) return;
Upon getting here, mMountedImageList[imageSlot].dataBlock is NULL, so the function exits and nothing else is done as a result of calling setImageTrigger( 2, true ).
From looking at the rest of the code, I gather that I am barking up the wrong tree with this one.
I also looked at the key bindings in the client scripts and found this:
function jump(%val)
{
$mvTriggerCount2++;
}being called to make the player jump when pressing space. But I have no idea how to figure out what exactly this is doing. I don't see mvTriggerCount2 anywhere else.
Anyway... any help on figuring out how to trigger the bot to jump on the current HEAD would be great...
Also, before I spend hours digging through the animation code, does the Torque animation system that the player models use support IK or any other mechanism for dynamic animations, and if so is there any documentation on it, or any pointers where I should begin to look? ;) The initial problem to be solved would be having one of the characters hands reach out to grab a door handle by specifying the location to grab.
Thanks
#2
for some weird reason I also have to comment out
Any details on your pathfinding and planning stuff?
04/28/2004 (10:42 pm)
Yeah, I have movePtr->trigger[2] = true;in my AIPlayer to make it jump...
for some weird reason I also have to comment out
// Replicate the trigger state into the move so that // triggers can be controlled from scripts. //for( int i = 0; i < MaxTriggerKeys; i++ ) // movePtr->trigger[i] = getImageTriggerState(i);to get anything triggered...
Any details on your pathfinding and planning stuff?
#3
The pathfinding right now is pretty simplistic, not nearly as neat as the folks who are working on the auto-generated navigation mesh. The structure is just a hierarchical waypoint graph that automatically disperses waypoints around the level which can then be tweaked in the World Editor, or added to from within 3D Studio Max which I use for modelling my interiors. Invisible geometry is used to represent special cases, such as pits in the ground or climbable areas, or other hotspots that the bot should either jump over or avoid.
I use Djikstra's algorithm for the traversal, for development purposes, because it is more straightforward than A* and tweaking an edge bias has a better defined consequence. I will probably end up making an 11th hour switch over to A* though, for performance reasons.
I also use a series of repulsion vectors to avoid dynamic obstacles. Though it is kind of a dumb repulsion, because the repulsion ignores the static obstacles, and occasionally repulses the bot right into a wall... lol... have some work to do on that.
The planning is a stack-based goal oriented system that feeds information about the goals into the pathfinder, and retrieves contingencies from the pathplanner. Information is stored in the environment to help guide the goals.
For instance, as a theoretical, assume the bot wants to move from point A to point B... along the path from A to B, the pathfinder raycast crosses an object, which it queries and finds out it is a locked door, which has a set of goals attached to it for passage. The path is returned, along with the list of requirements to open the door. For instance, the requirements for opening the door could be something like "insert key card into slot, stand back for 2 seconds, walk through"... the planner then checks it's inventory to see if it possesses the key card, if it does, it pushes the 'move to point B' goal to the stack, then generates these new goals: 1) move to a point in front of the door 2) insert key card 3) step back and wait 2 seconds... when that is complete it will pop the old goal off the stack and resume 'move to point B' If the key card is not in the inventory, it will first determine whether it knows where the key card is at, if it does, it will push the current goal to the stack, and the new goal will be to move to where the keycard is at and get it. If it doesnt know where the key card is at, the new goal will become 'search for the key card'
I haven't gotten anything like that to actually work in practice yet, but that is how it is being organized.
The combat layer right now is just a 'terminator' that uses the pathfinder to head towards the player and start shooting as soon as the player is in range and within a line of fire.
There just aren't enough hours in the day to work on this stuff :p
Thanks for the tip re: jump trigger, I will try that out pretty shortly.
Peace
04/29/2004 (6:36 am)
Ahhh yes... I tried the movePtr->trigger[2] = true, but I did not comment out those other lines, which I guess would make sense :pThe pathfinding right now is pretty simplistic, not nearly as neat as the folks who are working on the auto-generated navigation mesh. The structure is just a hierarchical waypoint graph that automatically disperses waypoints around the level which can then be tweaked in the World Editor, or added to from within 3D Studio Max which I use for modelling my interiors. Invisible geometry is used to represent special cases, such as pits in the ground or climbable areas, or other hotspots that the bot should either jump over or avoid.
I use Djikstra's algorithm for the traversal, for development purposes, because it is more straightforward than A* and tweaking an edge bias has a better defined consequence. I will probably end up making an 11th hour switch over to A* though, for performance reasons.
I also use a series of repulsion vectors to avoid dynamic obstacles. Though it is kind of a dumb repulsion, because the repulsion ignores the static obstacles, and occasionally repulses the bot right into a wall... lol... have some work to do on that.
The planning is a stack-based goal oriented system that feeds information about the goals into the pathfinder, and retrieves contingencies from the pathplanner. Information is stored in the environment to help guide the goals.
For instance, as a theoretical, assume the bot wants to move from point A to point B... along the path from A to B, the pathfinder raycast crosses an object, which it queries and finds out it is a locked door, which has a set of goals attached to it for passage. The path is returned, along with the list of requirements to open the door. For instance, the requirements for opening the door could be something like "insert key card into slot, stand back for 2 seconds, walk through"... the planner then checks it's inventory to see if it possesses the key card, if it does, it pushes the 'move to point B' goal to the stack, then generates these new goals: 1) move to a point in front of the door 2) insert key card 3) step back and wait 2 seconds... when that is complete it will pop the old goal off the stack and resume 'move to point B' If the key card is not in the inventory, it will first determine whether it knows where the key card is at, if it does, it will push the current goal to the stack, and the new goal will be to move to where the keycard is at and get it. If it doesnt know where the key card is at, the new goal will become 'search for the key card'
I haven't gotten anything like that to actually work in practice yet, but that is how it is being organized.
The combat layer right now is just a 'terminator' that uses the pathfinder to head towards the player and start shooting as soon as the player is in range and within a line of fire.
There just aren't enough hours in the day to work on this stuff :p
Thanks for the tip re: jump trigger, I will try that out pretty shortly.
Peace
#4
04/29/2004 (10:21 am)
Hey, sounds really interesting and like 80% of what we are doing currently ;) Maybe you should join our (that is, "the folks who are working on the auto-generated navigation mesh" :P) discussions at beffy.de/phpwiki-1.3.7/index.php/TorqueDiscussion (check the chat logs if you want to know what we are going to implement etc.) and on IRC (irc.maxgaming.net, channel #torqueai) and maybe we can share some ideas or even work together on parts of this if you want ...
#5
Sounds cool, I will definitely be joining your discussions real soon. Been on an AI crash course for the last several months, and am far more excited about it than any human should be about anything :p
Peace
04/29/2004 (10:43 am)
Haha, once again I demonstrate my glorious lack of observation skills :pSounds cool, I will definitely be joining your discussions real soon. Been on an AI crash course for the last several months, and am far more excited about it than any human should be about anything :p
Peace
#6
After reading Justin's description of his method for generating the mesh I was inspired to scrap my waypoint graph and go with a navigation mesh as well. For some reason it sounded like far more work than it actually is.
I was able to slap together something similar, though not nearly as cool yet, pretty quickly. I've also got some good ideas for making it more hierarchical for faster planning of long distances. Though I don't know if he has anything similar in mind, or in practice right now.
I would be interested in joining you guys in a chat some time. I also have some ideas for navigation for different types of entities, including flying and waterbound entities, and ways to communicate between land/sea/air graphs, for some cool combat behaviors.
Peace
04/29/2004 (6:59 pm)
I must say, I only got a chance to read a couple of the chat logs on that site, but they were good reading ;)After reading Justin's description of his method for generating the mesh I was inspired to scrap my waypoint graph and go with a navigation mesh as well. For some reason it sounded like far more work than it actually is.
I was able to slap together something similar, though not nearly as cool yet, pretty quickly. I've also got some good ideas for making it more hierarchical for faster planning of long distances. Though I don't know if he has anything similar in mind, or in practice right now.
I would be interested in joining you guys in a chat some time. I also have some ideas for navigation for different types of entities, including flying and waterbound entities, and ways to communicate between land/sea/air graphs, for some cool combat behaviors.
Peace
#7
I have tried playing around with the movePtr->trigger[2] to get my bots to jump and have managed to get them to either never jump or continually jump. I obviously need to have some sort of jump condition for when I need that bot to jump but can't seem to time things right. When you use this line:
// ======>
movePtr->trigger[2] = true;
// <======
when exactly does that get the bot to jump, what function, or call has to be executed for this to happen? The reason why I ask is because I want the bot to jump once and not consecutively. If I know where the actual line of code is that makes the bot jump then I can turn off the jump mode.
Does anyone know the purpose of these lines:
// ======>
//for( int i = 0; i < MaxTriggerKeys; i++ )
// movePtr->trigger[i] = getImageTriggerState(i);
// <======
The posts above say to comment the above lines out, but if I do my bots just kinda stand there and doodle about...?
I CANNOT BELIEVE THERE IS NO SIMPLE JUMP FUNCTION....??? It just seems like it should be a natural thing/function to build when making an engine......?
I do not want to use an impulse to make my bots jump because from time to time they will keep calling impulses right after another making them jump higher and higher into the sky. UNLESS, someone knows how to detect if the bot is in the air and not on a surface. Then this could work.
I truly hope someone can shed some light on this.
Thx in advance.
DALO.
04/13/2008 (8:55 pm)
Hello,I have tried playing around with the movePtr->trigger[2] to get my bots to jump and have managed to get them to either never jump or continually jump. I obviously need to have some sort of jump condition for when I need that bot to jump but can't seem to time things right. When you use this line:
// ======>
movePtr->trigger[2] = true;
// <======
when exactly does that get the bot to jump, what function, or call has to be executed for this to happen? The reason why I ask is because I want the bot to jump once and not consecutively. If I know where the actual line of code is that makes the bot jump then I can turn off the jump mode.
Does anyone know the purpose of these lines:
// ======>
//for( int i = 0; i < MaxTriggerKeys; i++ )
// movePtr->trigger[i] = getImageTriggerState(i);
// <======
The posts above say to comment the above lines out, but if I do my bots just kinda stand there and doodle about...?
I CANNOT BELIEVE THERE IS NO SIMPLE JUMP FUNCTION....??? It just seems like it should be a natural thing/function to build when making an engine......?
I do not want to use an impulse to make my bots jump because from time to time they will keep calling impulses right after another making them jump higher and higher into the sky. UNLESS, someone knows how to detect if the bot is in the air and not on a surface. Then this could work.
I truly hope someone can shed some light on this.
Thx in advance.
DALO.
#8
TriggerKeys are used for better control over a few animations (like run).
When run it is beter to complete the started step, or it will return to root.
Read about that triggers, they are used in your modelling software, and are controled in the updatethread function.
There is a lot of information about that you asked, but the whole info is spreaded out in a lot of topics.
The forums is still not organized well, it is hard to find a lot of things, even using the search engine.
04/15/2008 (10:06 am)
In updateMove:if (move->trigger[2] && !isMounted() && canJump())
{....}TriggerKeys are used for better control over a few animations (like run).
When run it is beter to complete the started step, or it will return to root.
Read about that triggers, they are used in your modelling software, and are controled in the updatethread function.
There is a lot of information about that you asked, but the whole info is spreaded out in a lot of topics.
The forums is still not organized well, it is hard to find a lot of things, even using the search engine.
#9
movePtr->trigger[2] = true;
This line, I am guessing, would go somewhere in AIPlayer::getAIMove. The move->trigger[] array is basically a bunch of booleans that you can use for most things. You might want to add fields to AIPlayer itself to control when the trigger[2] is set to true. If you just stick it somewhere in the function, it should make your bots jump constantly.
//for( int i = 0; i < MaxTriggerKeys; i++ )
// movePtr->trigger[i] = getImageTriggerState(i);
These lines copy all the image trigger states from the bot to the move pointer. So if a bot's image trigger in slot 1 is don, movePtr->trigger[0] will be true.
The problem is, someone forgot that triggers are used for things other than images. So if you have no image in slot 2, image trigger 2 will always be set to false.
My advice would be to add movePtr->trigger[2] = true; AFTER the above for loop, so that move->trigger[2] is overwritten to make jumping happen regardless of having no image mounted in slot 2.
04/16/2008 (8:18 am)
Dalo:movePtr->trigger[2] = true;
This line, I am guessing, would go somewhere in AIPlayer::getAIMove. The move->trigger[] array is basically a bunch of booleans that you can use for most things. You might want to add fields to AIPlayer itself to control when the trigger[2] is set to true. If you just stick it somewhere in the function, it should make your bots jump constantly.
//for( int i = 0; i < MaxTriggerKeys; i++ )
// movePtr->trigger[i] = getImageTriggerState(i);
These lines copy all the image trigger states from the bot to the move pointer. So if a bot's image trigger in slot 1 is don, movePtr->trigger[0] will be true.
The problem is, someone forgot that triggers are used for things other than images. So if you have no image in slot 2, image trigger 2 will always be set to false.
My advice would be to add movePtr->trigger[2] = true; AFTER the above for loop, so that move->trigger[2] is overwritten to make jumping happen regardless of having no image mounted in slot 2.
Torque Owner Josh Moore
[code]move->trigger[2] = 1;[code]