Crescendo

Sorry, there's zero chance that the FC3 aircraft will all have AFM "in one year". You're grossly underestimating the time and effort it takes to physically simulate a complicated structure moving through the air at various thrust settings and angles of attack. And since when are DCS: F15C and DCS: Su-27SM confirmed as ED's next official projects? First I've heard of it.

OK, all good points. Thanks for the replies.:)

Regarding my thoughts about AIM-7 loft trajectory, I take your point that certain kinds of people will argue something to death because they "believe" it to be the case (you see that all the time on these forums). I am not one of those people; I can be perusaded otherwise by someone more knowledgable in the subject. ;) I do understand that programming efficient non-terminal trajectories and loft trajectories is very difficult, especially if you are trying to program them to be as efficient as possible in all circumstances. There are so many variables and situations to consider that you just have to feel bad for the person attempting the task. However, my thought was to implement some simple if-then logic that might get you, say, 75% of the way there with a really simple tweak, as opposed to coding a complete and highly complicated trajectory system that would cover 100% of situations. This would be sort of a 'good enough for now' stop-gap solution. For this reason I would like to question you saying that "there's no benefit for throwing a few if-then's just for the 120." I would point out that the AIM-120 already is special: it's currently the only missile with any loft at all (AFAIK), so obviously ED is enthusiastic about having AIM-120 lofting in the game right now and is willing to accept its current substandard performance. If AIM-120 lofting needs to be in the game, why not implement a simpler stop-gap logic tweak instead of waiting for the complete overhaul of the missile system? That, or remove the AIM-120 loft entirely until it meets ED's usual standards. Again, I don't purport to know anything about game design and the practicalities of making feature decisions and allotting time for coding etc. :blush:

OK, I didn't know that the weird AIM-120 lofting behaviour was a known issue that is actively being addressed. Thanks all. What about the AIM-7 and other SARH missiles? Surely they must loft in real life to some degree also?

I have two questions regarding NATO ait-to-air missiles in 1.2.2. First question: 1. Why does the AIM-120 have a 'loft' trajectory, while the AIM-7 does not? This significantly reduces the Rmax range of an AIM-7 compared to the Rmax range of an AIM-120. I have attached two Tacview recordings. "Recording 1" shows an AIM-7 launch at 25nm, and "Recording 2" shows an AIM-120 launch at 25nm. All other variables are essentially identical. Note how the AIM-7 falls well short of the target while the AIM-120 only barely misses — this is the energy difference between a non-lofted and lofted missile shot (discounting the kinemtatic range difference between the actual missiles themselves of course). I can't see any reason why the AIM-7 shouldn't have this lofting profile too. I understand that the AIM-120 is a more sophisticated missile with better software, but I find it difficult to believe that the AIM-7 doesn't at least attempt a similar sort of loft trajectory in real life. Perhaps ED has decided to simulate the advantages of the AIM-120 by giving it—and only it—access to a lofted trajectory, but I think this is a mistake because it disproportionally undermodels the AIM-7, and because the current lofting logic in-game is very rudimentary anyway. This brings me to my second question: 2. Why is the loft trajectory of the AIM-120 so inefficient? Specifically, why does the missile perform such a high-g pull down maneuvor (up to 22g according to Tacview) at the apex of the trajectory? This high-g maneuvor is inefficient and costs a signficant amount of energy — energy that could have been used to extend the range of an Rmax missile shot if it hadn't been 'spent' so wastefully. This inefficiency can easily be seen in "Recording 2". Regarding question 2, I don't pretend to understand the complexity of ED's missile code, but wouldn't this be a simple matter of g-limiting the AIM-120 to say 10g for a few seconds after it goes active? (I am assuming that the reason the AIM-120 pulls 22g at apex is because this is the point at which it goes active and starts intercepting the target. If this is the case, the apex of the loft trajectory is a direct result of the missile going active, not any real lofting logic at all.) Naturally this g-limiting idea would negatively affect AIM-120 missile shots near Rmin, because in that situation you need the missile to pull max-G immediately to intercept the target. However, couldn't this be solved by implementing some sort of simple logic condition such as 'if range to target is less than 13nm (or whatever) upon launch, the missile will not impose a 10g limit for x seconds upon going active'? To sum up: I think that the AIM-7 needs a loft trajectory, and that the lofting logic is flawed and needs to be improved (which I, perhaps naively, think should be easy to do). Tacview recordings.zip

