Flagrum

"Vorsprung durch Technik" :smartass:

Cyclikc left/right - bank left/right Cyclic fwd/aft - pitch nose down/up Collective up/down - increase/decrease lift Anti torque pedals ("Rudder Pedals") left/right - yaw left/right Throttle (twist grip at the collective) - adjust engine power The throttle is controlled by a govenor and under normal circumstances during flight, you don't use it manually. To make the helo for example go forward (faster): Cyclic fwd (pitche nose down) and increase lift by raising the collective.

Omg, I think, I slowly start to understand Swedish, lol. "Taktikska Anvisningar för Jaktvörband" german: "Taktische Anweisungen für (den) Jagdtverband" not too different, imo. :-D

It is not so much about what we do or not do to fly an aircraft realistically. It is more about what the aircraft does or does not do to fly realistically. Smalll, but important difference! I mean, that is the beauty of simulations: we can experiment and try out things we would never do in real life. That "What If..."-factor ... it starts with "What if I were a pilot?" and continues with "What if i try this or that maneuvre" over "What if I try to kill F-15s with my Gazelle?" to "What happens if I eject while flying NoE ... inverted.":D

? Maybe because that are the aircraft he payed for and that he could fly (and not the list of aircraft of developers he likes or would encourage anyone to buy from) :doh:

Das Ziel darf auch nicht zu weit entfernt sein. Der Laser hat nur eine gewisse Reichweite - bin mir gerade nicht sicher, wie weit tatsächlich. Ich würde versuchen < 3-4 km zu bleiben (zusammen mit "Unsichtbar" sollte es auch kein Problem sein, den JTAC nahe ans Ziel heranzubringen).

Some ideas for improving the kneeboard(s): 1. Make it usable with the mouse. Flip next / previous page, Go To page, open a specific section (see #2) 2. Add index tabs (ofc mouse clickable). I.e. one tab "Comms", one tab "Maps", one tab "Check Lists", etc. Ideally there should be a common set of tabs available across all modules, like the ones mentioned above, but also "Settings" (Gunner settings, Loadout config, etc.) and probably a few more. Module developer decides which of their pages go under which tab. 3. Scratch Pad. Allow the pilot to add free-form notes (typed text). Maybe even mouse-drawings? Or allow the mouse to be used to draw on every page (i.e. circling or underlining important stuff). Maybe these user creations can also (optionally) be saved to be reused between missions.

Thank you! :thumbup:

I think, I said it already, but this is seriously some AWESOME work. Thank you for that! But maybe it is possible that you share the source files of the pages - so that one can reformat/rearrange the the content a bit - for better offline printing?

Trading license keys is not allowed, afaik. Trading license keys that ran out of activations and thus can not be used is even worse. Can it be called fraud? Maybe a better option would be to provide more information on what you did and when concerning your DCS installation (version, when updated, what happened then, provide log files, whatever) to get help here. And/or contact support to get your issues sorted.

Should be implemented already:

The changelogs never really cover all changes. And I am not even talking about all those smaller fixes that sadly go unnoticed sometimes - but often the changes of a whole module is missing. Sometimes a 3rd party dev did not manage to get their list of changes to ED in time, sometimes they don't even keep track of the changes for their customers at all ... ED, maybe you can change the build process: make it mandatory that any changes to a module that were uploaded to your servers by a 1...2...3rd party dev must contain an updated "changelog.txt". This should help the devs to not forget about the changelog of their respective module and this should also help you, ED, to automatically collect and compile the info for the DCS changelog posting here on the forums.

ED, please extend the auto updater in a way that additional messages can be displayed before performing the actual update. I am thinking about an additional window to show warnings or other cruical information concerning the update - like the DRM issue with the latest Mig-21 update. The user then should be forced to deliberately accept/acknowledge that the text was read (i.e. not just another "ok" button!). Make the displayed text HTML, so links to, i.e. forum threads, can be used as well.

I agree, that would have been better. The thing is only, this kind of action required to be performed by the user, is something that was never needed so far in the past. The auto-updater is just not capable of showing such kind of warnings and would need some code changes first. (which should be not too difficult to do by ED, though). So, this is a somewhat "corner case" - it is imho not exacly just M3's error (althought the warning could/should indeed have been comunicated earlier), nor EDs error.

There was an advisory note posted together with the change log regarding the Mig-21 and the DRM system. At least for the latest update of 1.5.6 stable and 2.0.5 OpenAlpha. Yes, that was missing for 1.5.6 OpenBeta ... but then, well, it is Open Beta and you can not expect that never ever anything could go wrong with that install ...

Maybe ED wants to consider making a changelog mandatory for 1...2...3rd party devs. I.e. when they upload their changes to ED's servers, always an (updated) "changelog.txt" must be present as part of the distribution files of a module. That would also help to collect the changes for the compiled changelog posting and keeps it consistent with the content of a patch. (yes, if someone does not keeps their changelog.txt up to date, this will not help either. But that is then a different problem.)

*bump* ... maybe this can be fixed together with the oter, general rearming issues? Please? :-)

