Afterburner on su34

[EricM 0]

You mean the condensation trails at the tips of wings ?

[nuxil 2]

no i mean the fog that appares close to the fuselage.

if you look at this

look closly at the root of the wings,, you see what i mean

[lethal 0]

i thought about adding both the condensation trails and the "fog" that appears at high aoa. problem right now is determining a method of measuring the angle of attack of the airplane as there is no such function in arma by default (at least not to my knowledge).

i guess it'll have to be something along the line of firse getting the velocity vector and then the vector along the aircrafts nose... gonna think about that for a while. feel free to chime in if you have any ideas

[EricM 0]

No idea about how to code that, but maybe computing the difference between the velocity vector and the direction vector of the plane, and if it's over value X, it triggers the effect...

like

if ((velocity vector - direction vector)^2 >= X then exec script...

[lethal 0]

edit: nevermind - i think i have a solution

instead of doing complex calculation on the aoa i'm just gonna monitor the rate of direction change a *lot* easier if you ask me and it should do the same...

[lethal 0]

wingtip condensation trails are in:

activated by hard manuevering (ie. changing of direction - up and down, too, of course). thats the closest i could get to aoa but i think it works nicely

[ColonelSandersLite 0]

I just gotta say that this is an awesome bit of scripting there lethal.

Not my thing really, but it still looks nice.

[nuxil 2]

Thise nice effects should be standar in the next patch

[lethal 0]

next version ready:

- keystroke doesn't use global variable anymore so there's no problem with multiple ac's anymore

- new wingtip trail effect

- new fuselage vapor effect at high-speed-high-rate manouvering

and i've cleaned up the scripts a bit so there's less rendundant code and less unnecessary variables. might be mp-compatible but is untested.

download

[[aps]gnat 28]

Very Cool lethal!

How about a small change so we can use the same script on the AV8s? i.e. no afterburners

Just a comment, I think fuel usage could be reduced a little.

Thanks again.

[enti 0]

which folder do you put this script into to make it work???

[StryDa 0]

In your mission folder...

my documents\arma other profiles\profile\missions\missionname\

in there put the Su34 effects folder... Then in the int field (in game) of your aircraft (su34) put

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">this exec "su34effects\su34effects.sqf"

-StryDa-

[Vulture2k1 0]

- new fuselage vapor effect at high-speed-high-rate manouvering

Looks totally awesome.

[lethal 0]

as i keep being asked where to put those files i made a picture to clear that up:

you *can* put them elsewhere but you'd have to change the paths inside the "su34effects.sqf" file and, of course, the one in the init field

also i'm thinking of having the script search for any 34s in the mission so you won't have to put it into the init of every ac anymore.

as for adding the effects to the harrier - it souldn't be much of a problem. turning off the afterburner just takes commenting out one line inside the "su34effects.sqf" file. it's a little bit more work to adjust the position of the other particles but it's only changing a few coordinates, nothing more.

and please tell me what you think of the afterburner effect - that is pretty much my main concern right now. i think it looks really ugly at high speed and i'm thinking of disabling it altogether when a certain speed is reached unless i can find a solution to the stretching. I would appreciate any help on that subject

[StryDa 0]

The afterburner doesn't seem to work :S

[lethal 0]

what do you mean "doesn't seem to work"? is the effect not showing? is the scceleration not happening? both? does this happen always? sometimes?

hasn't happened to me yet, but any details you can give might be helpful in solving this

also try binding it to a different key:

in "afterburner.sqf" find these two lines:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">finddisplay(46) displayseteventhandler ["Keydown","if ((_this select 1) == 16) then {(vehicle player) setVariable [""_on"",true]}"];

finddisplay(46) displayseteventhandler ["Keyup","if ((_this select 1) == 16) then {(vehicle player) setVariable [""_on"",false]}"];

and change the keycode 16 to a key you'd like.

look here for valid keycodes. what kind of keyboard are you using? maybe there's some kind of incompatibility there...

to find out the keycode of certain key on your keyboard for sure you can also try this little script on the playerunit:

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

finddisplay(46) displayseteventhandler ["Keyup","hint format[""code: %1"",_this select 1]"];

finddisplay(46) displayseteventhandler ["KeyDown","hint format[""code: %1"",_this select 1]"];

doesn't work in the init line for some reason so you'll have to make a small script and exec it. it gives you a hint with the keycode everytime you press a key.

[TiGGa 0]

The effect won't work well in MP as the drop command has a local effect. Only the one, who is running the script will see the effects.

[lethal 0]

The effect won't work well in MP as the drop command has a local effect. Only the one, who is running the script will see the effects.

if it won't work in mp, it's not because of that as i'm not using the drop effect - instead the script creates "particlesources" with the createvehicle command which is not local. besides, this method has already been tested and found to be working in the signal.sqf script

[lethal 0]

please ignore - double post

[EricM 0]

Very Well done Lethal.

You should send this to BIS so that they include such thing in the next patch...

[TiGGa 0]

In that case: Good job! )))

