Moa

There is lag in the Fly By Wire Systems of all aircraft fitted with them. You issue a command and some time later (after processing) the flight control system actuates the control surfaces. For an F-16 this figure is 4.95 ms (stabiliator) to 0.136 ms (flaps) according to the NASA technical report I'm using for my simulator (which I hope to adapt to the SuperHornet too). This lag bites pilots transitioning to the F-16, especially on take-off where they overcommand pitch up due to the slight delay between giving the command and the FLCS implementing it. Where this matters is that the longer the time to build up from unloaded to loaded condition generally the longer a pilot can maintain Gs. That's why pilots are trained to progressively apply G rather than jerking the stick to max loading.

IIRC, the F/A-18 is limited to 7.5 G maneuvering by its Flight Control system. Hence, the name of that freeware F/A-18 simulator is "seven-g". The F-16 pilots are trained at 9 G. Do you know what the loading was that the Hornet pilot was subjected too? The centrifuge can apply G in a much more controlled manner than yanking on the stick (although there is lag in the Fly By Wire System). Plus, any inverted acceleration gets an additional 1 G, plus the effects of turbulence on the body. So it is unknown which is worse.

Ok, let's have a look at selected samples on YouTube: * Here's a USAF F-16 Major who does passes at 7G, then 8G then passes out * Young fit pilot does G-Loc after a few seconds at 9G: * This exceptional female does 15secs at 9G: So, I think it is fair to say that G-Loc happens fairly quickly for these people and after a much shorter time that than what happens in LockOn FC2. For the way most of us fly in-game, at high speed and do instantaneous pulls to 9G (rather than gradually increasing the loading as they try to do in real-life), it is suprising that the game does not simulated the onset of G-Loc earlier (although the recovery time in-game can be quite long; these guys recover quite quickly; although there are cases where it can take a long time such as Israeli astronaut Ilon Ramon's son Assaf Ramon who died from maneuvering an F-16A in 2009 http://news.bbc.co.uk/2/hi/8253465.stm ). I think GGTharos has a better appreciation of G-Loc than perhaps you do, Maverick22. He does get to talk to a fair number of real USAF fighter pilots. The YouTube videos back up the FC2 experience; if anything, onset should be earlier and recovery could be earlier - but it is not too unrealistic at the moment (especially as it models cumulative fatigue from earlier maneuvering). This is one thing that makes modern fighter combat so hard.

I have the same problem. Do I need the old versions, well yes, because I want to integrate Ka-50 with FC2 (in my case, the VNAO mod only works with FC2). I believe there are som registry hacks you can try and then re-install BlackShark 1 (BS1). I hope it doesn't turn out that installing DCS World screws up BS1. Will look around the forums to see if anyone solved this ... Edit: found this http://en.wiki.eagle.ru/wiki/Troubleshooting:starforce:5.x#Asks_for_activation_on_each_launch Edit2: Worked for me, although it used up an activation :(

I have had some grey-out on the periphery of my vision doing a loop at four and a quarter g, as a young, fit 20 year old guy. No G-suit. Th G limit at which you are still combat effective is usually below the G limit at which you can still be conscious. This is probably the reason for the 4G limit recommendation for average pilots. A 9 G turn can only be held for a few seconds. IIRC F-16 pilots have to be conscious for 10 seconds at 9G in a centrifuge as part of their selection/training. Many pilots used to maneuvering still pass out. In an aircraft you notice even 2 G. You can function at 4 but it starts gettin' tough, and there are time limits. At 9 G only the fittest people with G suit can handle it. And then some muppet comes on here and says they routinely do 14 G in their aerobatic aircraft (I'm not counting the occasional millisecond transients, but your G meter won' show these). Lol, it is clear they haven't even done 2 or 3 G - or they would know how ridiculous that is. To reinforce this, take a look at the videos of young guys that pay for rides in Sukhois or MiG. They are struggling to concentrate even at lower Gs (although their screaming like little girls seems to be on autopilot). At higher Gs they do pass out, fortunately the pilot is conditioned for this during the few seconds it takes for an aerobatic maneuver. GGTharos is entirely right when talking about thinking in terms of average pilots. For example, the exceptional eyesight of Chuck Yeager and other aces was nearly twice that of the average pilot, IIRC. In a sim you have to go by the average values or it is not realistic. Even better than thinking about averages is getting technical and thinking about 'distributions'. For a normal shaped distribution the 'expectation value' is the mean or average. You can get different distibutions, bimodal under certain circumstances. Thinking in terms of distributions helps when considering a lot of pilot variables: fitness, eyesight, skill etc. For example, the distribution of pilot flight hours for the USAF is higher than Ethiopian air force for example. So on average you would expect a USAF pilot to beat his Eithopian counter-part most of the time (since combat skill is strongly correlated with flight hours). Now, because it is a distribution it may turn out that you have an Ethiopian of 'ace' quality vs a USAF nugget and the Ethiopian would probably win. That's all good. The *big problem* comes when you take that latter example from different parts of the ability spectrum and assume this is the 'expectation value' or average. That is why is is a mistake to say: * because you once read about a pilot doing 9 G for 20 seconds that all pilots can do it. * because you read that Aircraft A once beat Aircraft B is a dogfight that this would mean Aircraft A would usually beat Aircraft B. Applies to Eurofighter beat F-22 in a match, Indian pilots vs USAF in Red Flag etc. These 'upsets' can happen, due to exceptionally skilled pilots, but it is not the statistical expectation value (for an average pilot) * because Chuck Yeager used to spot Messerscmitts at 20 miles you should be able to see the MiG-29 at the same range * etc I hope that helps some readers put things in perspective - in the way that strange things can happen in aviation, but when you start thinking in terms of where does this even fit on a likelihood distribution then you can better judge whether what you heard/read is likely to happen often, or is a less likely event. So, thinking in terms of distributions, most pilots can function around 4G for useful time periods. Hence, as JimMack points out, 4G is what the manual says. Some pilots can do more (fit and feelin well), some can do less (less fit, and/or feeling exhausted/sick/hungover!). Make sense?

Nice find. I might even fly 'across the Ditch' to participate in this one :)

