Whisper

Has anyone actually considered implementing a "butt meter" in simulation? Essentially a visual feedback of vertical acceleration.

Well, I get really close to this behavior with a simple plane put in ME @29700 fts, so I guess full tank since I didn't touch fuel. Yes, when jumping into the pit, I get a full pitch up effect, and if I just push forward I guess I would struggle to keep in a dive, but once @1° trim (slightly more), stabilising flight in cruise (1.35ata / 2400RPM) to establish 400kph (the start of the test in the chart sheet 10), push engine toward combat settings (1.45ata / 2600RPM) and dive, I'll need full trim to get a dive while keeping a slight push of the stick, I then monitor RPM to keep them out of danger zone while building up speed, and the need for pushing the stick goes slowly away until I need to pull to get out of dive. (actually, all controls get horribly stiff at that point). I didn't replicate the actual dive in chart, I probably could have pushed engine a bit more to accelerate faster, but that was close enough, imho. I guess it's not perfect (we will never know for sure), but the whole thing about plane pitching up, if that was a problem before (no clue, I'm a relatively recent user of DCS 109), isn't an issue now.

The text seems to imply a push of the stick during dive, on top of full trim. In sim, full trim, I don't even have to push at the end of the dive. I'm at loss about your expectations, tbh. Which chart are you referring to? Last page of the doc? The pilot is pullling to get out of the dive, isn't he? I get smtg remarkably close in the sim, tbh To correct on my previous statements on cruise & pitch up tendancy, I indeed had rose tinted glasses, it's slightly above the "1" mark that I keep the bird level on cruise settings. No need for push of stick.

Which means the stick has to be pushed forward + full trimmed nose heavy to force the plane into the dive. Where's the discrepancy with the sim?

Well, there is apparently a fixed 6° deviation set up when you start up the chopper : [EDIT : wrong info following!!] If, once GMK1 is up & running, on a chopper on ground aligned to 0° geographic (ie aligned north on ME & F10 map), you switch from GPK to MK (which performs an automatic gyro alignment to detected magnetic north, from what the doc say), your UGR-4UK will indicate a heading of 354° after a few seconds, which should be the heading of geographic north relative to magetic north, in caucasus. Switching back to GPK doesn't put back the heading to 0, meaning you need to correct geo north manually with the ZK switch So that means that initially, on an untouched Mi8, UGR-4UK indicates geographic north. [/EDIT] EDIT : Further testing proves the above wrong! HSI indicates 354° heading on startup no matter what, I was just not waiting long enough for proper alignment! It's not me switching to MK which made the heading go 254°, but the end of alignment process! So the whole chopper is aligned on magnetic north! Including GMK1, in MK or GPK mode, and the UGR-4UK gives heading relative to magnetic north. As said above, to use geographic north, copilot must switch to GPK mode and correct the heading using the SK switch. What about doppler nav systems? Do they use corrected GMK input (ie, heading relative to geographic north) or "MK", uncorrected GMK input (ie, relative to magnetic north)? EDIT 2 : preliminary tests seems to tell the Doppler Nav systems use corrected GMK input when GMK1 is in GPK position.

Names are not the same. Tacview seems to take the first part of the name, if I'm not mistaken

I'm trying to get confirmation on this : all instruments on Mi8 are using magnetic North as north? And F10 map is using geographic north for azimuth indication? Is that it or am I mistaken somewhere? Which means we need to substract 6° (in caucasus) from F10 map reading to enter either azimuth on "HSI" (yes, that's not the correct term :) UGR-4UK, there you go) or on the Doppler nav system, that's it?

Thing is, with proper combination of RPM & supercharger pressure, when keeping them into proper (real) parameters, eg between 1.15ata/1800RPM and 1.35ata/2400RPM if I remember well, for cruising, you don't have this pitch up tendency. At 1.15ata / 1800RPM, I usually maintain a trim between 0 and 1 to have the bird flying level. I'm not fighting against the plane at all. Same when cruising at 1.35/2400. Manual prop pitch is the key to learn the proper flying parameters, you have far more control (auto pitch lags behind every change of RPM or speed and perhaps has a tendency of pushing too much RPM while adapting to a new regime and perhaps, I'm just guessing here, that's what creates pitch up for some people. That or people are always using too much power out of their engine). EDIT : gotta go make again a test for this as I've not flown the 109 for quite a while, too much into choppers lately. Maybe I'm rose tinted optimistic about the trim value :) But I'm sure I don't fight the plane all the time, and with the latest changes form a few weeks back, I had to push trim back quite a bit to avoid going down, I need to confirm my "between 0 & 1 trim" statement, though

