fargo007

With the East, they added some real FOBs and PBs. Daysie, Clark, Thunder, Gardez for instance, and they look fantastic. Zoom in and you will see a little green triangle where these are. null

Sorry about that, it's from the actual mission we flew. It had six RF hellfires and two SAL hellfires on 2x2 racks, with an FCR and full fuel. It was within OGE hover limits for conditions (-4C). Besides - George had no problem going straight up as fast as possible. He did not warn or refuse as he has in the past. If it matters, the aircraft had a target as the acquisition source at the time. Will try to reproduce in a smaller file.

I had this occur last night on CWG. We were trying to organize remote hellfire shots on a SAM site being lased by a 58. Every time I would hit a hover and switch to the front seat (which automatically gave George flight control), he would immediately pull the collective into his armpit, vaulting the helicopter upward. I had to switch back to the rear seat and evade missiles and radar locks. Commands in H-B mode to lower altitude were acknowledged, but he kept going upward. I also tried switching such that I'd have George slow the apache down and hover it. Same thing. This was a cold start, from Fulda airbase. It occurs several times in this track and I fought with it for a good 15-20 minutes. @BIGNEWY https://drive.google.com/file/d/1QhnVKVUVft946O_bYBERzMliI9kV0tip/view?usp=sharing

--- - name: Add lines to mission file to hide it on the Apache/Hornet/etc MFD hosts: localhost become: true tasks: - name: Replace taskSelected line with two lines ansible.builtin.replace: path: /cases/dcs/playbooks/mission regexp: '\[\"hidden\"\] = true,' replace: | ["hidden"] = true, ["hiddenOnMFD"] = true, - name: Replace taskSelected line with two lines ansible.builtin.replace: path: /cases/dcs/playbooks/mission regexp: '\[\"hidden\"\] = false,' replace: | ["hidden"] = false, ["hiddenOnMFD"] = true, Here's an ansible playbook I made that will accomplish hiding everything from the MFDs on a mission file. I also made a DCSServerBot preset that will do the same thing if anyone is using that remarkably excellent server & mission management tool: HideStaticMFD: modify: file: mission for-each: coalition/*/country/*/static/group/* select: vehicle/group/[1] replace: insert: hiddenOnMFD: true HideUnitMFD: modify: file: mission for-each: coalition/*/country/*/vehicle/group/* select: vehicle/group/[1] replace: insert: hiddenOnMFD: true HideAllMFD: - HideStaticMFD - HideUnitMFD

Props to whoever came up with that backstory. Very nice.

I recommend to start from scratch. This is a pretty comprehensive update. The names of the units & statics have changed in order to deconflict the names with other scripts in a more reliable way. With the statics I point out to make sure that it doesn't append anything onto the name. This is good (they match exactly) This is bad - They don't match. Sometimes happens with statics when imported via a static template. Just change so it matches.

Thanks for your patience guys. Version 13 is now published as a release on git. https://github.com/Fargo007/TROOPS-IN-CONTACT/releases Significant changes include: Sounds are played directly on the radio in the mission instead of via srs_stts. You can still modify it easily to do that but I'm not going to support both moving forward. Target markings now include Tracers (with and without LoS), Laser (configurable codes), and marking of the friendlies with an IR strobe for night/NVG engagements. That is awesome and you're gonna love it. Cleanup routine totally reworked. The original README.md on the main branch page has been updated. The names of the assets have changed as well to avoid conflicts and render them consistent. Thanks as always for your interest and feedback.

I'd like to ask how exactly you guys are using it. Single player, multiplayer? Is anyone using the SRS-STTS features (e.g. having the sounds play from dedicated server)?

I'm honored guys, thank you!

@NineLine Sorry for the necrotag, but I'd like to see if we can visit this request officially. A TL;DR would be: Because the "Hidden on MFD" box is unchecked by default, every unit & static gets pushed into the databases of aircraft with MFD's, blocking their ability to add more points, and exposing locations of the enemy that shouldn't be exposed. This also includes static templates where that box hasn't been checked for every unit & static (most). Having an option which will allow us to define the default behavior of that box, or to change in bulk would be huge. For example, exposing a "Hidden on MFD" box in the multi select tool would accomplish the same thing.

This should be the other way around, or we should have the ability to mandate the default behavior. For instance, the Apache's database becomes full if this box isn't checked for every swinging necktie on the map.

Thanks for the interest. I'm still working on it, but pretty soon.

I'm still hoping for Abbottabad Pakistan. Even if it's an isolated island.

This helicopter will be flying in BSD without any doubt. We're ready when you are.

When the pair of enemy spawns I'm using an :OnSpawnGroup() function to set an attack task (TaskAttackGroup) on the group that spawned them which you can get from the clientmenu class. This has been working great up until the last update. Since that, the -2 flakes out and dips. Before the update this didn't occur.

Thanks for the reply. I'm using MOOSE for this actually, and it's a two ship group. I wonder if I'd have better luck spawning two singles. Perhaps it would bypass this behavior?

Is anyone else seeing this since the last update? At BVR distance (70nm), the pair splits up after activating. Often with several miles between them. The enemy group is expressly given a task to attack you in this case. The option in the group to override AI disengage decision is set. Once the -1 element is shot down, the -2 turns toward the nearest airfield and disengages. Sometimes but not always, both of them will disengage if they are near enough to a neutral airfield. Anyone else seeing this?

I hear ya. The Corsair is supposed to be an energy fighter, not a slow speed turner, which the Zero was. Instead, all of the AI energy fight us, and since they have access to some other universe's physics, they win. While this gets sorted out, I do think there's fun to be had with ground attack, and all the naval assets @Devil 505 is pointing us to. There's a stunning visual experience there. I'll throw some bat bombs & rox in the meantime. Why not.

The AI on the jet side do some absolutely crazy things too, but it's way, way less extreme than in the warbirds situation. I dove in chase, trailing a diving zero (could not catch up) and wound up ripping MY wings off.

I agree. They really need to fix this. It's not just out of step with history; it's out of step with physics itself. And not slightly either. It's discouraging, and it threatens the (otherwise excellent) WW2 pacific theater concept that ED is trying to bring to market.

I know this guy. He's pretty cool.

None. Can you move on now? This thread isn't here for this.

Instead of arguing the particulars of one specific plane at a time, address why the corsiar comes in second from the last. If you're claiming that it should in fact come in second to last in this kind of comparative testing against all of these other aircraft, then okay. The issue here is the claim that the corsair isn't showing as much speed as it ought to. This video more or less bears that out, and there's also a second one where they test it with the 4200rpm secret extra power technique (where it wins unrealistically and dramatically) as well as an included control, which produces the same result as the first video.

Really nice, thank you!

It is. I meant to say the FW-190. I just confused them. And in this video it comes in second to last which doesn't seem correct to me.