Darkdiz

Player not available in ME IIRC, client only. I made a custom mission for it, still no joy I don't have that mod, I DO have the F-15E (RAZBAM). I'm choosing the FC3 F-15C, which USED to work fine until the upgrade(?) to FC2024

After the most recent recent patch, I am unable to fly the F-15C (flaming cliffs). Cold start, free flight, doesn't matter. The screen shows the map, and thats it. The voice-overs work, and if I hit F2 I can see the jet, but cannot get into the cockpit. The jet seems under AI control as well. In other threads I have seen other folks with the same issue. I was hoping that the FC auth fix would fix this as well.

I upgraded to FC2024 (legacy FC3 owner), all of the aircraft, including the legacy ones seem to be there. IIRC, I had to use the old module manager to get to where the files would download properly. That being said, all of the aircraft are available, but the F-15C's cockpit is unavailable. If it is a hot or air start, the aircraft is visible in F2 view, but seems to be controlled by AI, even with Client or Player selected in the ME.

Trying to stay on topic... Apparently the TFR is also date-challenged

In any court of law, truth is the first casualty. So who is "right" and who is "wrong" becomes irrelevant, and is really a function of how good your lawyer is

Outstanding work Loophole, outstanding. Maybe the "displacement" spelling works, because IIRC when I remmed certain ones out as in my original post I got a different result on the display. At the end of the day though, clearly a bug

Could be. The post I got it from said diplacement, but to me that didn't make sense, so I changed it to displacement. Did you test it with diplacement? If so, did it work? Hope so, that would be AWESOME! UPDATE: Tried it with diplacement, I get the whole screen grid once again, and no ability to control the radar cursor

So after more f!@#ing around with this... RHAW export works fine, I couldn't see any side affects of this export. To export this, do the following: Monitor config file, add your viewport. I called mine F4_ALR46, the final input into this lua file should look something like: --/////////////////////// --F-4 --/////////////////////// F4_ALR46 = -- MFD 2 { x = 1205; y = 600; width = 600; height = 600; aspect = 1--600/600 } --F4_DSCG = -- MFD 1 --{ -- x = 90; -- y = 600; -- width = 595; -- height = 595; -- aspect = 1--600/600 --} Note that I have double-dashed my DSCG viewport, just too many bugs right now in this export, I'll discuss that later in the post. For the ALR46, you will have to adjust the x and y pixel coords, as well as the width, height and aspect for your own setup. For the DSCG, clearly a few bugs that need to be worked out by HB. In no particular order: 1 - If the DSCG is exported, I lost my ability to control the radar cursor. Bindings work without the export. Range NOT displayed on the DSCG 2 - If a TV source is selected, it displays, but also displays on the HUD. Looks like its the first monitor export contents that are displayed (so since mine is the ALR46, this is what got displayed, if I disabled this export, the TV image was displayed) 3 - Most folks get the radar grid lines displayed over their entire DCS-defined screenspace. After much testing, I found that adding update_screenspace_displacement(1, true, 0) to various files in addition to the dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") try_find_assigned_viewport("F4_DSCG") lines got rid of the overlaid gridlines. 4 - Finally, if you select a TV source, the targetting crosshairs (looks like # on the display) will remain on your display, and cannot be erased (at least I did not find a way) The list of files I played with are as follows, all in the mods/aircraft/F-4E/cockpit/Scripts folder RHAW/Indicator/init_bake.lua --> added dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") try_find_assigned_viewport("F4_ALR46") DSCG/indicator/init.lua DSCG/indicator/DSCG_Pilot/init_bake.lua, DSCG/indicator/DSCG_WSO/init_bake.lua --> added dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") --update_screenspace_displacement(1, true, 0) try_find_assigned_viewport("F4_DSCG") Note the update_screenspace_displacement(1, true, 0) is remmed out (ignored by the system) Radar_Indicator/radar_page.lua, TV_Indicator/hobos_page.lua, init.lua, maverick_page.lua, pave_spike_page.lua, walleye_page.lua --> added dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") TV_Sensor/init.lua --> added dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") --update_screenspace_displacement(1, true, 0) try_find_assigned_viewport("F4_DSCG") Clearly more testing needed here, there are a myriad of combination left to try (I never got around to playing with the remaining files in the TV_Sensor folder other than the init.lua file. As I stated above, Until someone with more talent (and time) than I figures out the DSCG export, I'm just going to use the ALR46 export. Sorry for the long a technical post, good luck to folks who use this try try and move the football. Diz out

