Crescendo

I'll second that. :thumbup:

Hi, Thanks for the reply. I will investigate both of those retailers, but I will be surprised (pleasantly mind you) if they have it in stock. I've tried at least half a dozen similar retailers in the past, and while all appeared to have the book in stock and had prices listed, when I went to actually order they would without fail email me and indicate "no stock". There are some Ebay sellers around, but I'd rather try here first.

Yes. Creating a pretty external model for an AI plane such as the E-2 and F-15 is 'easy' (relatively!). I would imagine the hard part is creating, testing, and then re-testing a realistic flight model, simulating and troubleshooting the avionics, and filling the external model with realistic hydraulics, linkages, engines, undercarriage and so on and then making it all damagable etc., and let's not forget the steps I probably missed. With all that in mind, I would imagine having a nice-looking external model is only a small step towards a new DCS module. Like, a very small step even. So, a new external model for the E-2 therefore doesn't necessarily suggest an F-18 module, just as seeing a new external model for the F-15E doesn't necessarily suggest an F-15 module. It might suggest something, but there is literally so much more required to complete a DCS module that it would be foolish to make predications based purely on external models. Maybe ED is just updating external model fidelity to make things look pretty? It could simply be a small part of the never-ending incremental graphical improvements, nothing more. I'm not trying to rain on anyone's parade, but I think people should be realistic about what must actually be involved in making these sims.

Hi all, I am looking to buy this book, but unfortunately it's out of print. I know Amazon has two new copies for sale, but there is no way I'm paying $300. However, I am willing to pay a small premium above your purchase price if it helps to facilitate a sale, even if the book is in a non-new state. PM me details, or reply here if you wish. Thanks.

Damn. My thread was moved here after I posted it in the wrong forum. If I had noticed the Object Errors forum sooner I would have seen your thread. :poster_oops:

Most trivial bug ever: F-15E navigation light ground illumination ED, this is absolutely unacceptable. My immersion is ruined. ... ... ... :D

Also, see the following threads. However, keep in mind that some information may be out of date. http://forums.eagle.ru/showthread.php?t=76856 http://forums.eagle.ru/showthread.php?t=68182

I don't know, I think it's actually quite easy to achieve repeatable parameters if you fly with a plan and have a bag of practiced maneuvers to draw from (spilt-s dive, orbit and roll-in dive, pop-up etc.). The most difficult part when doing it 'for real' is actually finding the targets in the first place, and then making sure you've eliminated any SHORAD threats around them. Once that's done it should essentially become a muscle memory shooting gallery. I can regularly kill 6-10 MBTs with 1150 rounds in a typical mission that features typical SHORAD.

What do you guys using touchscreens and mouse devices do when you need to access the IFFCC test mode in-flight (for example)? If the three-state toggle switch logic is cyclic, wouldn't you be forced to turn the IFFCC off before before switching to test mode? That seems impractical and dangerous.

Thanks for the replies, all. I have to admit I thought this topic might have delved too far into minutiae, so I'm glad I'm not the only one who finds it annoying. I essentially agree with this, but with slight reservations about remaining consistent with the left-click 'up/forward' and right-click 'down/aft' convention. I think right-clicking will work fine for anything you would normally 'pull out' such as the fire handles, but anything you 'push-in' should still require left-clicking. However, I definitely support the idea of preventing errant mouse-clicks, especially if it simulates actual lockout-type features that would be present in the real jet. With that in mind, maybe instead of right-clicking for 'push-in' emergency switches (such as emergency jettison) you could instead left-click and hold for say 0.5-1.0 seconds? I'm not privy to the correct function of the radio frequency knobs, but I agree 100% based upon your experience. Regarding the "safety features", ideally I do think they should be modelled if present in the Hog. I know I've accidentally switched off my IFFCC at least once when setting up consent to release parameters. Although that particular instance was a result of left-clicking when I should have right-clicked (which is more to do with the switch logic in my OP), it's just as easy to accidentally right-click when in test mode too. Greetings.

