Flagrum

-1 local storage = more flexibility ... which is sometimes necessary if things get screwed up (yeah, not really a legit reason, but still...) and which is sometimes just convinient (modding things)

Cross posting? Well, still applies: https://forums.eagle.ru/forumdisplay.php?f=438

My average age varies from day to day!

You can set a curve for the two axes, like you would normally do in the control setup for an axis. But as using curves with FFB sticks has issues, PC implemented their own way to apply curves. (the issue is probably DCS core related: if you set an axis where your your cyclic deflects 25% if you deflect your joystick 50% and then press trim, DCS tells the module "set the forces so that the stick is set to 25%" ... all while you are holding it still at 50%) edit: PC solution does not suffer from this issue, but I found it unpleasant to use anyway. But as an advice: start with small curves (like 5...10...MAYBE 15) - otherwise it will probably really mess up your flying. ;-)

That holding the trim button depressed does not disable the forces ... is "ok" (as in, we all suffer from this, but I haven't seen this confirmed as a bug by PC). But the main issue ... that is really strange. You say, you deflect the joystick, see the cyclic do the same, but when you release the trim button, the cyclic returns to the center, but your joystick remains where you trimmed it? Almost sounds as what someone else stated somewhere here: seems that the trim does not set the stick position and the helo follows the stick, but that trim sets the desired attitude and the stick follows the helo. (This sounds even stranger as I type it ...) I have to experiment more, but I can not recall seeing this behaviour. Or perhaps the effect is not as pronouced as it seems to be in your case? I mean, I DO find that flying the helo is ... somehow weired - but I have not exactly figgured out, why it feels that way for me.

Hypnos, please explain once more, step by step, what you do, what you see, and what you would expect to happen. What do you do with your joystick, what does the controls indicator show, what does the in-game cyclic do and how does the helo behave?

My G940 works well with the Gazelle. Nothing special in regards to the set-up - no curves, no inverted axes, no FFB axes inverted. Maybe you want to try to start from scratch with your input config. Delete your Saved Games\Config\Input\SA342\joystick folder (after making a backup) and start over mapping the controls. Maybe some odd setting managed to hide in the files in your case ...?

Interesting, I have to experiment with this in mind a bit more. But at least from just reading about this, I get the feeling that this seems to make a lot of sense for trimming using the trim hat. But I am unsure, if trimming with the magnetic trim should work the same way. Would not lead this to discrepancies between cyclic position and actual helo attitude that the AP tries to maintain? Maybe this is what feels so odd sometimes? And on another note: depressing the magnetic trim should remove the forces from the stick and if released, the forces should be re-applied at the new position. Or am I wrong? Because currently it does not work like that which makes it very hard (litterally) to use.

They would wonder, why it was not on that list. Which means that it would not be the one with the finished 3D model that we would see in the video. (not sure, if I confused me myself now more than you confused me with that statement ... ;-)

Zeus, thanks for elaborating on this topic. I understand where the challenges are here, but I just want this system to be not too "simple" as it would make it too powerful. We all know how difficult it is to visually detect ground targets - especially in DCS. But with a sensor that now would tell me exactly where they are, with a minimum probability of (100 - x) %, it would spoil the fun greatly, though. A sensor that tells me, "if I point at something, then there IS something" makes it too easy. That is why I am so strongly proposing a random factor to be added. I understand now that it might not be viable to incorporate some sort of contextual elements into that random factor if DCS does not provide such data to a module (i.e. the random factor weighted, based upon the type of terrain). But there are still options that you could consider. Maybe the relative position of the sun? Like if it is behind me, is less likely to produce false positives than if it is in front of me (if makes that makes sense, physically)? Or the time of day (daytime vs. night time?). Or ... dunno, we all could brain storm a bit. :-) And the limit of max. 10 contacts to be displayd are not really a concern here, imo. RL pilots have to deal with that, too. Again, I would not want to have the system always clutter the HUD with 10 contacts, false positives or real ones, all the time. But just enough to make me have to double check. And we should also have false negatives - no contact indicated, although an object IS there. I understand, that adding such a random factor is challaging in regards to "balancing", to make the sensor not totally useless. But on the other hand, a totally "uber" sensor is also not really fun.

Paralleler Kurs mit gleicher Geschwindigkeit wie der Träger?

hrmm ... no objections ... that is a good sign, right? :smilewink:

