Flagrum

Training films of the Bundeswehr: relocating a Hawk site, including recon / gathering intel about the new site and the actual Hawk site setup. warning: those BW training films of the 70s/80s are all a bit cheesy ... ;-)

Regarding 1.: AI does need NVGs, but probably doesn't use them. Ok, possible that the AI in a player aircraft is implemented differently, but at least default AI aircraft (and ground units, I assume) that rely on their eyesight "sensors" have different spotting distances under different circumstances - one of those being the fact wether it is day or night.

This has been reported as bug: https://forums.eagle.ru/showthread.php?p=3105826 But yeah, +1 for looking forward for a fix.

The laser is only good for a certain amount of lasing cycles, no matter if or if not there is a cool down period between the cycles (and afaik, there is always a cool down period, no matter if with or wirhtout that mod). There are some threads around here covering this topic in more detail and the manual has some info as well, iirc.

The logic is, that if stuff like this happens, it could be very possible that the issue is based on problems within the normal envelope. I am not suggesting that the fix should be "IF outside-of-envelope THEN helo-explode". But when the formula, the curve of the flight parameters, converges with the documented flight envelope, and then just continues as if nothing is wrong, is not good enough. Some logarithmical or exponential factor is perhaps just a tiny bit off. And if corrected, the curve of the flight parameter will not just cross the limits of the normal flight envelope and just continue, but degrade in a way that seem physically plausible - and eventually result in physically sound reactions like loss of control and or overstraining the airframe. No, this will not lead to a 100% accurate flight modell, neither within nor without the normal envelope. But it get's closer to 100% than just saying "ok, we ignore everything outside the normal envelope". Imo it is not important if the airframe breaks because the sim calculated "force = x" or "force = x + y" as long as it breaks whenever "x" is clearly out of bounds.

The thing is, to enter such an abnormal condition, the aircraft was close to the edges of the normal envelope at least once at some point in time, before it eventually left it. And at that point the FM should probably have reacted in a way that would make the end result impossible - or at least far less probable (i.e. stable?).

+1 for the effort and the idea, but my advice: save your energy, Wraith.

+1 for interest in this feature! ... does that thread you mentioned exists? link? thanks!

What is the limiting factor here? Cable length between the different units, I assume?

Of course it belongs there ... if the bad guys have a foothold there then someone has to push them out again, right? :smilewink: It all depends - on the creativity of the mission designer and our imagination as vpilots.

Yes, but that is not necessarily unrealistic. Just think about an full fledged war scenario with massive jamming and other ECM employment. In a WWIII scenario, I would not expect many radio or sattelite NAV and COMs to be operational ...

I wonder, if there is GPS available over Normandy. Theoretically it shouldn't, but technically that is not a feature of the map module, but of the aircraft module... so ... maybe?

Almost sounds like a problem with your procedure. Safety off? Correct weapon selected? (Is the weapon even mounted on the helo?) In case of rockets: ripple quantity at least set to "1"? Maybe post a short track where you demonstrate the issue?

Breaking down everything in smaller portions - that is what I would have suggested as well. Nobody can digest it all in one go. Just pick topic by topic - after reading once through the manual to get an overview of what is ahead of you. And maybe one thing to keep in mind in regards to the memory concerns ... training the brain with stuff like this is maybe just the right thing to do? ;-)

Difference is, you release the CBU - it has it's own flight model and the state of the CBU fligh model influences the flight model of the sub-munitions. But you don't release the TER - you release the Mk82 individually as if they were mounted independently.

That is not a rhetorical question? If not, then the answer is simple:

Interesting question. Wikipedia: "The closest airports (Gelendzhik Airport, Anapa Airport and Krasnodar Airport, situated 33 kilometres (21 mi), 53 kilometres (33 mi) and 172 kilometres (107 mi) away from the city, respectively, offers flights to many cities in Russia."

That raises some questions right away - perhaps PolyChop and/or PolyDynamics are willing to address these: - how does this affect the 3rd party dev status of both parties? I assume for PolyChop nothing changes, but what about PolyDynamics? - beyond what Oliver stated, are there any other personal changes in the team(s)? I.e. will PolyChop perhaps lose other team members that were previously working on the Gazelle? - or to be more precise: does this split affect the further development and maintenance of the Gazelle module? edit: oh, and of course: all the best to both teams! Hope you guys keep on going stronger than ever! :-D

Ok, understood. I was just under the impression that we might be missing a feature or so when it was only about a bug.

This is not new, it is like that since ... dunno, since the Wright Brothers.

You set the Bx-waypoints, including the descent waypoint, direction change waypoint, etc. ... what exactly are we missing there?

Could it be that you have the Upgrade key for BS2 and a regular key for BS2 bound to your account and that DCS is just asking if you want to install the module for the Upgrade key - although you already have the module installed for the regular key? Maybe post a screenshot of that message where DCS is asking you to upgrade BS2...

Seit den Patches (1.5 und 2.0) vom 7.4. ist das Starforce Thema bei der MiG-21 abgeschlossen - alle DCS Geschmacksrichtungen sind damit auf dem letzten Stand hinsichtlich Starforce. Oder was meinst du genau?

It is not an approach to learn a module - I never said that! And if I do that, I don't do it to prove where a module is faulty - I never said that either! First of all, it is a way to explore things - and with things I mean the aircraft, not the module. The difference, again, is to explore the capabilities of what the aircraft can do, not what the module or the module developer can do. Computers, computer games and also simulations give us freedom to do things that we could not do otherwise. That is what it makes fun, right? If I want it to be exactly like in real life, well, I would do it in real life. Yes, sometimes this leads to discoveries that a modelled aircraft is lacking in one aspect or another. But if that is explainable, for example in a situation that can not be simulated exactly because nobody can possibly know what exactly would happen ("is the tail boom of a helo strong enough to land on it vertically?" ;-), or for example that calculating the results would be too demanding for our computers ("which parts of which sub components would how be damaged by the fractions of a bullet that hit the 22th rived of section X? And would the swinging/vibrating hydraulics line be cut open by 1 or 2 milimeters?"). But for generally well understood concepts I would hope for reasonable simulation results, even at the limits of normal, real life, operating parameters. And if I find something that seems unreasonable ... but can be explained in a reasonable way, then I am the first to admit that I am happy to learn something new. "It is good as it is" is, btw. NOT a explanation - an explanation must always answer the "why".

The system does not support mixed A2G loadouts. You either load ARAKs or RB75.