Pitching Camera Script

[chris330 0]

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 0]

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 0]

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 29]

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 0]

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 ["_xdistance","_ydistance","_adjacent","_cdajacent1","_cdheightasl1","_cdajacent2","_cdheightasl2","_angle","_tiltdirection"];

_xdistance = ((_this select 0) select 0) - ((_this select 1) select 0);

_ydistance = ((_this select 0) select 1) - ((_this select 1) select 1);

_adjacent = sqrt ((_xdistance^2)+(_ydistance^2));

referencesl setpos [0,0,0];

referenceslobj setpos (_this select 0);

_cdajacent1 = sqrt ((((_this select 0) select 0)^2)+(((_this select 0) select 1)^2));

_cdheightasl1 = sqrt (((referenceslobj distance referencesl)^2)-(_cdajacent1^2));

referencesl setpos [0,0,0];

referenceslobj setpos (_this select 1);

_cdajacent2 = sqrt ((((_this select 1) select 0)^2)+(((_this select 1) select 1)^2));

_cdheightasl2 = sqrt (((referenceslobj distance referencesl)^2)-(_cdajacent2^2));

_tiltdirection = 0;

if ((_cdheightasl1 - _cdheightasl2) >= 0) then

{_tiltdirection = -1;

}else{_tiltdirection = 1;};

_angle = acos(_adjacent/5);

_angle * _tiltdirection

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 "GetBankPitch" by Dschulle

// GetHeight above SL from Position

// Do not edit!

// Do not call!

// *******************************************************************

BankPitchObjPos setpos _this;

BankPitchSL setpos [_this select 0, _this select 1, 0];

BankPitchSL distance BankPitchObjPos

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'll keep you informed and I'll link other relevant threads to this one

[General Barron 0]

Very, very cool effect. It definately gives a completely different 'feel' to the cutscene than I'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 [(_xh + _xa),(_yh + _ya),0]

_dist = _helo distance cameraeffect2

_height = sqrt ((_dist^2)-(_camoffx^2))

cameraeffect1 setpos [(_xh + _xa),(_yh + _ya),_height]

cameraeffect1 setdir _heading

logiccomplete = true

#checkserverready

?logiccomplete : goto "camerapositioning"

goto "checkserverready"

#camerapositioning

...

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'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 : goto "whatever"

~0.5

goto "loop"

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.

----------

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'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'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'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 = "logic" camcreate [0,0,0]

_cameraeffect2 = "logic" camcreate [0,0,0]

