Eurofighter Typhoon beta

[BlackScorpion 0]

I'd also add Saudi-Arabia to the list, maybe. They're apparently getting some, although I'm not sure whether they have actually made the contract yet.

http://www.airforce-technology.com/projects/ef2000/

[mattxr 9]

i noticed that the other textures the like the tiger stripes are already in the addons so is their anyway to get them activated like code in the init?

[sa8gecko 0]

Firing the standard weapon loadout of the Typhoon, I noticed that, when banking or pitching, the missiles are fired as the plane would be horizontal: this is particularly evident firing the sidewinders during a bank turn and/or the amraams when pitching.

The question is (for Kikill or Hardrock): am I doing something wrong or is it because ACES is still beta?

I've given a very fast look to the scripts, and what i understood is that the missiles are setposed taking into account the plane position. Perhaps a better option could be to use a camera placing it relative to the plane using camSetRelPos command, and take its position to place the missile: the bad is that this camera won't bank with the plane (but maybe i missed something), but anyway it will pitch.

Here are some videos I made (divx 5.2.1):

video files

(7 days only)

they show the difference between the typhoon and a Footmunch's F4-E (modified without permission for private use only) using camSetRelPos. If just this command would take into account the plane bank angle (like dropping a particle) it would be perfect. I'm saying this because, especially when launching lot of bombs during a dive, some of the launched objects, if not in the right position, can collide with the plane, with catastrophic results, as you can imagine.

Did I say anyway that I like this project (ACES)?

Do you plan to transport it to ArmA, if it doesn't have something like this by its own, once it gets released ?

[hardrock 1]

Due to scripting limitations and due to the fact, that after the fired event a config file is parsed and the weapon placed according to the config values, the performance of the fired script is not as good as one dedicated to a single addon. Of course, the script could be improved, but as you might have noticed, it was written in early 2004 and I never found the time to improve it as it was quite well for that time.

Of course, solutions using camSetRelPos would be possible, and feel free to change the ACES scripting logic to use that command. I only warn you that it won't be easy as you'll also have to adjust the config file system to that. If you manage to improve the script though, tell us and we might include it in some further release (if there is).

I won't comment on the question whether ACES will be improved and transported to Armed Assault. It all depends on the time I have, the things ArmA already offers and the scripting possibilities offered by the engine.

[Footmunch 0]

Gecko - I've also been working on a camSetRelPos pseudo-proxy system for the Su-24. Great minds think alike Here's a sample of what I've got so far:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">; Create the positioning camera

_missposcam = "CAMERA" camCreate [0,0,0]

_missposcam camSetTarget _plane

[...]

#R60B_away

_plane setobjecttexture[12, ""]

_missrelpos =[4, -7, 0]

goto "MoveMissile"

[...]

#MoveMissile

; Get the missile object

_missobj = nearestobject[_plane, _ammoname]

; Get an offset position from the plane

_missposcam camSetRelPos _missrelpos

_missposcam camCommit 0

_missobj setpos (getpos _missposcam)

camDestroy _missposcam

The main problem I've encountered with this approach compared to a standard sideways move is the speed of execution. Even in your vid with the Typhoon, you can see the missile being created above the 'spine' of the aircraft while the camCommit 0 line gets executed. The quicker grab and move ACES approach means that the missile spends less time above the plane. With the overhead that HR mentions relating to hard-mounted and multiple rail weapons, the it may be difficult to keep the speed in line.

Here's hoping ArmA has things like this built in - it already looks as though the MCar stuff won't be needed...

[tankieboy 0]

Good to see you in this thread Footmunch.

Can I ask if you are working on finalising this Typhoon?

[sa8gecko 0]

Quote[/b] ]Even in your vid with the Typhoon, you can see the missile being created above the 'spine' of the aircraft while the camCommit 0 line gets executed.

No. That's the standard Typhoon, I didn't touch it. Compare it to the F-4E to see the difference. I should have explained that the Typhoon video was only for comparison, sorry.

Quote[/b] ]The main problem I've encountered with this approach compared to a standard sideways move is the speed of execution.

It should be faster cause it requires less calculations: really, to say this for sure I should know the time it takes the camSetRelPos command to be executed comparing with the calculation needed using the other way; since I used an array to store the exact ammo positions, I didn't need any trigonometry. Anyway, try this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">call "_missposcam camSetRelPos _missrelpos;_missposcam camCommit 0;_missobj setpos (getpos _missposcam)"

The major gripe I have with camSetRelPos is that it's bugged, that is it doesn't bank with the aircraft, although it pitches OK: you, Footmunch, should know this from your Backfire's turret. Perhaps someone expert in handling cameras can provide a good answer: if it's not possible that the camera banks with the plane, I hope BIS read this so to fix the command for ArmA, as I doubt a system like ACES would be implemented in that game. But then, maybe I'm wrong.