Perhaps dependant on your return path more than direct one. return from Cogent to your DTAG address => not through a congested Cogent / DTAG link. return from Cogent router connected to GEANT => through congested Cogent / DTAG link.

Are we still talking about this when the lift up effect is only present at take off (like every report of the 109 states) and with proper settings you don't get this lift up effect during flight anymore?

Working for Cogent ? :) Peering relationship takes both parties. I've seen these issues and excuses from Cogent countless times over the last decade and more, with a variety of their peers. Not from my other transit providers, not that often. Something wrong with the way they treat their peerings. Not saying DTAG is not at fault here (from what I've read, it's a frozen situation for months now, both parties unwilling to move), but a peering is 2 orgs, and peering getting wrong is an issue on both side. Anyway, it's VPN time for our german pilots! Btw it doesn't look like the issue is going to resove anytime soon. Cogent sued DTAG last year, you're not going to have a nice peering with someone you push in court.

Got an official report of congestion issues between Cogent and Deusche Telekom (Microvax provider) right now, we are facing issues with customers here in France because of this. I'll get a hand on the Cogent official statement about this, but that explains Microvax traceroute and VPN workaround being efficient for some people. EDIT : here it is, Cogent response from Oct 5th to our ticket, still unresolved : DTAG is Deutsche Telekom AG. Usual peering issues where both parties don't want to pay for the little investment needed for upgrade. Like I said, not the first time we see this from Cogent, and why I have a rather bad history with them as a provider. That means german players are probably gonna face issues on BS server.

The GRNET connections were not the ones incriminated. GR-Net to GEANT links are "upstream" links, GEANT acts as an aggregation european network for national universities networks. Gr-Net has access to Internet through : 1) Geant network, 2) direct peerings in IX in Greece (GRIX), with notable Internet actors (GAFA and such) present there. It's all described in RIPE database. GEANT has 2 Tier 1 transit providers, Cogent and Level3, + a whole lot of peerings everywhere as expected from a network this size in Europe. Same, all described in RIPE. From experience, this is not impossible. That said, the return path may indicate a network issue somewhere else than the Cogent / Geant link. But basing the "it's not a network issue" conclusion on the fact it's a Tier 1 network (Cogent) isn't wise, if you ask me, I've had many issues of this type in the past with Tier1 peering links (particular Tier1 being .... Cogent, ending us into a "never Cogent as transit provider again" policy. That was pre-MegaUpload shutdown, so things are perhaps better today). Based on Microvax MTR, this is a very hasty conclusion.

Sorry but that's not an argument :) (what do you think I do for a living? ;) ) I still think Microvax packet loss distribution along his path is pointing toward a network congestion more than any other explanation so far. And your argument didn't tell me either why you are 100% sure, since you don't seem to take microvax packet loss distribution along traceroute into account. The fact same some router could throttle some ICMP packet doesn't mean each time you see packet loss, it's a router throttling ICMP. Another point, we only see the Internet -> BS server in these MRTs. Perhaps the issue lies in the other direction, if the return path toward microvax differs from yours that may explain the differences. I tried to ping with Record Route option activated, but that was (as expected) ignored by routers on the way :(

Errrr ... That's not what I was saying :) I think OperatorJack is talking about BS server hardware issues which would cause some of the disconnect problems, not the potential routing issue which would cause some other of the disconnect problems. That's why I talk about 2 different issues and 2 different fixes.

VPN cannot be a solution to a server harware issue, it may be a solution to network congestion issue. I would advise to not mix 2 issues and 2 fixes at the same time since you won't know what fixes what. Fix the network issue first, then go for fixing the hardware issue, if (some of) the problem remains