Very interesting post effte. My understanding that the principal advantage of the F-86 against the MiG-15 was the former had power controls and the latter did not. That meant that if the MiG-15 did not beat you within the first turn or two then the MiG-15's slightly superior performance would drop as the pilot became fatigued and then the F-86 could capitalize on this. So there are ups and downs to powered controls.

Very nice graphics EtherealN. I guess the Postgresql database (IMHO the best of the lot) is under "Other"? Also, people may not known that "Android" is actually the marketing term for a customized version of Java running on Linux (which might make give Linux proponents warm fuzzies). Back on topic: MeshLab is a handy free tool for creating different levels of detail for a model: http://meshlab.sourceforge.net/

Thanks EtherealN. I was making a comment on the *external* part of the flight model. Indeed, you can provide coefficients for the SFM (and are still bound by the limits of the SFM). However there was a question about JSBSim integration and there is (AFAIK) currently no method for integrating this with DCS/FC2 (I looked at doing this myself at one point).

I don't believe such comments are accurate. Consider all the Open Source projects that succeed even without funds (a large proportion all of the Internet/Web/email/Google infrastructure is run on Open Source, but this is invisible to most users). Then consider how much has been done by unpaid modders in FC1 and FC2. Flight simulation is indeed a niche compared to the blockbuster first-person-shooter titles. That means that giants like EA or Microsoft cannot support their heavy infrastructure (big offices and layers and layers of management) with flight sim products. However the smaller and nimbler Eagle Dynamics seems to be thriving with flight simulation and they probably are sufficiently profitable to keep going (even if not in the same scale as EA or Microsoft). So please don't mistake the flight simulation niche as unprofitable or at risk of evaporating. For small capital outlays there can be modest profits in developing extensions to flight simulators (read the introduction to the VRS SuperBug where they provide a perspective on this). For those that develop good add-ons to DCS they will probably get sufficient returns to make it worthwhile (and the funny thing is, they will be more profitable than giants like Sony who make billions in losses, although revenues are obviously smaller - but that makes even this niche a better use of capital than the capital in Sony's consumer electronics!). Finally, I think it is a statement to the incredible success and innovation of the DCS products that the community here is worried that the high standard will be maintained. As much as it must be a pain for the moderators to read, you guys should take it as a pat on the back for both the product and the community you have built and maintain.

> LoEnableExternalFlightModel() function listed in the export.lua This is disabled, is it not? my understanding was that external flight models were going to be allowed but it had to be disabled because of the possibility of cheaters exploiting this. I could well be wrong and it has been enabled all along (which might explain some Mach 25 aircraft we've seen on servers, although that could unchecked engine thrust values too).

JBSim would be better than the SFM. With the SFM things like stalls are scripted. That means you can stall an F-15 at 20,000 feet , the script kicks in, and you descend with a nose-high attitude until surface impact. No pilot initiated action can recover from certain script conditions. This is because the aircraft doesn't appear to be modelled as a distribution of masses (so no nose drop) nor do the wings have multiple elements (where you could stall the outer wing but not the inner wing). So this can result in some very odd behaviour. Of course the Ka-50 an A-10C have vastly better models than this, and the Su-25T 'AFM' is good, but all other aircraft have this scripted SFM behaiour. JSBSim does allow you to define an aircraft in far more detail than the SFM, so you should get more realistic behaviour provide you do the work to make a good model. That said, there are no publicly known integration points to use an external flight model with DCS. Perhaps one is available to licensed DCS developers but it is not *publicly* available. From the posts on these forums integration with ED products is so new it is likely that the integration API is still being designed. Note there are better (as in, more realistic) flight models out there than JSBSim (and almost certainly on par with the A-10C FM), but you need to be good at both physics/aerodynamics and software development (C/FORTRAN/Java/MATLAB) to understand them properly (both the theory and the specifics of the implementation).

The Turbosquid rights allow you to redistribute provided you do so in a proprietary format (eg. putting into ED's undocumented EDM format is sufficient). @WRAITH: you wanted an F-16C Block 52? This is also from Turbosquid also rendered by the (cross-platform OpenGL!) engine I'm hacking on: Turbosquid has great stuff!

The picture on their facebook page is this model: http://www.turbosquid.com/3d-models/3d-super-hornet-fighter-tomcatters-model/655908 I used the same model to do this (early, work-in-progress) rendering of the same aircraft (for the cross-platform, indepdent simulator I'm working on): So I hope they do get around to do more than copy the rendering from the Turbosquid page. off-topic: if anyone else is interested I've also rendered an F-16C Block 52 an F-14D. Look for them in YouTube close to the YouTube link I gave. Please do not post any comments about them in this thread (try to stay on-topic, please).

Yeah, not exactly precision bombing, is it? someone on these forums pointed out that bombing across (diagonal to) the runway increases the chance of getting a hit. This is true but kinda the tactics you'd expect from the 70s were you had a lot of unguided munitions. I doubt the USAF or much of NATO would have used that pattern in 2008 - they have much bigger inventories of precision guided munitions (but not by much, the Libyan operations depleting the PGMs of many airforces to low levels - forcing them to order new stock from their suppliers).

The best way to tell a release is about to happen is that the forums are inaccessable for a day or two before the release (probably while they get re-organized in preparation for the release). That's the indicator I now use as it as happened every time since the FC2 release.

Hi Yoda. Good to see you are alive and well and modding. I think what Speed was trying to point out was that in DCS the different scripts (called "environments") are prevented from accessing each other's data - apart from some massively inconvenient tricks. Your data bus is an excellent idea. Mucking around in Lua is a complete pain and the lack of decent messages makes it very unproductive. Something all the eager beavers porting their aircraft to DCS:World will soon learn (although no doubt many projects will succeed through sheer force of will). I do have a moving map control for FC2 that would be an ideal candidate for using this bus. It uses Igormk's excellent TC-1 map. The map control works fine for FC2 but I'm trying not to mod for ED products anymore (the unproductiveness of Lua makes me grit my teeth and the recent firewalling of "environments" drives me batty), so I don't know whether it'll still work for DCS. I have been intending to put the map source code up (Java and Lua, of course) for use. This might be a good candidate for testing your data bus. Personally I prefer XML to JSON, since Java handles XML in the standard library (JAXB is awesome once you get your head around it) and for small messages the size is the same on the wire (since a single TCP packet could be involved in both cases, thanks to Minimum Transfer Unit sizing). The inefficiency of XML would not be apparent for small messages, although testing would be required to see whether the processing time for large messages would be significant or not (often, just by caching the XML marshaller and unmarshaller you can speed XML up enormously).

Thanks you very much rockwelder. I stumbled across XFrog myself just the other night (after posting). Besides the lovely foliage your collision work is very interesting. Please keep up the great work!

No, I have about 30 mins of time in DCS World. If the stutters are not hardware related then it could be thread locking or starvation if DCS World is using more threads. Good luck to the ED team to sort it out (I'm sure they will).

Hi chromium. Is this for FC2 or, more likely, DCS? Do you need the results in real-time, or only at the end of the mission? If you need them only at the end of the mission then the debrief log could be converted into XML and I think Access/Excel can import that. I have a LUA-table (which the debrief log is) to XML converter that I wrote (and abandoned because I started working on my own simulator, see for early work). I can make a little stand-alone tool that you can run to convert the debrief.log into XML. Then you can drag it into Access. Note that the default debrief log doesn't really contain enough information to determine who did what to whom. I have some customized LUA scripts to do that, but changes restricting LUA information have broken them somewhat (fixed by Speed for DCS:A-10C, but will likely be re-broken for DCS:World). Unfortunately I dislike LUA so can give you the scripts but you'll probably have to find some LUA expert on these forums to tweak them for you (with my own sim I have no time nor inclination to work with lame LUA). That's the best I can do for you amico. If I don't send the stuff through for you this weekend then please re-PM me to remind me. Stuff does fall off my list from time to time. Good luck with your project. ps. love the AMVI logo and your pilot patch!

Great to hear you'll finally be getting an upgrade Cali - it's about time :) I recently switched from buying Gigabyte boards to an Asus board. The Asus is noticeably superior enough I won't be going back. The BIOS is much better and friendlier for overclocking, and coupled with a few reset buttons on the Asus board to help out if you get a setting wrong (like accidentally disabling the USB ports, doop!) then I'd say the Asus is the clear winner. A 2500k is also a good choice. There isn't much point at getting anything more expensive at this stage. Do try and get as fast RAM as you can, between 1600 MHz and 2133 MHz seems to be a good price point. I wouldn't get less than 8 GB these days - especially as you'll want to run a 64-bit operating system. Don't buy a video card with less than 2 GB Video RAM (VRAM) on it. If doesn't matter how fast the rest of your system is, if you video card starts swapping excessively between RAM and VRAM then you will notice it. All that VRAM is needed if you crank texture quality, anti-aliasing, anisotropic filtering, high dynamic range (HDR) rendering, or Screen Space Ambient Occlusion (SSAO) up. You're gonna love these sims with your new rig.

Very cool and very interesting. Rep inbound.

In-game stuttering is usually caused by either: * swapping between main memory and virtual memory on disk. As Mustang correctly points out, if you have enough RAM you should consider disabling your page file when gaming to prevent this. * loading items from hard disk. Having more RAM reduces this as items remain in game memory or in RAM disk-cache. * you could be experiencing 'thrashing' as items are copied along your computer's bus between main RAM and Video RAM (VRAM). If you have a high settings of anti-aliasing, an-isotropic filtering, or texture quality you can have problems with this. OF course, check that anti-aliasing and an-isotropic filtering are set to "application controlled" in the graphics driver control panel (eg. by NVidia controller or AMD Catalyst Control Panel) and only adjust these settings in the applications themselves. The system of seeing stutters after 15 mins is typical when you run out of VRAM. The free program GPUZ will let you monitor your VRAM usage in real time. Have a look and see whether your settings commit more VRAM than you actually have. * there is a possibility of a problem with the games. However, since the games are smooth for most people this is less likely. It is far more likely that your current settings have you running out of RAM or VRAM resulting in swapping of data between parts of your system. Adjusting your settings is likely to be the cure for you.

That scenery looks excellent rockwelder. Did you create the trees yourself? use a tool (eg. SpeedTree)? or is there a library out there with tree textures? I'm curious since I'm looking at generating tree textures myself.

Yes, disbanded (disclaimer, I'm an ex 169th Panther from 2008). Many ex-Panthers are now in the 104th Phoenix squadron ("Phoenix, re-born from the ashes", get it :))