Fallout New Vegas GECK & Scripting Help 101

[Guest tomm434]

One of the ways is to use sin+GetDIstance. (Maybe A.J. will tell us her method with sin+sqrt , I'm interested in hearing)

 

We need to know C angle. For that we can use sinus. Sinus is eval to "B\A". Thus

 

1)We need to find a disparity in Z offset between character and camera.

2) We need to find X\Y disparity offset between camera and character (GetDistance)

 

Then we divide Height Diff on Distance Diff(find sin) and here's our angle!

 

Now in my cutscene player is situated above(or on the same height) the character he's looking at. That's why I substracr player height first. I believe I would need additional check for whether player or character  are higher (because when I was experimenting I had to multiply result on "-1" because camera was moving in the opposite direction clone falls.

 

 

 

It's fast, but not accurate enough, so I have a lot of manually added numbers into the script =\

Same thing. I did a cutscene and I used code like this because I didn't want heavy code (getdistance||headingangle||getangle||sin) running each frame + Havoc.

if aaaquestFFScribes.cloneStage >=1 && aaaquestFFScribes.cloneStage <5
let Pangle:=PlayerREf.GetAngle Z + PlayerRef.GetHeadingAngle cloneref
set tempor to 11889 -cloneref.getpos Z
let sinus := tempor/500
let gradus := sin sinus 1 - 3
Player.SetAngle Z Pangle
Player.SetAngle X gradus
endif

11889 goes for height.(character falls from heavy distance)

500 goes for the exemplarily distance between camera and clone.

and gradus is sin + my fix (- 3 degrees is enough for camera to be in the right place.)

 

 

 

[Guest]

sqrt because I'm calculating hypotenuse in a triangle where the catheti are GetDistance and the Z offset.

Here's the script

		let Dist := CamDestREF.GetDistance Player
		let ZDiffTemp := (CamDestREF.GetPos Z) - (Player.GetPos Z)
		let CatSumTemp := ((ZDiffTemp * ZDiffTemp) + (Dist * Dist))
		let HypTemp := sqrt CatSumTemp

		let DivTemp := Dist / HypTemp

		if (CamDestREF.GetPos Z) >= (Player.GetPos Z)
			let aCamMQ.pcXGap := (90 - (sin DivTemp 1)) / frame
		else
			let aCamMQ.pcXGap := (-90 + (sin DivTemp 1)) / frame
		endif

In the last part I divide for "frame" since mine is an interpolation movement

[Guest tomm434]

Clever.Why do you use player.getpos Z for 2 times? Is there a reason behind that? I think game engine calculates it twice in your script. Tell me if I'm wrong.

[Xilandro]

tomm434

Tried your code. And... no cigar =) Seems like it also need a lot of manual numbers)

[Guest tomm434]

tomm434

Tried your code. And... no cigar =) Seems like it also need a lot of manual numbers)

 

strange. It worked for me flawlessly without any additional figures.

 

Use A.J.'s code then. It works 100%

[Xilandro]

sqrt because I'm calculating hypotenuse in a triangle where the catheti are GetDistance and the Z offset.

Here's the script

		let Dist := CamDestREF.GetDistance Player
		let ZDiffTemp := (CamDestREF.GetPos Z) - (Player.GetPos Z)
		let CatSumTemp := ((ZDiffTemp * ZDiffTemp) + (Dist * Dist))
		let HypTemp := sqrt CatSumTemp

		let DivTemp := Dist / HypTemp

		if (CamDestREF.GetPos Z) >= (Player.GetPos Z)
			let aCamMQ.pcXGap := (90 - (sin DivTemp 1)) / frame
		else
			let aCamMQ.pcXGap := (-90 + (sin DivTemp 1)) / frame
		endif

In the last part I divide for "frame" since mine is an interpolation movement

 

So this is how it should be =)) Almost similar to arctan way, but seems like this code is a lot more accurate. Will test in a few minutes

 