The question should be, "since when are they being removed" :-D According to wikipedia, the Celts began to build them 2000 years ago, as a way to fence in their property. Since 19th/20th century, more and more are removed - probably as they make modern farming difficult. I also read somewhere (can't remember where) that they shall help to keep the soil in place. Otherwise the costal winds would erode the flat land into the atlantic eventually. Not sure, if this function was intentional (by the celts?) or just a positive coincidence.

My understanding is, a NAV fix overwrites what the aircraft thinks where it is at. The TERNAV only adjusts the nav polygon, but is unable to overwrite the pilot decision. Lets say, you perform a nav fix on a land mark. The nav polygon adjusts accordingly. But you were off by a few dozent or so meters - this will be detected (after some time) by the TERNAV and further adjusts the nav polygon. TERNAV will recognize the height profile around the aircraft, if the nav fix was only a bit off. But if your nav fix was completely off, the TERNAV data will be completely different from the real situation. TERNAV then goes into one of those reduced-precission modes. TERNAV is like a microscope. If you look at dirt with a microscope, would you be able to tell where on the crop field you are standing? :-)

Wait ... did I understand you right, you bought a license for the F5 module, but refunded it. And now you wonder that you can not use the F5 anymore?

The sound quality is unbearable. It took me a while to realise that you are speaking german (I am german as well) - I can barely understand anything, maybe only 20% of what you are saying. Seriously, get a better microphone ...

That was interesting - thanks! Quite interesting to see how the markers are often aligned with the shadow of a forrest: the sun is in front of the a/c and the area before (flat ground) and after (the forrest itself, the treetops) the shadow are probably heated by the sun but the shadow is cooler. Also interesting - although this could just be an effect of using the camera to capture the HUD? - is that the V markers seem to be drawn a bit over the actual hot spot. Which would make some sense at least - probably to not obscure/cover the actual point.

Iirc, black or grey text in the radio menu means "Radio Assists = on". So DCS is telling you if the receiver is able to receive a transmission, i.e. if the choosen radio is set up for the correct frequency. So it seems that the wingman is theoretically able to hear you, but you are using the wrong freq. If you modified a mission yourself to fly it with the Viggen, you should double check the radio presets in the mission editor.

It might be a far fetched guess, but maybe this is the intent of the procedure ... The thing is, StarForce is not just "a DRM". It is a tool box that allows a software vendor to implement several kinds of DRM checks. StarForce can be configured in different ways and the program code has to be adopted accordingly as well. For example, one developer can decide to configure SF that way that the software simply cease to work. Or he decides to only disable certain features. Or that it should run for a limited time. Etc. In the end, there are many aspects that require developer decisions that can affect how intrusive or unintrusive a DRM like SF will behave. Maybe LNS made some unlucky decisions - which M3 now tries to remedy.

Afaik the different fuze settings or other details of the fuzes are only for "the looks". differences of specific fuze types are not modelled in DCS right now. Everything is either an impact fuze with no delay or, in some cases, a few(!) seconds(!!) delay.