How to moveto an actor in front of the player?

[Nexusmodsaccountno2]

I want to moveto an actor to just in front of where the player is looking.

 

I am assuming I have to use

 

PlayerRef.Getangle z

 

And then use that value in the moveto function but I don't know how to do that...any help appreciated.

[dubiousintent]

The role of "z" axis varies by function. As such it gets tricky to understand in specific circumstances and is best left unchanged in "positioning" functions like "MoveTo" or "SetPosEx" if possible. Then use a "rotation" function (such as "SetAngle") as needed if that is what you are after.

 

Look at the "MoveTo" description again. You want the example:

BuddyRef.MoveTo Player 512 0 0

Just choose which axis you want "BuddyRef" to be offset from the "Player" and by how much. The "z" axis of "MoveTo" would (as I recall) place them vertically offset, either above or below the Player's elevation. ("Above" by a small amount would be better, so the Actor doesn't get stuck in the ground but usually is not needed unless "Player" is in rough terrain.)

 

"Facing" angle doesn't really come into it for moving.

 

-Dubious-

[madmongo]

As you guessed, use getangle z to get the angle of the player's rotation, which will be the direction the player is facing. Then decide what distance you want to place the actor from the player.

 

To get the position offset based on angle and distance, use the following formulas:

x = distance * sin (angle)

y = distance * cos (angle)

 

As Dubious said, you can either use those offsets in the moveto or add them to the player's offsets and use setpos instead.

 

Since you know the player's angle, adding 180 to that and using setangle z will rotate the actor to face the opposite direction (i.e. directly facing the player).

 