Anyway a command working half the way it should is always better than nothing. As I already pointed out, this is not only a question of eye candy effects, but has practical meanings if you happen to launch bombs (or any other free falling object) when banking: it's true, you should not: but it's a game.

Another way to solve this issue could be to use proxy cargo spaces in the model: anyway you already have them in the Typhoon to attach the weapons. Three would be needed, one in the middle of the plane, the other in front of this one and the latter exactly right (I'm not sure if right or left) of the first. Taking their relative position in game (with a function) will give you the pitch and bank angle. Now, with some tranformation matrix you shold be able to translate the relative position of the ammo being launched (as regard to the plane itself) to the absolute one (the 'world' around it). I'm no more fresh in math; anyway: you have the relative vector to the ammo as regard to the 'reference system' plane, its origin being the plane center: [u,v,w]. Now, to find the absolute [x,y,z] cohordinates you should use the following equations, IF I remember correctly, (please bear with me):

x = (u+DX)*cos (a) + (v+DY)*cos (90-b) + (w+DZ)*cos (90+c)

y = (u+DX)*cos (90+a) + (v+DY)*cos (b) + (w+DZ)*cos (90-c)

z = (u+DX)* cos (90-a) + (v+DY)*cos (90+b) + (w+DZ)*cos ©,

(of course you can simplify knowing that cos(90+alpha) = - sin(alpha) and cos(90-alpha) = sin (alpha) )

where a,b and c are the angles the system [u,V,W] forms with the reference system (the outside world) [X,Y,Z] : they should be ('should', tbr) respectively the plane 's yawn angle (given by getdir), the bank angle and the pitch angle. DX,DY and DZ are the distances between the origins of the two systems (plane and outside world) that is, simply:

DX = position plane select 0

DY = position plane select 1

DZ = position plane select 2

even if (AGAIN) if you take the distances between two objects with the 'distance' command and then compare with the results obtained using the Pythagoras' theorem on their cohordinates (as returned by getpos) you get different numbers.

Now, I'm not sure the above equations are completely exact, so it just remains to try them out (I'll do when I'll get some time, but if some of you would try them first, please step in).

Of course if the damn camSetRelPos would work the way it should, there would be no need of the above calculations.

[Footmunch 0]

Good to see you in this thread Footmunch.

Can I ask if you are working on finalising this Typhoon?

I've got a fair amount of FLK work to do at the moment. Once that's done, I'll be converting some of my existing planes to ACES (F-16, F-4, Flogger and Su-33 are the priorities there, but the Jag and Bucc will be converted over as well) and maybe helping out on ACES debugging (which should leak-over into improvements with the EF).

So, sadly, I can't make a committment on the EF right now...

Gecko - My mistake on the videos - the F4 release does seem quite smooth - nice work.

Does putting the list of commands into the call function pre-compile them (and increase the speed) in some way? Interesting.

[kikill 0]

hey footmunch and sa8gecko, i invite you to continue this interesting discussion in this new thread dedicated to ACES, so people don't get confuse between EF and ACES related things

[sa8gecko 0]

Kikill:

Quote[/b] ]hey footmunch and sa8gecko, i invite you to continue this interesting discussion in this new thread dedicated to ACES, so people don't get confuse between EF and ACES related things

You're right, but first I must specify that the equations I gave above are wrong, so don't use them. They should have been:

x - DX= u*cos (UX) + v*cos (UY) + w*cos (UZ)

y - DY = u*cos (VX) + v*cos (VY) + w*cos (VZ)

z - DZ = u* cos (WX) + v*cos (WY) + w*cos (WZ),

where UX is the angle formed by the axis U (of the plane reference system) and the axis X (of the 'world' reference system), UY is the angle formed by the axis U and the axis Y and so on.

Got these one assuming the axis Z and W have the same orientation: they simplify in this case in the standard ones, for two dimensional rotations (of an angle 'a': WZ=0,VZ=UZ=90°,WX=WY=90°,UX=VY=a,UY=90+a,VX=90-a):

x - DX= u*cos (a) + v*sin (a)

y - DY = - u*sin (a) + v*cos (a)

z - DZ = w

but sorry I can't think of a way to obtain UX,UY,UZ,VX,VY,VZ,WX,WY,WZ knowing the yawn,bank and pitch angles, so I'm stuck. It's easy in 2D, but I can't visualize it in 3D.

[EDIT]

Ok, I think I got it:

since cos(UX), cos(UY), cos(UZ) and so on are nothing else that the scalar product of the versors (U ° X), (U ° Y), (U ° Z) (and so on), we can just do that; now:

