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

I can second this. For me the HAD cursor just doesn't feel smooth compared to the FCR.

I noticed two behaviors, which I thought were strange, and thought I'd post them for comments/investigation. Firstly, if I achieve a moving point track on a vehicle and then I switch ground weapons, the point track is lost. I would have thought the point track would be independent of the weapon. Secondly, if I manoeuvre such that I lose line of sight of the moving vehicle for 15-30s, the point track is maintained and is perfectly tracking the target when the TGP regains line of sight. I wouldn't be surprised if the TGP could attempt to predict the position based on the previously observed motion, but am somewhat skeptical that it can do this perfectly. I've attached a track showing both of these behaviors. testTGP.trk

This sounds awesome. I've been waiting so long for another F-16 campaign. Do you have an approximate ETA?

For some reason my throttle bindings were set to default after the latest patch, although it is generally not an issue I face on a regular basis. My joystick settings were untouched. Edit: I fly the F16.

I wasn't sure where else to post this and it might not necessarily be a bug. I've been modifying my HOTAS and have been doing a lot of testing recently, particularly with the TGP. I've noticed that when very close to targets (e.g. flying overhead when dropping GBUs, or zoomed in at close range) that the image is very jittery when the radar cursors are being moved. Without touching the radar cursors the TGP tracks smoothly. At long range, while the problem may be present, it isn't really an issue. It could very well be limited to my setup. I would be very interested to hear if others can observe this with their setups or if it is just me. I've attached tracks with the F16C and A10C II demonstrating this behavior. Thanks. Edit: I just did the same test but instead of using my HOTAS, I bound the RDR cursor to the keyboard (to rule out any obvious sensor-related issues). This also produces comparable amounts of jitter (on my system); it might be some type of sampling/polling issue. I think it deserves further investigation. testTGP_A10CII.trk testTGP_F16C.trk

TMS long button presses must first be released before the mode change is initiated. This can be observed in the following scenarios: - TMS Right when FCR is SOI (switching between RWS and TWS) - TMS Up when HUD is SOI and wanting to select the HMCS for markpoint creation It was claimed here that this behavior is not correct: I'd ask this to be referred to the team to see if this behavior is in fact correct. Interestingly, DMS Down long to blank the HMD works as I would expect it to; the HMD goes blank while the button is still being pressed providing visual feedback that you can release it. You can test this behavior in any instant action mission.

Sorry to hijack, but I found your last point very interesting that TMS long doesn't have to wait for the button to be released. I definitely have found this a bit frustrating (also for setting HMCS to SOI). It would be nice if the system responded after 0.5s giving the user visual feedback to release the button. I can't find a bug report for this; maybe it should be reported if it hasn't been already.

You have to provide power to the HAD (SNSR PWR Left Hardpoint).

I was on a MP server taxiing behind a Hornet and noticed that the heat blur effect (set to High on my machine) was being applied to the HUD in my F16. I'm not sure if it is specific to the F16, but I would guess it isn't. I wouldn't expect my HUD to be blurry. Screenshot attached.

First suggestion: When creating a new group, it seems that the unit names are inherited from the last group name (I'm sure this is a bug and has been reported before). It would be nice, at least cosmetically, if groups had a property, which by default was set but could be manually disabled, which automatically aligns the group/unit names. For example, if I change a group name to SA10_1, it would automatically set the unit names to SA10_1-1, SA10_1-2 etc, if the autonaming property is set. Second suggestion: This became apparent as I was looking at some fairly large mission templates developed by others. I found the skill was set to Average for several hundred units/groups and there seems to be no other way of setting the skill level than to manually select it for each unit in the group for all groups in the mission. This should be possible via scripting, but shouldn't be necessary since I would guess that most people who build missions probably use the editor exclusively. An optional property to align the skill levels of all units within a group would be nice. Third suggestion: I saw another suggestion regarding a group list, which I think would be great for large missions. Currently for the user list there are columns for unit type, skill, status etc. If these columns could be extended (user definable) to include properties such as group name consistency, late activation, hidden on MFD (or any other useful common property), the ability to modify properties of multiple units/groups simultaneously (via shift or control clicking) would be very helpful.