[ColonelSandersLite 0]

With the afterburners looking bad at speed, I believe I have a solution for you.

Set the particle's initial velocity to the veloctiy of the vehicle+whatever velocity changes you're tacking onto it for the effect itself.

It's stretching because the particles can't keep up. It should clear up your problem at low speeds too.

[lethal 0]

With the afterburners looking bad at speed, I believe I have a solution for you.

Set the particle's initial velocity to the veloctiy of the vehicle+whatever velocity changes you're tacking onto it for the effect itself.

It's stretching because the particles can't keep up. It should clear up your problem at low speeds too.

i wish that was the solution

i have already done that to prevent the initial stretching that occurs right from the start... additionally i have modified the particles lifetimes to decrease with increased speed and tried ways to fade out particles sooner as speed increases. all that doesn't prevent the kind of stretching one can see when at high speed - my impression is that the actual point of origin of the particles doesn't get updated quickly enough meaning particles get "spawned" already well behind the point they are supposed to appear. this is not related to the position of the actual particlesouce object - it doesn't make any difference at which rate its position gets updated as long as it stays within "range"...

here's the code for updating the initial velocity of the particles btw:

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

exhaustvector =

[

(velocity _this select 0) - ((vectordir _this) select 0)*30,

(velocity _this select 1) - ((vectordir _this) select 1)*30,

(velocity _this select 2) - ((vectordir _this) select 2)*30

]

as you can see it does exactly what you describe (plus it also works for a non-moving vehicle).

oh, and i've also tried modifying the initial velocity (-30*direction+velocity) to be something like this to no avail:

(1/speed)*(-30*direction)+velocity

that way the trail should even become shorter with increased speed in theory - only it didn't

edit: all that is with the "rubbing" parameter set to 0, of course, so that the velocity of the wind rushing by doesn't affect the particles...

edit2: argh - I shouldn't be posting when half asleep - i hope the examples are now correct

[mandoble 1]

Lethal, you are using vectorDir there, but what you need is vectorUp mainly. If you use vectorDir your exhausts will point to the opposite direction of current movement direction of the plane, not to the opposite of current heading of the plane.

For example, if your Su34 stalls, if will fall down even while pointing up. If you use dirvector, you will have weird drops going straight up while the plane stalls nose up (your dir vector would be [0,0,-1]).

[lethal 0]

Lethal, you are using vectorDir there, but what you need is vectorUp mainly. If you use vectorDir your exhausts will point to the opposite direction of current movement direction of the plane, not to the opposite of current heading of the plane.

For example, if your Su34 stalls, if will fall down even while pointing up. If you use dirvector, you will have weird drops going straight up while the plane stalls nose up (your dir vector would be [0,0,-1]).

so vectordir describes the direction of movement? i was under the impression that it says where you were pointing your nose at (come to think of it, how come the AB works fine when standing still then?)

i only used velocity for direction of movement...

and where exactly does vectorup point? i assumed it meant a position straight above and was used for tilted positions?

edit: just tested this and the AB's direction is just fine even when stalling, flying backwards, sideways or standing still.