Hellbat

+1. I also noticed this a few days ago.

I will add more evidence to this. Same issue fundamentally, but I can get this behaviour when I set a markpoint with Mavericks in VIS mode. Changing the weapon submode to PRE causes the behaviour described above. Track attached. markpoint.trk

I've just recently got back into the F16 and have also noticed some weird behaviour while playing with mark points, particularly when changing between the weapon submodes (VIS, DTOS, PRE, etc). As an example, I set a mark point using the TGP in VIS mode (Mavericks). I then hit M-SEL to make it the current steerpoint and when I go back to PRE mode and TMS down while still set to steerpoint 26, it points to what looks to be steerpoint 1. Only after changing the steerpoint and then going back to steerpoint 26 does it point to the right location. Not sure if it is intended behaviour or not. markpoint.trk

I'm really enjoying this campaign so far! Most missions take about 1-1.5hrs which is perfect, but I also appreciate the occasional longer mission. Just flew Mission 9 and I understand you don't want AAR to be necessary, but Part 1 felt rather underwhelming and then automatically setting up the cockpit in Part 2 wouldn't be necessary. The break felt a little awkward and I would have loved flying it as one long mission with refueling. If people are unable to refuel, what about giving them the option for unlimited fuel? I've not played around with this in the mission editor so I'm not sure what the possibilities are. They could rendevouz with the tanker and use the F10 menu to select finished refueling without having to take on fuel. This would be no more unrealistic than the option for invincibility at the start of each mission. Just something to consider for the next campaign.

Thanks @Radboy16 and @doright for adding your experiences of this issue. @BIGNEWY can you provide an update? Has this been reproduced internally?

null

I'm not sure how the decision was made so quickly that this is a hardware limitation without checking the track file. My ministick has 10 bit magnetoresistive sensors and I don't experience issues in other modules. The same result was obtained on a brand new Warthog HOTAS in September 2022 and while Thrustmaster stock sensors aren't the highest fidelity, if these are considered low quality, then I'm not sure what hardware passes as good quality? Edit: I just mapped my Gunfighter Mk3 base to the TGP slew control. Same behaviour!

Hi, I brought this issue up 9 months ago while testing the Warthog HOTAS, yet I don't think it was really considered a bug. It has been observed on multiple hardware setups. I recently decided to test the module again and it persists. I believe this is a software issue and I am reporting it as such. The issue only occurs when HOTAS slew is controlled with an axis; for those who use discrete buttons, you wouldn't notice this. If I slew to the limits in left/right and make small adjustments up and down (around the 3 o'clock or 9 o'clock positions), it appears to ignore one of the axes of my controller as it crosses into the new quadrant. I have attached a track file where I first demonstrate behaviour with the keyboard and then I do the same thing with the axis and you see the slewing just randomly stops, but I am holding my joystick at its limit. It only recovers once I reset the mini joystick closer to the center. I tried modifying the calibration of my hardware so that when I pull the axes to their physical limits it only registers as 96% in game. This alleviated the problem when slewing left, but not right. This suggests to me that it is in fact a software issue. I'm not sure what resolution the input signals are converted to in the game world but I think this bug should be simple to find and correct and I don't think it is worth it sacrificing 10%+ of the resolution of my physical sensor to try and get a workaround. warthogThrottleIssue.trk

When I upgraded to a wide-gamut 10-bit monitor I also noticed banding at night and on darker skies. I fixed it with the debanding filter in Reshade and now it is barely noticeable.

I bought some DIN912 M3 and they fit perfectly. Link (Germany) to where I got mine: https://rc-schrauben.de/Zylinderkopfschraube-DIN-912-M3-Stahl-129

Ahh cheers. It didn't even cross my mind that today was Halloween and I thought the guys above were just joking

I also noticed the bloom effect seems too yellow/green. Attached a couple screenshots. In the cockpit, it is a little more subtle, but look on the center console where the left leg should go. This effect seems to be there on multiple maps for me. I think it is as straightforward as just tweaking the colours of the bloom effect.

Hmm, does that mean that watching my track replay doesn't show the unexpected stop in left/right motion? I watched it back on my system without any input devices attached and I saw the behavior. The easiest way to reproduce on my system is to select TGP as SOI in A10C II, hold the slew ministick as far to the left as it goes. The TGP will start slewing to the left. Now, maintain maximum displacement on the slew ministick and move it up and down around the 3 o'clock (or 9 o'clock) position (depending on how you look at your sensor). When you first slewed left the vertical sensor probably had a small nonzero value which resulted in a very slight up or down trend. As soon as the vertical component changes sign from this initial input, I lose the horizontal motion and the TGP only slews up and down. Horizontal motion only starts again if I release the ministick a little and then it seems the game gets updated with the new sensor value. I originally had the autodetected TM Warthog settings, although playing with saturation and curves didn't resolve the issue. It might be that throttle setups with older analog sensors might have enough noise from the potentiometers so that there are constant perturbations on the sensor values which masks the behavior described above.

To add to this, I just tried the same test with my Cougar throttle and I can reproduce the same behavior; the Warthog throttle is fine, but this seems to be a limitation in the game how the axis commands are interpreted when the sign of one of the inputs changes.

Hi, I am testing a brand new Warthog throttle and noticed something very peculiar with the slew control. When I slew in an arbitrary x/y direction and I then slide the stick such that the sign of the vertical input changes, it ignores the left-right command which is being held. When I play with the inputs in game on the controls screen it all looks fine, but it doesn't work in the cockpit while flying. I performed a slow repair, no mods are installed and I demonstrate this behavior in an instant action mission. I start by slewing the TGP cursor left and up/down and as I alternate between up and down you can see the cursor freezes unexpectedly. I would expect that the cursor should not stop moving to the left or right as it is being held. warthogThrottleIssue.trk