This sounds exactly like this: https://forums.eagle.ru/showthread.php?p=3217364#post3217364 i5-2500K 3.3 GHz ... I know, I know ... but no real problems with other aircraft, though.

The thing is, it is hard to find information and data to modell it. All classified stuff. So it is probably safe to say that we will not see this in the next two weeks.

No it isn't. German Tornados, for example, were at first not capable to fly at night over Syria in 2016 because of that. https://www.welt.de/newsticker/news1/article151170326/Deutsche-Tornados-koennen-nachts-nicht-ueber-Syrien-fliegen.html

I mentioned this already, burried in some thread, but as I just stumbled upon this again in the WIP manual, I'll want to propose something. The WIP manual says: "The real NAVFLIR hotspot detector has more features and options that cannot be simulated on DCS. One of these features is sensibility. The real NAVFLIR hotspot detector will detect ALL temperature differentials which creates many false readings. Unfortunately, it is not possible to simulate such sensibility in DCS, so the hotspot detector is limited to detection of active vehicles (AI or player controlled vehicles). The hotspot detector in DCS will not mark buildings or scenery objects." As we have no temperatures for objects and scenery, I understand that the hotspot detector can only be an approximation. But if the hot spot detector would give false positives and also false negatives, it would not be so "uber" in terms of target detection. Afaik scenery objects can not be queried by a module and so the hotspot detector just has no clue about their presence or absence. But maybe terrain type can be determined? The Viggen seems to be able to distinguish at least water, grass/fields and forrests. Perhaps even urban terrain. I would like to see false positive returns around the borders of different terrain - ofc with only a certain probability. That would emulate to some extend the temperature differences between i.e. a forrest and an open field. Perhaps some more false positives around urban areas? If we want to go overboard with it, take the position of the sun into account and add false positives on water (i.e. reflections of the sun). And ofc not every real object should give a cue in every instance. Maybe the ratio can also depend on the terrain type? (i.e. open fields + truck heated up by the sun, clearly visible > shadowed truck in a dense forrest). What do you think, Razbams? ;-)

:thumbup:

I am not sure I understand what you are refering to ... if it is about our request regarding the screenshots, then there might be a misunderstanding. At least what I meant was, the numbering of the elements of a screenshot does not stand out enough. For example, at first, I did not even saw that there were numbers added to the fuel gauge. The white numbers looked almost as were they part of the instruments labelling. Finding a specific element by number, i.e. when reading the description text, is somewhat difficult. So, it is not about the screenshots itself, or any surrounding scenery, it is just simply the numbers added for referencing the switches and gauges. It would probably already help alot, if they would stand out more by using a bright (red?) colour and/or graphically (framing them into a circle or something like that) to make clear, that they are not part of the actual cockpit labels. edit: But if you say, you would have to redo all your pictures and that this would be an insane amount of work ... I would totally understand that. But if it is NOT too late, then, well, maybe something could be done here. ;-)

Nice work, I really like it! But - if it is not too late - maybe you would like to consider changing the way the elements in the pictures/hardcopies are numbered. As it is in these sample chapters, the numbering is somewhat hard to read. I actually like the ED way - numbering outside of the pic and arrows/lines connecting them to the cockpit elements. But if that is not viable, at least make the numbers stand out a bit more? Put a circle around them, use a deliberately (and consistent) highly visible colour?

I disagree here. Imo the manual should cover all aspects at least to a level to serve as a reference guide. Training missions are great and a good way to practice what you learned from the manual - and maybe a bit more. But a training mission can not be loaded on an e-book reader and studied at the toil... well, where ever one finds the time and peace to learn stuff. I hope, you had something like that in mind..?

The head movement does not cause much distortion because in our cockpit our head movements are quite restricted - not much change of the virtual eye-point here anyways. Distortion comes into play if the total FOV is different from what it would be in reality. I.e. if we squeeze a 120 deg. FoV scene into a 27" monitor - which practically can only cover something like 40-50 deg (or so).

For me, it does ... I think. If i move my head sideways, parts of the cockpit closer to me are moving more than objects further away. For example in the M2000 - the HUD assembly protudes quite a bit into the cockpit and by moving my head sideways, I can see "around" it, see the side of it and parts of the dashboard that were hidden by the assembly before.

Isn't that exactly what TrackIR in DCS is already used for? You can move your head laterally and the scene/cockpit is adjusted for the changing eye position.

Huh? Eagle Dynamics releases no sticks. Thrustmaster might, though.

That is not normal ... what are your grapics settings and have you tried to run DCS Repair?