LeCuvier

It's already reported as a bug. See this thread: https://forum.dcs.world/topic/321349-skhval-wrong-texture-with-mt/#elControls_5172779_menu

I have always seen the Shkval display as monochrome, sometimes greenish, sometimes greyish. Under MT now it displays full color. While I'm not complaining about this luxury I suspect it's not meant to be this nice. Can an expert comment please? I attach a screenshot which I took from an exported view for better quality. The display on the main monitor shows the same colours.

I use the left throttle on my TMWH throttle. Works fine. If you have a game controller (e.g. button box) with rotary encoders, try one of these. They produce extremely short input pulses and usually work well with over-sensitive key inputs.

I have to apologize: The reason why I have these axis commands is that I have added them to "default.lua". The stock file does not have them, and the reason I have added them a long time ago is that the stock file didn't include them at the time. And I doubt that it ever did. If you want to wait for ED to make the addition you might need a huge amount of patience. I suspect it's a low priority because few people have axis input devices to spare. If you want to make the addition, here are the lines of LUA code i added: {action = 3001, cockpit_device_id = 49, name = _('Engine Instruments Lights Axis')}, {action = 3002, cockpit_device_id = 49, name = _('Flight Instruments Lights Axis')}, {action = 3003, cockpit_device_id = 49, name = _('Auxiliary Instruments Lights Axis')}, {action = 3005, cockpit_device_id = 49, name = _('Flood Light Axis')}, {action = 3006, cockpit_device_id = 49, name = _('Console Light Axis')}, {action = 3011, cockpit_device_id = 54, name = _('UHF Radio Volume Axis')}, {action = 3005, cockpit_device_id = 55, name = _('VHF AM Radio Volume Axis')}, {action = 3005, cockpit_device_id = 56, name = _('VHF FM Radio Volume Axis')}, {action = 3013, cockpit_device_id = 38, name = _('Yaw Trim Knob Axis')}, This post is obviously not a solution, just a work-around.

I checked in Open Beta and all the axis command lines are there as far as I can see. See attached screen shot. These are the same lines as in the stable release which has not changed for a long time. What lines are you missing? Please post a screen shot of the page!

I have my HMD knob bound to a rotary encoder on my button box, which works very well. Wanted to see whether the problem reported here is a general issue. So I bound the HMD Axis to the slider on my TM WH throttle. Result: No issue here. I can set the HMD over the full range from OFF to 100%, and it does not jump back to a different position.

