Pitching Camera Script

[chris330]

Ok was going to post this in the scripting section, but I thought maybe not because that is for discussion not finished scripts, also it is not really an addon? Anyway I made this last summer and it never got released as I did some bug testing on it and fixed it but when I tried to re-submit it to OFPEC the site had gone down.

Placebo opened my eyes to the fact that you can get free webhosting so I searched for some and found some, which means I can now offer this to the community. It is a script which attaches a camera to a game logic unit which is set an offset distance from the side of a helicopter. As the helicopter pitches so does the camera making it look like it is permanently fixed to the side of the helicopter. The offset values are editable from the radio trigger in the editor. Avoid zero values because OFP doesn't like zero values passed into the camsetrelpos command for game logics or invisible H's for that matter.

Here it is anyway.

Pitching Camera Script

Please let me know if the link doesn't work, or if this is posted in an inappropriate section (I would imagine if that were the case it will be moved anyway).

Hope you like it ***

**Edit, it uses Dschulle's GetBankPitch utility to get the helicopter's pitch. This utility was not made by me, it was made by Dschulle.

[Blanco]

Link works, don't worry
I remember that script and I'm glad you fixed it.

To fix the zero issue just put 0.1 or so instead of zero

GJ

[chris330]

Link works, don't worry ***
I remember that script and I'm glad you fixed it.

To fix the zero issue just put 0.1 or so instead of zero

GJ

You're the last person I expected to reply in this thread I investigated everything and discovered the reason behind the zero value problem which I've explained above. I also haven't had any probs with the x offset being either negative or positive, it just switches the side of the aircraft being looked at. If you make the y offset positive it looks from the front back which can't be altered plus I don't want to change it because it gives the user more scope as to what they can do with it. It should also now work in multiplayer but this has yet to be tested.

[Placebo]

It's a script so it belong in mission editing & scripting. General is purely for vanilla Flashpoint, no editing, no MP, no addons, just straight out of the box.

[chris330]

Well just thought I'd let you know I have managed to quite heavily modify Dschulle's GetBankPitch utility so it no longer has to rely on inaccurate values caused by acquiring values for height above sea level using the distance command. I am getting super smooth results with it when used with my camera script. Here's what the new function that I have changed looks like:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">private &#91;&#34;_xdistance&#34;,&#34;_ydistance&#34;,&#3 4;_adjacent&#34;,&#34;_cdajacent1&#34;,&#34;_cdhei ghtasl1&#34;,&#34;_cdajacent2&#34;,&#34;_cdheighta sl2&#34;,&#34;_angle&#34;,&#34;_tiltdirection&#34; &#93;;
_xdistance = &#40;&#40;_this select 0&#41; select 0&#41; - &#40;&#40;_this select 1&#41; select 0&#41;;
_ydistance = &#40;&#40;_this select 0&#41; select 1&#41; - &#40;&#40;_this select 1&#41; select 1&#41;;
_adjacent = sqrt &#40;&#40;_xdistance^2&#41;+&#40;_ydistance^2&#41; &#41;;

referencesl setpos &#91;0,0,0&#93;;
referenceslobj setpos &#40;_this select 0&#41;;
_cdajacent1 = sqrt &#40;&#40;&#40;&#40;_this select 0&#41; select 0&#41;^2&#41;+&#40;&#40;&#40;_this select 0&#41; select 1&#41;^2&#41;&#41;;
_cdheightasl1 = sqrt &#40;&#40;&#40;referenceslobj distance referencesl&#41;^2&#41;-&#40;_cdajacent1^2&#41;&#41;;

referencesl setpos &#91;0,0,0&#93;;
referenceslobj setpos &#40;_this select 1&#41;;
_cdajacent2 = sqrt &#40;&#40;&#40;&#40;_this select 1&#41; select 0&#41;^2&#41;+&#40;&#40;&#40;_this select 1&#41; select 1&#41;^2&#41;&#41;;
_cdheightasl2 = sqrt &#40;&#40;&#40;referenceslobj distance referencesl&#41;^2&#41;-&#40;_cdajacent2^2&#41;&#41;;