X=(1,0,0)

Y=(0,1,0)

Z=(0,0,1)

U,V,W are easy to obtain: if you remember I supposed to place 3 extra gamelogics on the plane, one in the center (O), one in front of it horizontally (P), and the other on the left of the first one (Q). Now, you can get U just by getting the plane velocity and normalizing it: but since this can be misleading because the plane could be sideslipping, let's use the first two gamelogics:

if we placed them exactly one meters apart (in the p3d model) we simply have:

U=[(getpos P select 0)-(getpos O select 0),(getpos P select 1)-(getpos O select 1),(getpos P select 2)-(getpos O select 2)]

of course asl heights should be used for maximum precision. We could even normalize this vector just to be sure we get a direction.

In the same manner:

V=[(getpos Q select 0)-(getpos O select 0),(getpos Q select 1)-(getpos O select 1),(getpos Q select 2)-(getpos O select 2)]

It only remains W to be calculated. This can be done using the vectorial product between U and V (if you don't want to use another gamelogic):

W= U x V = [u1,u2,u3] x [v1,v2,v3] = [(u2*v3 - u3*v2),(u3*v1 - u1*v3),(u1*v2 - u2*v1)] = [w1,w2,w3]

(I think that W obtained this way should be already normalized, anyway it can always be normalized)

At this point the scalar product of the versors must be calculated:

U ° X = [u1,u2,u3] ° [1,0,0] = u1*1 + u2*0 + u3*0 = u1

U ° Y = [u1,u2,u3] ° [0,1,0] = u1*0 + u2*1 + u3*0 = u2

U ° Z = [u1,u2,u3] ° [0,0,1] = u1*0 + u2*0 + u3*1 = u3

V ° X = v1

V ° Y = v2

V ° Z = v3

W ° X = w1

W ° Y = w2

W ° Z = w3

obtaining, at the end:

x - DX= u*u1 + v*u2 + w*u3

y - DY = u*v1 + v*v2 + w*v3

z - DZ = u*w1 + v*w2 + w*w3

shame on me if I got it still wrong.

[END EDIT]

Footmunch:

Quote[/b] ]Does putting the list of commands into the call function pre-compile them (and increase the speed) in some way? Interesting.

I don't think 'pre-compile' is the exact word here, but it should behave almost the same (like calling a function), that is it should ensure the engine stops, executes all the instructions in the string, and then goes on (returning to the rest of the script or updating frames and projectile trajectories or calculating collisions, for example)

[hardrock 1]

@sa8gecko: You made some good attempts there and also gave me new inspiration. But still it is unprobable that I will work further on ACES prior to Armed Assault, that is if Armed Assault is released as planned. If not and if I find some more time in the summer and some more ifs, then I can maybe implement the camSetRelPos (but without any banking calculations, since the outcome would be 0) into ACES, since it really sounds as if it would speed up the process of firing the weapons quite a bit. Remember the scripts are pretty old.

This would require some minor changes in the cfg system though, but I guess they wouldn't be much of a problem. I also have some more ideas on how to improve the code of ACES, mainly based on the experiences I've made the past two years.

Still, many ifs.

[sa8gecko 0]

Could I say I'm sorry, again ?

(Kikill, I'm continuing the discussion here because I've posted here about the whole concept)

Please don't start to laugh: the matrix I posted above is wrong: that is, it's useful to find the relative cohordinates if you know the absolute ones. We just need the contrary: in this case it's enough to transpose the matrix, obtaining:

x - DX = u*u1 + v*v1 + w*w1

y - DY = u*u2 + v*v2 + w*w2

z - DZ = u*u3 + v*v2 + w*w3

this works, guaranteed: I back up my words with this video, showing the 'usual' F-4E releasing bombs from its MERs while banking, turning and pitching:

test video

(7 days only, divx 5.2.1)

A part the usual OFP setpos 'bug' (that is, everything is turned horizontal), you can see the bombs releasing from the right spots.

This is how the camSetRelPos command should work, if it wasn't bugged.

[sakura 0]

Hi

I would like to have all camoversions of The EF added in the PBO

So thi see 5 EF in the Editor 1 for every camo!!

So Does anyone have done it??? So please can someone help me make it i have not much knowlage at Scripting but if someone can tell me where i must ad the lines and what must be written there i would be glad PLEASE HELP!!

[kai121 0]

Never mind, links up again

[danup96 0]

hi everybody!!! i am a little noob because i only play flashpoint for 2 moths... i want ask you if you could tell me everystep to install the eurofighter. the readme file is very confuse to me because i am not very good understanding flashpoint. i think that i am not only the one looking for this help, and i think that this is a very good airplane (that`s why i want it ) hope you help me