Py

Sorry I don't think I was clear enough on the issue. Maybe it doesn't happen to you? But for me, the new DX buttons don't get set until I move the associated switch. Eg on the throttle a 3 position switch has positions UP/MID/DN, which are mapped to 3 DX buttons DX1/DX2/DX3. There should always be one of those DX buttons active, no matter what position the switch is in. But when running the TARGET script, all 3 DX outputs are 0, so in DCS the switches are in the default state and not the same as the real switch. The DCS option of "synchronise to HOTAS on mission start" is on, but the DX buttons are all zero so it has no effect. The switch has to be moved eg to UP and the state will change to 1/0/0 then back to mid -> 0/1/0 for the state to be synchronised. PULSE mode will not help, as the initial state of the switches will still not be synchronised. For me, I had to move EVERY mapped switch to get the correct synchronised outputs. Does this not happen to you? The code I added at the end of main improves this so any switch or axis change will synchronise all buttons at once, but still one manual action is needed.

OK there seems to be a pretty major issue... The buttons on the virtual joystick don't synchronise to the real buttons when you run the script, so all directx buttons stay off until you move the switch they are driven by. So you have to toggle EVERY switch, EVERY time you run the script to get the output buttons to be properly synchronised. I found a kind of dodgy way to synchronise them all at once, but you still need to cause a single update by pressing any button/moving any axis. Add this at the end of the main function: // Update all the throttle inputs to synchronise the mapped outputs with the actual device state // Not needed for the joystick as all buttons are momentary int i=0; while(i < 52) { DefEventHandler(EV_HID_INPUT_DATA, &Throttle, i); i = i + 1; } Do you know of any way to trigger an update so it will work without any manual actions at all?

Ahh ok, that makes sense. I knew there must be some kind of logic to it!

The choice to put extra functions on some buttons but not others. eg on the throttle the up/down directions have long-press but not left right, and the stick TMS is the opposite with long-press on left/right but not up/down. It's not important and simple to change thanks to your organised code, I just wondered if you had figured out some really efficient control scheme or something that was the reason for those choices.

This is really nicely done sedenion, the code is clear, easily customisable, and well commented. Thanks for providing it! Just wondering, what is the logic behind which buttons you chose to add the submode and long press functions to?

The F-14 can fire in TWS mode which gives you no warning until the missile turns on it's own radar. The phoenix missile only turns it's radar on a few miles from impact, which doesn't give you very long to react, which is the whole point!

On most controllers it is more up/down than fwd/aft, and depending on the controller it can be either on the front (away from the user) or back (toward the user). This is why an option to reverse the direction would be useful. Example - Warthog throttle slew control or coolie hat (away from the user) If you set it logically so that up=antenna up and down=antenna down, then up=zoom in and down=zoom out which does not make sense! Example - Warthog stick TMS or DMS (towards the user) If you set it logically so that up=antenna up and down=antenna down, then up=zoom out and down=zoom in which is logical (this is how DCS does it currently) So an option to reverse it would allow a logical mapping to be used in both situation. Saying it is not "realistic" is not valid because we are not using a realistic hornet HOTAS and have to map functions to non-realistic locations.

Yes please! The current sort by only date is not useful at all, searching manually for popular/highly rated files takes a long time.

So nothing to do with the actual input data then... Are you sure it isn't just something aerodynamic? What speed are you testing this at? Maybe the plane is forced into a high AoA and low speed when you use the end region of the stick and the plane is not happy. Does it happen when the plane is on the ground? Also you could try it on another module to see if it's the same, eg the free TF-51D or Su-25T No need to set up all the controls, just the stick/throttle and do an air-start instant action

What happens if you go to the Axis Tune menu for your joystick axes, are they smooth there? It really does sound like an axis assignment conflict, you triple checked it?

