TAIPAN_

Is it only the Hornet having the issue? I thought it was NVG & HMD for all aircraft not working? Also the "Complete and Rejoin" command doesn't work, you need to use the menu to tell your AI wingman to attack the mission target. Hoping that gets fixed too

Thanks for the bug report. Regarding Multicrew exports and the Tomcat, it seems to be coded slightly differently but works really well exactly as I want it to work actually.. I setup my exports and I'm able to see the same exports from both the front seat and the back seat, whereas the Apache the TADs will only export when I switch the the front seat. When I switch back to the pilot seat the TADs disappears. Maybe it's cheating but I can see some of the RIO screens from my front seat. See photos front seat and back seat I've got the same setup so I can jump seats and still see what's going on

So the whole time you knew it didn't work? From your posts I thought you were trying to say that it should work if only we looked closely enough... So in your normal setup, i.e not the example setup, it also doesn't work for you to have one config file. I wish you'd told us this at the start it would have saved me alot of explaining! There's something funny with the Apache files. For the F-5 I'm fully able to rename the exports and switch the screens around and there's no hidden exports overwriting anything. I just rename them and it's done. But with the apache it seems the viewport for the CPG will always be sent to LEFT_MFCD and RIGHT_MFCD even when renamed. Hopefully ED can advise or at least swap the priority so that the Pilot is the primary export instead of the CPG..

Thanks! It was worth a try. Even though our edits to the indicators/lua files are very similar, I decided to copy your files exactly as attached and updated to your custom names LEFT_Pilot and RIGHT_Pilot to see if there was any difference. Unfortunately even with your lua edits the LEFT_MFCD and RIGHT_MFCD still override the LEFT_Pilot and RIGHT_Pilot viewports, because my x/y/width/height are exactly the same position since I only have 2 LCDs. To prove the lua setup and monitor config is correct, I ran a separate test with LEFT_MFCD and RIGHT_MFCD commented out in the monitor config. The second photo shows them displaying correctly... so everything is setup correct in terms of paths/lua/files etc. The only issue is the bug with CPG views in the default MFD viewports overriding any custom viewport. We can't really use your Monitor Config file as a good example because your screen outputs are all over the place, they are all in different positions. The use case for us is that the 2 screens are always in the same position. The only reason the LEFT_MFCD (Copilots) is not overriding your LEFT_Pilot is because your monitor config file places them in a totally different position on the virtual screen. Most of us can't do this because we want to put the Apache Pilot MFDs in the same position as the default MFD viewports. Not sure why you've got them in other positions, maybe you have alot of screens? I've made a modification to your Monitor Config file to ensure your standard LEFT_MFCD and RIGHT_MFCD are now in the same position as your apache pilot MFDs - can you please test that out and confirm you're seeing the same issue as us? PHOTO1 - this monitor config still has LEFT_MFCD and RIGHT_MFCD in there (not commented out). This prevents the pilot displays from showing because they are in the same position on the screen PHOTO2 - this monitor config has commented out LEFT_MFCD and RIGHT_MFCD so that they do not interfere with the Pilots display export. If you use the same X/Y coordinates, commenting out these in the MonitorConfig is the only way to get it to work. All Setting 1.lua MonitorConfig - photo2 working.lua MonitorConfig - photo1 NOTworking.lua

Yeah I've tried all of them, even commented out every single viewport line except for the pilot ones.. It stubbornly puts the CPG MFDs into the allocated position for LEFT_MFCD and RIGHT_MFCD no matter what we do. Even switched up the order in the MonitorConfig, doesn't seem to matter which comes first..

Moving the Pilot MFDs to a new position will work, which is why @Hobel is able to work I believe. Those of us that are limited to one default location are stuck..

Have been looking VERY closely The MonitorConfig in the video is the same format as me (default LEFT_MFCD at the top, custom at the bottom of each section). So far everything matches.. and you haven't posted your MonitorConfig, please share. Setting the indicator exports for pilot with the names in your post #2 doesn't prevent the default CPG RIGHT_MFCD from overwriting them. ACTUALLY - I have an idea. Looking at your post #2 I can see that you listed the CPG first, and the Pilot second. This wouldn't reproduce the issue of being overwritten because you wouldn't notice the pilot getting overwritten because it is in a new location (and CPG overwriting itself is a non-issue). Try and switch them around, see if you can get the Pilot MFD to go in the same position as your Hornet LEFT_MFCD would go. That should highlight the issue we are having. I don't have a choice of putting the CPG first unfortunately because I only have one left and right LCD, so I can only export the pilot.. and it has to be the same location as the default LEFT_MFCD because it's used for the Hornet and others.

Curious is anyone just flying from the front and doing 100% of the work/fun? Any reason why we couldn't besides workload and buttons? Or is George really that great that flying from the back seat is just better? What's missing from the front besides startup/shutdown items? Serious question since I haven't RTFM yet..

The video is not applicable to that issue though, because in the video they left the LEFT_MFCD and RIGHT_MFCD in the file. Also the video just shows the basic process of setting this up, which is very easy to do anyway. File paths are not an issue either as we're all using the same paths. My issue was if we remove the default MFCD: I don't want to remove the default MFCDs from the MonitorConfig (same as the video, leaving them there is best) because I want to keep a single configuration for all aircraft. What @Bunny Clark found though was that unless you remove them from the MonitorConfig, the CPG screens overwrite the pilot screens (and I verified it). Your original post doesn't show your monitorConfig, so I'm not sure if it includes the default LEFT_MFCDs or not, I'm hoping it does so that you can share the solution... but I fear you maybe setup a separate config for the apache. Happy to be proven wrong (actually HOPING I'll be proven wrong) to fix this, but I feel it was just a miscommunication. Yeah I've done a "find in files" for the whole module folder hierarchy and it seems there's no extra calls to try_find_assigned_viewport, except I did find some in the _LCD indicators for the MFDs but commenting these out didn't fix the issue. In fact I commented out EVERY single reference to the MFCD viewports and the CPG viewports are STILL exported lol. I reckon it might be in a dll or some other hidden code, unless there's another lua method besides the try_find_assigned_viewport that we don't know about.