Then just use those local variables instead of the global ones ("cameraeffect1/2"), and delete your three logics (don'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' mess!

<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

-----------

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'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's camera script uses the variable "camend", there won'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 0]

Very, very cool effect. It definately gives a completely different 'feel' to the cutscene than I'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.

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'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'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'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'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 = "logic" camcreate [0,0,0]

_cameraeffect2 = "logic" camcreate [0,0,0]

Then just use those local variables instead of the global ones ("cameraeffect1/2"), and delete your three logics (don'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' mess!

<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

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'm delighted you like the script.

I'm even more delighted it got the chance to be viewed with a fresh pair of eyes though as I'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'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's deviations from the aircraft'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't release it like this, I when I do release it I will include alot of documentation

Thanks alot for looking at it

[chris330 0]

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't like. Not really relevant though.

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

1) Using a drop'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's positional array to evaluate pitch and bank angles and don'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'll keep you informed

[chris330 0]

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'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 0]

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

[chris330 0]

I'd appreciate it if anyone who tries to download this would let me know if the link works

**Update

On some more testing it appears to be (I could well be wrong) causing the odd infinite loop error, almost as if it is being bypassed completely, yet in other scripts it works

Check out the demo mission anyway (that works ok) but I think this needs a little more investigation before you go putting it into any of your scripts

**Update Again

To be honest even though I have discovered it, I don't like it. I suspect in reality that the smooth execution time is in reality a red herring for something which is in fact not being recognised and is just initiating an infinite loop which you can get away with in the demo mission because the code is so simple. I'm not sure about that though. I'm not done with it, mind, I think that weird error message might end up leading to something. If anything else really interesting happens I will let you know, but for now you can consider this as to have hit something of a brick wall for the time being.

[Blanco 0]

grmfffp...delete this post

[Blanco 0]

Hmmm...I don't understand the meaning of this line :

_waituntil = _time + (0.1);

You initialise the _waituntil variable by the sum of the time the script runs + 0.1 sec but you aren't using it in your script.

Imo the delay in the loop in script1 is simply 0 because the var is not executed.

This executes the var :

_waituntil = _time + (0.1);

~_waituntil

But it makes no sence because ~_waituntil will be longer and longer and the camera will be setpossed father away behind the chopper each time the script loops.

[General Barron 0]

Haven't looked at the new version yet, nor have I seen the jerking problem you are talking about. But one idea on what COULD cause a problem:

When you 'setpos' an object over another object, wacky things can happen. For example, setting an object at 29m above an object that is 5m above the ground might set the object at 34m above the ground, while setting the object 30m above might result in it dropping down to 30m above ground level.

So, perhaps when the camera is directly over a bush, rock, or other object, there might be a problem. Or maybe the ASL function gets screwed up.

I dunno if it would be the problem, just throwing a possiblity out there. To test it, you could fly a chopper over the ocean--if it is still jerky, then you can ignore everything I said .

[UNN 0]

Chris,

The __waituntil is a reserved variable used with the ~ command. To see for your self run a script with just a ~ and no value:

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

~

Player SideChat "End"

You will get this error:

There are two camps, one that believes the ~ command is a more efficient way to pause a script. The other believes its the @ command.

From that error you could assume there both the same and these two bits of code do the same thing.

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

~1

Player SideChat "End"

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

_MyTime=Time+1

@(_MyTime<Time)

Player SideChat "End"

However there are quite dramatic differences in the way OFP handles the @ and ~ commands. So for me the jury is still out. But under certain circumstances the @ command does appear to be more efficient, one example of this might be:

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

@(MYBOOLEAN)

Player SideChat "End"

Compared to the less efficient method:

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

#Loop

~0.001

If !MYBOOLEAN Then {goto "Loop"}

Player SideChat "End"

The latter requires much more code for starters. But like I said the way OFP handles both these commands is not as straight forward as it first appears.

[chris330 0]

To quote a phrase froma famous song:

I get by with a little help from my friends

Thanks for the help gentlemen. At least that means I can drop the whole wait thingy without wasting anymore time on the damn thing. By preference though I think the @ command looks like a nicer way of doing it.

I had a major moment of hilarity last night when I discovered that the setvelocity command is infact cumulative. I've never seen a soldier move that fast before

General Barron, I think you might be onto something there. The modifications I have made to the original Dschulle GetBankPitch utility and the method I use to position the game logic at the same height as the helicopter (which caters for uneven terrain), means that height above sea level functions are no longer necessary for this to work properly and as such none are used.

Here is the way the correct height is obtained for the game logic which the camera points at:

Height/Setpos triangle

The pitch and bank data of the modified utility now acquires values using a very similar method to height above sea level functions.

It works out the distance between the the centre and front drop using their x and y co-ordinates, and then compares it to the hypotenuse which is set to 5 by the drop command. See the image below:

Hopefully that is reasonably clear. Here is where it gets bizarre. I shall number point these for clarity:

1) The old GetBankPitch version used heights above terrain (not sea-level as was intended - check my reverse engineer project for info about this) to acquire pitch data. Oddly, my script worked with this method.

2) Since modifying the old GetBankPitch utility to return more accurate values of pitch which do not rely on terrain or sea level heights, the script has begun to return jolts errors occassionally, which I believe is related in some way to General Barron's point. The script definitely runs smoother than it did before in between 'jolts' however.

3) So, to determine if it is uneven terrain causing these issue I will now perform some testing on the desert island. This will return some important conclusions.

i) There are no trees or rocks on the desert island, so if the script runs smoothly at all times I will know it is this that is upsetting it.

ii) If the script does not run smoothly over changes in terrain height then it will prove that terrain heights are causing the issue.

iii) Further more I will do some testing without the camera script but with the modified version of GetBankPitch using a hint which constantly informs me of the vehicles pitch to make sure there are no oddities in the operation of the new version.

That should pin down this rather nasty issue.

On a final note before testing begins, given the fact that the original version of the GetBankPitch utility appeared to be using heights above terrain (I'll test this to to make sure) for pitch data, do you think it is possible that there was some wierd correlation between this data and the setpos triangle I have used both acting on the same variations in terrain height caused by trees and such like, where each countered the offset effect of the other and therefore returned proper values?

I really am puzzled as to why it work before but not now?

Anyway I think as you have probably guessed by now I don't intend to stop until I have found the source of this issue. I will let you know what conclusions I drew from the testing I'm about to do

[UNN 0]

Lol...I got carried away with my favourite debate. I forgot what I originaly wanted to post.

The line in your script:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">__waituntil = _time + (0.1);

Does not do anything. The improvement you see is down to the fact that your loop no longer has a delay. Peronelly I don't think this is a problem when your calling CamComit in the same loop. But to be on the safe side I would change it to.

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

That should still let your script run as smoothly as it does now, without any danger of it locking up.

[chris330 0]

Thanks for the reply UNN,

So using the camcommit part will also build an acceptable delay into the script? What does the:

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

Part do? Should I write this exactly as it is in place of the waituntil part?

Thanks again

[UNN 0]

Quote[/b] ]So using the camcommit part will also build an acceptable delay into the script?

It looks that way. If you run this, OFP will lock up for sure:

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

_I=_I+1

goto "Loop"

I have not seen a loop with camcomit lock yet. But the @ forces it to at least wait a single clock cycle (roughly 0.001 seconds).

