RedBeard2

Never mind. I forgot about using scaling to change the size of the box.

Ok, here's my latest set of unknowns that I'm looking for answers to: What is Mzalfa and Mzalfadt? They are described as coefficients for pitch agility, but that isn't making any sense to me. Pitch is going to be based on a sum of moments about the center of gravity such as wing lift and tail plane down force and you would need to know the distance of each from the CG. There's not much in the way of variability for these either. For Mzalfa, 33 aircraft use 4.355, 2 used 6, and 26 use 6.6. Mzalfadt is similar in that 33 aircraft use 0.8 and 29 use a value of 1. Also, the sign and magnitude look wrong to be coefficients as most aerodynamic coefficients are negative and rarely are they greater than 1. What is kjx and kjz? Kjz appears to be a constant of 0.00125 as it never varies for any of the aircraft. I can't figure what kjx means. Czbe appears to be the coefficient for directional (yaw) stability (C sub n sub beta), but I can't figure out how the side slip angle beta is determined unless it is hard coded to the rudder pedal controller value. In this case, 23 planes use a value of -0.012 and 39 use a value of -0.016. I'd appreciate any help in understanding how these parameters are used.

The bones method seems to work reasonably well once I figured out how to position everything. However, the bounding box remains a bit of a mystery to me. I can create a dummy object with TYPE = "bounding_box"; but it is completely square, with quite a bit of open space above and below the aircraft. I tried using a regular box to get a closer fit to the aircraft, but the exporter didn't like that. Is there something else I should try?

I searched the forums for techniques for engine nozzle animation and I've seen some people are animating each individual vane and others have tried to using scaling, but didn't get it to work. I'm seeing similar issues and wondering if there's a good and simple way to do this. Does anyone want to describe their favorite technique?

I just checked all the links and they work for me. Can you point out any specific ones?

I'm working on the lights for the aircraft mod guide and I've run into an odd problem. I've been adding lights using a TGA texture with an alpha channel, creating a plane and applying the texture to the plane. For 3DS max material, I use a standard material with the bitmap mapped to the diffuse and opacity channels. I set the material to fake_omni_lights and the Opacity to Blend. There are two problems I can see with this. 1) Lights are showing through solid objects 2) I use visibility animation to turn the light bloom planes on/off, but it looks like they are being kept at the origin and translated into place when the visibility argument goes to 1.0. I would rather have seen a gradual visibility. Here is the current end result: There are four lights on the back of the fuselage (two left, two right) and the red / green position lights in front of the wing root are all visible, even if they are on the far side. Am I doing something wrong to cause this? http://forums.eagle.ru/<a href=http://s1344.photobucket.com/user/jknutson21/media/Posted%20Screenshots/visible_hidden_lights_zpsf93f8a4b.jpg.html target=_blank>

I'm not sure exactly. Do you have Adobe Acrobat Reader installed? Also, it looks like you are using Google Chrome. Have you tried IE or Firefox?

I should probably point out, before someone notices, that although the stage 4 zip write up says the SFM has been tuned, it has not. I need more answers to questions in that regard before I can claim it has been tuned.

I've tried to make it as simple as possible, but adding aircraft does require a certain amount of knowledge and experience. Note that I started with no DCS or modeling experience at all (though I have 20+ years of programming experience). At a minimum, you need skills in algebra and geometry and some ability to understand conversion from one unit scale to another. Knowledge of calculus is an advantage, but I've tried to isolate that as much as possible. The above will get you far enough to add an AI flown aircraft using the SFM and possibly a human flown aircraft with some existing cockpit (e.g. Su-25T). Adding your own cockpit or using the External Flight Model instead of the SFM will require programming experience.

After going through the forums many times, fiddling with the Wunderluft sample, and trying to figure out how to go about adding a human flyable aircraft Mod, I have finally broken down and started to collect all the information I've had to learn into one spot. This is an on-going work in progress as I still have outstanding questions that are yet to be answered. I plan to continue to update this as more information becomes available. So far, it is over 70 pages of collected information and references and I have included 3DS Max models to illustrate the steps as well. The guide and samples may be viewed and/or downloaded here: Beginners Guide to DCS World Aircraft Mods 0.5.1 Beginners Guide samples zip 0.5.1

Ok, I went back through my aerodynamics text books and while K' and K'' are calculated as above for subsonic flows, there is a different calculation for K for supersonic flows, so I'm going to have to rethink a little bit about K being a constant, but I still cannot figure how Cy^4*B4 is equivalent to (CLa-CLmin)^2*K''.

How right you are! I'm not sure why Canopy controls were not affected, but there is something about using the default Su-25 cockpit that allows all the control surfaces and chaff/flare to start working.

Interesting. The .doc file has more arguments than those listed the zip file, but thank you both for posting. Rudel, is there a thread that keeps the .doc file up to date?