I HAD that, but I managed to get rid of it by adding the following to the dscg/indicator/init.lua between dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") and try_find_assigned_viewport lines: update_screenspace_displacement(1, true, 0) It should look like this... (my custom viewport is F4_DSCG) dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") update_screenspace_displacement(1, true, 0) try_find_assigned_viewport("F4_DSCG") I also added the same line as above to the following files: /indicator/Radar_indicator/radar_page.lua, TV_Indicator/walleye_page.lua, pave_spike_page.lua, maverick_page.lua and hobos_page.lua. There is STILL a bug that I haven't figured out yet... When you select (arm) one of the stations you have a tv on (Maverick, Walleye etc) you get the image not only on the monitor, BUT IN THE MIDDLE OF THE HUD! Clearly a bug. Seems that whichever the first monitor export you define (I also have the ALR46 exported to a different monitor), this will be displayed in the center of the HUD. If I disable the ALR46 export, the DSCG image gets displayed in the HUD. One more thing I see: If you switch from Radar to TV and get an image, the crosshairs from the TV display will remain on the radar image. Its early access, so I guess these things are to be expected. I'll be playing with this, and trying to sort out a few other issues today

I think its a bug tbh. The RHAW works fine, but not the DSCG. The radar scaling is clearly SOMEWHERE, just haven't found it. Hopefully a fix at some point