WayC00lio and ralfidude are correct. The line that is in the centre of the HUD is a course steering director. If you follow the course steering director line eventually you will fly the aircraft back onto the correct course as dictated by the flightplan. This is easiest to see by creating a flightplan with multiple waypoints, and then looking at the horizontal situation indicator and course deviation indicator. If you follow the course steering director, eventually you will intercept each waypoint on the correct course of the flightplan. However, if you instead wish to fly directly to a waypoint (and not follow the flightplan), you can use the waypoint heading indictor on the heading tape at the top of the HUD. The waypoint heading indictor is the direct heading to the next waypoint from your present location. Think of it as the shortest and most direct route to the next waypoint without any 'fancy flying' to keep you on the flightplan. So, if you want to fly 'on course' using the flightplan, use the course steering director. But if you just want to get to the next waypoint ASAP, use the waypoint heading indictor. Note that when you're flying on course towards the next waypoint, the course steering director and the waypoint heading indicator will be aligned. However, when you've flown off the flightplan and have deviated from the correct course, they won't be. This is because the course steering director will want to get you back on course, while the waypoint heading indicator will want you to fly directly towards the waypoint (course be damned!). It's worth understanding the difference.

Yes, using the editor is the best option. The editor is a little daunting, but what you're trying to create is pretty simple. If you have Teamspeak or Mumble I can talk you through the process if you'd like.

Jokes aside, I think this is a legitimate question. If the VSD in TWS mode is displaying multiple discrete targets then you should be able to select them individually, even if they are in close formation. It can be frustrating using the cursor to select indivudual targets when the cursor is so large and indisciminate. I can't believe that there isn't a button you can press that cycles through each TWS contact on the VSD, thus allowing you to select and bug whichever contact you please. Surely the real F-15 radar must have a feature like this as it would demonstratively reduce the pilot's workload in close formation situations. Chalk it up to simplified FC3 avionics and higher priorities I suppose, but it would be nice if ED implemented a cycling feature. It should be a relatively simple task for a programmer.

JEFX, joey45 answered your question better than I could have. --- If anyone is interested, I made a curve that works for my HOTAS Warthog with the afterburner detent installed. In practice I'm not sure if this curve will work with everyone's individual throttles, but if Thrustmaster's quality control is decent it should come pretty close. Simply edit your curves (both left and right thrust) to reflect the settings below: This curve gives me military power at the afterburner detent and AB beyond it. It fits my HW throttle perfectly—hopefully it will work for others with no or minimum adjustment.

You're technically correct in that it wouldn't be strictly realistic, but no person in their right mind would ever set AB to 10,20,30,40% of axis travel because that would result in almost no ability to fine tune throttle position below the afterburner threshold. Setting your AB threshold so low would be pretty terrible for formation flying, aerial refueling, landing etc., pretty much situation where you require high resolution fine throttle adjustments. The threshold button would be a practical solution, not a strictly realistic one, although in effect it would be essentially as realistic as having an physical detent for the reasons outlined above.

OK, I guess I'll have to play with the curves. Thanks for the replies. Regarding the issue of multiple aircraft, ED could implement a "threshold" button in the controls section of each individual aircraft, which when pressed would designate whatever throttle percentage you have selected as the afterburner 'kick in' point. It would then be trivially easy to set your AB anywhere you want for any aircraft. Something for the wishlist I suppose.

Hi all, Is it possible to set the afterburner threshold in FC3? I have physically adjusted my HOTAS Warthog throttle unit to use the afterburner detent, and now I want to configure FC3 such that MIL power is at the detent and afterburner is above it. Can I do this without painfully fiddling around with the throttle curves? (I know in Falcon 4.0 there is an option to manually set where the afterburner 'kicks in.' I'm hoping FC has a similar setting, but if it does I can't seem to find it.) Thanks.

One of the problems here is that people have different definitions of what constitutes 'hardcore' in relation to combat flight simulators. Some people think that hardcore is mostly about the complexity of button pushing and systems operation, while others think that hardcore is actually using your aircraft to fight effectively in a dynamic combat environment. You might call these different positions 'switch flippers' and 'tacticians'. I am of the tactician viewpoint. This is because switch flipping is merely a pre-requisite hurdle to flying a combat aircraft, not the purpose in and of itself. As someone said above, fighter pilots don't boast about memorising which button does what, because learning the aircraft's systems by rote is one of the first and most basic steps in a pilot's training. The goal is to make switch flipping as transparent as possible so that the pilot may focus on the most important and difficult aspect of combat aviation: flying the aircraft in coordination with wingmen to complete the mission. Anything else is just a distraction, which is why aircraft designers try to make the instruments, avionics, and controls as simple as possible. In short: hardcore is not about flipping switches. Hardcore is how you train and fight, and how you employ your aircraft to keep yourself and your buddies alive to complete the mission. Frankly, anyone who places a disproportionate amount of importance on switch flipping is ultimately taking a very shallow view of what it means to be a fighter pilot. I accept that some people may derive their enjoyment from mastering switch flipping, but I politely suggest that such a person would perhaps be better served by a civillian flight simulator. If this is too harsh, said person should at least recalibrate their definition of what it means to be 'hardcore' by considering the context — this is a combat simulator after all. The implication of all this is simple: I guarantee that flying a 'basic' FC3 aircraft can be just as hardcore as any DCS aircraft. This will be proven time and time again in combat records when tactician-minded FC3 pilots face off against switch flipping DCS pilots. No doubt switch flippers will be resistant to this idea and will try to claim moral superiority by citing their switch flipping complexity, but as previously stated, this is a shallow and false complexity that completely misses the point.