UPD

 

Nope, accuracy is just the same as with arctan. But this script don't need manual numbers =)

 

here's my script

            set CameraZ to getgamesetting fovershoulderposZ
            set iDistance to Player.GetDistance rLast
            set TanCalc to 0 - (iDistance / 1000)
            set rLastPosZ to rLast.GetPos Z
            set PlayerPosZ to Player.GetPos Z
            set OffsetZ to (rLastPosZ - PlayerPosZ) - (CameraZ * 1.15)
            set AngleXcalc to 0 - (OffsetZ/iDistance)
            set ArcTan to tan AngleXcalc 1
            Player.SetAngle X ArcTan

[Guest]

It depends by what you mean for accuracy, Xil. The problem I noticed in camera movements is mainly the fact they look at Bip01, which is on feet, so there's still the need to add an offset, that could be "value / perspective". But... I still didn't think about it, it's just a feeling.

 

EDIT: I explained bad. "value" depends by how tall is the reference / 2, then this value, this offset, should be tweaked concerning the perspective

[Guest]

Clever.Why do you use player.getpos Z for 2 times? Is there a reason behind that? I think game engine calculates it twice in your script. Tell me if I'm wrong.

 

Well, I use it on top of the script to get the value and find the difference on the Z.

When I use it the second time, on the bottom, it is to give my movement a sign (+ or -). I guess it's a personal use of my heading UDF: when the camera is looking down, and the reference is higher, the movement will be +, and viceversa if the camera is looking high and the reference is lower it will be -. My UDFs tend to give a direction at the movement. Same happens for rotation, let's say camera is 270 degrees, it will rotate counter-clockwise if the reference is at 200 degrees, but it will rotate clockwise if it's at 10 degrees. How can I say, it tends to reach the focus using the shortest path.

[Xilandro]

Yep, offset is required indeed, but so far - both scripts aim right into the head, so it's fine. By the accuracy I mean OffsetZ/iDistance. The closer and higher you are - less accurate script will be and aim will be above the target. Not critical for camera mod, but for autoaim - a dead end.

I'm sure there's something cool in the trig I don't know that can fix this problem once and for all =D

[Guest]

Yep, offset is required indeed, but so far - both scripts aim right into the head, so it's fine. By the accuracy I mean OffsetZ/iDistance. The closer and higher you are - less accurate script will be and aim will be above the target. Not critical for camera mod, but for autoaim - a dead end.

I'm sure there's something cool in the trig I don't know that can fix this problem once and for all =D

 

Mmmh you know what... you use npcs as references so much or less you have the same Z, while I was referring to the offset created by how tall a reference is.

 

My guess is when you get closer 4 digits after the decimal point are not enough to calculate it nice, especially when it comes to trigonometry, you know, for the... cusp / apex / that thing...

 

EDIT: it's late. Probably tomorrow when I'll re-read I will laugh at what I wrote. For now I just need to sleep *laughs*

[Guest tomm434]

 

Clever.Why do you use player.getpos Z for 2 times? Is there a reason behind that? I think game engine calculates it twice in your script. Tell me if I'm wrong.

 

Well, I use it on top of the script to get the value and find the difference on the Z.

When I use it the second time, on the bottom, it is to give my movement a sign (+ or -). I guess it's a personal use of my heading UDF: when the camera is looking down, and the reference is higher, the movement will be +, and viceversa if the camera is looking high and the reference is lower it will be -. My UDFs tend to give a direction at the movement. Same happens for rotation, let's say camera is 270 degrees, it will rotate counter-clockwise if the reference is at 200 degrees, but it will rotate clockwise if it's at 10 degrees. How can I say, it tends to reach the focus using the shortest path.

 

 

I asked the other thing.

I mean that in your script game engine calculater Player.getpos Z twice. If you set a variable to it and then use variable in script later, do you think function would be less heavy? (only concerned by that because camera is very heavy and everything you can optimise can matter)