_tiltdirection = 0;
if &#40;&#40;_cdheightasl1 - _cdheightasl2&#41; &#62;= 0&#41; then
{_tiltdirection = -1;
}else{_tiltdirection = 1;};

_angle = acos&#40;_adjacent/5&#41;;
_angle * _tiltdirection
[/QUOTE]

And what it used to be:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">// ************************************************** *****************
// Internal Script of Function &#34;GetBankPitch&#34; by Dschulle
// GetHeight above SL from Position
// Do not edit&#33;
// Do not call&#33;
// ************************************************** *****************
BankPitchObjPos setpos _this;
BankPitchSL setpos &#91;_this select 0, _this select 1, 0&#93;;
BankPitchSL distance BankPitchObjPos
[/QUOTE]

There is only one problem however. The increase in smoothness of the execution of this command seems to be exposing a flaw in another part of the camera script which causes the camera tracking the game logic next to the aircraft to very occasionally (once every 10 seconds or so) jolt very severely. I need to look into this. Tomorrow I will try this new version of the camera script on an ordinary camera script to see if it is the positioning of the game logic which is at fault. By the looks of it, it is as when the aircraft jolts it moves forward awayfrom the camera (not always and not for definite as it is so quick) which would suggest a shortcoming in the setpos method of positioning the game logic.

I think a better way would be to use the setvelocity command as I think the positional data of the game logic would be better recorded by the game engine.

Anyway at least it means the GetBankPitch utility is working more accurately after being tweaked. Not sure why I am suddenyl experiencing problems with it now though and not before because the new modifications to it actually remove dependency on terrain and sea level heights Really, really wierd.

Got to stop and have a break now as I am getting so mad with this thing

I&#39;ll keep you informed and I&#39;ll link other relevant threads to this one

[General Barron]

Very, very cool effect. It definately gives a completely different &#39;feel&#39; to the cutscene than I&#39;m used to in OFP. I hope lots of people use this script.

Getting technical: lemme point out some potential problems with the code, in this section:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">;Position the game logics
cameraeffect2 setpos &#91;&#40;_xh + _xa&#41;,&#40;_yh + _ya&#41;,0&#93;
_dist = _helo distance cameraeffect2
_height = sqrt &#40;&#40;_dist^2&#41;-&#40;_camoffx^2&#41;&#41;
cameraeffect1 setpos &#91;&#40;_xh + _xa&#41;,&#40;_yh + _ya&#41;,_height&#93;
cameraeffect1 setdir _heading
logiccomplete = true

#checkserverready
?logiccomplete &#58; goto &#34;camerapositioning&#34;
goto &#34;checkserverready&#34;

#camerapositioning
...
[/QUOTE]

First off, NEVER use a loop like you have in #checkserverready. If you are going to have an indefinite loop like that (that is, it isn&#39;t repeating a fixed # of times, but rather repeats until a condition occurs), ALWAYS put a timed delay between the loops. For example, a 1/2 second delay:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#loop
? condition &#58; goto &#34;whatever&#34;
~0.5
goto &#34;loop&#34;[/QUOTE]

The lowest delay you should use is about 0.1 seconds. If you need to check the condition faster than that, use the @ command:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">@condition[/QUOTE]

This causes the script to pause until "condition" is TRUE. (OFP checks the condition some 1000 times a second)

Only use @ if you need to check more than 10 times a second. Otherwise it is generally better (performance-wise) to use a loop + delay.

----------

Second: MP issues. First off, you never publicvariable "logiccomplete", so clients will sit at #checkserverready forever, waiting for it to never change.

Even so, I don&#39;t like this approach of broadcasting the position of the camera to the clients. You will be broadcasting variables 1000 times a second, which could cause serious network problems.

Normally in MP, camera scripts are simply run on every single client. I&#39;d do the same here: just write the script for SP, and if the editor executes it on all clients in MP, it should work perfectly.

-----------

