Flagrum

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?

Despite the supposed bug fix, I am having issues with the rocket pods. I tried this with pods on each station, i.e. only the outer ones, only the middle ones, only the inner ones and also with rocket pods on every station. The very first volley goes off okay, but subsequent trigger presses seem to do nothing. I can't say what caused it, but after several seconds (was checking the pods from the F2 view, checked cockpit settings - but didnt change anything, etc.), I could shoot again until the pod was empty. Having unlimited ammo active, I waited until the pods were reloaded. But since then, I could not fire off any rocket anymore. When I had rockets loaded only on the inner pylons, I had GUVs at the other stations. I switched back and forth between rockets and GUV and while rockets where making troubles as described above, I was always able to fire the GUVs, even after an unlim.-auto-reload. This happened on 2.1.1.9459.269 NTTR (+ NS430, if that matters).

That is Neo-Caucasus as well, isn't it?

No, I understood you correctly, I think. But I am pretty sure that the RIO will be very tightly integrated into the F-14. A F-14 RIO would be pretty useless in a L-39 as the fighting in both aircraft would be very different. The "radar" part in RIO is the keyword here... Yes, looking outside the cockpit could be applied to both aircraft, but that probably makes "only" half of the capabilities of what the AI RIO is supposed to have. A RIO is not a GNS430 ... ;-) Instead the AI RIO is just another component in the F-14 cockpit as any other avionics device or sensor.

Well, how could a AI F-14 RIO be proven to work well ... without a F-14?

I believe, _( ... ) is a function call which returns the localized/translated text.

IF you have purchased the module. ;-)

https://support.garmin.com/support/manuals/manuals.faces?partNo=010-00139-11