In case my theory about calculating player pos twice is correct, you can reduce calculating player height in twice per frame!!

        Set PlayerHeight to player.getposZ

        let Dist := CamDestREF.GetDistance Player
        let ZDiffTemp := (CamDestREF.GetPos Z) - (PlayerHeight)
        let CatSumTemp := ((ZDiffTemp * ZDiffTemp) + (Dist * Dist))
        let HypTemp := sqrt CatSumTemp

        let DivTemp := Dist / HypTemp

        if (CamDestREF.GetPos Z) >= (PlayerHeight)
            let aCamMQ.pcXGap := (90 - (sin DivTemp 1)) / frame
        else
            let aCamMQ.pcXGap := (-90 + (sin DivTemp 1)) / frame
        endif

[Xilandro]

In case my theory about calculating player pos twice is correct, you can avoid calculating player pos for 60 times a second!!

Fair, but getpos is not as heavy as you think. And less variables is good for script length =)

And you can't make bDoOnce if script is dynamic and player's Z is changing. So set PlayerHeight to Player.GetPos Z will run [fps] times per second anyway. One more - one less, it's very subtle func, so you will never notice it (like sin, tan or ref walking, for example)

set PlayerHeight to Player.GetPos Z
let ZDiffTemp := (CamDestREF.GetPos Z) - (PlayerHeight)

versus

 let ZDiffTemp := (CamDestREF.GetPos Z) - (Player.GetPos Z)

[Guest tomm434]

 

In case my theory about calculating player pos twice is correct, you can avoid calculating player pos for 60 times a second!!

Fair, but getpos is not as heavy as you think. And less variables is good for script length =)

And you can't make bDoOnce if script is dynamic and player's Z is changing. So set PlayerHeight to Player.GetPos Z will run [fps] times per second anyway. One more - one less, it's very subtle func, so you will never notice it (like sin, tan or ref walking, for example)

set PlayerHeight to Player.GetPos Z
let ZDiffTemp := (CamDestREF.GetPos Z) - (PlayerHeight)

versus

 let ZDiffTemp := (CamDestREF.GetPos Z) - (Player.GetPos Z)

 

I didn't want to make DoOnce. Variable will be set every frame. It's bad for script lenght, yes but imagine that every time in these  2 lines

        let ZDiffTemp := (CamDestREF.GetPos Z) - (PlayerHeight)
        if (CamDestREF.GetPos Z) >= (PlayerHeight)

game engine will

 

1)calculate player height

2)use player height

 

But if Player height is a variable, It will just use a figure to calculate.

[Xilandro]

This line will calculate once per frame anyway: set PlayerHeight to Player.GetPos Z

So, without var you have same thing calculating twice per frame, with var - only once per frame. I can't see the difference in performance between this two variants. I'm sure I saw somewhere a thread about script optimisation and a lot functions tests. I should try to find it and look if there's something about getpos

[Guest tomm434]

This line will calculate once per frame anyway: set PlayerHeight to Player.GetPos Z

So, without var you have same thing calculating twice per frame, with var - only once per frame. I can't see the difference in performance between this two variants. I'm sure I saw somewhere a thread about script optimisation and a lot functions tests. I should try to find it and look if there's something about getpos

 

I don't remember anything on getpos there.I remember that getDistance is heavy

let ZDiffTemp := (CamDestREF.GetPos Z) - (PlayerHeight)
if (CamDestREF.GetPos Z) >= (PlayerHeight)

X1 per frame =2 lines + extracting player pos each frame ==4 commands

        set PlayerHeight to Player.GetPos Z
        let ZDiffTemp := (CamDestREF.GetPos Z) - (PlayerHeight)
        if (CamDestREF.GetPos Z) >= (PlayerHeight)

X1 per frame - 3 lines ==3 commands

 

Now about heaviness - have no idea what will be faster - to set a variable or to check player position.  On the first thought checking for something is heavier.

 

 