Third: logics. Instead of using editor-placed game logics, you should have the script create it&#39;s own. This is also required if you want it to work properly in MP (using my above suggestion). To create the logics at the top of the script:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_cameraeffect1 = &#34;logic&#34; camcreate &#91;0,0,0&#93;
_cameraeffect2 = &#34;logic&#34; camcreate &#91;0,0,0&#93;[/QUOTE]

Then just use those local variables instead of the global ones ("cameraeffect1/2"), and delete your three logics (don&#39;t need "server" either) from the test mission.

Be sure to delete the logics when the script ends though. Always be tidy and clean up your scripts&#39; mess&#33;

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">deletevehicle _cameraeffect1
deletevehicle _cameraeffect2[/QUOTE]

-----------

Last: finishing touches. I really hope you will submit this awesome script to OFPEC, once you are finished with it (and once OFPEC is back up). Like I said, I really, really like this script.

But to make it really "complete", you should write up a readme with instructions on how to use the script, contact info, version, date, etc etc.

I&#39;d also suggest that you use an OFP Tag for your global variable names. Basically, this means you come up with a 3-4 letter prefix that you will attatch to all the global variables you use in all the scripts/addons/etc you create. This way, if someone else&#39;s camera script uses the variable "camend", there won&#39;t be any catfights between the two scripts (since your script will use "C330_camend" or something instead).

Looking forward to the next version.

[chris330]

Very, very cool effect. It definately gives a completely different &#39;feel&#39; to the cutscene than I&#39;m used to in OFP. I hope lots of people use this script.

Cheers It surpassed my expectations by quite a long way.

First off, NEVER use a loop like you have in #checkserverready....

....The lowest delay you should use is about 0.1 seconds. If you need to check the condition faster than that, use the @ command:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">@condition

This causes the script to pause until "condition" is TRUE. (OFP checks the condition some 1000 times a second)

Only use @ if you need to check more than 10 times a second. Otherwise it is generally better (performance-wise) to use a loop + delay.
[/QUOTE]

Understood. Will either be inputting time delay or dropping the loop for the @ command you mentioned. I know it may be CPU intensive but I really like the sound of that refresh time. Plus it&#39;s such a clean way of doing it.

Second: MP issues. First off, you never publicvariable "logiccomplete", so clients will sit at #checkserverready forever, waiting for it to never change.

Even so, I don&#39;t like this approach of broadcasting the position of the camera to the clients. You will be broadcasting variables 1000 times a second, which could cause serious network problems.

Normally in MP, camera scripts are simply run on every single client. I&#39;d do the same here: just write the script for SP, and if the editor executes it on all clients in MP, it should work perfectly.

I agree completely. Attempt to make MP compatability by broadcasting variables will now be permanently dropped.

Third: logics. Instead of using editor-placed game logics, you should have the script create it&#39;s own. This is also required if you want it to work properly in MP (using my above suggestion). To create the logics at the top of the script:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_cameraeffect1 = &#34;logic&#34; camcreate &#91;0,0,0&#93;
_cameraeffect2 = &#34;logic&#34; camcreate &#91;0,0,0&#93;

Then just use those local variables instead of the global ones ("cameraeffect1/2"), and delete your three logics (don&#39;t need "server" either) from the test mission.

Be sure to delete the logics when the script ends though. Always be tidy and clean up your scripts&#39; mess&#33;

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">deletevehicle _cameraeffect1
deletevehicle _cameraeffect2[/QUOTE]
[/QUOTE]

Understood I guess this idea means there is no reason to have to have things such as game logics globally accessible to provide a solid cross reference point for client machines as the logics each client needs to do this will be created locally on their machine. Even better

I will certainly be submitting the final version and if I remember correctly I already have an OFP tag. I&#39;m delighted you like the script.

I&#39;m even more delighted it got the chance to be viewed with a fresh pair of eyes though as I&#39;ve been at it so many times now it is beginning to become difficult to see the wood for the trees. So I often need other people to highlight its shortcomings.

I&#39;m not sure which version you have used General Barron but the latest version is super-smooth and removes even the really tiny fluctuations of the camera angle&#39;s deviations from the aircraft&#39;s pitch angle when in flight. However there is still some fundamental problem which is causing it to go off its bloody head for a fraction of a second every now then. Obviously I can&#39;t release it like this, I when I do release it I will include alot of documentation

Thanks alot for looking at it

[chris330]

Okay I have fixed everything barring the jolt. After an awful lot of testing and five more rebuilds of the entire script including more tampering with the GetBankPitch utility I think I have narrowed down what it is.

It is not an issue relating to using the camsetrelpos with the game logics, although this is certainly an issue when you try and use a [0,0,0] array for this, which should never happen in this script. I did some testing on the desert island and found no issues when the helicopter was going through zero bank with camera positioning commands referenced to game logics.

I did notice that even in this environment though it did not like 90 degree angles used as I presume it puts a zero in there somewhere which it doesn&#39;t like. Not really relevant though.

The big problem I think is one of either two things:

1) Using a drop&#39;s positional reference to perform distance commands with (I doubt this is it, although I had no jolt errors before I used this method but resolution of camera angles was a little bit poor the old way).

Or

2) An issue with using the setpos command to place the game logic which is next to the helicopter. More than likely this is the one.