Thanks, Eddie. That clears it up. Interesting how type is omitted from the A/A calls — I think I'll ignore that part.

Hi all, This is a simple question, but it's been bugging me for a while now. What is the technically correct word order for the brevity terms NAILS, MUD, and SPIKE when making a radio call? Is the brevity term supposed to come before or after the informative term? For example, is it this: LOBO 1, 29 NAILS, right 2 LOBO 1, 2 MUD, left 11 Or is it this: LOBO 1, NAILS 29, right 2 LOBO 1, MUD 2, left 11 I've generally always used the former method, but lately I've noticed that I've been saying the informative term first when making an air-to-air call (e.g. 29 NAILS), and saying it second when making an air-to-ground (e.g. MUD 2). I guess it just 'feels better' for me to say it that way. However, after considering the matter, I think the latter method is most appropriate because there is less chance for ambiguity. Still, I'm hoping that someone can clear this up definitively so that I can break some bad habits if necessary.

I decided to see which method it was, so I made a test mission and flew it three times. I fired one Vikhr during each flight. The first Vikhr was fired at maximum range, the second Vikhr at medium range, and the third Vikhr at close range. I recorded three variables: 'Shkval TTI', 'Laser Firing Duration' (measured with a stopwatch), and 'Actual TTI' (measured with a stopwatch). One strange behaviour that I noticed is that the Shkval display TTI 'recomputes' itself immediately upon firing a missile. For example, if I launch a Vikhr when the Shkval display TTI is X, the Shkval display TTI very rapidly increases and then rapidly decreases to a 'correct' TTI of X-Y. This rapid increase and subsequent correction takes place in the fraction of second, after which time the corrected TTI counts down as per normal. As a consequence, I decided to record a fourth variable: 'Corrected Shkval TTI' (this variable was noted by slowing down time during track playback). Here are the results: Flight 1 Shkval TTI: 17.9 Corrected Shkval TTI: 12.4 Laser Firing Duration: 24 Actual TTI: 12 Flight 2 Shkval TTI: 10.4 Corrected Shkval TTI: 7.3 Laser Firing Duration: 16 Actual TTI: 7 Flight 3 Shkval TTI: 6.1 Corrected Shkval TTI: 4.1 Laser Firing Duration: 12 Actual TTI: 4 --- Some conclusions: 1. 'Laser Firing Duration' is indeed Shkval TTI + 6s. Your first recollection was correct. 2. 'Corrected Shkval TTI' is 70% of 'Shkval TTI'. This 70% figure was consistent over all three tests (taking into account stopwatch error), so for some unkown reason, the Shkval TTI is artificially increased prior to launching a Vikhr. 3. 'Corrected Shkval TTI' is equal to 'Actual TTI'. Therefore, 'Corrected Shkval TTI', as calculated by the Shkval system after launch, is a pretty accurate approximation of actual time of flight. It seems to me that 'Corrected Shkval TTI' should replace 'Shkval TTI' in the 'Laser firing duration' calculation. 4. If 'Corrected Shkval TTI' was used in the 'Laser firing duration' calculation, the time savings in each of the three flights would be 6s, 3s, and 2s. Naturally there are diminishing returns at close range, but at long range the saving of 6s could make a big difference to the pilot. 5. The purpose of 'Shkval TTI' remains unclear. It's only effect seems to be to increase 'Laser Firing Duration'. If that's the intended purpose, then it doesn't make much sense for two reasons: firstly, 'Corrected Shkval TTI' is seemingly accurate enough to reliably shorten 'Laser Firing Duration' with no ill effect; and secondly, if the goal is to increase 'Laser Firing Duration', it would be more logical to simply increase the '+ 6s' variable to '+ 10s' (or whatever). Right now I can't think of any good reason for 'Shkval TTI' to exist, but that doesn't mean there isn't one. We really need that manual.

