Footmunch

We're talking about AA missiles here, of course. I haven't got time to chase a Flanker around with a cannon. Makes sense but it's kind of buggy, preventing an Event Handler from reporting things correctly. Any way to improve on these proximity scripts without detracting from the accuracy of the "killed" event handler? Nothing good's occurring at the moment, sadly. Best guess would be to infer the kill by 'triggering' when the missile dies - if the target plane dies within a few tenths of a second (maybe with a distance check as well), then you can give the player the points.

It could also be a consequence of the proximity detonation scripting. In that case, a large 'target' box is created in the path of the missile: the missile hits it and explodes, hopefully catching the OPFOR plane in the blast. In that case, the firing-plane only 'kills' the proximity target, rather than the 'dead' plane itself. Does it happen when a particular weapon is used? If it's guns only (via removeweapon), there _shouldn't_ be a problem. I'm not sure if the SFM Flanker uses proximity detonation, but both the F-16 and Su-27 from me do.

It _could_ be a 'timing' issue. The init scripts on 3rd party planes usually take a few 'beats' to run, unlike the BIS planes. Maybe insert a half-second delay after creation before addeventhandler (or check on alive _plane)?

G8/Crippler Tornado : ftp://www.gamezone.cz:8021/ofpd/unofaddons2/RAF_Tornado_GR4.rar

FW - Was it the 'cockpit-starter-kit'?

I'll check on the Nimitz. It was working fine on the Hermes Â

PM now 'open' again. Apologies for any 'bounced' messages. New Tomcat Beta (same link as previously): http://www.footmunch.org.uk/beta/rkttomcat.zip Most of the changes requested are in: Now works properly on Aircraft Carriers. Slight reduction in AB power. Larger initial field of view. Long range air-radar. Flight model 'tweaked' slightly. Still to do: 14D cockpit Ejection scripting.

The other possibility is to adjust the turret so that the gun can't be depressed so far that you can 'self-shoot'.

My fault. Fixed in new version.

jpgz plz

By the way could it be that the afterburner accelerates too fast? Is that attached to the GearEH? I'll give it a try. There's an 'acceleration' parameter in the burner script. I'll adjust where necessary.

(Great minds think alike ) Yep - you could either: a) Have the 'motor-pods' spin around as well (ie include them in the vrtule selection, but not in the staticka or blur). You could probably 'hide' this by having a 'perfect' cylindrical texture, so that visually they don't appear to spin. or b) Tilt them via a script that senses the speed - sync _would_ be hard, agreed.

They are the same basic airframe, but the nose is 'bent' downwards on the -27 in order to give a better view of the targets on the ground. There is also a lot of 'ground radar' avionics carried. The -27's tail is larger to give better directional stability in the 'thicker' air at low altitude. IIRC the -27 has better pilot armour as well, especially against small (rifle) calibre bullets.

Avon's right, there's a missing }; or two in there. CfgSounds (and CfgRadio) should be _outside_ CfgVehicles. They are separate sections, like CfgModels.

The rotating plane wheels are done like this: You have 'turning' wheels in the 'gear-down' position. These animate to look as though they are 'rolling'. You have _separate_ 'folding' wheels which move up and down into the plane. When you fire the gear-up or gear-down command, you setobjecttexture to hide one set, and 'reveal' the other set. So, there's only one anim per selection. As a test, try this: http://www.footmunch.org.uk/temp/rkt_osp.zip This is in West->Air->Osprey Test, and is a 'kludge' applied to the BIS Chinook. The main and tail rotor blades tilt forward to around 45 degrees. It should be quite easy for someone to take the selections in the Chinnie, and apply them to the props on an Osprey model. Not perfect, but it uses the 'built-in' stuff, so there's no scripting overhead. Also, as it's based on a heli, there's no need for VTOL scripting. Sole - Sorry about the hi-jack.

ACES? Â Don't worry, I'm _all_ over ACES Â As a compromise, how about I add some 'groups'? What about a two plane Tomcat flight (with four crew altogether)?

Eversham - It's built into the OFP engine. Try the BIS A-10 if you don't believe me Â