Maybe one is USD and the other is your local currency? Or taxes not added on one?

It's not good to remove LEFT_MFCD and RIGHT_MFCD from monitor.cfg because it affects other aircraft that use these, ie the A10C, Hornet etc... If you do this then we need to change monitor config every time we switch aircraft... so far I've got all the modules working with a single monitor config EXCEPT the Apache unfortunately Hopefully ED patches it to have separate viewport names. Regarding the TADS - it will export, I have put it on my Center LCD screen: 1. Edit the file E:\DCS World OpenBeta\Mods\aircraft\AH-64D\Cockpit\Scripts\Displays\TEDAC\TEDAC_init.lua 2. Add these two lines to the end of the file: dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") try_find_assigned_viewport("AH64_TEDAC") 3. Add an entry in your monitorconfig to read from the AH64_TEDAC viewport. ISSUE - once doing this the in-game TEDAC will have a sort of double-vision ghosting Maybe someone who knows the LUA can figure out how to prevent the added viewport from messing up the in-game view?

With all the new viper changes today I noted the PDF manual updated for DE, but the EN version is still dated back in October last year (same with the DCS website). Was the manual intended to update for all languages?

Hornet guide is awesome and taught me everything learning this plane. Re the future - 23 items coming according to a guy on reddit's research but not sure how accurate or how long these will take:

Seems everyone having the same issue. More details here: Hoping @Hollywood_315finds the cause

Same here with the Hornet, crew chief won't load NVGs. Command is recognised, and he does some kind of re-arming but it's still the HMCS loaded. He responds with "rearming complete" which is not what's expected after adding NVG he should say "NVG installed". Doing it manually clicking through the F-menu in the same jet configuration (canopy open both times) works, and then the response is "NVG Installed" This is with the hornet. "Request NVG" is the command in the manual. Looks like a bug in the connection to API or however it talks to DCS. The same thing is happening with Wingman command "Mission and Rejoin", the command is spoken but flight does not attach the mission target or reply unless you use the F-menu manually.

Hi Guys, A year later and I've noticed this still happens. Is this in the bugs queue for fixing? Thanks

Version: Current openbeta on todays date. Steps to reproduce: -Program Harpoons to any search distance (eg zero), with a destruct distance 10 miles after that -Low flight profile and skim setting -Launch Harpoons when in range with no errors in HUD -Harpoons fly past the destruct point of 10 miles, and keep flying and searching for targets. In the track they actually strike ships that are 26 miles away. Tested this with 10 and 15 miles, in both modes with and without waypoint, and they still fly past the destruct point and hit a ship target. Tested releasing from high altitude and low altitude. Harpoon dont self destruct - high altitude.trk Harpoon dont self destruct - low altitude test.trk

Ahh good to hear, though its a shame their modeling is not up to scratch, I guess it IS a really old module at this point and hasn't had a refresh. We do have quite a few Vietnam era aircraft coming with the F-4 Phantom, A-6 Intruder coming on top of those we already have (F-5E, A-4E), so hopefully a Huey v2 will be on the cards one day just like the Blackshark & A10 got a refresh. One would even hope that the new map technology tested in Marianas could allow a Vietnam map!

Nice, thanks! I hope you or someone else can do the Huey cockpit too, it's still a great chopper to fly but alot of the textures have alot of jaggies especially when zooming in

Hi mate, Had any chance to work on the english version? Cheers

Unfortunately not unless you make a mod. Someone has made an awesome mod for the F-16 that lets you set all kind of presets called "DTC" but currently not for the Hornet. Hoping that one day some keen young dev gets the urge to make something similar. Here's the mod for the F-16:

How did you get the Theme menu to appear? As you can see in my screenshot someone removed my Theme menu as a cruel joke to force me to listen to Christmas lights smashing all year long

+1 Can increase/decrease binds be added for the lights rotaries? Also for the harrier its not available either, could it be added for both? Lighting control panel cannot be used with both Razbam aircraft

Thanks guys, I guess it's another Hornetism that the Maverick page functions a bit differently if you use it more than once. If your sources show it uncaging on the first maverick, but staying caged on the 2nd maverick, then that's what we simmers will have to live with too.

When designating a target with the TGP, the first Laser Maverick will always uncage automatically simply by setting the maverick page to SOI (sensor select switch in the direction of the Maverick page). Once the first Maverick is fired and a new target is designated with the TGP, the behaviour changes and all future mavericks remain caged during the same procedure of TGP Designate -> Sensor select set Maverick page as SOI. Expected behaviour would be that the behaviour of the system would remain the same if performing all the steps from scratch, but it seems there is a state change once the first maverick is fired future mavericks always require a manual uncage. Track is attached, first Maverick uncages automatically. 2nd Maverick you can see it fails to uncage. (Ignore maverick hitting the ground and targeting the ground, the moving targets in the track are in a different position to where they actually were but the uncage behaviour is the same) Hornet 2nd MavE does not uncage.trk