Path instructions

Posted By: msl_manni

Path instructions - 11/15/06 08:03

Can't find any path functions for
1. previous node
2. number of edges - from the node
3. number of edges leading to the node.
How to find the parents of a node and number of edges to and from the particular node. Please give a specific answer possible so that I can continue my work. Else use some other alternative, than using the path.
Posted By: jcl

Re: Path instructions - 11/15/06 11:22

Any node has a number of edges that lead to or from connected nodes. There is no such thing as a "previous node".

The number of edges of a node can be determined by path_getedge with increasing edge numbers until 0 is returned.

The nodes leading to the current node can be found by enumerating all nodes (path_getnode) and checking if an edge leads to the current node (path_nextnode).
Posted By: msl_manni

Re: Path instructions - 11/15/06 11:51

shouldn't these be built into the path system. Path is stored in a lnked-list and it would be easier to build there itself. If one has to go at such length to find these things then the new path system is useless for advanced AI.
I think and know that this would be better and easier to implement into the path system.
Please tell me if you are going to implement it, maybe later. Because it is better to have these functionality built into the path system as much better behaviour can be implemented thus.
Posted By: jcl

Re: Path instructions - 11/15/06 12:23

Let me say it this way: if the current path system is for you useless "for advanced AI", you probably won't have any better luck with any other path system.

It is trivial to program your desired functions in a few lines of C-Script. The engine provides all basic functions that you need, but we don't want to unnecessarily inflate the software by implementing functions that are seldom needed and easily scripted.
Posted By: msl_manni

Re: Path instructions - 11/15/06 14:33

It can be easily scripted but would need unnecessary amount of execution time and overhead. Instead it would be simple to store pointers of child and parents in c++ and counters for number of parents and childs in the structure node itself.

AI demands for prvious nodes arises due to the fact that, a AI should be able to walk in both direction's on a path. And thus seem natural where it would chase or evade the player.

If it seems as useless function implementation, then think about a path which could have hundreds of nodes and several thousand edges. Just to find the parents of such node, one would have to go through all nodes and its edges. Think about the no of times it would have to traverse through the path instructions to find no of edges leading from or to the node. It would be very simple to implement in c++ as pointers and counters in the linked list. The list would have to be double sided with n-sided pointers.

It is not necessary for me to explain the benefits to you, as you are better knowledged person in these matters.
Posted By: jcl

Re: Path instructions - 11/15/06 16:45

You do not need a reverse node pointer list for your AI to walk in both directions - just use bidirectional edges. Thus, at the moment none of the functions you're demanding makes much sense to me. But if you have a suggestion for a really useful function that would be otherwise awkward to script, then of course we're open for proposals.

Have a look at other people's AI code to learn how to work with paths. There are some path finding tutorials on the AU tutorial page.
Posted By: Doug

Re: Path instructions - 11/15/06 19:20

Maybe if you tell us what you are trying to do (give code if you can) we can figure out what (if anything) might be missing.

For example, finding a "previous node" isn't always possible using just the node graph. If two or more nodes connect to this node, which one is previous? However, it is trival to store the number of the last node in the entity, so they know which node they visited last.

Also, as JCL pointed out, paths can go both ways. This can be very handy in some cases, for example: it might be valid for an AI to jump off a roof into a pool, but it isn't valid for him to jump from the pool back onto the roof.


In short, I think you might be looking for the wrong tools to solve a problem.
Posted By: msl_manni

Re: Path instructions - 11/16/06 05:08

These are the situations that I would like to be helped to be coded.

1.) AI is walking along a path and in the middle of an edge encounters the player. It can go into chase-evade-shoot state. When it goes into an evade state it should be able to run back, say in a narrow hall all the way back. Where it might come to a decision node with multiple edges and parents. There might be certain things along different routes that might be of immediate use for the AI. Say an alarm, a helth pack, a box to hide behind etc. These can be any where from the node to edgeds or in a parent route. He should be able to walk freely on any edge and find its way.

2.) How would an AI be walking a path back and forth on a forked path.

In both ways paths, nodes point to each other. And I have not been able to even walk my AI on a single open path with many nodes. Perhaps a simple script, where an AI walks between say A-B-C-D-E and then E-D-C-B-A would be great to solve my problem. I would then store no of parents and childs in variables.

