Custom Companion Move to Player

[Xaranth]

What? It's pretty basic geometry.

[RBRoAB]

It's not the geometry part, it's the scripting part.

How much do you know about it?

[llamaRCA]

Well that escalated quickly.

If I wanted him to come up right behind me, like a few feet back maybe, what would that look like?

an example of the script would be nice

and what variables need defining

 

lol. okay. I totally lied. Her moveto script for her following packages has her move to the player's side. I had originally intended to do it putting her behind the player but the side placement worked out well. (Xaranth it works for you most of the time because she usually only gets stuck in places where she can't get through a door or, like you say, the navmesh is messed up and I'd guess your character is on the move so by the time she gets to your character he/she has moved on from where Willow drops in).

 

@RBRoAB - So I do a very small distance because if you do it very far from the player you run the risk of setting the companion down inside a rock or a static. So what I did with Willow looks like this:

 

WillowREF.MoveTo Player 50, 0, 0

 

which is not nearly as pretty as what Xaranth did, but it works.

[RBRoAB]

This is completely off topic, but while you two are here, and you both seem to really know your stuff

 

When I tell my companion to wait, he slowly walks in the opposite direction. Any ideas why?

[Xaranth]

It's not the geometry part, it's the scripting part.

How much do you know about it?

 

Oh, I went through all the fun of moveTo and construction a month ago when I designed my portable teleporter. :) This is easy, because it's an actor. No wizardry necessary. But I've actually done very little with NPCs, so I'm not the best to ask about blockTypes and such. looking at it, though, you've got implicit addressing in your conditional, so it would have to be an object script attached to your NPC's form.

 

If it were me, I'd probably set it up with explicit referencing and a gameMode block, and stick it in a quest script, probably the one attached to your NPC's Dialogue tree.

 

Although there's probably a better way.

[RBRoAB]

Thanks Xaranth! I put your script into the ProtectronObjectScript and it worked like a charm. You too are definitely getting credit on this mod.

 

But I can honestly say I have no idea what you're talking about on your second part.

 

And llamarca, do I have your permission to try out your script for moveto as well?

[llamaRCA]

If it were me, I'd probably set it up with explicit referencing and a gameMode block, and stick it in a quest script, probably the one attached to your NPC's Dialogue tree.

 

Although there's probably a better way.

 

I dunno. It works fine out of the object script, but it would work fine out of a quest script too. I don't know that it matters much. It's a script that just needs to chug away in the background which is kind of perfect, actually, for the NPC object script. It doesn't need to run more often than it does in the object script and it's not related to anything other than the NPC itself. I have mine in the object script and I wouldn't move it.

 

@RBRoAB - Couple things:

 

1.Make sure that you are setting the variable that controls the follow package(s) to zero at the same time that you set the variable for the wait package to 1 and be sure to evp after those changes. It should look something like this:

 

 

 

ProtectronREF.yourfollowingvar to 0
ProtectronREF.yourwaitingvar to 1
ProtectronREF.evp

 

If you have other packages that might be interfering then zero those out too before you set the waiting package variable to 1.

 

and if you are already doing that then,

 

2) Reorder the packages in the NPC package list. Try putting the wait package above the following packages in his list and see if everything works like it should.

 

 

Re: the line of code above?

 

Yes, of course :)

[Xaranth]

Oh, Explicit referencing is what you did in the second part of the script, where you call functions directly against ProtectronREF, i.e. ProtectronREF.moveTo

 

Implicit referencing is what you did in the condition. With an implicit reference it looks like you had it:

 

if (getDead == 0) && (getUnconscious == 0)

 

Implicit referencing is easy, but limited - as I said, you HAVE to have it in the object script attached to your NPC form. If we changed it to an explicit reference:

 

if (ProtectronREF.getDead == 0) && (ProtectronREF.getUnconscious == 0)

 

it could be placed in a variety of other scripts. Me, for things like that, I like to use quest Scripts, because there's no real need to be checking every frame whether the Protectron has gotten out of range.

 

And I may be wrong, but I think all dialogue is attached to a quest form? So your protectron's dialogue should have a quest associated with it, yes? Which provides a convenient spot to plunk in those every few seconds tasks as opposed to the every frame tasks.

 

But, as I've said before, I'm kind of OCD about efficiency.

 

Edit: That's a lie. I'm not "kind of" OCD about efficiency. I'm completely neurotically OCD about efficiency.

Edited December 19, 2012 by Xaranth

[RBRoAB]

Have either of you scripted dialogue?

I've been working on that. I have a small concept of If and EndIf, but I'm still intimidated. I've done all dialogue so far through quests. I've created basic companions with a working companion wheel and all ranged/distance/aggression functions.

 

However, the companion I'm working on now is a little different. I've been able to create some workarounds, but when it's done, I want to be able to publish it here and have no bugs or flaws

[llamaRCA]

it could be placed in a variety of other scripts. Me, for things like that, I like to use quest Scripts, because there's no real need to be checking every frame whether the Protectron has gotten out of range.

 

And I may be wrong, but I think all dialogue is attached to a quest form? So your protectron's dialogue should have a quest associated with it, yes? Which provides a convenient spot to plunk in those every few seconds tasks as opposed to the every frame tasks.

 

But, as I've said before, I'm kind of OCD about efficiency.

 

Edit: That's a lie. I'm not "kind of" OCD about efficiency. I'm completely neurotically OCD about efficiency.

 

Object scripts run every frame? Huh, that's not what I've read before. That's perspective changing.