Eversham - It's alright, I'll upload a version with carrier- capable gear soon. In order to do it, you have to: 1) Set gearRetracting = 0 2) Increase maxSpeed to compensate for the extra drag 3) Add UserActions for gear up and down dependent on speed and current state. 4) Add scripts so that the AI retracts the gear automatically (it thinks there isn't gear to retract anymore). 5) Make sure that the 'Landing Autopilot' lowers the gear as well. If you've got another way of doing it, I'd be interested...

You could, but the texture swap in-out is limited by the number of textures you're willing to generate (and overall pbo size). Even if you do 50 textures, that's still a 120/50 = 2.4 degree jump between them. It may look a bit 'jumpy' on such a big texture. Plus, you have to 'swap' in a 'stationary' prop for when it's at rest. Do-able, but maybe a bit 'long-winded'? There is the main-rotor-tilt on the helis as well. Not sure what would happen if you set this to 1.57...

Curses. Foiled again. I tried some 'throttle-sensing' things like that with drop[] and POSX, but they came to nothing. Need to kick-start the brain again.

first off scripting an automatic pilot in the back would be cake.... and if hte mission maker wanted both seats empty he could simple put in an empty F14. note Col Klink Inc's PT boats... you want a fully maned boat.. u put one in.. u want all the guns empty u put in an empty boat. all guns are maned automaticly by script and if u want it empty then the guns are placed but the peole are not... so you could place the plane with or without the RIO... plus with simple editor commands you could edit the script to function base don the editor command IE: rio = 0  in the F14's init line in the editor  Well, Klink's boats are a _bit_ different. If I auto-add a RIO, should he be the same rank/skill as the pilot? Personally, I find that a RIO who out-ranks the pilot is a good idea, as you then 'control' the AI pilot. That's the built-in gear behaviour. The BIS A-10 does exactly the same thing. Sorry, my bad. When I said the _released_ Tomcat, I meant the one _after_ the beta links posted here. It needs a bit of model fiddling, and scripting that I didn't put into the beta's here. The 'stowage' folding is being put in. It'll be activated either at low speed, or switch with the engine on/off state.

Ferret - The problem is that the prop-axis can't be made to tilt forwards and backwards if it's in the main model - you can't 'animate' the axis points of a 'different' animation. Just tossing an idea into the ring - you could model the engines and propellers as a 'class thing', with a script that spins the props at a given speed. Then, in the main model, these 'engine blocks' could be added to the main model as 'cargo' proxies. The proxies can be made to rotate forward and backward, and the 'spin' of the engine blocks should follow, I think. It'll need some fancy scripting to maintain the engine blocks when people are getting in and out, but not impossible, I would think.

RIO/Gunner/Cargo - I've thought this over _many_ times. The best reason I can give for the current way of doing things is to repeat what AgentFox said - without a true radar in the back seat, the situational awareness for the gunner just from the visuals is very poor, what with the pilot and his seat right in front of you. I could add gunner 'optics', but they only really work in the case of a 'bombardier'. In cases where the gunner is in the front seat, eg Kegety's Hawk, then it's a good idea to have a gunner. It _is_ a pain to have to add a second pilot as cargo, and I could script an automatic RIO, but that could conflict with mission makers. Hawkeye - No plans for a 'Bunny' 14A, at least not in the initial release. Seal84 - Thanks for those. Pappy - The gear in the released Tomcat will work in the same way as the A-6. Cleo - That's odd. I'll check the addon - I may have added the wrong sound.

Niiiiiiiiiiiice. Wouldn't have thought of that in a thousand years.

You could try: rotorBig="SEF_CH53\vrt_ch53_bl"; rotorBigBlend="SEF_CH53\vrt_ch53_bl"; rotorSmall="SEF_CH53\vrt_ch53_sbl"; rotorSmallBlend="SEF_CH53\vrt_ch53_sbl"; (if that's where the textures are). Note _no_ leading "\" - that's the same syntax as the CfgTextureToMaterial section. If that doesn't work, try it _with_ a leading "\" - Â Also, try a CfgModels like this: class CfgModels { Â Â Â class Helicopter{}; Â Â Â class CH53E_Green: Helicopter{}; };