37 réponses à ce sujet

[Artfoundry]

Hi
I've got a conversation in which at one point the PC and companion NPC are instructed using ga_move to move to 2 waypoints.  The PC moves fine, but the NPC doesn't - he just follows the PC, staying a few feet behind.  I've triple-checked the waypoint tag and the NPC tag both in the objects and in the conv. node action script.  I've also tried putting the action in two different nodes - the same one that has the action for the PC and the one following it.  Made no difference.

Any ideas?

[Shallina]

Beceause the compagnion is commandable and will change his course of action and go back after the PC.



You got 2 choice : Remove the compagnion from the group for the duration or your event. Or play with the SetCommandable Function.

[Artfoundry]

I suspected that might be the problem. I just tried using ga_commandable in the conv. (one call before the ga_move that made the stack modifiable and one call after that reversed it), but that didn't work. Then I tried using ga_roster_party_remove before the ga_move and then ga_party_add after, and not only did it not work, but it froze my computer. So I'm thinking I didn't do it right.



For ga_commandable, is there something else I need to do?

For removing the companion, what could i be doing wrong? If I remove a companion from the party, I don't need to readd him to the roster before readding to the party, do I?

[Olblach]

I'm using something like that to have a henchman stop following:

#include "x0_i0_assoc"

void main()
{
object oPC = GetPCSpeaker() ;
object oHench = GetLocalObject(oPC, "HENCHMAN") ;
	
    if (GetIsObjectValid(oHench))
    {
	SetAssociateState(NW_ASC_MODE_STAND_GROUND, TRUE, oHench) ;
        RemoveHenchman(oPC, oHench);
	AssignCommand(oHench, ClearAllActions(TRUE)); // needed to get rid of autofollow
    }	
}

 

I added the RemoveHenchman because the NPC wouldn't follow but would go into area transitions anyway. Now the SetAssociateState might be an overkill, I wrote this script 3 years ago don't really remember

In your case you can use this script without the RemoveHenchman line and see if you can get the ga_move to work afterwards.
Or maybe something like this:

#include "x0_i0_assoc"

void main()
{
object oPC = GetPCSpeaker() ;
object oHench = GetLocalObject(oPC, "HENCHMAN") ;
	
    if (GetIsObjectValid(oHench))
    {
SetAssociateState(NW_ASC_MODE_PUPPET, TRUE, oHench) ;       
 AssignCommand(oHench, ClearAllActions(TRUE)); 
    }	
}

 
then this to resume to normal state

#include "x0_i0_assoc"

void main()
{
object oPC = GetPCSpeaker() ;
object oHench = GetLocalObject(oPC, "HENCHMAN") ;
	
    if (GetIsObjectValid(oHench))
    {
 SetAssociateState(NW_ASC_MODE_PUPPET, FALSE, oHench) ;      
 AssignCommand(oHench, ClearAllActions(TRUE));
    }	
}

 
Sorry don't have the time to test it but SetAssociateState seems to be the way to go to me. STAND_GROUND or PUPPET or maybe a mix of the two are the best candidates.

Modifié par Olblach, 12 octobre 2010 - 07:46 .

[Artfoundry]

I finally got around to trying this (the two little scripts you wrote), and the companion just continued to follow the PC rather than going to the waypoint. Any other ideas?

[Olblach]

Lets try to fix it before you try something else...



What happens if you use NW_ASC_MODE_STAND_GROUND, instead of NW_ASC_MODE_PUPPET?



Did you try both? I'm quite sure STAND_GROUND will stop the follow, as for going to the waypoint it's another story.



Another possibility would be that HENCHMAN variable is not set. There are plenty ways to access your Henchman, how do you get his/her object normally?

[Artfoundry]

Yep, tried both - didn't make any difference.



For setting the companion, I altered your code slightly to allow make the script more generic and allow me to enter the name through the conversation parameters UI:



#include "x0_i0_assoc"



void main(string sHench)

{

object oPC = GetPCSpeaker() ;

object oHench = GetLocalObject(oPC, sHench) ;



if (GetIsObjectValid(oHench))

{

SetAssociateState(NW_ASC_MODE_STAND_GROUND, TRUE, oHench) ;

AssignCommand(oHench, ClearAllActions(TRUE));

}

}

[Olblach]

Well STAND_GROUND must work since it is what it is designed for (and it works for me). You still have the RemoveHenchman() possibility but that's an overkill imho.

if (GetIsObjectValid(oHench))

{

SetAssociateState(NW_ASC_MODE_STAND_GROUND, TRUE, oHench) ;

AssignCommand(oHench, ClearAllActions(TRUE));

}
else
{
 SendMessageToPC(oPC, "Where is your henchman?!");
}

Modifié par Olblach, 13 novembre 2010 - 10:14 .

[Artfoundry]

