PhoenixBvo

Regarding the bunkers (hints):

Better post that question in Barthek's mod thread. And supply a screen shot to show what you mean. Cause I'm not sure I understand. Is it related to the tree shadows? EDIT: ah, you mean they become visible only at close range? That should not be the case for the max settings...

Hmmm, I'd swear I didn't have that diamond in the TAD for a while now. I'm not at my flight sim rig at the moment, but I'll check when I get back home this evening and post a pic. Perhaps I'll have to do a repair or check without any mods activated. Although I have very little running now with 1.5.2. Thanks for replying!

Related to this, can you guys also confirm that the TGP marker has disappeared in the TAD since 1.5 became available? This also makes using of the TGP more difficult for me. I can't confirm anymore that I'm looking at the correct location on the map. Yurgon, your terrain noise reduction mod is very helpful btw!

Hi Baltic, first off, I'm a big fan of this campaign as I played through most of the original free version, before jumping right in again after the paid version became available. I also had the same problems with this particular mission and I'd really like to fly your updated version. But how does it update? Given that is gets installed through the module manager, can I assume that updates are managed by DCS_update.exe? Or can I install something manually? Thanks for your awesome work!

GTX980 Ti (Palit Super Jetstream)

Well, reading tacca's post, it sounds like the mod has to be rewritten :(. I'm waiting for 1.5 to come out of beta as things may yet change. But then we'll have to start from scratch essentially. nrgized is not active anymore (Last Activity: 04-17-2013 08:53 AM), so it is up to any of us to do it. Although I have some coding experience and did a bit of successful modifying on this mod, I'm not actually familiar with HLSL. I'll give it a shot as soon as 1.5 is stable. :helpsmilie: Call to people with shader coding experience: please chip in! :helpsmilie: :thumbup:

visibility is a big problem: In general and especially with DCS right now. Like it was said before, try turning off AA in both the DCS settings and your graphics card helps to better see edges of the bandit's aircraft. Apart from that, try setting up labels to only show a dot as a training measure: You already watched Youtube vids, but still I found this particular one by Iron Jockel very helpful for the Fw-190 vs P-51D: In particular he notes: "The Dora can't outturn a P51 but outroll it." Also note the way he keeps track of the bandit and clearly has a mental picture of his motion with respect to his own maneuvering. That together with excellent gunnery skills makes this particular pilot outstanding! My own experience with the Dora vs AI is that you can consistently win if you fly rolling scissors with him. Try to keep your load vector pointed at the bandit: that is roll smoothly to keep him along the center canopy rim and pull just as much as the aircraft can sustain. You want to conserve energy. As soon as the AI pulls up into the vertical you can easily shoot him down, but be careful on the throttle not to overshoot him.

:doh: So now it turns out there isn't any difference of understanding (anymore)... Case closed. PS All these graph are very nice, but hardly relevant to the OP, that being the model of Bf-109 controls in the DCS simulator environment. Those yellow boxes show a rudder at constant deflection with varying forces acting on it. We all agree that is what happens during such a maneuver with rudder held fixed :) Congratulations:music_whistling:

Crumpp, just drop it please. As a flight dynamics engineer I can confirm that effte, Yo-Yo and Echo38 are right. Fixed controls means that the specific control input is held at a constant position during the maneuver. That is usually the position for trimmed steady-state flight immediately before the start of the maneuver.

If you'd move the stick very slowly at constant airspeed, you would find that the response is nearly constant up to the cutting force. This is hard to do though, as your airspeed will change by pulling the stick. Maybe someone could write a little .lua output script (similar to what is done by Tacview for example) with the dynamic pressure (~airspeed), joystick position and simulated stick position. Then you'd have to fly the same dive over and over again and try to match a certain speed to different simulated stick positions (while moving the joystick very slowly). You'd then come to the conclusion that the control curve slope is constant. Oooooor, you could just believe Yo-Yo and me :)

No, this is actually the dynamic behavior of the reduced agility filter you are observing. It depends on the speed of your input. Yo-Yo explicitly denied any "curve" being applied to the input model (other than the user curve in the control setup). To understand this dynamic behavior refer to Low-pass_filter on Wikipedia and pay special attention to the concepts "delay" and "phase shift".

effte and DavidRed, could it be that you guys have not understood my point 3 concerning the zone of reduced response agility...?

Is is however exactly what is now in 1.2.15. Also, I don't think you should judge it that quickly and harshly. You seem not to have tried it yet... My impression is that the response agility filter can do with some fine tuning. When you move your stick into it, it immediately acts as a thick soup slowing the stick down. My suggestion would be to make the filter directional: moving against the force is subjected to lag, but reducing your input should get you out of the zone without lag.