Hi all, I have a pet peeve regarding the way ED has implemented the toggle switch logic in the 3D cockpit. It's been percolating within me for a good few months now. At present a virtual pilot has two options when manipulating toggle switches via the mouse: Left-click and right-click. Assuming the virtual pilot's point of view, left-click typically moves the toggle switch 'up' or 'forward', and right-click typically moves the toggle switch 'down' or 'aft'. Currently the switch logic is such that all toggle switches are cyclic in nature, i.e. if you keep left-clicking or right-clicking eventually you will traverse through the entire range of switch states. I find this implementation objectionable, especially for three-way toggle switches. This is because technically you cannot push a three-state toggle switch any further 'up' or 'forward' if it is already toggled to the 'up' or 'forward' position. No matter how hard you try, you can't continue moving the switch in one direction with the vain hope that it will somehow reset the cycle anew. Allow me to explain further with a picture. Keep in mind that two and three-stage toggle switches in the 3D cockpit move 'up/forward' when left-clicked, and 'down/aft' when and right-clicked. As you can see, if you keep left-clicking (or right-clicking), you can cycle through each of the toggle switch states in an unrealistic manner. So why do I care? Three reasons: I like consistency. If left-click means 'up/forward', that's all it should do. No switch 'reset' functionality should be modelled. Toggle switches aren't magic. They have states that you move 'up' and 'down' between. You can't push or pull the switch for a full 360° and expect it to eventually reset to its initial state. Sometimes I forget whether I have a toggle switch set to the 'on' (or whatever) position, and wrangling with TrackIR can often make visually confirming the switch's state difficult. In these cases I like to push the switch 'up' to confirm that it is indeed 'on', but unfortunately this often switches it 'off' for reasons outlined above. Admittedly this is a problem that can be solved by taking a moment to look harder, or by checking the Caution Light Panel, HUD and the various other displays etc., which is why I put it last. My solution? Model the physical limitations of toggle switches (and all switches really). They can only move so far in either direction before stopping. Maintain the consistency of the current left-click/right-click system when interfacing with toggle switches. The only exception might be rotatory knobs which currently work in the opposite manner (left-click is 'down/aft', right-click is 'up/forward'), presumably to simulate moving your fingers in the direction of rotation (?). Of course all of this is predicated on the notion that 'up/forward' and 'down/aft' actually mean something when we are clicking switches/knobs using the mouse interface! I personally think it does mean something (and ED would seem to agree if you take into account the rotary knob modelling), but if the reader and ED don't really care, what I'm saying will seem utterly silly. I know some people will like the ability to teleport instantly from one switch state to the next, and some will say I should simply get used to it. To them I say fair enough — I'm not saying it has to be this way, I just feel it seems a little logically inconsistent and does't strictly correspond to the real world. Well, there you have it. That's my pet-peeve. Remember, it wouldn't be a pet-peeve if it was major issue that affected my enjoyment of the game. :thumbsup:

Oh, and one last thing, do not fight PAC. That means no stick input from you when using PAC-1 (to stabilise) and PAC-2 (firing). PAC is designed to keep your rounds on target, and it does a very good job of it as long as you don't mess up its aim. :thumbup: The only time it is acceptable to be 'fighting' PAC is when using PAC-1 to refine your stabilisation point. With PAC-1 engaged you will have reduced stick authority in order to 'fine tune' your pipper around a stable point, but after you've established a good point of aim leave PAC alone. I personally do all my aiming without PAC, and then engage PAC-1 to 'settle' my pipper on that point. If I've messed up my aim I usually disengage PAC-1 and recquire, or abort the run. That's just personal preference though.