When was your traceroute done, Cisco? I'm basing my assumptions on what is found on post #49, by microvax : https://forums.eagle.ru/showpost.php?p=2923442&postcount=49 On this MTR, all hops before the Cogent-Geant link show zero packet drop, and all hops from the Cogent-Geant link and after show packet drops While I agree that single hop showing packet drop are completely unconclusive due to the many ICMP throttling in place, the probability that all hops before one point never throttle ICMP while all after said point do throttle ICMP is really, really low. The only possible throttling explanation would be that all hops showing drops are managed by the same entiry, thus may be the same hardware with the same configuration. That's not our case, as at least 2 orgs are routing after the Cogent/Geant link, GEANT, the entity aggregating europeans university and research networks, and GR-Net, the Greek university network. Seeing the varietty of networks aggregated by Geant (like RENATER that I know a lil bit :) ), I'm confident Geant and GR-Net are pretty independant from each others. So based on this traceroute, I'm logically going for the conclusion that the Cogent-Geant links really looks faulty. At what time was your MTR done? I've tested as well last week, going through Cogent-Giant link, didn't see the PL listed in microvax post. I tested at 11AM. I assumed microvax tested at european "Internet business hour" (18:00 - 00:00) where traffic is way higher than the rest of the day.

To add on a subject, since it's the same CPU that handles ICMP messages and real important routing tasks, we very often artificially limit the amount of ICMP packets that will reach the CPU to avoid loading it with not important stuff. This is done via filters, usually. So packet loss on a hop may not indicate anything at all, apart from the fact that this node is getting pinged by too many people and its operators have limited ping bandwidth. But when you keep having packet loss on a route after a certain point, the explanation is more on a saturated link. The probablility of hitting ICMP limits of every hop after the 1st showing PL, and no limit of any hop before, is pretty low.

+100 :( ED, proper dedicated server is paramount to unified DCSv2 success, tbh.

Hello Cisco (guess I'll have to rename myself Juniper just for trolling purposes ;) ). Actually the MTR shown clearly show packet loss starting from 1 hop and continuing on all hops after that. Also, when doing the same during the morning (I'm in the same hours than Greece), I didn't see any packet loss, and I use the incriminated link. This is quite indicative of congestion during peak trafic hours. Checking the GEANT RIPE entry (https://apps.db.ripe.net/search/query.html?searchtext=AS20965), they seem to have quite a few peering links and are also using Level3 as a second upstream provider, so people using these peering or Level3 links would not be affected if the issue is indeed a Cogent - GEANT congestion. That would explain why some people are not affected, and others are. I'd say many things point toward a congested link in this case :)

http://www.cogentco.com/en/about-cogent

From my ISP network engineer PoV, Cogent is indeed an huge and old "transit provider" (international network connected to everybody on the net and reselling connectivity service), but has on more than a few occasions shown issues managing and upgrading their "peering" connections (free links with other networks and organisation that permit them to be connected everywhere and resell this connectivity to others) when saturating. I would not be surprised if that was the case. Anyway, there's nothing anyone can do apart from working @Geant or Cogent.

Yes, it's generated in the CTLD script. Having it force 1688 is probably some lines of code in it.

AFAIK these libs are protected in DCS. In this file : <DCS main directory>/Scripts/MissionScripting.lua there are calls to a SanitizeModule function which prohibits the use of these libs. You need to comment out the corresponding line to be able to use the lib.

I did like Zeus, because I found Saitek software to be rather unreliable in some instances. Sticky keys, or lag in input, to name a few. I only have a generic very simple profile for all DCS aircraft, with mapping for VoIP PTT and OpenTrack centering function, and the throttle "ministick" (which is not one) mapped to the usual TDC keys in DCS. That way I don't need to change profile when I change aircraft. My own setup is a real nightmare without any proper order, I gonna take some inspiration from yours, Zeus, thanks for posting EDIT : I don't know for you, but I also find the TGL1 and SW5 & 6 on throttle to be reachable enough for quick functions, if needed. You didn't list your mapping on these, Zeus, do you actually use these switches?