And what if in line "let ZDiffTemp := (CamDestREF.GetPos Z) - (PlayerHeight)"

1)game engine calculates player height

2) game engine creates temporary variable to store the number (set tempvar to player.getpos Z)

3) game engine  does the substract with CamDestREF.GetPos Z and new temporal variable ((CamDestREF.GetPos Z) - Tempvar)

 

damn. I have no idea about programming.

[Xilandro]

Nah, I don't want to think about it, or I will end up rewriting every single script I have to save 1 FPS =D

[Halstrom]

One of the ways is to use sin+GetDIstance. (Maybe A.J. will tell us her method with sin+sqrt , I'm interested in hearing)

 

Same thing. I did a cutscene and I used code like this because I didn't want heavy code (getdistance||headingangle||getangle||sin) running each frame + Havoc.

if aaaquestFFScribes.cloneStage >=1 && aaaquestFFScribes.cloneStage <5
let Pangle:=PlayerREf.GetAngle Z + PlayerRef.GetHeadingAngle cloneref
set tempor to 11889 -cloneref.getpos Z
let sinus := tempor/500
let gradus := sin sinus 1 - 3
Player.SetAngle Z Pangle
Player.SetAngle X gradus
endif

11889 goes for height.(character falls from heavy distance)

500 goes for the exemplarily distance between camera and clone.

and gradus is sin + my fix (- 3 degrees is enough for camera to be in the right place.)

 

School didn't teach me how to do a tax return, invest money wisely, apply for a job or housing loan, how to budget, or how to break up a relationship without emotional crap, but it did teach me Pythagoras theory so I could position actors in SexMods on computer games

[nyaalich]

@Hal:  lol.  Besides the maybe 2% that's applied at work, I think that the other 98% of my CS degree is actually being made use of since starting to mod.

 

Too fucking lazy, and haven't gotten nearly enough sleep:  There's no alternative for getdistance, right?  Or if there is, it can only be worse, yes?

[Guest]

Tomm, much or less what Xilandro said.

GetDistance is heavier because... well, I think these functions act much or less like UDFs. So if I should rewrite a GetDistance I should use sqrt to find hypothenuse from the difference between my X - Y and my ref's X - Y. For the same reason, I think GetHeadingAngle is a slow function too, at least slower than a simple GetPos because it's probably some math between player GetAngle and ref's GetAngle.

I don't really think that a Get function is heavier than a Set function in this case, interrogating the engine to which position I am is different than asking the engine to do some math involving more datas, so I don't see that as a true optimization in changing that setting a variable.

 

[Halstrom]

@Hal:  lol.  Besides the maybe 2% that's applied at work, I think that the other 98% of my CS degree is actually being made use of since starting to mod.

And the dumb thing is at that age if they had told us there were practical applications for algebra in Sex Modding games we probably would have shown a great deal more interest and got much better grades

[Guest tomm434]

A.J. just checked in in Cipcis's code comparions code and yes -for 1000 frames there was no difference whatsoever.

 

But then I decied to check GetDistance code.

set playerheight to player.getdistance SunnyRef
set sol1 to playerheight - 50
set sol2 to playerheight + 50

versus

set sol1 to player.getdistance SunnyRef - 50
set sol2 to player.getdistance SunnyRef + 50

And here is the result. No difference whatsoever below 1000 executions per frame. for 10000 executinons per frame there is a big gap but there is no script that will be executing getdistance for 10000 per frame. That's strange. Can game actually store variables in 1 script or it is variable set that takes so much resources, I don't know.

 

 

 

 

 

 

And the dumb thing is at that age if they had told us there were practical applications for algebra in Sex Modding games we probably would have shown a great deal more interest and got much better grades

Haelstrom, do you think it's a good idea to motivate kids to become sex modders?

getDistanceTest.rar

[Halstrom]

 

And the dumb thing is at that age if they had told us there were practical applications for algebra in Sex Modding games we probably would have shown a great deal more interest and got much better grades

Haelstrom, do you think it's a good idea to motivate kids to become sex modders?

 

Not really, just saying it would have got better results than basically telling us Algebra was needed so we could go to uni to become teachers to teach Algebra to another batch of Math students

[Halstrom]

 

 

And the dumb thing is at that age if they had told us there were practical applications for algebra in Sex Modding games we probably would have shown a great deal more interest and got much better grades

Haelstrom, do you think it's a good idea to motivate kids to become sex modders?

 

Not really, just saying it would have got better results than basically telling us Algebra was needed so we could go to uni to become teachers to teach Algebra to another batch of Math students

 

Heck, I only found parabola interesting when I worked out it was a good way to calculate shell position in the computer game artillery on the Apple 2e & C64.

[Guest tomm434]

Not really, just saying it would have got better results than basically telling us Algebra was needed so we could go to uni to become teachers to teach Algebra to another batch of Math students

Agreed. I rememebr that in tenth grade everyone said that algebra and geometry are useless in programming. Kids need a better-motivated education.

[Guest]

A.J. just checked in in Cipcis's code comparions code and yes -for 1000 frames there was no difference whatsoever.

 

But then I decied to check GetDistance code.

set playerheight to player.getdistance SunnyRef
set sol1 to playerheight - 50
set sol2 to playerheight + 50

versus

set sol1 to player.getdistance SunnyRef - 50
set sol2 to player.getdistance SunnyRef + 50

And here is the result. No difference whatsoever below 1000 executions per frame. for 10000 executinons per frame there is a big gap but there is no script that will be executing getdistance for 10000 per frame. That's strange. Can game actually store variables in 1 script or it is variable set that takes so much resources, I don't know.

 

I see a very big difference in the two scripts, concerning what I stated before.

 

But then I thought a bit more about it, and maybe it makes sense. Maybe it's not true that GetDistance is slow, you know? Oh well, one GetDistance is slow, but N GetDistance in the same frame could be just executed a single time. Jaam would be someone who could explain this in a deeper and more correct way, I just base that by feeling.

 

Generally, my feeling is that every function is slow if it's the result of "not basic operations". Let me make an example, see if I can explain... The engine knows exactly the ref's position, since it uses them everytime for everything, so they are stored somewhere and if I interrogate with a GetPos it shouldn't be a big effort, same for GetAngle, it only gives me back the current value.

 

But now I think, the engine knows the distance between references too, because it uses it for aggro radius, so it should be still a data which is avaiable every time for the script, something low level and not something like "let me do some math involving sin and positions to find distance".

I think it is something the engine already does, but it doesn't do it continuously but only every N operations. Because, well, the aggro answer of an enemy could even be at 0.1 for example, would you notice it? would you notice the dot becoming red if it's at 0.01 or 0.1? I guess not. Now I think that calling a GetDistance could force the engine to re-evaluate that data, because of its timing. So, re-doing that will slow the operations. But since in the second script you call it twice in the same frame, the engine could be smart enough to do it only once since the value won't change when it will be executed the second time in a row. I... don't know if I explained well my feeling...

 

Last thing, I would be careful with big numbers. I mean, big numbers on tests are ok, but "too much big" numbers I'm not sure they can give you a correct value. If you break some kind of "limit", the result would be completely unexpected. In a perfect environment, doing a test 100 times would take 1/10 of the time in doing it 1000 times. But the game itself is not a perfect environment. These tests give different values concerning different environments, like being indoor / outdoor, having npcs around or not, etc. more elements present in the scene and interacting with it should change that. It's something Cipscis didn't specify: while I use that thread as reference for optimization I'm not sure if he took care of these things. Generally, I think tests like these should be made on an empty test cell with nothing else than 4 walls, no npcs, and no installed mods at all, especially with GameMode scripts.