http://www.youtube.com/watch?v=lV3RcSEyEPQ

I am making a mod and messing with something, and well, I think someone with a math degree would get it done quicker and better than I am. Maybe this is your thing so, if it is, I'm putting it out here...


So the player is standing there. He can rotate on his Z axis in 360 degrees (looking around from left to right), or he can pivot up and down to an extent, which is his X axis. When he is not pivotting up or down, just looking straight ahead, his X axis is zero. When he looks up, the X axis decreases. When he looks down, the X axis increases. The maximum that he can pivot on that X axis is around -90 and +90.

So, there is a long-ass light beam whose base is attached to his face by my pre-exsting script function. As he runs around, it stays on his face. The code that makes the light beam's base stay in front of the player's face is already done. Not a big deal.

This light beam is a particular pain in the ass because it does not appear in the world on exactly the player's same axis. It appears slanted at, I guess, 45 degrees both up and down, and sideways, from the player. When you query the light beam's X and Y axes, it will tell you 0 and 0, but when in that position it does not match up to the player when he's in a 0 and 0 set of angles.

My goal is to make the light beam stick out of the player's face, straight ahead of him, no matter which way he spins or looks. Like: a spotlight.

I found a way to do exactly HALF of the job. I have made the light beam pivot perfectly from side to side, like a big fat headlight on a car, when the player pivots on his Z axis, but it's got a catch. I have to lock the light beam's X angle at 90. and I am only changing the Y one. So, my intended spotlight is more of a ... headlight... like that, because the player can look up and down but the light will always be locked straight ahead of him.

The code which created the perfect pivot behavior of this light, while keeping it sticking straight out from his face and not up or down, is this:

		if PlayerAngleZ == 180 			set LightY to 0		elseif PlayerAngleZ == 0			set LightY to 180		elseif PlayerAngleZ < 180			set LightY to 180 - PlayerAngleZ		else			set LightY to 360 - (PlayerAngleZ - 180)		endif 		PhalanxSpotlightBeamREF.setangle y LightY		PhalanxSpotlightBeamREF.setangle x 90

Trying to use the above code in a way which also adjusts the X axis of the light beam to change with the player's X is kinda rough.

I have found that its necessary to change both the X and Y coordinates in a smooth sorta way to get the perfect thing I want.

I divided the player's Z axis into 4 quadrants, and then, I observed just what the light beam had to do to be correct throughout those quadrants. I took notes with the player's Z at 0, 90. 180, and 270. Those notes went like this:

With the player's Z angle at zero:with his X angle set to 0, he is facing straight. The correct X angle for the beam is 90, and its Y angle is 180.with his X angle set to -45, he is pointing up. The correct X angle for the beam is 45 and the Y angle is still 180with his X angle set to 45 he is pointing down. The correct X angle for the beam is -45, and the Y angle is 0.With the player's Z at 90:with his X set to 0, he is facing forward, the beam's X is 0, Y is 90With his X set to -45 (pointing up), the beam's X is 0, Y is 135.With his X set to 45 (pointing down), the beam's X is 0, Y is 45.With the player's Z at 180With his X set to 0, he is facing forward, the beam's X is 90, Y is 0.With his X set to -45 (pointing up), the X is 135, the Y is 0.With his X set to 45 (pointing down), the X is 45, the y is 0with the player's Z at 270:With the player's X at 0, he is facing forward, the beam's x is 0, y is 270.With the player's X at -45 (facing up), X is 0, Y is 225With the player's X at 45 (facing down), X is 0, Y is 315

That pretty much lays out a roadmap for what I need to do in my code. BUT, anything I do with this is going to be explicitly coded for each of the 4 quadrants of the player's Z, and within each one of those, I'd be using arithmatic for the beam's two possible X pivot directions. Because... I svck at arithmatic less than I svck at trigonometry and this looks like trigonometry to me.