By the way, if you're having trouble seeing targets I would simply zoom in more. Yes, it's unrealistic, but the resolution of the simulation is also unrealistic in terms of the human eye, so zooming in helps to counter that. That said, if you're still having issues seeing targets you can try using the CCIP gun-cross with "CCIP GUN CROSS OCCULT" set to "N" in the IFFCC menu. This will provide you with a CCIP gun-cross that will NOT occult the SPI symbol on the HUD, provided that you use CCIP mode rather than GUNS mode. Then all you have to do is place the CCIP gun-cross in the center of the SPI symbol (which is NOT occulted) and fire at the appropriate range — you need not even have a visual on the target. Of course this method requires your SPI to be very accurate and your TGP to be tracking correctly (no gimbal roll or lock), but I have used it with success. In my opinion it will never replace zooming and actually seeing the target, however. If you visually acquire the target with practice you can aim for specific parts of the tank, which is something you can't easily do with CCIP gun-cross and a SPI symbol.

The key to consistently destroying tanks is to attack them directly from the rear and the top, or directly from the side and top where the armour is thinnest; to attack the armour as 'straight on' as possible to minimize deflections and ricochets; to attack from a steep dive angle so that the rounds cluster tightly together; and finally to attack from close range so that your rounds have high kinetic energy when striking the target. In short, you want to do this: Attack the tank from the rear and top (preferably), or from the side and top Attack with an angle-off of 0° (preferably straight-on, no acute angles) Attack with a dive angle of around 20-30° Engage PAC-1 as early as possible and for as long as possible Attack with a 1-1.5sec burst at 0.6nm or less, then egress in the vertical and horizontal at 0.3-0.4nm PAC-1 stabilisation before firing is preferable but NOT required; PAC-2 (firing your gun immediately) works just fine if you're short on time and your aim is true. Others will advise attacking at further distances for reasons of safety and egress and so on (which I won't argue with), but if you want to consistently kill T-80s in one pass, the closer you are the better. In a real mission with tank machine gun fire flying all around, you might prefer to kill them in two passes at longer ranges for increased survivability. How you fly your airplane to meet those parameters is up to you, but I generally fly a rectangular pattern around the target at 3000-6000ft, and then 'roll-in' to the target at reduced throttle when it's roughly at my 2 or 10 o'clock (using the right and left wings as a refernece). Then all you have to do is pull up 'into' the target and roll wings-level when the center of the HUD frame or pipper is centred on the target. From there you should be established in a dive of between 20-30° with wings-level, and with the target under or near the pipper. Adjust aim as necessary. Your airspeed should be somewhere between 300-375 KIAS, as you want to be fast enough to quickly egress the area and to have enough energy to respond to threats, but not so fast as to over-g the aircraft. So, Establish a rectangular or circular 'orbit' around a target at 3000-6000ft On the final 'leg' of the rectangle or circle, ensure the target is at your 2 or 10 o'clock using the wings as a reference Bank unloaded 100°+ into the target Pull up 'into' the target maintaining bank as necessary Roll wings-level when the center of the HUD frame or pipper are centered on the target Adjust aim as necessary (minimal banking should be required if done correctly) Engage PAC-1 when pipper is on target and adjust aim if required Fire at ~0.6nm for 1-1.5 seconds Egress in the horizontal and vertical no less than 0.3nm from target. I recommend always 'rolling-in' to targets rather than flying directly towards them because it's easier to adjust your aim when you're already banking and pitching into a target. If you fly directly towards a target you can sometimes get stuck banking left and right like a pendulum to correct your aim, whereas if you 'roll-in' to a target you only ever have one direction in which to bank, and then all you have to do is pull up 'into' the target and roll wings-level. The other advantage is that flying rectangles or circles around a target takes up a lot less space in comparison to flying directly towards a target, egressing, and then slowly setting up another direct run. The roll-in quickly beomes intuitive and is very versatile. I've attached a track to this post demonstrating the above steps. You'll notice that I don't actually complete a full circle or rectangle around the target — this is because I was already correctly aligned with the rear of the tank on my second 'leg'. I killed this particular T-80 with 110 rounds, which is consistent with my usual 80-120 rounds. You can use less rounds if you're closer to target, are are well-stabilised with PAC-1, or are attacking from a higher angle (tighter cluster). Similarly, you can also use less rounds if you want to 'gamble' about whether or not you'll kill the tank in one pass. NOTE: The track is recorded with the 64-bit executable and version 1.0.0.9. Using the 32-bit executable and different versions may result in faulty playback. cres_guns_kill_1xT80.trk