The reasoning behind me believing it is the second possibility that it most responsible is because when I substituted game logics for chairs the jolt effect got worse not better. If there was an issue with using a drop&#39;s positional array to evaluate pitch and bank angles and don&#39;t think it would have affected this part of the script as it is entirely seperate.

So I think I could use my triangle theory to place the game logic at the very start of the script but I think beyond that the setvelocity command will have to be used. If this command is used then the position of the helicopter and that of the game logic will be updated in a perfectly synchronised fashion by the game engine. I suspect jolt effects are being caused by some lack of snychronisation as a result of the game engine being responsible for the postion of the helicopter but the setpos command being responsible for the position of the game logic.

I think (I could be wrong - this is Operation Flashpoint after all) that using the setvelocity command will mean positional references for the game logic and those for the helicopter will be preaching from the same book (i.e. the internal functions of the game engine).

Not using the setpos command should hopefully make the whole jolt issue become a lot less well....jolty

I&#39;ll keep you informed

[chris330]

Some potentially very important news

Assuming nobody has ever encountered this before, and as far as I know I have never seen it used in a script before made by anybody else,

Then it looks like I have made a major breakthrough in the correct use of the wait command or more commonly known as:

~

Please look at the code below:

Begin Script

_helicopter = _this;
_logic1 = "logic" createvehicle [0,0,0];

_cam = "camera" camcreate [0,0,0];
_cam cameraeffect ["internal", "back"];
_cam camsettarget _this;
_cam camsetrelpos [0,-5,0];
_cam camcommit 0;

#loop

_x = getpos _helicopter select 0;
_y = getpos _helicopter select 1;
_z = getpos _helicopter select 2;

_logic1 setpos [(_x + 5),_y,_z];

_cam camsetrelpos [0,-5,0];
_cam camcommit 0;

__waituntil = _time + (0.1);

goto "loop";

EndScript

Run it with a mission which uses a helicopter which starts as flying and has waypoints to follow and start the script with the helicopter&#39;s ID passed to start the script. Run it again and change the waituntil part with the standard used by everybody else up to now which is:

~0.1

See the difference for yourself. I discovered it when I put a semi-colon ; at the end of the ~0.1 line in my first build of this test script. It returned a rogue error-code I have never seen before which gave away the proper use of the wait command.

I hope sincerely this will work as well on your machine as it does on mine. Please try this, I really am not exaggerating.

Note the two underscores before the waituntil part are not a typing mistake.

[chris330]

Oddly enough it also works if you write this:

~0.1;

But it returns an unsightly error message whereas the first method I quoted does not.

**Update

I have made a mission which demonstrates this. Put it into your mission folder under your user name not your single missions folder.

Radio Alpha calls the new verison and Radio Bravo calls the version which uses the old traditional way of instructing a wait time.

Wait Time Example