So! If anyone with better math/trigonometry background than me would be interested in coming up with some class-act code that does this... it would be stupendous! I have spent some time on doing it the arithmatic-sort-of-way and, well, its DOABLE but I mean... its kinda goofy. I bet there are trigonometry functions that can do this, and the right person can put the code out there for it.

The final thing that this will be is a high-powered spotlight. It is going to be a very good spotlight. It uses the mesmetron weapon as its handheld object and will look natural and correct when its done. I'll probably release it as stand-alone but also Phalanx needs it. If someone came up with the part of the code that deals with this lovely math issue, I'd be happy to put them in the mod credits with me.

Well people say math is my strong point, so let me give this a go. I think one of your main issues is you are rotating it incorrectly, causing you to have to use both the X and Y axis to tip it up and down. If you look at some objects in the geck you will find that to tip them perfectly on their side (90 degrees) and then rotate them around on their side, you must mess around with which two axes to use in combination to get it so you only have to use two. It will be easier with your light beam as there is no top side or front or back. (like with a cabinet or endtable) So go in geck and mess with your light beam (is it custom, or if not which one is it?) until you figure out which two axis to use together so that only those two are necissary. What you might find is you must use the Y axis of the beam with the Z axis of the player, and the Z of the beam with the X of the player or something. Then simply check the players Z rotation every frame, and set the beam to that according (on whatever axis you figured out matches in my last step) adding a multiple of 90 degrees if necissary to correct it. (like if its always sticking out of the side of their head) Then simply to the same with the X of the player. I can help you more when I get home, (I'm at school right now) with exactly what axis correspond to what axis. I can probably even make a script for you to do exactly what your looking for. But possibly, provided I have described it well enough, you can get it. Let me know if you need a better description of what I mean. I will be available for 45 minutes, then its off to other classes. So hopefully you can see this by then if you need more help right now, otherwise I'll help after school.

Sounds to me like the 0 and 0 that's being reported as the beams axes is the actual 0 and 0 rotation of the base BSFadeNode in the beam nif, not that of the visible NiTriStrip beam itself. Could this be solved by opening the beam nif and rotating the NiTriStrips those 45 some degrees to offset it from the base nodes rotation, and bring it back into alignment with the player rotation numbers? I think I'd back up the nif and try this before smoking the brain with trying to code it.

It sounds like what you say. When you place the object into the world it is already rotated. Like if the player is standing next to the unrotated light beam, it looks like this from the front:

I originally said it was rotated 45 degrees, that was wrong, it's 90. I'm also not certain that the observations I made while checking each quadrant are 100% correct btw, I was trying to eyeball it. But the objects look like this ...

   O                   |                 / | \                 |                  |                   |            /\                   | player               beam 

The light beam does have two ends. It seems like it is made of like, 3 lines or so, and those 3 lines intersect and cross near the end that has a bunch of glare. When you pivot the beam it pivots from that crossy-line-spot, and that's the end which belongs close to the light source/player. I cannot draw it in ascii but if you look at FXLightBeamBrt06 in the GECK and rotate it along the Z or X axis you'll see what I mean.



Yes that sounds exactly like what is making the numbers be different between the beam and the player's orientation.

If I could set the player's Z to 0 and his X to 0, and have the beam be set the same, and while at those axis rotations the beam is perfectly angled and facing away from the player from the front, no math would be necessary.

I couldn't tell you how to rotate the actual object in a nif editor or whatever. I was attempting to use it as it was I guess and not need to distribute a custom mesh or anything with the mod.

The actual light beam object does not exist in the game as a moveable static. I created a moveable static by picking the one moveable light beam in the game, which was "LightBeamsFog", and making my own copy of it, and then opening up FO3edit and editing the path that was there, putting in "Effects\Ambient\FXLightBeamBrt06.NIF" taken from the static named "FXLightBeamBrt06", instead of its original "Effects\LightBeamsFog.NIF". Given the choice I'd want to rotate the object in the script instead of shipping one that has been turned kinda.

;------------------------------------------

My script itself looks like ass right now. it is totally temporary - it will live on the light beam itself, not the equipped object, when I'm through. But if you wanted to really look at it I think you'd need to see it, so here's what it looks like with my Not-X-Inclusive rotation code included.

scn PhalanxSpotlightSCRIPTfloat fAngleXfloat fAngleZfloat fAnglefloat fRelativePosfloat fdistancefloat fposxfloat fposyfloat fplayerheightshort iplayerheightfloat newxfloat newyfloat newzfloat oldxfloat oldyfloat oldzfloat oldanglexfloat oldanglezfloat newanglexfloat newanglezfloat tempfloatfloat firstyshort sneakingbegin gamemodeset newx to player.getpos xset newy to player.getpos yset newz to player.getpos zset newanglex to player.getangle xset newanglez to player.getangle z; Has the player moved, crouched, or changed angle since we last checked?if oldx != newx || oldy != newy || oldz != newz || (Player.IsSneaking && sneaking == 0) || (Player.IsSneaking == 0 && sneaking == 1) || newanglex != oldanglex || newanglez != oldanglez; If so, store the coordinates for later comparison	set oldz to newz	set oldy to newy	set oldx to newx; Adjust the sneaking height of the light if necessary	if Player.IsSneaking		set sneaking to 1		set iPlayerHeight to 18	else		set sneaking to 0		set iPlayerHeight to 58	endif; Move the beam to the right spot in front of the player's face (based on GECK useful scripts code + Pelinor messed with it)	set fAngleX to Player.GetAngle X	set fAngleX to abs fAngleX	set fAngleZ to Player.GetAngle Z * -1 + 90	set fDistance to iPlayerHeight * cos fAngleX / sin fAngleX	if fDistance > 64		set fDistance to 64	endif	set fAngleX to Player.GetAngle X * -1	set fPosX to fDistance * cos fAngleX * cos fAngleZ	set fPosY to fDistance * cos fAngleX * sin fAngleZ	set fPlayerHeight to iPlayerHeight	PhalanxSpotlightBeamREF.MoveTo Player fPosX fPosY fPlayerHeight; If the angle changed, reset the angle of the beam left-right	if newanglex != oldanglex || newanglez != oldanglez		if oldanglez == 180			set firsty to 0		elseif oldanglez == 0			set firsty to 180		elseif oldanglez < 180			set firsty to 180 - oldanglez		else			set firsty to 360 - (oldanglez - 180)		endif		PhalanxSpotlightBeamREF.setangle y firsty; Store the angles for later comparison		set oldanglez to newanglez		set oldanglex to newanglex	endif; Force the X axis of the light to angle 90	PhalanxSpotlightBeamREF.setangle X 90endifendbegin onequip playerPhalanxSpotlightBeamREF.enablePhalanxSpotlightBeamREF.moveto playerendbegin onunequip playerPhalanxSpotlightBeamREF.disableendbegin ondropPhalanxSpotlightBeamREF.disableend

Here is a short, low-quality video showing the fact that the thing does actually work as scripted above...

http://www.youtube.com/watch?v=lV3RcSEyEPQ

Just no pitch to the beam.

This isnt what itll look like in final! It's only the FX beam portion, not the real light source. What that spotlight does to the area in terms of visibility is not yet there, but I know what I'm set to do.

Oh I see what you mean. D: I figured that you could simply move the X and Y around and it would work, but it does rotate it all weird, preventing that from working very well. I don't see how you could script it to compensate for the weirdness, especially considering it only tips up or down to about 50* maximum, so looking straight up or down would result in the beam not going up or down enough. I tried with several objects, so its just the way things rotate. Its relative to eachother so it messes it up. I even tried rotate it, pretending it was already at 90* (something you would change in nifskope or something) with a chair, but it still was messed up. I don't really think you could do it unless you found some rediculously crazy script to fix that, but I don't think trig can help you here. Sorry :shrug:

About the video, is there a reason its turning is delayed to the player, or is that unavoidable? (Light moves slower in the Fallout universe? )

If you tried it with a chair or something, yep I think you are seeing what I mean.

Lag in the video: its 2 things.

- My crappy framerate as I pivot rapidly while zoomed out so far

- The script notices in the next frame, after the player moves, that the player's position has changed and the beam needs to have its position/angle updated. So, there's a 1 frame latency. If the .exe were doing this instead of a script, it could move the light in the same frame but in a script I did not want to try doing a constant, never-stopping update on the beam relative to the player's position. I'm not even sure doing that would eliminate it but I did not try at least not as of yet.

I might try it but I don't like running stuff involving math and all in an every-frame-no-matter-what setup. It makes the game work harder than it should, kinda.

I feel certain that it is possible to script the right math into that beam to make it pitch properly. When I do not lock the X at 90, the light still turns, but its sorta turning in a circle around me up-and-down, in addition to doing what is basically-correct left-and-right. It may even be easy to do with the right trigonometry understanding. Or, it may be easy to do, period, and I'm having a brain fart.

If it can be done, it would not be very simple. And doing a check of the math every frame would not be too bad for the CPU, especially if you clean up your script, and finalize it once you have it all figured out, it not tax the game engine too badly at all.

Edit: Oops, nevermind (was asking for the model of the light beam )

In using a custom beam nif, there's a way to attach and include a NiPointLight, configure everything about it, and have it be a permanent part of the beam mesh... no messing around, one could just attach the single object as a fake headwear->mouth object and you wouldn't have to do any of this. The sad part is I haven't figured out how to setup the light part of it yet.

That video looks pretty cool! While HugePinball was developing his item placement mod, http://www.fallout3nexus.com/downloads/file.php?id=11532, he did quite a lot of work with rotating objects, and I talked with him about it for a while as well. If I remember correctly (I do - I've verified it while writing this post), objects rotate about the global X axis and use local X and Y axes, whereas the player uses the global Z axis and a local X axis, while ignoring the Y axis.

What this means is that when you rotate an object around the X axis, the Y and Z axes of rotation change, just like how rotating the player around the Z axis changes how rotation around the X axis will affect them. Because of this, rotating an object about the same Z axis as the player is only possible when its local Z axis coincides with the global Z axis, which requires its X angle to be 0. A really great way to have a look at this for yourself is to rotate an object in HugePinball's Feng Shui with the rotation rings visible.

In order to equate the player's facing with the direction of the beam, I'm going to represent each of these directions as a unit vector in the global coordinate system, in terms of their local rotational coordinates, then equate each element of the vectors to come up with an expression of the object's rotation in terms of the player's rotation.

Holding the player's rotation about their local X axis at 0, here is their facing at various rotations about the Z axis:

Z = 0:[ 0  1  0]Z = 90:[ 1  0  0]Z = 180:[ 0 -1  0]Z = 270:[-1  0  0]

From this, we can deduce that, while holding rotation about the X axis at 0, the player's facing can be described as:

[sin(Z)cos(Z) 0]

Now, holding rotation about the Z axis at 0, here is the player's facing at various rotations about the X axis (keep in mind that http://geck.gamesas.com/index.php/SetAngle can force the player's X angle past normal limits:

X = 0:[ 0  1  0]X = 90:[ 0  0 -1]X = 180:[ 0 -1  0]X = 270:[ 0  0  1]

So, when the player's Z rotation is 0, their facing can be described as:

[0cos(X)-sin(X)]

Now, let's think about when the player's X angle is either 90 or 270 (-90) - rotation about the Z axis shouldn't change their facing, right? So both the X and Y components of the vector must be independent of Z when X = 0. Let's try this:

[sin(Z)*cos(X)cos(Z)*cos(X)-sin(X)]

Ok, now let's set up a simple thought experiment with the hypothesis that this vector accurately represents the player's direction in global coordinates. Let's rotate the player 45 degress about the global Z axis, then a further 45 degrees about the local X axis. According to the hypothesis, we should expect them to display a facing of about:

[0.5 0.5-0.7]

Because we first rotated the player 45 degrees about the global Z axis, their direction vector will be 45 degrees from the X and Y axes on the XY plane, so the first two numbers in our direction vector should be the same - this is correct. After that, we rotated the player 45 degrees about their local X axis, which would change the Z component of their vector relative to the other two components. Finding the exact numbers, however, is not the easiest task without some calculation involved. However, our visualisation isn't powerless just yet.

Because the first two components of the vector have the same magnitude, we can reduce this example to a 2D system by looking at our vector from the direction of the X axis such that it appears projected along the YZ plane. But first, let's look at another projection for a moment - a projection onto the local YZ plane. During the second rotation, the vector's length would appear to stay the same, with both the horizontal and vertical components changing in such a way that magnitude is conserved. However, in our global system, the horizontal component is made up equally of X and Y components, and we're observing only one of these components in our global YZ projection.

The vector in local coordinates would appear to change like this during the second rotation:

[1  -> [0.7 0]    -0.7

If we transform the horizontal component into global coordinates, such that it consists of two components of equal magnitude, it will be transformed like this:

[0.7 -> [0.5 0.7]    0.5]

So, in conclusion, the result of our thought experiment exactly fits our hypothesis that the player's direction can be represented as:

[sin(Z)*cos(X)cos(Z)*cos(X)-sin(X)]

Ok, now we need to do the same thing for our object which rotates about a global X axis and local Y and Z axes. The important thing to realise here is that, although the object does have a local Z axis that it can rotate around, it is always directed along this axis so rotation about Z will never affect its direction. Because of this, we need only contemplate rotation about X and Y axes. Let's have a look first at rotation about Y, holding X constant at 0:

Y = 0:[ 0  0 -1]Y = 90:[ 1  0  0]Y = 180:[ 0  0  1]Y = 270:[-1  0  0]

It looks like, while X is held constant at 0, the object's direction can be represented by:

[sin(Y)0-cos(Y)

Next up, let's try holding Y constant at 0 and rotating about X:

X = 0:[ 0  0 -1]X = 90:[ 0 -1  0]X = 180:[ 0  0  1]X = 270:[ 0  1  0]

So, while holding Y constant at 0, the direction can be expressed as:

[0-sin(X)-cos(X)]

Now, let's try rotating through Y again, but this time holding X constant at 90:

Y = 0:[ 0 -1  0]Y = 90:[ 1  0  0]Y = 180:[ 0  1  0]Y = 270:[-1  0  0]

This implies that, while X is held at 90, the direction can be expressed as:

[sin(Y)-cos(Y)0]

Compare this vector with the result of holding X at 0:

[sin(Y)0-cos(Y)

As you can see, the first component is still dependent only on Y, but the other two components are not. This implies that we can combine the two vectors like this:

[sin(Y)-cos(Y)*sin(X)-cos(Y)*cos(X)]

Let's put it to the test - what if we rotate the object by 45 degrees about X, then a further 45 degrees about Y? We'd expect to see this as a result:

[0.7-0.5-0.5]

Using a similar thought experiment to last time (which I won't go through again unless someone really wants me to), we can show that this is correct.

So, now we have an expression for each direction, in terms of rotation about local axes. All we need to do now is equate the two, and find out how to express the object's rotation about its axes in terms of the player's rotation about their axes. Note that although we appear to have an overconstrained system - 3 equations with only 2 unknowns - once you work it out the problem is not overconstrained. For the sake of symplicity I'll ignore the 3rd equation, although if you'd like to verify that the system is not overconstrained you could plug in some numbers and see that it all works out:

sin(Zp)*cos(Xp) = sin(Yb)cos(Zp)*cos(Xp) = -cos(Yb)*sin(Xb)-sin(Xp) = -cos(Yb)*cos(Xb)=> Yb = arcsin(sin(Zp)*cos(Xp))=> Xb = arcsin(-cos(Zp)*cos(Xp)/cos(Yb)Xp, Zp are X and Z rotations of the playerXb, Yb are X and Y rotations of the beam

The arcsine function is available via the second parameter of http://geck.gamesas.com/index.php/Sin in Fallout 3 scripting, so something like this should do it:

float fPlayerAXfloat fPlayerAZfloat fBeamAXfloat fBeamAY...set fPlayerAX to player.GetAngle Xset fPlayerAZ to player.GetAngle Zset fBeamAY to sin fPlayerAZ * cos fPlayerAXset fBeamAY to sin fBeamAY 1set fBeamAX to -cos fPlayerAZ * cos fPlayerAX / cos fBeamAYset fBeamAX to sin fBeamAX 1beam.SetAngle X fBeamAXbeam.SetAngle Y fBeamAY

Phew, finally there. Let me know how it goes!

Cipscis

EDIT:

I recommend updating the beam's rotation every frame. Mathematical functions tend to be quite fast, so you shouldn't encounter any problems by calling them multiple times per frame.

Cipscis

I read your post and I was like, oh my god? .... ???

So then I found the code-like part and was like... whew. I'm glad that's there. The explanation was cool but, I would not have been able to code that math up myself...

So. I plugged your code into my script (with some syntax changes, looks like you been coding perl or somethin).

It was perfect for when the player is pivotting left to right and when he faces the beam downward. When he pitches upward, the beam sorta points back down instead of pointing up.

fascinating... Do you think you can see what's making the beam go down when the player points up? remember that the player is at X of 0 when facing forward and when facing up the number goes negative.

So anyway.. .here's the script with your code in it ...

PS: anyone know how can I detect by script if the player is "zooming" with the weapon's sight, if you know what I mean?

scn PhalanxSpotlightSCRIPTfloat fAngleXfloat fAngleZfloat fAnglefloat fRelativePosfloat fdistancefloat fposxfloat fposyfloat fplayerheightshort iplayerheightfloat newxfloat newyfloat newzfloat oldxfloat oldyfloat oldzfloat oldanglexfloat oldanglezfloat newanglexfloat newanglezfloat tempfloatfloat firstyshort sneakingfloat fPlayerAXfloat fPlayerAZfloat fBeamAXfloat fBeamAYbegin gamemodeset newx to player.getpos xset newy to player.getpos yset newz to player.getpos zset newanglex to player.getangle xset newanglez to player.getangle z; Has the player moved, crouched, or changed angle since we last checked?if oldx != newx || oldy != newy || oldz != newz || (Player.IsSneaking && sneaking == 0) || (Player.IsSneaking == 0 && sneaking == 1) || newanglex != oldanglex || newanglez != oldanglez; If so, store the coordinates for later comparison	set oldz to newz	set oldy to newy	set oldx to newx; Adjust the sneaking height of the light if necessary	if Player.IsSneaking		set sneaking to 1		set iPlayerHeight to 18	else		set sneaking to 0		set iPlayerHeight to 58	endif; Move the beam to the right spot in front of the player's face (based on GECK useful scripts code + Pelinor messed with it)	set fAngleX to Player.GetAngle X	set fAngleX to abs fAngleX	set fAngleZ to Player.GetAngle Z * -1 + 90	set fDistance to iPlayerHeight * cos fAngleX / sin fAngleX	if fDistance > 64		set fDistance to 64	endif	set fAngleX to Player.GetAngle X * -1	set fPosX to fDistance * cos fAngleX * cos fAngleZ	set fPosY to fDistance * cos fAngleX * sin fAngleZ	set fPlayerHeight to iPlayerHeight	PhalanxSpotlightBeamREF.MoveTo Player fPosX fPosY fPlayerHeight; If the angle changed, reset the angle of the beam left-right	if newanglex != oldanglex || newanglez != oldanglez; Cipscis math god code here		set fPlayerAX to player.GetAngle X		set fPlayerAZ to player.GetAngle Z		set fBeamAY to sin fPlayerAZ * cos fPlayerAX		set fBeamAY to sin fBeamAY 1		set fBeamAX to -cos fPlayerAZ * cos fPlayerAX / cos fBeamAY		set fBeamAX to sin fBeamAX 1		PhalanxSpotlightBeamREF.SetAngle X fBeamAX		PhalanxSpotlightBeamREF.SetAngle Y fBeamAY;		if oldanglez == 180;			set firsty to 0;		elseif oldanglez == 0;			set firsty to 180;		elseif oldanglez < 180;			set firsty to 180 - oldanglez;		else;			set firsty to 360 - (oldanglez - 180);		endif;		PhalanxSpotlightBeamREF.setangle y firsty; Store the angles for later comparison		set oldanglez to newanglez		set oldanglex to newanglex	endif; Force the X axis of the light to angle 90;	PhalanxSpotlightBeamREF.setangle X 90endifendbegin onequip playerPhalanxSpotlightBeamREF.enablePhalanxSpotlightBeamREF.moveto playerendbegin onunequip playerPhalanxSpotlightBeamREF.disableendbegin ondropPhalanxSpotlightBeamREF.disableend

Oh no, so it is... I'll have a look into it, but I don't have time at the moment to go too in depth. Hopefully someone else will notice my mistake, but if not I'll have another look later tonight.

If I try using the other equation, a similar problem occurs except with the object's rotation about the global Z axis. I've probably just made a typo somewhere - made something negative that should be positive or vice versa.

Cipscis

Well,

The fact that it works perfectly in the looking-down direction, and then just sorta duplicates the looking-down while you're looking up ..that sounds totally fixeable. That's 99% there, just something is off in the up direction. Like it doesn't like the negative numbers coming from the player's X at that point.

I was about to code all of this by hand using arithmatic for all 4 quadrants and each of the 2 sub-quadrants for those 4. Seeing how short and straight the properly-done one is going to be is like... YEAHHHHHHHH!!!!!!

hehe

Cipscis if you want, grab this:

http://www.finhosting.fi/~fallout/downloads/development/Cipscis-Spotlight.zip

Its got a savegame and a .esp in there. Ignore the navmesh warnings if you load it in the GECK eh ... Also the save has FOOK in it but it loads fine if you are only having Fallout 3.esm in the load order instead.

The player is standing on top of a pillar so, as long as you don't jump your dude down, you get a good vantage point of what the light beam is doing.

Its impossible to actually see the light beam with it in this configuration unless you pivot the camera around yourself. I do this by holding my numlock key while in third person view and turning my mouse. So, I turn the player, make him look up/down/whatever, and then hold numlock and turn the mouse to actually see which way the beam is pointed/facing.

I have found that if I use "setangle" on the player from the console, it tends to script halt the script, and its not because the script is doing anything illegal. Think of that as an .exe caviat.

The final form of this thing won't have the beam pretty much impossible to see, but it just is now because of the way it is positioned.

Cipscis I got it working in the up direction!!!!!!

.... and its a total hack. haha!

TOTAL hack.

I'll use the code just this way, if its what you want... !!!!

Here's your code, with my fix hack ...

set fPlayerAX to player.GetAngle Xset fPlayerAZ to player.GetAngle Z; if fPlayerAX < 0    set fPlayerAZ to FPlayerAZ + 180endif ; set fBeamAY to sin fPlayerAZ * cos fPlayerAXset fBeamAY to sin fBeamAY 1set fBeamAX to -cos fPlayerAZ * cos fPlayerAX / cos fBeamAYset fBeamAX to sin fBeamAX 1; if fPlayerAX < 0    set fBeamAY to FBeamAY + 180 endif ; PhalanxSpotlightBeamREF.SetAngle X fBeamAXPhalanxSpotlightBeamREF.SetAngle Y fBeamAY

Rats, I was hoping somebody would get this guy's suggestion to work (though even they did, it wouldn't work for your application). The models associated with clothes and gear are rendered separately from everything else - they have their own field of view setting and won't clip through gameworld objects, so a light attached to one wouldn't illuminate anything. They also won't render in 1st person, unless they're attached to an arm or hand node (that was the part I was hoping someone had solved.) I've been trying to make a 3D laser sight that moves with the player's vision the same way that your light does. The trouble is, to work as a http://www.fallout3nexus.com/imageshare/images/1250436-1273352762.jpg, the accuracy of the method you're using isn't good enough, and the lag is too noticeable.

There's a mod called "Directional Pipboy Light" that does much the same thing, and I think uses your same angle fix, though I don't think it uses that fog light effect, which will look cool. Wish I'd seen this thread earlier, I could have saved you some time.

Perhaps this has already been done?
How is what you are attempting different to Pelinor's directional light?
http://www.fallout3nexus.com/downloads/file.php?id=9084

===============Requirements:===============Fallout Script Extender, found at http://fose.silverlock.org/

So yes it's going to be different.

But Pelinor is a guru at this thing, he helped me with some directional object movement stuff Phalanx needed.

Hello, I've been looking at the work you guys have been doing intently. I am working a another math-related problem and was very impressed with the work you have laid out to accomplish your directional light, so Kudos to you. I don't mean to thread steal, but I have a similar math related problem, one revolving around the use of cos and sin, which I see you are using extensively. The GECK states that these higher math function are very slow, but your work proves otherwise which is good news to me. My problem is that I am tryin gto rotate a object around a center point in a circle with a radius of 96 units. The formula I'm using is

set NewX to ((cos AngleZ) * 96 + OriginX)set NewY to ((sin AngleZ) * 96 + OriginY)setPos, x NewXsetPos, y NewY

Unfortunately, not only does nothing happen, but it makes the activator lock up. It is a unique CGtarget that spins around. The code for the spinning when shot is completely valid, as it works when the rest of the code is not there. Everything else about the game and other runnign scripts and functions are fine, including over a dozen different "running and jumping" targets. I've tried the "cos script" with only a single activator present, and with multiple, and also, varying the execution rate from every frame to 20 fps to 1fps, and still it makes no difference. I'm at a comlete loss as to why it is freezing up, so I thought I'd bring it to the math script experts here.

Thank you for taking a look.

Animation > Math for all objects where it can be used -> its several times faster for processing and in your case will not cause people with slower comps to implode from constant overusing of Advanced Trig for 20 odd objects at once.

The problem is that there isn't animations for this, and I don't know how to make them. I've considered using predetermined locational values, easily acquired using excel, but if I remember right there is a limit on how many if statements you can have in a script. 100ish predetermined location values many still be faster than calling cos and sin, on 16+ object's and 2+ rotating objects.
Does anyone know what the limit on if statements is? I'm willing to "handwrite" the locations out if necessary, if it will work.

When an object is rotated with setangle, it's rotated around the origin specified in Nifscope. So if you're trying to rotate something around an axis that's offset from its visual center, you can either do trig like you're attempting, or open up the object in nifscope and move its origin (or move its model away from the origin, actually.) Then you just rotate, no trig needed, and its easier on the processor. If you want it to rotate about several different radii, though, you'll need to create multiple versions of the model.

you might want to check out Artorp's http://www.fallout3nexus.com/downloads/file.php?id=9700.

I'm not normally one to discard maths but have you tried setting the beam up as a projectile (e.g. a laser), and flagging it as embedded and using the node Camera01 or Head or something? If it works...
E: Yeah, Bip01 Head works in 1st/3rd.