SET_NAVGOAL and ramps

[JavaGuy]

I have a script that is supposed to make an NPC walk up a ramp. Everything in the script runs exactly as expected, but the NPC does not move.

 

As an experiment, I made a plain box map, copied into it all the entities associated with the script, and ran it. With the exact same script, when the route from the NPC to its navgoal was a flat surface it had no problem.

 

Has anybody had any luck getting an NPC to walk up a ramp in a script?

[Emon]

Add more nav points. Put a nav point at the end of the ramp, then one at the top of it. Maybe throw some more in there for good measure.

[clu]

I had loads of problems getting NPCs to walk up ramps (and with waypoints/navgoals in general).

 

1) Add more navgoals as Emon suggested; it may have to do with "line of sight" of the NPCs. If they can't see the nav in their feild of view because of the slant, then they won't go

 

2) With waypoints, some people suggest you target one to another and then have the last one target a Navgoal. I actually disagree with this a bit. In kejim_post I just see a series of waypoints with a navgoal (untargeted) that just intersects the path of one of the waypoint lines. I ended up doing it this way with a recent map and it was the only way I was able to get NPCs to consistently find the desired navgoal.

 

-clu

[JavaGuy]

Is this enough waypoints for you?

 

http://sammckee.com/waypoints.jpg

 

 

It still doesn't work!

[clu]

That certainly is a lot of waypoints. OK, here are some options/questions:

 

1) Post the script that you are using to make the guy go up the ramp

 

2) What is that big red line going from your info_player_start?

 

3) Do what Emon suggested: add more navgoals (Emon correct me if I'm wrong) then have the script run through more tasks that tell the user to go to nav1, then nav2, then nav3, etc.

 

affect ( "some_dude", FLUSH )

{

 

task ( "go_to_nav1" )

{

set ( "SET_NAVGOAL", "nav1" );

}

 

task ( "go_to_nav2" )

{

set ( "SET_NAVGOAL", "nav2" );

}

 

task ( "go_to_nav2" )

{

set ( "SET_NAVGOAL", "nav3" );

}

 

dowait ( "go_to_nav1" );

dowait ( "go_to_nav2" );

dowait ( "go_to_nav3" );

 

}

 

4) Would there be a problem with the entities intersecting the ramp brush? Just a guess

 

-clu

[JavaGuy]

//(BHVD)

camera ( /*@CAMERA_COMMANDS*/ ENABLE );

sound ( CHAN_AMBIENT, "music/yavin_final/yavfinal_atr03" );

camera ( /*@CAMERA_COMMANDS*/ MOVE, $tag( "gorog_cam1", ORIGIN)$, $0$ );

camera ( /*@CAMERA_COMMANDS*/ PAN, $tag( "gorog_cam1", ANGLES)$, < 0.000 0.000 0.000 >, 0 );

camera ( /*@CAMERA_COMMANDS*/ MOVE, $tag( "gorog_cam2", ORIGIN)$, $15000$ );

camera ( /*@CAMERA_COMMANDS*/ PAN, $tag( "gorog_cam2", ANGLES)$, < 0.000 0.000 0.000 >, 15000 );

wait ( 5000.000 );

 

task ( "01gorog" )

{

sound ( CHAN_VOICE_GLOBAL, "sound/chars/gorog/01gorog" );

}

 

 

task ( "01kyle" )

{

sound ( CHAN_VOICE_GLOBAL, "sound/chars/gorog/01kyle" );

}

 

 

task ( "02kyle" )

{

sound ( CHAN_VOICE_GLOBAL, "sound/chars/gorog/02kyle" );

}

 

 

task ( "02gorog" )

{

sound ( CHAN_VOICE_GLOBAL, "sound/chars/gorog/02gorog" );

}

 

 

affect ( "gorog", /*@AFFECT_TYPE*/ FLUSH )

{

set ( "SET_UNDYING", "true" );

set ( "SET_WALKING", "true" );

 

task ( "go_start" )

{

set ( "SET_NAVGOAL", "gorog_start" );

}

 

do ( "go_start" );

}

 

dowait ( "01gorog" );

dowait ( "01kyle" );

wait ( 5000.000 );

dowait ( "02gorog" );

dowait ( "02kyle" );

wait ( 3000.000 );

camera ( /*@CAMERA_COMMANDS*/ DISABLE );

 

Before you ask, yes I have verified that the NPC in question has his NPC_targetname set to "gorog" and that the navgoal in question has its targetname set to "gorog_start".

 

Now what happens when I run this is that it goes into cinematic mode, the sounds play, and the camera moves/pans exactly as I want--very dramatic stuff--but the NPC just stands there like a dork, which kind of spoils the effect and also leaves him in the wrong place when the cinematic ends. ;(

 

The red box is the NPC spawner, not the playerstart. The red line coming to it is from the trigger that spawns him and also targets the scriptrunner. He spawns okay, and the script runs.

 

I made sure that all the waypoints are not intersecting the ramp.

[clu]

I'm kind of stumped, but here are some suggestions (kind of grasping at straws here):

 

1) in your affect "gorog", set ( "SET_BEHAVIOR_STATE", "BS_CINEMATIC" ); just for kicks

 

 

2) For testing, take out all your other script after the affect "gorg" block. Maybe since you are using "do" instead of "dowait" it might somehow be skipping over the task. Anyway it always helps to get rid of extraneous code to identify a specific problem.

 

3) Again...do what Emon said! Try adding multiple navgoals: one that's very close to him, then one that's a bit further away, then one at the top of the ramp. Create three tasks and run them in succession just to see how far he gets (and to see if navgoal visibility is indeed the issue).

 

4) Also, for testing, try putting another task (like an animation or something) within gorgs affect statement just to see if it's a navgoal/waypoint issue at all. I remember lassev telling me there was an issue running scripts on entities immediately after spawning them.

 

-clu

[Mercenary]

You tested your setup on a flat surface and it worked, right? Don't waste your time looking at the script if it already works. The NPC can't see the waypoint_navgoal, it's too high. Try putting in an extra one in the middle of the ramp, get the NPC to walk to this one first then to the next.

[JavaGuy]

Problem solved! It was the issue of running a script on the entity right after spawning. Spawning it in advance solved the problem. I just spawned it as invisible, nonsolid and cinematic, then in my cinematic script changed him to visible, solid and bs_default.

[clu]

Originally posted by JavaGuy

Problem solved! It was the issue of running a script on the entity right after spawning. Spawning it in advance solved the problem. I just spawned it as invisible, nonsolid and cinematic, then in my cinematic script changed him to visible, solid and bs_default.

 

Cool. Lassev pointed this spawning/scripting issue out to me when I was struggling a few weeks ago with a different problem. Glad it works now, good luck.

 

-clu