This might be caused by default bindings in the .diff.lua files. I found this piece of code in the file "Throttle - HOTAS Warthog.diff.lua" under "DRIVE\Eagle Dynamics\DCS World OpenBeta\Mods\aircraft\FA-18C\Input\FA-18C\joystick" ["a3003cd58"] = { ["added"] = { [1] = { ["filter"] = { ["curvature"] = { [1] = 0, }, ["deadzone"] = 0, ["invert"] = true, ["saturationX"] = 1, ["saturationY"] = 1, ["slider"] = false, }, ["key"] = "JOY_SLIDER1", }, }, ["name"] = "HMD OFF/BRT Knob", This seems to provide a default binding of the axis command "HMD OFF/BRT Knob" to ""JOY_SLIDER1". I found the same in the file "WINWING Orion Throttle Base II + F18 HANDLE.diff.lua" and there may be more. I did not check all the .diff.lua files, so such a default binding may exist for more controllers.

Thanks for sharing this, @scoobie! I had no clue this was coming. Going forward, this may reduce the need for LUA editing. I would have expected that you could select the OFF transition by flicking the switch from ON to OFF, but it doesn't work that way (yet?). But even so, it's a very welcome addition!

That's certainly correct, but the tough part in BVR is to find and lock the target if you don't have any info about your target's location.

No. These commands require a switch with 3 stable positions, if you want full "realistic" functionality. You should have equipped your button box with a few maintained 3-position switches. Personally, I never use the "Train" position of the switch. With that usage philosophy, the momentary toggle switch is fine.

Thanks for clarification! I will make it a habit to power the HARMs up from the SMS page. And it would certainly help to have correct and complete instructions for weapons use in the documentation.

I used to open the HARM format page from the TAC page and this should work, as the Early Acess Guide states: "When the HARM is selected in either manner, it will first default to the Self-Protect (SP) mode or the last selected mode. From the SP mode, the other modescan also be selected: Target of Opportunity (TOO) mode and Pre-Briefed (PB) mode." Either manner, that's from the SMS page or from the TAC page. Also, the HARM works in SP mode even when I select it from the TAC page. I therefore doubt (with all due respect) that the HARM is not powered ON if selected that way. @NineLine: Can you please get clarification? As far as I can see, it's either a bug, or it needs to be corrected in the Early Access Guide.

My post dated 18-JAN-2023 indicates that I have created a new thread with a more recently updated version of the document. I do not update the document in the old thread. The fundamentals described in the document don't change that much. So don't expect an update every year. And the stuff about "Misc" settings is totally out of scope for that document.

Bingo! When I open the HARM page from the Stores page the TOO handoff works like a charm. Thanks for spotting this, I was getting desperate! I would guess then that we have found a bug that needs to be addressed.

I have spent a fair number of hours during the past week trying to understand how the TOO mode works. I have used a slightly modified version of the stock mission "Caucasus FA-18C AGM-88C HARM". I believe I did everthing right (according to the Early Access Guide) but would be grateful to learn what I might be doing incorrectly. I have been very careful to always use the same steps, avoiding all unnecessary variation. I will describe what I experience in about 95% of all instances. A track is attached. When I approach the target zone in TOO mode the first time, the HARM display shows no radars. At some point, the HARM warns me and switches to SP mode. I fire a missile and turn back to get to a safe distance. The missile hits. I turn around for a new run and switch back to TOO mode. As I get close enough, the HARM display in TOO now shows the enemy radars, with one of them boxed. So I hit the "Cage/Uncage" button, but no handoff happens. Also the "HARM Sequence" button has no effect. I also tried the "I" and "C" buttons, no effect either. I keep trying, until I get a new threat warning and the HARM reverts to SP mode. I fire my second missile etc. etc. This continues until I have fired my 4 missiles. In one instance out of >20 the TOO mode worked as expected. In another instance it switched to SP mode and I fired the missile, and after switching back to TOO i could actually hand off. But these were rare exceptions. Again, I would be happy to learn where I went wrong. But please no speculation like "the HARM display was not SOI". It was! FA-18 HARM TOO No Handoff 2.trk

This worked for me! Thanks!

Yes, certainly.

I'm not sure at all, and I can't really tell because visibility on the MAV display is rather poor in my perception. Do I actually have to designate the 2nd target in the MAV display?

Trying to learn the use of the MAV with ATFLIR. I have 2 targets sitting at Waypoint 2. In the approach, with MAV and ATFLIR active on the MFD's, I designate to waypoint 2 and slew the ATFLIR to the first target. SOI to MAV and Rifle. The first MAV goes and hits the target. Now I want to strike the 2nd target. I hit the "Undesignate" button, slew the ATFLIR to the 2nd target, SOI and Rifle. The 2nd MAV goes and hits the first target which is already dead. I have tried this several times with some little variations, but the 2nd MAV never hits the 2nd taget. What am I doing wrong?

Yes, but it's custom code heroically developed by an enthusiast, and that code could be broken by any future ED update.

I would be happy if ED provided a solution that allows us to add bindings that are not lost during updates. The Mod manager helps, but it does not merge new ED-introduced bindings or changes to existing bindings into our modified LUA files.

I'm in open beta. I have been able to make the boresighting on the ground work twice in a row. But it seems very unforgiving. No errors allowed. Now I have another issue, which also exists in air-start missions: I want to hit 3 colocated targets at the same steerpoint. So I point the TGP to the first target, handoff, MAV go! Then I move the TGP to the second target, handoff, MAV go! And same for the 3rd target. Unfortunately all 3 MAV's hit the same target. What's the magic to make the handoff go to 3 separate targets?

I agree. Spent hours again to make it work. I'm utterly frustrated and will therefore not say any more.

I still have concerns about the boresighting process. Let me explain: I had boresighted weapon stations 3 and 7 (carrying AGM-65D) on the ground, before takeoff. After the boresighting process, before takeoff, I switched Mavericks and TGP OFF and reverted to NAV mode. Once airborne, I activated A/G mode and re-started TGP and Mavericks, and set everything up for preplanned mode. Hit CZ and selected steerpoint 5. Designated the first of 3 targets at that location and within 7 NM range handed off and fired the MAV. It hit the target. Worked like a charm for this first MAV. On my run-in for the 2nd target I designated the new target on the TGP and tried handoff. But the MAV seeker did not correlate to the TGP-designated target. I tried several more runs but without success. I have a second version of that mission which is air-started, so the MAVs are boresighted at mission start. The mission has the same load-out with 2 each AGM-65 on stations 3 and 7 . Targets are at 2 steerpoints. In this mission, handoff works for all targets. Despite some statements in posts above, I suspect that the boresighting process executed once per station does not boresight all MAVs. I will run more tests to exercise the boresighting process.

That's neat; but with the flip trigger on the original VRP T-50 stick I cannot do that, because the "flip-up" doesn't generate any signal. IThe flip trigger is just another button that's activated when I pull the flip trigger in its DOWN position. Newer VRP grips provide a separate switch for the UP position. But I can live with the single button functionality as the KA-50 HUD shows clearly what mode I'm in.