I believe the arguments are set correctly. For example, I have the left aileron argument based rotation animation using argument 12 with key frames at -100, 0, and 100. I can exercise the argument in 3DS and in the model viewer, but nothing visual happens in game. As far as the cockpit goes, at this point, I'm basically using the Wunderluft cockpit (with Radar creators/indicators commented out). Still, I don't see anything about the canopy control in the Wunderluft cockpit and it works. I can start adding cockpit systems and controls to see if that makes a difference, but it would be nice to get an explanation rather than random behavior differences.

Then what do B2 and B4 mean if they vary with Mach number and are not the K' and K'' constants?

I have my Wunderluft derivative working reasonably stable at this point on the latest 1.2.5.16508 update. Hmm, I see 1.2.5.16508.227 just came out, so I'll have to try that. Yep, .227 seems to be stable too.

I've noticed that with this patch, the scripts seem to be very sensitive to missing files. The Wunderluft sample does not include the model files, message file, and maybe some other things I'm forgetting. If you fix up the missing files, it should get a bit more stable.

I'm slowly working through transforming Wunderluft into another aircraft. I have an external model and have created the animations and arguments for the various draw arguments and I am able to exercise them in the model viewer. However, only some work in game. I can see the canopy open and close and I can see wheels rotating when I taxi, but I don't see the nose wheel strut turn, flaps go up/down, ailerons, elevators, or rudder move. What's the difference between these things that causes some to work and others to not? I have a similar issue with flares not showing, though I'm not sure if it's the same issue. Thanks for any help.

Sorry for raising this old thread again, but I'd like to clarify some things with the SFM. The SFM_Data[table_data] includes terms B and B4 by Mach, which appear to be used in the equation Cx = Cx_0 + Cy^2*B2 + Cy^4*B4. While this appears to be an equation for drag, I have yet to see any drag equation that uses a coefficient raised to the 4th power. My understanding is that CD (coefficient of drag) = CDmin (coefficient of drag for minimum lift) + CDi (coefficient of drag for induced drag) + CDv (coefficient of drag for viscous drag or drag due to skin friction). CDi = K'CLa(coefficient of lift per AoA)^2 and CDv = K''(CLa-CLmin)^2 where K' and K'' are constants based on wing efficiency, leading edge radius, and taper ratio. Note that none of the terms are raised to the 4th power and that K does not vary with Mach. So, what am I confusing in interpreting the drag formula and terms? Also, there seem to be two pitch coefficients, Mzalfa and Mzalfadt. The torque around the center of gravity will be based on lift from the wing, down force from the tail and offset thrust from the engine, though engine thrust torque doesn't vary by AoA. Pressure from the airstream hitting the engine air intakes and other parts of the body at higher AoA can also have an effect, though that may be overkill for the SFM. However, Mzalfa and MZalfadt are constants and do not vary by Mach, so I can't figure how these relate. Lastly, I cannot find any reference anywhere to kjx and kjz either in the LOMAC equations or in any flight dynamics equations. Can someone help educate me? Thanks

I've got a Draw Arguments.zip file that has version 1.1 of the aircraft and weapons draw arguments and version 1.2 of the vehicle draw arguments. However, I have searched several for the originating source of this and I can't find it any more. I thought it came from the wiki somewhere, but I couldn't find it there either. Does anyone have the originating location for this info? Thanks

I'm going through the effort to look at and understand the SFM to create a Mod and there are some things that are just mysterious and hard to interpret. I'm going to try to cover as many as I can here, but may have to split it into multiple postings to get answers to everything. First are the thrust values: thrust_sum_max = 8000, -- thrust in kg (44kN) thrust_sum_ab = 10000, -- thrust in kg (71kN) It's really unclear what the intended values are here since converting 44 kN to kgf should be 4487 kgf. Should I ignore the comment and just do the normal kN -> kgf conversion? Next is understanding range value: range = 2000, -- Max range in km (for AI) Is this a ferry range or a combat load range as these can vary dramatically? The M_nominal weight value is not a precise term. Is this weight including full internal fuel and pilot or is it supposed to include a typical combat load? M_empty = 8000, -- kg M_nominal = 10000, -- kg M_max = 12000, -- kg Some speed values are ambiguous as well: V_max_h = 800, -- Max speed at max altitude in m/s (for AI) Is that supposed to be CAS or TAS? I'd appreciate any help I can get. Thanks

Thanks! That's exactly what I was looking for.

Sorry to bump this, but it's somewhat dated and I haven't seen a resolution posted anywhere yet. Did this ever get resolved?

I've also noticed that the Wunderluft Cockpit model is reusing draw argument numbers with different purposes than the external model draw arguments. For example, the Cockpit/mainpanel_init.lua uses argument #1 for the Canopy position gauge, but the external model is using argument #1 for nose gear strut compression. Are these argument domains completely independent?

But I don't have nor do I want an empty Cockpit folder. I wanted to start experimenting with creating a 3D cockpit. What I don't understand is why crew_members settings is affecting the 3D cockpit or how the two are related.