Quote[/b] ]Should I write this exactly as it is in place of the waituntil part?

Yes but not quite, afarid I made a mistake. Should have been:

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

BTW Do those jolts you mentioned in your camera script, happen when your flying from land to water and vice versa?

I must admit I'm suprised you can get away with not using  HASL, there are some objects that work on absolute coordinates. Ammo being one, perhaps drop particles do to. Most objects return positions relative to the terrain.

[chris330 0]

Just a quick note before I hit you with all my testing findings, so I can reply to UNN,

Jolts occur over perfectly level terrain. Which answers quite a few questions from the earlier post.

Using the triangle theorem and the fact that the drop offset distance from the vehicle's centre is known to be 5 metres I only need it's x and y co-ordinates to get pitch values, so I don't have to reference to terrain or sea level

[chris330 0]

Just a quick note to say I have had chance to digest what you are saying and I have decided to attempt to discover whether or not drops are absolute or relative to terrain heights, just to make absolutely sure. All I can tell you is I have run this script using the means of evaluating pitch data shown above (i.e. avoiding HASL data) and for the most part it runs very well (the camera angle better matches the pitch of the helicopter), including over uneven terrain. It is just the occasional jolt that pulls it down and must obviously be eliminated.

This will probably go quiet for a while because I am about to return back to work, which is almost a blessing considering how much all this has been occupying my mind lately. Once I have ascertained for certain that drops are absolute I shall attempt somemore testing.

On a final note just in case this gives somebody else an insight into what is going on which I am presently unable to see (this has happened to me many times before) I noticed that during some of the jolts the camera appeared to remain stationary whilst the helicopter flew ahead of it. It only occurred for a brief moment but it was long enough for me to see what was going on. So I suppose without trying to say too much for certain, that this would suggest the position of the game logic is not being updated in tandem with the change in position of the helicopter for that brief moment of time.

What is causing this however, I really couldn't say. I have almost completed the latest version of this script. If anyone would like me to send it over to them so they can pick through it when it's complete please let me know.

Thanks again, hopefully I'll see you all soon

[UNN 0]

Quote[/b] ]All I can tell you is I have run this script using the means of evaluating pitch data shown above (i.e. avoiding HASL data) and for the most part it runs very well (the camera angle better matches the pitch of the helicopter), including over uneven terrain. It is just the occasional jolt that pulls it down and must obviously be eliminated.

If it works, don't worry about it

I was looking at the few examples I've written using cameras. The camera does appear to have a life of it's own.

Sometimes in the external view, it will drift away from the target. Then as I start to roatate the view, snap back to the distance you would expect from the internal view and start moving away again. It's position should be fixed in a loop with with SetCamRelPos, but it will not always stay at that position.

Perhaps it's just something hardcoded into cameras? I tried changing interia e.t.c but that made no difference.

[chris330 0]

Thanks for getting back to me UNN

I would just like to say that having had another look at the original version I don't really know what the hell I have been whining about. It runs absolutely super smooth so I don't really know why I have had such a critical view of it

I am more than happy to consider the first downloadable version I have provided in this thread as a final release as it is easily good enough to go out as a finished product.

I have noticed some very slight wobbles of the camera angle but they are so small that it is hardly an issue at all, and anyone whom had not had so much to do with the script as I have (seeing as I made it) probably wouldn't even notice it.

I shall attempt to fix the issue with the new version however purely as a matter of improving my investigative powers and better understanding oddities of script behaviour.

However if anyone reading this thread would like to host the original version on their site please feel free to do so as I am happy to call it a complete build.

As for the new version it would appear that the short break has done me some good and I am investigating the possibility that it may be a synchronisation error between the script positioning the camera and the one returning pitch data. I am not certain of this however and will of course be looking into it. If I ever solve this issue I will probably just distribute the new version amongst certain community members and maybe post my findings in this thread to help other script writers in the future.

If I uncover anything useful I will let you know

**Update just in case anyone is interested here is a version of the script which has scrapped the use of the publicvariable command and also creates and deletes the game logics used every time the script runs. It also uses the @camcommitted command for the delay. It's a slightly nicer version than the first one I uploaded anyway.

Cleaned up version of pitching camera script.

It awaits a variable called CHRcamend to come true to exit the script. I have tested it and it works fine

**Update, I would be grateful if anyone who downloads this script would let me know if it definitely works okay (there's no reason why it shouldn't - I have downloaded it and ran it myself) because if it does I will probably e-mail the staff at OFP.info and submit it there

[UNN 0]

Quote[/b] ]Update, I would be grateful if anyone who downloads this script would let me know if it definitely works okay

I can't download anything from www.savefile.com  

[chris330 0]

It works for me. I just click the orange download button and then click on the 'download now' underlined text and it works. I'll send you a copy over now. If anyone else is having trouble let me know and I'll e-mail it over to you.