SetFacing (Finally)

This may be useful to others too … but I know at least @andgalf and @kevL_s were looking into this with me some while back.

The Problem … When using the SetFacing to make faction members face an NPC in a conversation, the odd faction member would fail to face correctly. i.e. they would be off facing another way.

The Cause … I tracked the issue down to what appears to be due to a “bumping” of the faction member prior the conversation starts. This is not always the cause, but has been often for myself.

The Solution … As far as my own tests have gone, this simple addition to my previous attempts of enforcing a facing has finally appeared to force the correct facing … The idea is that the initial assigning forces a kind of “reset” on the faction member prior the actual facing we need.

// FINALLY FIXED THE ODD FM NOT FACING CORRECTLY
				DelayCommand(0.0, AssignCommand(oFM, SetFacingPoint(GetPosition(oFM))));	
				DelayCommand(0.25, AssignCommand(oFM, SetFacingPoint(vTarget, 1)));	

If you have any other versions that appear to fail, then try doing this first. I have updated a couple of my own scripts to fix this issue so far.

3 Likes

Interesting. So now the companion is first facing him/herself before facing something else?

@andgalf

Kind of… I think the first setting sort of resets where it thinks the FM is currently facing, after any erroneous setting was placed on it.

I was thinking of the SetFacingPoint(GetPosition(oFM) which to me sounds like the oFM is facing oFM here, but maybe I interpret the script wrong.

@andgalf

That’s about right (from a literal interpretation) … which I hope is why it “resets” itself too. BTW, I have tested in around 3 situations and all appear to have worked for me so far.

Alright. Sounds great. I’ll copy this and use it if I again notice issues with the wacky weird non-turning of characters.
Thanks for posting this!

1 Like

I’m looking for the opposite of this. When using animations in conversations, I don’t want the npc to turn and face the player. In fact I want them to remain facing whatever way they are currently facing (default turns them east after each line of conversation is selected). Is there a way to do that (not a single post I received on the forum corrected this). The PC displays this same behavior. Conversations in an xml menus or commands don’t have this issue, but I don’t create xml’s and converting one is too time consuming for what I am putting in the game now. Any ideas (subject is: Maintaining current facing direction for NPC/PC during a custom conversation).

1 Like

Off the top of my head, I would say, yes.

Have you tried applying SetOrientOnDialog to FALSE for the NPC prior the conversation starting?

Try that first and let me know.

1 Like

I think what Lance is saying is right. I believe I’ve used that a few times in the past. Or maybe use ga_face_target and set bLockOrientation to 1.

1 Like

Yup. Someone suggested that in the discord chat, several months ago, t’s still selected on the convo. I think Direction east is hard coded. You can vary whether they face the speaker and it does override that, but there doesn’t appear to be a 'do nothing override (even a scripted still animation command doesn’t work it simply cycles through that command to the turn, if you are not already facing east).

Well, what you could do (I know I’ve sometimes done this) is to on every node do a ga_face_target towards the thing you want them to be facing. It’s a bit tedious to do this, but from my experience it works pretty well at least.

This does it…

//PC always disorientated
//PGB 12/05/07
#include “ginc_actions”
void main()
{
object oPC=GetPCSpeaker();
AssignCommand(oPC,ActionOrientToTag(“the tag of who you want to face”,ORIENT_FACE_TARGET));
}

If you put it on the line before they have to face someone they’ll always be facing that way when they talk. It’s pretty fast because you just go to actions and type in the first few letters of the script name and it comes up, click it and it’s done. Copy and paste the script for all npcs and give them individual names… face_john, face_fred etc. that way when you type in fa all your facing scripts appear and it’s not a hassle of filling in boxes etc.

1 Like

@Tsongo - Out of curiosity: Why do you use this script instead of ga_face_target? Do find this to be better?

andgalf… The truth is that a long time ago I didn’t know ga_face_target existed so I always used that script. In my last module I used both my ( not mine really it’s PGBs ) script and the ga_face_target action with the lock set as on.

But in all my other mods the script never failed and once you’ve made one and templated it you can set it on anything very quickly.

I think they’re both as good as each other, if anything the lock makes ga_face_target easier but with the script… I can’t explain this but here goes…

Three people talking to the PC they are A B and C.
Set first line face A.
Talk to A, set face B.
Talk to B but now A is facing B, which can’t happen with a lock.

1 Like

Sorry for the late response, but I’ve only just come out of an internet issue lasting over 24 hours.

Anyway …

@Tsongo, and others.

The ActionOrientToTag is a wrapper function that eventually leads to this …

// Orient to a target object 
void ActionOrientToObject(object oTarget, int iOrientation = ORIENT_FACE_TARGET)
{
	switch (iOrientation){
		case ORIENT_FACE_TARGET:
		    //ActionDoCommand(SetFacingPoint( GetPositionFromLocation(GetLocation(oTarget))));
		    ActionDoCommand(SetFacingPoint(GetPosition(oTarget)));
			break;
				
		case ORIENT_FACE_SAME_AS_TARGET:
			ActionDoCommand(SetFacing(GetFacing(oTarget)));
			break;
	}
	
    ActionWait(0.5f);  // need time to change facing
}

… and so you can see that it ends up using the same fundamental function, SetFacing or SetfacingPoint, but both these functions suffered from the issue I mean. (See next.)

However, to avoid locking for the duration of a conversation, this is what you need to do … However, the problem that I was experiencing, and I believe @andgalf may also have experienced, as well as some others perhaps, is that these functions that use SetFacing were still failing to ensure the PCs were all facing the speaker when required.

The problem would be whenever such functions were called, one PC would ignore the function and not have their SetFacing work, no matter how it was called. @kevL_s and I looked long and hard at this a while back, and there appeared to be one consistent “issue” that upset a PC from turning … and it was this …

Imagine a group of PCs gathered around and in front of an NPC. If a player then controlled a PC to walk up to an NPC to speak with them … if said player controlled PC bumped into a PC as they approached the NPC to speak with them, and caused the PC bumped into to change direction just prior the conversation starting, the bumped PC would remain looking in their previously bumped position even after this function is called.

It was as if the bumped/changed direction PC had not registered the fact that it was facing a new direction after the bump and so any call to change that facing was being calculated from some facing value prior the bump, and so any new SetFacing appeared to be ignored … BUT … I think I recall later applying SetFacing (maybe after a few seconds) did start to work again.

So, the bottom line for this is that the “fix” mentioned above (which appears to work for some of my own situations after a bumped PC has been changed direction), appears to allow the SetFacing to work immediately when required from using the function.

It’s hard to explain, as unless you experience the annoyance of a rogue PC ignoring the SetFacing function, one may not realise the problem even exists.

Anyway, I hope that helps to explain it a bit more. :slight_smile:

@adam_ii323

I have an example for you below. It could simply be a case that your NPC is being bumped by something else before the conversation starts, and so using the SetOrientOnDialog in this case will simply lock them into facing the direction they were looking at prior the conversation.

So, if their direction has changed, as I explain above, then it won’t help. Assuming the NPC is not moving around, you could ensure they are not jolted prior any conversation by ensuring they cannot be “bumped” in any way and then the SetOrientOnDialog will work as intended. Or, if you want them to face a direction prior to fixing the orientation, then apply the facing just prior the conversation starting, or even on the first node and then lock it in.

I can confirm with a test I just carried out that the following does prevent the NPC from turning to face the PC … The line was added in the creature on conversation script.

SetOrientOnDialog(OBJECT_SELF, FALSE); // ADDED THIS LINE PRIOR CONVERSATION STARTING
BeginConversation(sCONV, OBJECT_INVALID, PreventHello);

This was just a quick test, and you can update it to use a conditional variable held on the NPC instead. It was just to show it does work.

Here is a version where you can control the lock via an integer on the NPC … EDIT: I added a bumpstate lock as well, just in case you have another creature pass by and jolt them … BUT, You may wish to add these two conditions to the NPC in question a long time prior the conversation is about to start if there is any risk they can be bumped out of their orientation before the conversation starts.

// NB: RESET ORIENTATION AND BUMP STATE WITHIN CONVERSATION WHEN REQUIRED
			int iORIENT = GetLocalInt(OBJECT_SELF, "LOCKORIENT");
						
			if(iORIENT)
			{
				SetOrientOnDialog(OBJECT_SELF, !iORIENT);
				SetBumpState(OBJECT_SELF, 2);
			}

REMEMBER TO DO THIS …

EXAMPLE IN USE:

1 Like

Thanks. However, when I experiment with the anim functions I usually only have 1 pc or the pc invisible and the 1 npc. 1 thing new you said was the variance in ‘behavior’ or function response by pc (I have noticed this on pc change, it’s a real thing in this game!). I may try introducing the orient command you provided, after the initial attempt to see if the correction ‘fires’. It’s just a sad truth that a lot of the functionality of the command apparatus of this games coding is ‘inconsistent’…lol. Having said that, since we are trying to get it to do things that the devs may not have cared to include for whatever reason, it’s still fun to get it to work! Thanks again, will let you know if I get a different result.

The above example I have above used only one PC and one NPC. The same would work for an invisible PC, unless you have added extra checks like I have in my own modules. i.e. It should work fine. (There are some other NPCs hovering around in the background, which show in the screenshot, but the conversation is only taking place with the single NPC with the single PC.)

The NPC is the halfling with her eyes shut who is facing the fire (to the left), and the PC is the dwarf on the right hand side. The halfling has remained facing away from the dwarf as the conversation plays out and until I unlock her orientation on a conversation node. (The woman with her arm out is just a drunken patron dancing in the background.)

What you may be experiencing is other scripts from elsewhere firing and impacting on what you are trying to do. i.e. Once you have grasped what events are firing and when, it is fairly consistent. However, it takes some experience and sometimes perseverance to work out what is having an impact on what you are trying to do. I am still discovering things, years on.

1 Like

Ok here’s an easier way for me to show you the issue. Take a single pc and give them an item with a conversation on it. Open a mod area with no other npc’s in it, and face them in any direction but east. When you open the conversation they will turn east, turn them back to their original direction, select a conversation node, and they will turn east again, if you have an end dialogue node or another tree selection underneath, (even if you have a lock orientation command on). My conversation with the animation would have the end dialogue node (with a link destination router), simply for the purpose of keeping the conversation open, so the action can be repeated continuously. If you can stop the pc from turning east when the conversation is opened, and when a node is used with the above conditions, problem solved and let me know how you did it.

Maybe I’m not thinking straight here, but to me it sounds like all kinds of weird things would happen if you have an item that’s the owner of a conversation, since then the game wouldn’t know where to turn the characters. I mean, if you instead had an tiny almost invisible kobold (like @Tsongo does it) or an Ipoint Speaker (you can find that among the placeables), you could place that in the west of the area. Thus the party will turn west all the time instead of east.

I might be interpreting this totally wrong as I don’t fully understand the situation here @adam_ii323 and for that I apologize.

andgalf… I think you’re right about the item, npcs want to face the conversation owner and might get confused. If this is a compass thing I wonder if it’s possible with a bit of practice to have all conversation with the pc standing east of the other npcs that are talking.

Invisible tiny kobolds are awesome but they can live in walls and fireplaces so be careful, you never know who’s listening !

adam_ii323… I think you need to think outside the box and work around the issue rather than go at it head on because it sounds like something’s hard coded.

Even if the item releases a genie that’s all it needs to do, stick the conversation on the genie blueprint that spawns. Have a conversation when it’s found that explains it fully and then a script on the item that carries out what it does when it’s used. Use gc_check_item in any conversation after getting it and fire it’s effect from that… “Oh look mummys, better use my mummy repellent on them” cast body of the sun etc.