Actually I think it IS a bug. Sure takeoffs shouldn't be done in auto flaps, but something seems to be wrong with the flight model if you do. I thought it might be the FCS doing something odd due to the incorrect procedure so I tried watching the stabilizers while "resetting" the violent pitch up with a quick auto-half-auto on the flaps switch (too fast for them to actually move). If it was the FCS, I would expect a sudden change in the pitch of the stabilizers as it is "reset" and stops trying to pull up hard. I saw no visible movement at all after the "reset", but the plane suddenly stopped pulling up, suggesting that it is not actually the control surfaces causing the odd behaviour. That would definitely be a bug if the plane is being influenced strongly by something besides the control surfaces. I'll watch the other surfaces when I have time, but such a strong pitching moment seems unlikely to be possible with the other control surfaces at low speed.

I get your point. Without input from an actual pilot with experience on this matter, the logical answer is that if they find it difficult to make fine adjustments, they would disengage ATC. Or maybe it's standard procedure not to use it in that situation anyway.

I've been having a similar issue when using double racks but thought I was just doing something wrong. I got sick of testing so didn't quite figure out which bomb went where, but always had the same result of one target getting 2 bombs. This was using 4x double racks and only PP1 for each station, dropping 4 bombs.

I also reported this as well (https://forums.eagle.ru/showthread.php?t=245759), it's a really bad issue but there has been no ED comment in that thread either...

I agree! Actually I was just coming here to write about the same topic. The period is 0.8 seconds, but it's easy to accidentally hold for too short when concentrating on other things in a busy situation. If that is how it really works then fine (but bad design!), otherwise it would be nice to have it fixed.

RAID/FOV button affects both maverick and TGP when TGP display is active When the TGP display is selected as active and the maverick-F sensor view is also being displayed, pressing the RAID/FOV button changes the FOV on both the maverick and TGP displays (incorrect I think). In the same situation if the maverick display is set as active, the TGP FOV is not affected (correct). TGP_mav_zoom.trk

Vertical scan only locks within 5 miles, boresight within 10.

Then please just go away and stop posting if you have nothing useful to add. There are some good possibilities in this thread, I hope ED at least tests some of them out internally.

Absolutely nothing. It just happens to occur in his startup sequence when he is about to start the left engine anyway. I assume he means to begin starting the left engine.

Just wondering why you want to disable the in-cockpit displays. Does it improve the framerate rendering just to the extra displays instead of to both?

But the pipper jumps all over the place under some conditions, while the FORESIGHT moves smoothly. I don't know why, but they must be calculated quite differently.

Please follow these suggestions! A small amount of work for a large improvement in user friendliness, especially for new players.

I've had a similar issue with other weapons, it happens if you move after the weapons are loaded onto the plane but before the ground crew say "rearming complete". The weapons appear visually and on the stores page, but you can't set fuses etc or use them. That is a separate bug really, but could that be what happened in this case?

Yes I noticed a delay when using the warthog with Delta sim mod. Is that what you are using? I haven't tried it with the unmodified warthog. There was no delay when using keyboard buttons or a hat switch.

The bug of bouncing carrier-based planes in multiplayer is back, and combined with wake turbulence it becomes a much greater problem. When a plane spawns on a carrier and then lands at an airbase, it appears fine to the player flying the plane, but to all other players in a multiplayer server it appears to be bouncing up and down at high speeds. This is in open beta 2.5.5.33552, but the bug was also present in the previous version. The bouncing bug originally appeared several months ago and was eventually fixed, but returned a couple of weeks ago. Before it was a minor annoyance, but with the recent addition of wake turbulence, the bouncing planes now cause extreme turbulence in their vicinity. And not just near the plane, the area of effect is at least 500 feet in all directions! A single bouncing plane in the parking area renders the entire airbase unusable to all other planes. The turbulence is strong enough to flip stationary planes, and throws planes approaching for landing around in all directions hard enough to make landing impossible. I have a multiplayer track, but it is very long so here is a short video of the effects. Here an F-14 which started on a carrier is stationary on the taxiway near one end of the runway. You can see it bouncing up and down to the right. The player aircraft is blown around violently from several hundred feet away. Please fix this bug quickly as it really messes up multiplayer when there are carrier-based planes.