Use with caution. There is nothing stopping those functions from placing the actor inside a tree or a rock or, as Dubious noted, underneath the terrain if the terrain happens to rise suddenly, In an interior cell, the actor could be placed outside of all existing rooms, causing them to fall into the abyss (they'll usually end up somewhere on the map afterwards). Depending on what you are doing, you might be better off using a trigger and an xmarker.

[Nexusmodsaccountno2]

So my script would look like

 

PlayerRef.getangle z

 

And then uh um use

 

x = distance * sin (angle)

 

y = distance * cos (angle)

 

And add these results to

 

Summonedactorref.moveto playerref

 

But how exactly do i use these formulas?

 

Pretend you are trying to explain it to an idiot, who doesn't know what those formulas mean, at all...just for laughs...

 

It looks like this is possible though, cool.

 

Oh don't worry about the rotation 180 I actually want the moveto actor to be facing the same direction as the player.

[dubiousintent]

The same as any calculation, just as madmongo explained. But try this example after defining the variables at the beginning of your script:

int iDistance
float fOffsetX
float fOffsetY
float fPlayerFacingZ
ref Summonedactorref

set iDistance to 128 ; or some desired <integer_value> in "game units"
set fPlayerFacingZ to PlayerRef.getangle z
set fOffsetX to iDistance * sin fPlayerFacingZ
set fOffsetY to iDistance * cos fPlayerFacingZ
Summonedactorref.moveto PlayerRef  fOffsetX fOffsetY fPlayerFacingZ

Once you confirm this works for you in the way you desire I'll turn it into a 'Tip' for the "Scripting" section of the wiki "Getting started creating mods using GECK" article.

 

-Dubious-

[Nexusmodsaccountno2]

The script works, just needed a a few tweaks to get it doing what I wanted thank you, very appreciated!

 

If you want to make a wiki entry:

 

This script can move a reference to right in front of wherever the player is facing (make sure to read the moveto function wiki entry first)

 

Scriptname moveinfrontscript

 

Begin onequip ;your choice

 

int iDistance

float fOffsetX

float fOffsetY

float fPlayerFacingZ

 

set iDistance to 70 ; or some desired <integer_value> in "game units"

set fPlayerFacingZ to PlayerRef.getangle z

set fOffsetX to iDistance * sin fPlayerFacingZ

set fOffsetY to iDistance * cos fPlayerFacingZ

 

SummonedRef.moveto PlayerRef fOffsetX fOffsetY ;you can put another value here if you want the ref to appear from above and drop down or if you find the moveto ref is getting stuck inside landscape or objects

 

end

[dubiousintent]

Thanks for reporting back. I wasn't certain if you would need to encapsulate the trig function part in parens, e.g. "(sin fPlayerFacingZ)", in order to be parsed correctly though the examples in the GECKWiki don't show that. You might if they were followed by something else or used in a conditional statement.

 

Just to be clear - by your comment after:

SummonedRef.moveto PlayerRef fOffsetX fOffsetY

"another value here" would be a "fOffsetZElevation" value, correct? You tested that?

 

Note: I failed to point out that "MoveTo" only works correctly if the "SummonedRef" actor is in the same cell as the Player. (See "GetInSameCell".) If not, you need to use "Player.GetParentCell" and "MoveToCell" functions instead, but in a similar manner.

 

-Dubious-

[Nexusmodsaccountno2]

In your original example

 

Summonedactorref.moveto PlayerRef fOffsetX fOffsetY fPlayerFacingZ

 

The summondactorref appeared at various heights as it calculated the players facing angle, then entered that value as the third value in the moveto function (the z value in moveto that is moveto x y z) In my script to try and stop the summoned actor from appearing inside the landscape I used 10 as the last z value but it was working fine without any value entered.

 

As for the moveto not working if the player is in a different cell. This would make the script fail if used on the border of a cell in an outdoor area right?

 

That should not be too much of an issue as the script is being used with a weapon and the intention is to make the weapon slightly unpredictable, also I am trying my best to get the summoned actor as close as possible to the player without "bumping" them which should hopefully reduce the possibility of this occuring. Thanks for the information though as it will make testing easier.

 

Thanks again for all your help, there is no way I would have been able to do that script without it.

[dubiousintent]

Glad I could help, but the credit really goes to madmongo for providing the correct formula. Implementation in the script is very straightforward.

So, you are saying the "PlayerRef.getangle z" function is returning the "elevation"? That is important to have clarified. In that case, you should rename the "fPlayerFacingZ" variable to something like "fPlayerElevationZ" for accuracy and to avoid confusion later on.

Whether interior or exterior cells is the destination of the "MoveTo" function, the object has to be in the same cell as the calling Reference (e.g. Player), or the "MoveToCell" function has to be used. "Borders/boundaries" are like walls: on one side or the other, but never straddling.

Exterior cells belong to a world space, and are part of that world space's landscape, which is basically a grid that extends infinitely in all directions. Each exterior cell is 4096 units by 4096 units or 192 feet by 192 feet or 58.5 meters by 58.5 meters. Each vertex in an exterior cell is 128 units apart - the same height roughly, as a human biped, or about 6 feet.

All exterior cells are automatically given a grid number that represents their X,Y coordinate starting from the center of the world space at coordinate 0,0. Cells to the right of 0,0 have a positive X coordinate. Cells above 0,0 have a positive Y coordinate. ... GetInGrid is similar to GetInSameCell, but checks a grid of cells, making it useful for exteriors. Returns true (1) if the specified reference is within the grid of cells centered on the player, the size of which is specified by depth. Depth defaults to 0, a value of -1 will use the uGrids to load setting. Added by NVSE 4.6.
--GECKWiki

You may need to use "GetPos" for each axis to check for large values which are likely to indicate they are approaching a boundary. The worldspace coordinate system uses the "x-axis" to indicate "left-right" and the "y-axis" to indicate "front-behind" on the same horizontal plane; while the "z-axis" indicates "up-down/elevation" on the vertical plane relative to the center (0,0,0) grid point.

When in an interior, the exterior world is no longer visible. Each interior cell is essentially its own universe.
--GECKWiki

There is no fixed size to interior cells, so it is more difficult to determine if a destination is near a boundary. A subsequent call to "GetInSameCell" to determine if the moved object was successfully re-located may be needed.

A "relocation" of an object by "MoveTo" or "MoveToCell" can only be determined to succeed or fail while the script if running. For this reason, the incorrect use of one or the other will not prevent the script from compiling/saving. During execution (while running in the game) only that statement will fail, but subsequent statements then fail as well as a result it's failing to provide a valid statement (e.g. failing to set a variable or condition). By default this will stop that script from running again, but there is an INI configuration setting for the "JIP LN NVSE Plugin" which allows such failing scripts to continue to run instead.


-Dubious-

[Nexusmodsaccountno2]

From your post: "So, you are saying the "PlayerRef.getangle z" function is returning the "elevation"?"

 

Answer: Only in that last line of script you provided, in the rest of the script it worked as intended.

 

 

As for the rest of your explanation does that mean if the moveto script fails one time because of the player and moveto ref being in diiferent cells or "borders" that the script will fail to run ever again in vanilla non fose fallout nv?

 

If that is the case then maybe I should just use the moveto player after all with no getangle z. This would move the summoned actor to the players exact position thus preventing the error of different cells happening, right? It's a shame though as the getangle z script works so well...

Edited January 23, 2019 by Nexusmodsaccountno2