The RHAW exports, so does the DSCG, but there are issues with the DSCG. For whatever reason, when I initially got the DSCG to display, I got what you would expect, the grid and cursor. Then, all of a sudden, I got the entire DSCG display overlaid onto my entire DCS screenspace, and try as I might, could not get that to disappear. I never successfully got the TV display ot work, but TBH I didn't try all that hard, as I was still working on the DSCG. For the RHAW, I editied the maingame/mods/aircraft/f4e/cockpit/scripts/RHAW/indicator init_bake.lue by adding the following: dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") try_find_assigned_viewport("F4_ALR46") Then, in my monitor config file, I added the following: --/////////////////////// --F-4 --/////////////////////// F4_ALR46 = -- MFD 2 { x = 1205; y = 600; width = 600; height = 600; aspect = 1--600/600 } F4_DSCG = -- MFD 1 { x = 90; y = 600; width = 595; height = 595; aspect = 1--600/600 } Obviously, the monitor config file will wildly vary from person to person. The RHAW dial grid also will not export, its just the data (I think similar to the F-14 ALR). The F4_DSCG line will display at those coords, however, I get the full radar grid over my entire screenspace. Its also a bit blurry, I suspect the large grid that is overlaid has something to do with that The file I edited was maingame/mods/aircraft/f4e/cockpit/scripts/DSCG/indicator/init.lua by adding the following (for the DSCG): dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") update_screenspace_displacement(1, true, 0) try_find_assigned_viewport("F4_DSCG") The second line in the above I am unsure of, I got it from another post on the forum, linked as few posts above. I also can't directly recall if I added the lines to the DSCG_Pilot and DSCG_WSO/init_bake.lua file (I'm about 75% sure I did, but note in the WSO file, the ViewportHandling command is already there, but without the try_find_assigned_viewport command). Since I couldn't get it to work, I double-dashed the lines for now, so they are ignored in my setup. I'm kind of "other tasked" right now, not sure how much time I can dedicate to this, fixing it as either going to be a HB thing, or its something stupid, like a syntax error or a setting. Please feel free to edit these lines and update the thread with successes or failures as they occur. Hope folks aren't as confused as I am

I found the answer here: You can actually call them what you like, mine are F4_ALR46 and F4_DSCG, as long as it is the same in your monitor setup lua

I have both the RWR and DSCG working (that is exporting to the correct monitor in the correct position). However, the DSCG only exports a blank, white screen, not what is displayed on the pilot/wso display. Still working on it.

Anyone figure out the names for the F4 radar and RWR? Trying to export them to my Cougar monitors UPDATE: Got the names and viewports sorted, but the DSCG exports as white, completely washed out. Any ideas? Still tweaking the exact position of the export

Very odd. Repair?

Once I updated to the latest patch, then I had to purchase the module, download it, then create a mission from scratch in the ME. I put it up on my server, works fine

yes. Works fine as far as I can tell

Same issue for me, I get around it by copying the Sinai map folder from my game install. I THINK the 2 files you need to copy over are dcs_manifest.bin and dcs_mt_manifest.bin (they were the only ones modified with the patch in this folder)

Yeah, figured it out... Designating with the HUD: In A-G MM with no tgt designated (boat switch aft), ensure the TPOD is in slave mode (Auto Acq press with TPOD in command, ATRK/PTRK unboxed). Take command of the HUD (Castle Press Short and Castle Fwd Short). If the "take command of the HUD" process is done a second time, the TPOD will automatically slew to the position of the velocity vector, and will remain slaved to the VV. PB17 on the TPOD will show SP RET. If the TDC button is pressed, as expected a tgt point will be created at the point of the pipper, however the TPOD will now remain locked onto that point, and the A-G radar will display a tgt point at that position. HUD cues will be for the release of the weapon to impact this point but will vary depending on if the system is in CDIP or AUTO mode. Auto Acq aft short with the HUD in command switches between the 2 release modes.

Was flying with a friend of mine and he managed to get the TPOD to slave to his A-G reticle. He was in A-G MM, took command of the HUD, took command of the HUD a second time and the TPOD slaved itself to the A0G pipper (center of the reticle). He was able to do this in CDIP or Auto mode. I was unable to duplicate this. Is this an undocumented "thing"?

Turns out that the keyboard was not recognizing the WIN key. Put another KB on, seemed to work now

Up until a few days ago, active pause worked fine (LSHIFT+LWIN+PAUSE). Now, even in the controls menu, it does not see this key combo, and I cannot select active pause. Ideas anyone?

Make sure the "Force AM" on radio 2 is starred (assuming you are using radio 2 to contact the tanker). Its on the radio 2 sub-menu, PB9. I was having that problem as well.

What I have found is that even if the pilot's XFR (PB1) button has nothing beside it, if the WSO designates (with whatever sensor) the transfer by the pilot STILL transfers the coords to the selected JDAM. To check, the pilot reads off the last 3 digits of the lat and the last 3 digits of the long, they SHOULD match what the TPOD/RADAR/Seq Pt says. The NAV designation (steerpoint with a decimal) gets you going in the right direction, and in the vicinity, unless it is a static tgt (building etc), then you can pick off exact coords and transfer them (pilot if he wants to do the drop and get the proper release cued. Agreed, its bugged, and hopefully fixed as the desynch issue has been problematic for some of the newer folks to the F-15E, and has detracted from several missions we have run.

Really like these. One thing you can add that I just learned, is that the NCTR can be done WITHOUT going through the EID IFF matrix by coolie right short. Coolie right long will also do the NCTR, but the system will run through the complete EID IFF matrix (interrogate whichever modes you have setup under EID). As well, another thing I discovered is that the AAI/EID works even if your radar is in stby. You get a return if a correct code is returned at the proper range and bearing of the contact on the radar display. It will either be a diamond (modes 1-3) or a circle (mode 4 friendly). Auto acq press will erase these mipples from the display. Obviously, you will get nothing if the tgt transponder is not replying (most hostiles dipn't reply, but friendlies do)