Ok, that's really odd - after adding the else statement, it worked! The companion walked to the waypoint. Why would adding the else statement fix it??

[Olblach]

There are pixies in the compiler, it's a well known fact^^.

It can happen for various reasons. The #1 is include file not recompiled and the #2 is syntax error unnoticed. "Compile All" fixes #1 and helps detecting #2.

[dunniteowl]

Don't If statements have to have supplemental Else statements? Even if there is no real choice to do more, I thought all IF statements had to have a corresponding ELSE statement to follow up.

Bear in mind that's just a logic point of view, not programming experience (of which my last real programming experience was around 1978 in High School with BASIC.)

dno

[_Knightmare_]

Chaos Wielder wrote...

"if" statements need not necessarily have an else statement in programming. In reality, too, I think it could be framed as. "I'm walking, and if it's raining I'll go inside." The "else" might be implicit that I'll keep walking if it doesn't rain, but I don't know if it's anything more than that(maybe just baggage language, or something like that).

/digression

A good analogy here.

You do not need an "else" for every "if" as the "else" is implied. In this case (of no "else") the implied "else" is "do nothing".

There's a bunch of ways to do that in normal language:

"If it is night time, I will go to sleep.... It is day time." Implies that since it is daytime I will not go to sleep.

[Artfoundry]

Olblach wrote...

There are pixies in the compiler, it's a well known fact^^.
It can happen for various reasons. The #1 is include file not recompiled and the #2 is syntax error unnoticed. "Compile All" fixes #1 and helps detecting #2.

heh heh, damn pixies.  Ok, well thanks for the help!

[Artfoundry]

Olblach wrote...

There are pixies in the compiler, it's a well known fact^^.
It can happen for various reasons. The #1 is include file not recompiled and the #2 is syntax error unnoticed. "Compile All" fixes #1 and helps detecting #2.

So, I'm still having problems with this issue.  Much of the time, the NPC doesn't go to the waypoint but continues to follow the PC instead.  Sometimes though he does what he's supposed to.  And I compile all scripts every time.  Any other ideas?

[M. Rieder]

I have had difficulty with NPC's moving to waypoints if the nearby walkmesh is too cluttered. It seems that the NPC AI can sometimes become confused. That does not explain the following of th PC, but just check the walkmesh. That may help.

[Artfoundry]

Well, the only thing that may be a problem with that is that I'm trying to get him to walk through a door (the waypoint is on the other side). The door is a double door though, so it's pretty wide. What seems to happen though is that he's just continuing to follow the PC (who is also walking through the doors to a waypoint next to the NPC's). When he does make it to the waypoint, he runs right toward it instead of following the PC. So I don't think it's the walkmesh/obstruction of the doorway. I think it's that he's just not detaching from his following behavior.

[Artfoundry]

I just realized, in the conversation, when I'm sending the ga_move commands to the PC and to the companion, I'm using $PC_NEAREST to refer to the PC. Maybe that's not the right way to refer to it? Could that be causing confusion?

Modifié par Artfoundry, 16 janvier 2011 - 12:46 .

[M. Rieder]

Have you tried using just $PC to refer to the PC?  Also, have you tried putting another NPC there, not in your party, and giving the command to it, to see what happens then?  I'm wondering if the script is somehow issuing the same command to both the PC and the companion, thinking that they are both the PC.

Modifié par M. Rieder, 16 janvier 2011 - 01:43 .

[M. Rieder]

I just looked in the script ginc_param_const and found the following:





const string TARGET_PC_NEAREST= "$PC_NEAREST";// NearestPC (owned and alive)



Therefore, if you use $PC_NEAREST, the script will use the nearest PC that is owned for the script. Not sure if this helps.

[Artfoundry]

I tried changing it to $PC, but no change in behavior that I could see.

I also tried removing the reference altogether (which makes the script use the owner of the conv. by default), and another NPC ended up moving to the PC's waypoint while my henchman moved to his waypoint (and the PC just stayed put - in fact, my henchman ran AROUND the PC to get to the waypoint).

[M. Rieder]

If you think that the AI of your companion is messing things up, you could boot the companion from the party briefly and then put him back once he is where he belongs.



Just to clarify, is it a henchman or companion?

[Artfoundry]

It's a companion, not henchman - sorry for being lazy and using the words interchangeably.

I'll try removing him from the party and then adding him back in.

[Artfoundry]

Hmm, not sure if I'm doing this correctly, but when I remove him from the party, he disappears entirely. I tried using both ga_roster_party_remove and ga_remove_comp, both with the same result.

[Shallina]

you are probably not using a good script to have him move,to the new point. For myself, I use personnals script to remove the compagnion from the party and then I make them wolk to an exit without problem with the default script for this,

You need to set your compagnion as campaign NPC as well.

Modifié par Shallina, 17 janvier 2011 - 09:53 .