:thumbup:

Sure, I'm totally onboard with all this. Still, perhaps naively, I maintain that a ~12 second LA cue delay after the initial TTI is a excessive. Imagine the following scenario (I know you understand all this stuff, but humour me): A Vikhr is fired at maximum range and the ideal TTI is X seconds. However, some of the effects you mentioned occur and the missile flight is extended by 4 seconds. That brings the actual TTI to X+4 seconds. We know that the LA cue delay lasts for ~12 seconds after the ideal TTI, but the missile actually took an extra 4 seconds, so the amount of time 'wasted' by the LA cue delay is 8 seconds. So, it seems to me that the LA cue delay could be cut in half to a convservative 6 seconds, and it would still allow for a buffer of 2 seconds in the above scenario and satisfy the majority of launches. (All this according to my fictional numbers and requirements of course, but you get the idea. :P) OK, I can get onboard with this as well. It's plausible that the 12 second LA cue delay after a Vikhr impact is the 'optimum' amount of time for the laser to cool, such that it will operate at peak performance the next time it is used. Alternatively, if the pilot chooses he can still manually reset the laser to quickly fire a second Vikhr, but he knows that this is not 'optimum' procedure and the laser may heat up faster and eventually take longer to cool. My only issue with this is that I often fly multiple passes where I launch a second Vikhr by manually resetting the laser (sometimes even a third for laughs), but I have never noticed any overheating. That's not to say overheating doesn't exist when using Vikhrs, but I haven't seen it in the sim.

