Yurgon

That's also what I saw in the track. The right engine never finished the startup, and when you taxi on the thrust of the left engine alone, the thrust asymmetry causes a severe yaw to the right. It also means the jet barely gets airborne on the takeoff roll, where the yaw instability should be the least of your worries. I'd recommend to make sure all caution lights are off prior to takeoff and give your engine instruments a good look-over to check they're all in the green. That is correct, but doesn't mean the autostart sequence is going to work 100% of the time. Anyway, in this particular case it looks like a known issue where the engines don't start up correctly when the outside air temperature is around or below freezing. So the repair didn't cause the issue. The requirement of shutting down the engines for the repair and the consecutive attempt to start them up again caused it to surface, and it wasn't evident before in what I assume was a hot spawn. The fact that the autostart sequence doesn't detect or report errors plays a role as well, compounded by the pilot's failure to monitor the aircraft systems after the automatic startup sequence. ENG START CYCLE is still on and all the cautions you'd expect from the right engine being stuck at low RPM.

Yup. All that should work out of the box with your TM Warthog. So the answer is yes. Yes. There is a "Reset category to defaults" option in the controller assignment dialog for each controller category. None that I am aware of. Now what's missing...? Chances are DCS fails to detect the position of your throttles when you enter a mission, and thus fails to detect when they get moved from OFF to IDLE. There's a sensible explanation for why that is, but the gist of it is, there are 2 common ways to solve the issue. After entering a mission in the A-10C or A-10C II modules, move your throttles from OFF to IDLE, then back to OFF. Now DCS will detect the next motion from OFF to IDLE. (Or, my personal SOP: Keep throttles in IDLE, then when entering a cold start A-10, move them to OFF after I've slotted into the cockpit and the mission is actively running). Set Options -> Misc. -> Synchronize Cockpit Controls with HOTAS Controls at Mission Start to Checked Does either of these solve the problem?

Oh yes, apologies. After a long day at the office I would have preferred to respond sooner. But I had to watch your 48 and/or 23 minute long tracks, or else all I could have responded with would have been "Hello." You omitted a few key parts in this initial description, but at least the 23 minute track does clear things up. Repairs have nothing to do with your issues. The repair works fine. I'm going to give you a hint without actually answering your question. You'll thank me later. Check. The. Caution. Light. Panel.

Recreate the issue in a short flight, maybe from an Instant Action mission. Quit as soon as the issue is evident, then hit "Save Track" on the debriefing screen. You can't. They begin at the beginning of your mission and then replay every single input you made. This is a flight sim forum, not a file sharing site. With thousands of users uploading screenshots, tracks, missions and so on, I'm guessing the servers already have to handle quite the load. Did the 2020s not tell you about actual filesharing sites from which you can then link the uploaded files? Anyway, no one wants to watch players fumble around for 2 hours in order to spot one very particular issue. If you can't recreate it in a track that's maybe 10 minutes long, don't bother. Plus, track replays sometimes play out differently than when they were recorded. The longer they run, the higher the probability of replays going amiss. It would be close to miraculous if your tracks of more than 50 MB would play out exactly like your mission, and we'll all just have wasted a lot of time. Also, please use the Caucasus map, because everyone has it. Make sure your mission doesn't require any mods.

Hey, herzlich willkommen! Das Schöne bei DCS ist, mir klappt immer noch ab und zu die Kinnlade runter. Montag waren wir zum Sonnenaufgang im Kaukasus unterwegs und wie sich da so langsam die AO unter mir von einem schwer identifizierbaren Brei in NVGs zu einem Tal mit feindlichen Panzern entfaltete, die auf eine befreundete Stellung anfuhren, das war einfach nur episch - obwohl das Terrain das Älteste in DCS ist und nun schon viele Jahre auf dem Buckel hat. Besuche im Deutschland-Terrain, Syrien oder Afghanistan sind natürlich auch immer sehr willkommen. Was Eagle Dynamics und die Partner uns hier kredenzen ist schon vom Allerfeinsten. Edit: Hab ein paar Screenshots vom Montag gefunden.

Haha yes 100% Well I've been flying the Hog in my squad for 9 years (and in single player since it came out) and can't say I see any major difference in the way Mavericks do or don't track objects, and also haven't heard questions or complaints from the squad mates who also have extensive experience in the A-10C and A-10C II modules, nor am I aware of other Hog-communities facing such issues. In fact I'd say that somewhere down the line the CCD seeker H and K model Mavs started tracking at much better ranges. They used to track reliably at maybe 4 or 5 miles, sometimes as low as 3, and nowadays I see no noticeable difference between the IR and CCD seekers. They track pretty reliably at 7 miles and often times as far out as 9 miles. So if your experience differs from that significantly, a fixed set of parameters would be needed to pinpoint the issue - and the easiest way to achieve that is a track.

Nice job almost destroying that server. Will you be on alert 5 on Monday at 7 AM just to be on the safe side if the phone rings? The timing with this thread is impeccable. Got a story to share as well. So I run a few Linux servers, and I have a hand written script that anonymizes IP addresses from their log files so I don't get in trouble with the GDPR. It's hooked into the logrotate daemon as a prerotate script. Super simple thing. I'd noticed a while ago that one of the servers takes unusually long to process the log files and is under heavy load every night. Well, the websites shouldn't have that much more traffic than those on other servers, but it's probably some AI scraper crap that's filling them up again and again day by day, forcing the server to go through countless lines of logs to scan for IPv4 addresses and replace the last 2 octets with zeros before the backup runs. Not ideal, maybe I should optimize the script. Maybe tomorrow. You know, the "that was 6 months ago" kind of tomorrow. Last week I found a smart article about optimizing backups and creating transparent snapshots using Linux filesystem hardlinks. Cool, I'm going to implement that. Start with this server first, it's got the least valuable data, just on the off chance I might mess something up. Nah, worked okay, except... the daily snapshot on the backup server was about the same size as the previous one. They should appear to have the same size, but the copy should really be tiny. But the file system was filling up big time, something apparently wasn't properly hard linked and instead copied. I checked a few random files, couldn't see anything wrong. Same file, same content, same inode number, proper hard linked. One thing I noticed while looking at this snapshot snafu was the server took 2:30 hours to get backed up. Similar servers took 2 minutes. That's... odd. Same OS, same software, same version of rsync, same custom backup script. Why on earth does the server insist on copying 400 GB of data every night when there's hardly any changes in the file system...? Ran a few more du -h to figure out where the largest amounts of data were hanging around. Err... the web host log file directories? Gigabytes over gigabytes of log data? That can't be right, there's no way I get so much traffic that the logs are this big day in and day out. Well. Turns out I had two custom config files for the logrotate daemon here. One from another server, and the one adapted for this server. I had forgotten to delete the old one after adapting. Wasn't a big deal until almost exactly one year ago when I changed the location of my IP address anonymizer script. Put the proper location into the logrotate prerotate hook - but only in the "correct" config file. I hadn't noticed that extraneous config file. That one still had the old path to the prerotate script, this path no longer existed, but by virtue of alphabetical sorting, the old and now wrong logrotate script was run before the correct one. For almost 365 days, the logrotate daemon failed to rotate any of my webserver logs on this server, dutifully logged the failure to syslog every night where I never bothered to check, and so I have amassed numerous gigabytes of access_logs, dwarfed in one particular case by an error_log that has grown to 352 gigabytes on this server. Since the logs get a few new lines every day, they need to be unlinked and transferred in the backup process, blowing snapshots completely out of proportion, and the oldest entries have had their logged IP addresses dutifully anonymized almost 365 times. And all it takes to fix was to delete one extraneous config file. As I write this, the IP address anonymizer should go through its gargantuan task one last time before the log rotation - hopefully - compresses the log files, rotates them, and now I can't wait to see my daily snapshots rotate those old logs into oblivion. You can probably tell I should also invest some time and effort into a more robust monitoring solution. On the plus side it seems I didn't need to dig into this server's Apache logs in at least a year, or else I might have noticed they're a little bigger than they need to be.

Yes; hit the Target Designate/Locate Function - Select / HOG Menu Page Down keybind that you can bind for the OH-58D Copilot (it's not available for the OH-58D Pilot category!). Keep the key depressed for a couple of seconds. I think you need to also fire the laser for an accurate coord to be generated. It'll then show on the Copilot's screen, and you can save the target with the L4 STORE Line Address Key on the Copilot's screen to have it available later on.

The endurance as shown on the HSD and VSD is currently calculated as h.0 hours instead of h.mm hours and minutes. I'm pretty sure it used to be calculated correctly in a previous version, but am not sure when this was broken. Currently seeing the issue in 2.9.19.13478 In the attached screenshots, the endurance is given as either 1.0 or 2.0 hours depending on the current fuel flow, with no in-between values. The issue seem reminiscent of the odd ETE calculation as reported here. KW_Endurance.trk

Sam Eckholm's Besuch in der C-130J ist schon 3 Jahre her, aber mir hat Youtube das Video jetzt erst vorgeschlagen.

Hahaha, den hatte ich komplett vergessen, und auch über die Suche nicht gefunden, als ich diesen hier aufgemacht habe. @EagleEye kannst du diesen Thread in den alten reinmergen?

Ich habe den Mod gerade mal frisch installiert, und obwohl meine eine Bremse sogar etwas verkalibriert ist, lässt sich die Maschine für mich ohne Probleme am Boden differentiell bremsen, abheben, landen und nach dem Aufsetzen runterbremsen, ohne dass sie nennenswert in irgendeine Richtung zieht. Kannst du mal einen kurzen Track im Kaukasus aufnehmen und hier teilen?

Yes, exactly. Plus the North when it releases.

Hat dir dein Browser da eine Übersetzer-KI untergemogelt? Ich sehe hier im Thread nur Posts auf Deutsch. Ich hab den Mod aktuell nicht installiert, aber wenn es kein Nose Wheel Steering / Power Steering oder ähnliches gibt, dann steuert man am Boden vermutlich mit differentiellem Bremsen. Was meinst du damit? Einen Overhead Break? "bremsen" ist "to brake". Soweit ich mich erinnere ging das mit ein bisschen Übung recht gut - vorausgesetzt, man hat Ruder mit Bremspedalen. Ohne Achse kann man vermutlich nur die rechte/linke Bremse kurz und häufig antippen, um das gewünschte Ergebnis zu erzielen, aber das ist dann in der Tat recht schwierig.

Gibt es nicht sogar zwei? Eine unten links im IFEI und eine im HUD (solange keine der REJect-Modes ausgewählt sind)?