So I count on you to help me.
Posted By: testDummy

Re: Path instructions - 11/16/06 06:23

I am somewhat unfamiliar with the newer path instructions.
Although there may be much better ways, if you have simple linear path, which isn't in a loop and you just want the entity to walk the path in numerical node order:
(These are just untested, inadequate, flawed '5 min examples'. They may not be helpful.)
Code:

define _node, skill22;
define _nodeDir, skill23;
define _nodePrev, skill24;
define _nodeCount, skill25;

define pathScanRange, 1000;
define nodeHitDist, 3;
define relMoveSpeed, 5;

var temp2[3];
/************************************
aPathWalker0

*************************************/
action aPathWalker0 {
path_scan(me, my.x, my.pan, vector(360, 180, pathScanRange);
my._node = 1;
// find the closest node(added as an example only;
// path_scan already returns the closest node)
// count the nodes (just an example; not really used)
var dist0; dist0 = 99999;
var dist1; dist1 = 0;
var node0; node0 = 1;
while(path_getnode(me, my._node, temp, null)) {
my._node += 1;
dist1 = vec_dist(my.x, temp);
if (dist1 < dist0) {
dist0 = dist1;
node0 = my._node;
}
}
my._nodeCount = my._node - 1;
if (my._nodeCount <= 1) { return; } // only for greater than 1 node
my._node = node0; //the closest node
my._nodeDir = 1; //default to +1 walking
my._nodePrev = 0;
while(me != null) {
if (path_getnode(me, my._node, temp, null)) {
//
} else {//over step
my._nodeDir = 0 - my._nodeDir; //reverse nodeDir
my._node += my._nodeDir * 2;
path_getnode(me, my._node, temp, null);
}
temp.z = my.z;
if (vec_dist(temp, my.x) <= nodeHitDist) {
my._nodePrev = my._node;
my._node += my._nodeDir;
} else {
vec_sub(temp, my.x);
vec_set(temp2, temp);
vec_angle(temp, temp);
temp.pan = ang(temp.pan - my.pan); temp.tilt = 0; temp.roll = 0;
c_rotate(me, temp, ignore_passable);
//The following 'cap' technique may only be valid for forward relative movement.
temp.x = min(relMoveSpeed * time, vec_length(temp2));
temp.y = 0; temp.z = 0;
c_move(me, temp, nullvector, ignore_passable);
}
wait(1);
}
}
/************************************
nodeGetEdges(_ent, _node)
*************************************/
var nodeEdges[10];
var nodeEdgeCount;
var nodeGetEdgesOverflow = 0;
function nodeGetEdges(_ent, _node) {
nodeGetEdgesOverflow = 0;
nodeEdgeCount = 0;
var node0; node0 = 0;
while(1) {
node0 = path_nextnode(_ent, _node, nodeEdgeCount + 1);
if (node0 == 0) { break; }
if (nodeEdgeCount >= 10) { nodeGetEdgesOverflow = 1; break; }
nodeEdges[nodeEdgeCount] = node0;
nodeEdgeCount += 1;
}
return nodeEdgeCount;
}


Weak, flawed, work-in-progress example of directing an entity from one node to another on a non-linear path using a breadth-first search algorithm:
bfs061109
Instructions:
*[ + ] [ - ] keys (not numpad): zoom camera
*click destination node with mouse; start node is closest node to entity (arrow)
Included:
*the original tutorial (my code is not a copy, but is instead, probably a weaker derivative created from scratch)
*_0b.wdl (an outdated debugging script file)
Applications: none; it's completely useless
Posted By: msl_manni

Re: Path instructions - 11/16/06 08:30

BFS example works perfectly. But I am not developing an FPs. I am developing a single player game. I have many paths for different situations. Your BFS example stores nodes into arrays and the calculates the required solutions on those array's at run time. It wont be good/possible to apply this solution for very many paths.
I will study BFS and see if it can be of any help. But from the 15 years experience of working with every major programming language, I know that it would be very simple to implement the solution that I have already suggested. But I dont know how conitec is storing edge data for every node, else I would have helped them to find the perfect solution.
Posted By: HeelX

Re: Path instructions - 11/17/06 16:20

Then set your path with nodes, generate a lookup table and write your own path instruction via c++.
© 2024 lite-C Forums