It would seem the monster function crashes(clicking 'ok' you continue to run the program,however the bad function never runs again .i.e. monster_code)) , however the loop inside ent_movepath is still running. The ent_animate is in the monster loop that has crashed, so stops running.

Anyway good luck have fun. I got no answers for you, there is a reason that I don't use that function. Also i see the " ....." and there have been times your issues were with code inside the "...."
Track down you e1513, also that function - the monster will always "wrap" to the first node.

You can modify my basic path function found here
http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Main=54661&Number=455425#Post455440

You my have add so math to smooth the between nodes like path_spline does.

By setting the node number closest to the monster here
my.NODE_NEXT=path_nextnode(my,1,1); // SET THE NODE
you can avoid the wrapping.

I am providing no more support for this, Unless I get bored when the weekend and drinks run out.
Mal

I have had my fill of ent_movepath(). It is not a user friendly function.

You mentioned you stay away from this function. Do you know of a better way to accomplish what I am trying to accomplish?

^ um see my post above ^ ????

Your function seems to partially work. I am still trying to adapt it to my code to possibly make it work.

In the meantime, I found another possible solution that seems to work mostly well. I am using ent_moveto() and ent_turnto() functions. They seem to be moving the monster down the staircase as needed. The only problem is that I am using a wait_for_my(ent_moveto) function that seems to prevent any animations from occurring, such as a running animation, until the ent_moveto() is finished.

Here is the code I am using to do this:



If I take out all the wait_for_my() code, the running animation will happen, but the monster entity will move through the air directly from the 1st spiral staircase location to the 3rd location. The wait_for_my() functions make it so that the monster entity reaches the next location before turning and moving toward the next location given. The ent_turnto() seems to work with the wait_for_my() function calls, just not the running animation.

If I took out just the last wait_for_my() function call out of the above code, the monster would move and face the correct destinations while gliding with no animation. Once it got past the second destination though, it would start a running animation while it was being moved using ent_moveto(), so it is clear that the wait_for_my() function is what is causing the running animation to not occur.

Is there a way to allow the running animation to keep going even though the wait_for_my() function is being used?

This method seems to work perfectly, except for the fact that the monster does not appear to be running, only gliding toward the right directions with no animation.

At this time, I am evoking this -


I'm a six-pack in already and it's a fun holiday weekend.

Best luck
Mal

I tried using your function. The monster does run toward the first node, but does not go beyond the first node.

I am trying to figure out how to make it go to the second node.

You obviously do not read what I post. That function works. It was the core of my space race game. I can write it, rewrite, mod it and make it give birth to little 3d puppies.

Good NIGHT
Mal

Ruben if your character does not go past the first node you obviously have to check the code and the comparisons involved which handle getting new nodes. From a first glance this seems to be stuff like this:

Use draw_point3d to display let's say my.x and vec_next_node.x. You can use draw_line3d too.
Then DEBUG_VAR or draw_num3d (http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=455738#Post455738) to check both the vec_dist and my.max_x values, and draw my.NODE_NEXT.
Oftentimes nodes and such can have different heights compared to where "my.z" is, let's say when the origin of your model is rather low and the path node z values at a too high position. Then xy-dist will get as close as it gets but the z-difference can, because of your gravity code and such, remain too big. If you only have one floor you can set the vec_next_node.z value always to my.z.

^ Of course Superku is correct. The code was write to in current form for 2d movement - no z changes. It's clear in the line Superku points out and the lack of a Z-axis in the c_move of the code.

This correct can help


Happy Halloween, I've got a ghost in my bed and she wants to rattle the chain. So have fun and game-on
Mal