Although I agree with you that a true force-based relation between joystick and simulated control stick is a good model, it is NOT what Yo-Yo implemented: After some further elaboration by Yo-Yo in the same thread I understand the model to work as follows: in principle, the controls are still position matched, but: there is a maximum pilot force defined: when this is reached, the simulated controls position will not move further (the 'cutting' force); before reaching that, there is a control force zone with 'reduced agility', meaning: a low-pass filter is applied to your input producing lag between your joystick's motion and the simulated control's motion. This was done to simulate the pilot's having trouble to move his stick against a large force rapidly. Point 3 seems to be what DavidRed is objecting to. I just wanted to clarify the new model here: it is NOT a true force-based model, but rather a hybrid model giving position-matched response under 'normal' conditions with the addition of force-based modeling of the pilot's physical limitations.

OK, so "the zone of low responce agility" you mentioned is implemented as a responsiveness lag, like a low-pass filter? I'd still think the nonlinearity in the plot is useful to avoid a "hard stop" in the stationary response. Otherwise you cutoff the effective joystick travel and thereby miss out on the highest spring forces of the joystick deflection. BTW Just to clarify what I meant in the plot: The non-linearity in the curve is not the same as an axis curve in the setup as it depends on the simstick position corresponding to the cutting force at the current flight condition.

Input curves being flight condition independent is your biggest problem there...

Hence my suggestion: But as I understood from Yo-Yo's answer ED decided to basically map the the joystick axis to the controls position directly, but to cut off the response at the maximum pilot force and add a zone of stiffening before that. I hope it will look like the green curve (the red line would be the direct position mapping): This means we get a flight condition dependent stiffening of the controls as desired. It is another approach than a force mapping, but may yield similar results. Perhaps there are advantages in the lower deflection range (implied by Yo-Yo) by doing it this way.

Thank you for the elaborate answer! I was under the impression that flight experience is more force based rather than position based. I think the cutting force with a zone of low response agility amounts to about the same effect as what I meant under option 2. The important point is that there is a gradual flattening of the response preceding the cutting force. Awaiting your model of this in an upcoming patch with high expectations! :thumbup:

I think I agree with you here. The problem is the fact that we cannot expect realistic control forces in this desktop simulation. Simply because no one has the right hardware to generate them (FF Stick or no). So what to do: Either you can simulate only the aircraft itself, meaning joystick position is simulated stick position. This leaves control forces out of the equation and we feel the same spring tension for a given stick deflection at any flight condition. or you can attempt to simulate the pilot experience within the limits given by inadequate hardware: Simulated aircraft inputs are now control forces, and the joystick input is filtered to provide a mapping from joystick position to simulated pilot control force. Now you can equate max joystick deflection to max pilot control force and provide some nonlinear function for lower forces to give the "right" feel. (The input curve setup allows some user customization, but it is flight condition independent) So what if any of these is implemented in the simulation now, and how could it be changed/improved?

Yo-Yo, could you please answer these questions: 1) Are those forces reported at the control stick? 2) Does the simulation take controls position as input directly for non FF-sticks? The problem we face here is complicated by the fact that those who fly this sim don't all use the same hardware. Simulating the real control forces (and thus stiffening) requires a powerful haptic feedback system which we cannot assume to be present. So either we can say OK control force simulation is not a realistic option and just equate joystick position to simulated control stick position, OR: we can filter the simulation input using a "force curve", i.e. a mapping of the stick force the simulated pilot is assumed to be capable of to the joystick range of motion. (The same holds for the rudder pedals btw.) So that's what I mean with question 2: When FF is turned off, is there a force curve filtering in the simulation or not? Thanks for being so present on these forums and taking time to explain the FM to us. Cheers! Mark

Please read this thread in the Bugs and Problems section: [REPORTED] wings break off at 4g Think about this: Just because you can pull your joystick into your stomach sitting at home does not mean the simulation itself is inaccurate. One obvious source of inaccuracy is the fact that you don't feel the accelerations a pilot would AND moreover the stick forces are nowhere near realistic. But that is hardly ED's fault now is it?

About the approach for landing, I really recommend a low altitude break turn approach: It avoids the need to slow down using prop pitch and most importantly once you can do it well in one prop plane, you can land all of them. And not unimportant: it looks cool too! 8)

Hmm, me neither. Perhaps the values aren't used yet. It's beta after all. That elevator trim tab might be useful as well!

+1 This would be a really nice immersion factor, plus easy to implement. Any plastic deformation modeling would be really impressive, but probably much more work.