Thanks ED for the sneak-peak and the excellent work. It all looks very cool, and is especially impressive because I imagine modelling sensor fused weapons is quite challenging in the context of hardware performance and the current DCS damage model. Regarding the back and forth, I think that any 'realistic' simulation is at its heart essentially about nitpicking, so it should be actively encouraged as long as it's in the right arena. However, I can't help but think that a generously provided preliminary WIP thread is not an ideal time and place for it. I won't say that people cannot and should not do it, but I also won't blame ED if they're not as quick to share WIPs in the future.

I've personally noticed that as soon as my game is windowed or alt-tabbed in any way, the subsequent track WILL be dodgy. I suspect HELIOS is windowing your game or doing something akin to alt-tabbing, so unfortunately your tracks will not work properly while it's running. I don't use HELIOS or any interface solution at the moment, but when I do try one I expect my tracks to become worthless.

They definitely were. I saw them all the time with the TGP in 1.0.0.8, especially when playing randomly-generated missions. I do remember seeing them in earlier versions too, but it has been a while so don't quote me on that.

:doh:

Thanks for the clarification — I can't believe I've never noticed that. I don't think I've refused a tasking before so I've never pressed anything other than WILCO, and have thus had no reason to look at OSB 7 until after I've already accepted. By then of course it will say "CNC" (as long as you have the object hooked), so I've always assumed it stood for "cannot comply". Clearly the character limit for OSB 7 is not limited to 3, so I think the avionics engineers should change "CNC" to "CNCL" or even "CANCL". That's my story and I'm sticking to it!

Mine came with the twist, it has not worsened with use, and I have read similar reports from other people, so I take the small movement to be a consequence of the design. I think some sticks have a small amount of twist and others will have a slightly larger amount, but all will twist to some degree if you force them. A lot of people won't even notice it until you mention it. As I said previously, in my experience it does not negatively affect the Warthog's performance in any detectable way, and with you time you forget it even occurs.

By the way, '"CNC" means "cannot comply", so it makes sense that it clears the tasking.

You're right. The twist in my stick is ~5° (measured pretty carefully using paper, a ruler, a protractor and the circular throttle base as a guide). That's if I gently force it by the way; in normal use it will only move 1°, maybe 2° at most, and even then it only happens sporadically when I press the Master Mode Control Button. It's a very small amount and negligible in my opinion.

33rd_Shark, the twist is normal, but not the amount you are describing. My Warthog twists about 2-3mm in the Z-axis. This movement is essentially an inevitable consequence of the design and typically occurs when I press the master mode button (the force required to push the button induces torque). Other users have reported similar experiences. I personally find it has no ill-effects on the Warthog's performance. A twist of 10mm seems really excessive. Does it move 10mm easily and loosely, or is that the amount it moves when you really try to force it? In order to get mine to move by that much I would really have to twist it hard. Are you sure your Warthog stick moves 10mm? I'm sorry to ask, but that's a pretty large amount. If it does indeed move that much loosely and easily I think you might have a defect somewhere in the ball and socket. On the other hand, if it typically moves <5mm and only moves 10mm when you force it, I think its performance is acceptable. By the way, when I first noticed the Z-axis twist I couldn't stop thinking about it because I didn't like the idea of any movement. I found I would constantly twist the stick to see how 'bad' it was, which ultimately was sort of like picking at a scab. I got over it eventually and now I don't notice it anymore. I'm not saying this is necessarily the case for you, but I personally found the movement wasn't as bad as I thought it was.

Thanks ED, I'm excited about the chance to fly COIN ops.

Thanks. It's always nice to add a little realism 'flavour' to multiplayer sessions.