OK, I didn't know about the enlarged laser "grid" at launch that facilitates the 'capture' of the Vikhr (so to speak), and I didn't know that the grid transitions to a finer beam when impact is near. From a practical real-world perspective it totally makes sense. Thanks for the explanation. However, I still think that the laser resetting system is poorly designed. Taking your explanation into consideration, I don't understand why the LA cue needs to be delayed for such a long time. To explain, surely the fire control computer must have a rough idea of a Vikhr's time to impact from the moment of its launch, otherwise how else would the FCC calculate a DLZ? Moreover, how would it know when to focus the laser beam? I suppose it could just be a matter of focussing the laser at some arbitrary point after 'capturing' the Vikhr, but that still doesn't address how the DLZ could be used to obtain a reasonably accurate TTI. At present, the LA cue delay for a second Vikhr is pretty darn long, in the order of ~12 seconds after the impact of the first Vikhr. As I now understand, this delay is caused by the system waiting for the laser grid 'cycle' to finish guiding the first Vikhr, but once again, I find it hard to believe that the FCC can't compute a TTI to speed this process up. Even with a buffer in place, a TTI should allow the FCC to reset the laser much sooner than 12 seconds and authorise a speedier second launch. I mean come on you stupid laser, 12 seconds is the time it takes one Vikhr to impact when fired at max range! (Note: I am aware that the DLZ can be overidden to launch Vikhrs at longer ranges. I'm not considering that scenario. If a launch override occurs, the best way to address the laser issue would be to have it fire continuously until the pilot manually resets it.) I don't pretend to understand the complexities of all the variables that would make up a TTI calculation, but they are all bound by physics and thus are amenable to calculation. The aircraft's speed, it's altitude, slant range to target, the burn time of the rocket motor and the missile's aerodynamics, I would have thought these are all things that can be approximated and used to produce something with an error bar of less than 12 seconds. As I mentioned in a previous paragraph, if this can't be done, how else is the DLZ calculated? Is the DLZ's accuracy that coarse?

maturin, I completely understand where you're coming from because this phenomenon annoys the hell out of me as well. The following is a description of the issue. (To avoid confusion, please be aware that I am not talking about ripple firing multiple Vikhrs — I am describing a situation in which I engage two separate targets one after the other, firing one Vikhr at each.) 1. Turn on Shkval and lock target with tracking gate. 2. Select Vikhr and fly aircraft into launch authorised ("LA") parameters. 3. Turn on laser and launch Vikhr (or use auto-laser, whichever). 4. Vikhr rides laser beam and destroys target. So far so good! 5. Slew Shkval to second target and lock tracking gates. IMPORTANT: Note that the laser is still firing from the previous Vikhr engagement, as indicated by "LR" on HUD. 6. Hold trigger to launch second Vikhr, but nothing happens. This is because there is no LA cue, despite the fact that the laser is firing continuously, the aircraft attitude is nominal, and the Vikhr dynamic launch zone (DLZ) conditions are satisfied. 7. After approximately 8 seconds of holding the trigger, the LA cue mysteriously reappears and the second Vikhr is launched. Obviously this is not ideal behaviour if you quickly want to prosecute a second target. However, we can address this issue by altering step 6. If I were first to manually turn the laser off and then on again, the LA cue reappears and I can immediately launch a second Vikhr without waiting for the ~8 second period. --- So, my question is this: why does this LA cue delay exist? All the necessary conditions are 100% satisfied (attitude, laser, DLZ), so why isn't a launch authorised? Naturally the Vikhr is a weapon system that typically employs one missile at a time and tracks one target at a time, so I suppose it's plausible that the weapon designers decided that a second launch should not be immediately authorised. However, why is there such a long delay while holding the trigger before the LA cue appears? This delay is a prohibitively long time to wait in order to launch a second Vikhr, especially as the SU-25T will be rapidly gaining speed and will be at risk of overflying the target. In my opinion it is not plausible that this delay corresponds to the predicated time to impact (TTI) of the first Vikhr, because by the time the LA delay has elapsed, the first target has been destroyed for well over 8 seconds. Furthermore, and most importantly, LA cue delay is simply bad design from the pilot's perspective. If the aircraft and weapon systems are in nominal parameters, a Vikhr launch should be authorised. Period. After all, the pilot is the one who is aware of the tactical situation, and he is more than capable of making intelligent launch decisions. No intelligent pilot is going to spam all of his Vikhrs just because the LA cue tells him he has permission, but he sure as hell may want to quickly engage a second target if it's appropriate for the tactical situation, so the aircraft should let him. That's the pilot's prerogative. Finally, I don't accept that this is a laser overheating issue. If the laser overheats after firing one Vikhr, the laser symbol in the HUD should flash and tell the pilot such. But it doesn't flash, or make any other indication, so as far as the pilot is concerned he should be able to launch another Vikhr at will. After all, the laser is firing (presumably) and the aircraft is within parameters, so why shouldn't he be able to? The last nail in the coffin is that the pilot can just turn the laser off and on again to effect an immediate launch. This falsifies the idea that the laser may be an overheating (simply turning the laser on and off will not immediately cool it), and is frankly a poor 'workaround' that needlessly adds switch-flipping complexity, at a critical time when the pilot should be solely focussed on flying the aircraft, launching the Vikhr, and responding to threats. To sum up: 1. An LA cue delay of this length (or possibly any length) makes no sense. Let pilots make intelligent decisions - the smart ones know damn well when to fire additional Vikhrs and don't appreciate being told otherwise by uppity avionics. 2. If the laser is overheating or has some other 'cooldown' effect (to borrow an MMO term), the pilot should be clearly notified. The LA cue should not simply disappear for no apparent reason without informing the pilot. 3. The 'workaround' of quickly turning the laser off and on again makes no sense if the issue is overheating and cooldown, and additionally adds another unneeded and unwanted step to perform in the heat of combat. 4. If this phenomenon is reflective of the real SU-25T Vikhr/Shkval weapon system, then the designers should be fired. This definitely seems like a bug to me.

Yes, I run Windows 7 64-bit. I set both the 'DCS World' and 'DCS World Multiplayer' shortcuts to "Run as administrator." As a result, the 'Launcher.exe' executable in '\DCS World\bin' is also set as such. Sadly, these changes had no effect. The Launcher.exe processes are still piling up. :P I also tried disabling my background antivirus file scanner, as well as adding the entire 'Eagle Dynamics' folder and its contents the exclusion list. Again, there was no effect.

Addendum: I made a small mission to practice landing the SU-25T, and I flew it 10 times using the "FLY AGAIN" button. Only after flying the mission 10 times did I exit DCS World. Sure enough, when I checked Task Manager there were 10 new instances of the Launcher.exe process. So, the Launcher.exe bug also occurs when when DCS World switches between the Launcher and the Sim, even if you don't manually exit the program. This makes sense I suppose, but I didn't specifically mention it my original post.

Thanks shamandgg and Bucic, I will make my own profile.

Thanks for the suggestion. I had a look, but unfortunately there are no profiles for the SU-25T on that website. (There is a profile for an SU-25, but it's not the T-model and is instead for Flaming Cliffs 2.)

Hi all, Having never flown the SU-25T before, I'm looking for anything that will help to flatten the learning curve. One such thing would be a HOTAS Warthog profile designed by someone who knows what they're doing. Unfortunately, I've had no luck finding a Warthog profile for the SU-25T using Google or the forums search etc. Does such a thing exist? Could a friendly forum member share their LUA or TARGET files? :D Thanks.