FusRoPotato

Yes, it has been reported here many times. The replication requires seeing buildings or trees behind exhaust gasses while in the AV-8's TPOD in thermal mode.

I imagine they did something sneaky, like reduce the smoke sprite size by some large % or reduce its count, not fixing the problem but making the symptoms a lot more tolerable. The Harrier exhaust smoke in FLIR on the other hand is still a massive FPS tanker. I have a 5800x3d with a 7900XTX that will still drop to less than 1 fps while viewing in the aft direction. It's so bad that it can sometimes just cause a complete lockup. I've learned to just switch IR off while overflying stuff to compensate but it's not fool-proof. It's probably reasonable to remove that smoke effect altogether as a temporary solution if this rendering issue can't be solved.

Flying between mountains helps too. Soon as the AI detects you through the mountain, they often just hit dirt.

The AI doesn't need AWACs or ground radar. They will see a helicopter parked behind a tall building from 50 nm away and fly directly towards it until only a few hundred meters away. Somehow the AI knows it doesn't have a shot, but doesn't know it shouldn't have it's nose pixel perfectly aligned with a helicopter behind a building. This is an LOS and awareness fidelity issue, but we could also argue a mission editor issue as well. None of the groups who run these big popular servers know, utilize, or stack the enroute tasks properly. I cracked open one of the 4YA tracks to discover they don't even use search and engage at all. Leaving the tasks and ROE empty bypasses a lot of the checks they'd normally go through so their AI just beams for you soon as you enter their god bubble. Once they started spawning enemy AI directly over top of enemy targets with bad excuses of ED messing up their script, I stopped flying there. Nobody else had problems spawning aircraft at airfields and these guys couldn't even pick a spot somewhere away from the bases, let alone use any kind of script to pick better spots dynamically. ShadowReapers is probably the best I've seen at scripting things based on distances, but they have the enroute tasks and ROE mistakes as well.

Couple things I have been noticing regularly: Radar can lock and track aircraft while on the ground after landing, continues to do so even after turning the radar off. AIM120 handoff issues. Saw an extreme example yesterday while on the tail of a Su-34 ~5nm away. 2 missiles dumbfired from TWS, 1 dumbfired from STT, then reacquired in HACQ and that one also dumbfired. I've not seen similar issues with the F-16, so I don't know if this is an AIM-120 modification issue or if the radar on the F-18 is pretending to be on but not actually fully working. This seems to happen most often after a rearm or landing but I'm not sure yet if that's the actual trigger. Not sure if this could be related or not, but I've also been seeing a lot of abnormal failures to track on AIM-54's as well. Both the Tomcat's 54's and 18's 120's have been less useful than Sparrows on an F-4. 120's from the 15 and 16 seem to be fine though...

Shortly after release, there was some criticism about this issue that got shot down pretty quickly. They firmly stated that there would be no adjustments or changes to it. It's understandable they'd take pride in going the extra mile to model stick force responses, so they were probably a bit offended. We've seen a few comments since from the team claiming that SMEs and internal testers feel the stick behavior is accurate, but there's been no direct support or evidence from those individuals. In fact, we've had the opposite from a few Phantom pilots who've noticed the problem and spoken up about it. They have not yet cleanly demonstrated that the understand the issue. We've tried YT videos showing the motion, detailed graphs, and data logs that compare force-feedback (FFB) to non-FFB sticks, but it seems to keep being met with deflection to other systems or factors such as trim duration. However, the trim rate isn't the issue. It's modeled correctly. It’s been explained that this isn’t a stick modeling issue, but rather a virtual pilot issue. The threaded-rod trim actuator creates a smooth, linear change in stick force and doesn’t interact with the bellows or anything else in a way that would cause bouncing. The stick shakes because the reaction force from the pilot’s arm isn’t being modeled accurately enough for users without a force-feedback stick. This results in unnatural oscillations that the pilot can’t easily correct for. There’s no rate dampening, transient dampening, or anticipatory control algorithms in place to produce a flight control result that is similar to FFB. The unspoken reality in contention here is that stick force modeling is only one part of a two part problem, and that the 2nd part is missing. That is sometimes the unfortunate risk of trying to go the extra mile in uncharted territory. It doesn't always produce a better result and requires more work.

While you guys are at it, you should probably do some digging into MIL-STD-1797A, at least around pg 170+. There's a really large section on it with numerous graphs, eqs, and descriptions outlining the formal requirements of pitch response qualities for a class 1 fighter. It doesn't detail what the F-16C's control responses look like, but provides general guidelines for aircraft in that time period. I could do a more formal presentation, but to be very brief about it, the rise times and transients for this DCS aircraft at MSL are significantly beyond the limits described in this document. Some of the examples and definitions in there might help your evaluations. The cutting down of overshoot at high altitude was commendable progress and I'd like to see both the Hornet and Viper continue to improve.

Based on how trim actuator threads in, it's hard to imagine that you'd feel anything other than a small gradual shift in force on the stick. I bet it should become so familiar that you'd be able to regularly trim without the stick moving a hair. They tried to do something fancy that's awesome for FFB, but isn't remotely appropriate for a sim where its users primarily use spring return sticks. To include force simulation without force feedback, you have to make big assumptions on how the pilot is going to physically react to forces. There are way to many postural options, welding, planting, double handing, leg squeezing/leaning, and force reactions from body jerk and G's that will all make major changes in how the stick itself responds to intention. Most importantly, there's a general familiarity (muscle memory) that get trained into a pilot resulting in fluent and skillful application of controls, all dependent on senses and reactions that do not exist in a computer chair without ffb. This was the result of stepping in towards a higher quality project without the conviction to see it through to a stage that actually results in a higher quality outcome. We fly to the feel of changes in G's and angle, not a theoretical neutral stick force position.

I've been seeing these black rectangles in this and the past version as well, but I don't use any VR equipment. I'm also using an AMD card unlike the rest of you so I'd assume this is a bug in the new shaders.

Some buildings can't be used because their sizes and locations are bugged, and regardless of size, can't be grabbed beyond 7 miles. That is a massive limitation to the standard procedure because it cannot fix to arbitrary pixel patterns when there are no buildings. When there are buildings, they are often bugged causing discrepancies between the TGP and seeker, or significant loss of time attempting to grab the same object in which case they are simply passed because of the original 7 mile limit. It leaves a lot of us making excessive attempts building after building trying to find something to bore on because of how frequently this object method fumbles. I've opted to skip the process entirely because it's easier to manually correct every single seeker. Your team has a tendency to take procedural guides too literally towards assuming their functional realities. 7 miles is considered a reliable lock for a small vehicle because that is the distance of which there is a 2-sigma pixel density view factor. There should be no distance limit with buildings if they can be recognized on screen and you guys still have a lot of building-size definition issues hidden in your object properties, especially on Marianas where the grab size of some buildings are so massive that they get grabbed even when off-screen which completely blocks all units in the area.

Since the simulated locking method is based on defined objects, range, and lighting levels, the bore-sighting procedure is no good. You can't fix onto arbitrary shapes beyond 7km. IRL the fixing algorithm is based on shape and pixel variations, not range. Range can't be calculated until the seeker has been fixed onto a pattern. Additionally, there are a lot of objects with bugged sizes that make using them very difficult. On maps like Marianas, some of the buildings are dozens times larger than they appear, causing a lot of tracking failures for TV and IR's. Having a client option to bypass the requirement is the only reasonable take until the tracking algorithms are completely rewritten.

This is pretty much the crux of the issue, but since we have not yet seen any of the implemented logic, we don't know if the issue is within the simulation of the forces going into the stick from the plane, or the forces going into the stick from the virtual pilot. Claims of it being acceptable by SME's still hasn't been validated nor has their qualification above someone with a background in mechanical engineering like mine. WarThunder gives a good example of the pure opposite of this problem. No matter where you put your real stick, the virtual stick will exactly match it as if your pilot has a terminator robot arm. Every time you return your stick to center, all the control surfaces lock stiff revealing all the natural short period oscillations on every axis. They have no force going into the control surfaces or any kind of inertial/kinematic simulation. On this F-4 module, there's a strange behavior of pilot arm stiffness that is rigid at the extreme deflections, but very soft in the center. If you move the stick forward and back just a tiny bit at the right frequency, you can get the stick to slap all over the place on harmonics, but if you rapidly move it to an extreme position, it instantly locks it in. This indicates either one of two problems: The virtual pilot is relaxed near center and rigid at large deflections The bob weight simulation has an error in inertial kinematics. I've reviewed the diagrams of the mechanical systems and there's no reason for inertia or damping to shift based on deflection, including aerodynamic forces. The bob weights, including the elevator itself, are rigidly fixed to axis and do not change weight or length. Additionally, there are human factors to consider. With an FFB stick, I can hold the stick rigidly and get used to to the response by learning the feedback. The aircraft becomes significantly easier to control and trim. In fact, I can hold the stick perfectly still while moving the trim around. With non-FFB, that choice to hold firm doesn't exist and there's no way to learn the feel of it because it happens automatically in the background. So not only does there seem to be an error in the modelling, there's no compensation for how a real pilot familiarizes themselves with routine handling. The ideal outcome should be that the plane behaves similarly between a user who is familiar with the FFB response, and a user who doesn't have FFB. Accomplishing that human factors consideration should relieve any need for fictional trim rates.

I don't think it would be appropriate as I'm not here to argue to what degree of fidelity this sim should be at, especially if the devs themselves are not interested in the subject. If it's more a matter of finding reasons to avoid investment, it's probably best left as is.

It's not that simple. There's a lot of things that need to be considered, especially the experience and report of pilots. That nose gear is held in position with an actuator that uses position integration logic, meaning you don't have to account for the extra force because the actuator does most of that on its own. There are accounts of it being very difficult to steer via the brakes when NWS was engaged. There were some situations when NWS would occasionally turn off if the aircraft was too light. They had to use brakes for steering, and in this condition, would notice sticky brakes. There is also a geometric consideration implemented for hard landings to stabilize the aircraft when one wheel touched down first. To help prevent roll over on hard touchdown, the camber shifts on the main gear during depression and becomes more positive. Additional to that geometric gear design, the lean of the aircraft itself also contributes to more positive camber on the heavy side and more negative on the light side. This causes both tires to push slightly in the direction of the heavier weight and results in a countering yaw. Heavy left wing -> positive left wheel camber -> right yaw. However, the moments produced by these effects are far too weak to overcome the actuator. A strong sidewind is much more likely to cause problems than any of those, especially tire drag. Tire drag to weight isn't typically documented or studied because they are usually negligent compared to tread patterns, speed, and temperature more than anything, and are very small forces in total. I think you are making assumptions of physics that are more in-line with cars that have flat tires and no power steering. You give your overweight friend a ride and suddenly realize you have to hold a slight tug on the wheel. Older aircraft like the Phantom and Warbirds were known for this because of older tire designs and manual linkages, but the Hornet and Viper were not known for it.

Seems like they refuse to acknowledge there is an error or absence of their virtual pilot modeling. They must have put this topic on ignore assuming it was joystick modeling issue that doesn't exist, or that a white paper will somehow eventually excuse it. It won't, because it's a virtual pilot modelling error. Moving the stick to center shouldn't cause the in-game stick to flop back and forth between -50% and +50% deflection. That is quite literally the pilot letting go of the stick. No F-4 pilot has ever described this kind of behavior before, and I know a few of them personally, because it's not real.

Videos are enough and there's no excuse not to accept them, but I've already listed the names of 3 specific documents older than their block that contain the relevant regulations.

They were allowed a 100 ms response delay as a result of any filtering. I don't know if that is what the delay ended up being exactly IRL or what is measures to in DCS, but those displays ran at 60 hz while receiving data at 20 hz. This required using a 3 point interpolator as a visual aid based on MIL-STD requirements at the time to produce a dynamic display defined as visually continuous (no less than 55 hz). Interpolating a 20 hz signal requires at least 50 ms plus some computation and routing time, thus the delay should be between 50 ms and the 100 ms limit. MIL-STD-1472D from 1989 describes all these requirements, including that gross numeric presentations must not exceed an update rate of 5 times per second. In the DCS F-16C HUD, everything updates at 20 hz. This is wrong and we can likely guess where that number came from. The bearing tape, elevation bars, reticles and target boxes were updated at a smoothed 60 hz from their 20 hz data input. The numbers displayed in boxes ( Velocity, altitude, and bearing ), all updated at 5 hz. This is also true for the HMCS. All components displayed in motion were required to be appear continuous. A 30 fps HUD tape that shows a new elevation bar location on every frame may not prove that a display component should be at 60 hz, but it is solid proof that 20 hz is incorrect. A 20 hz display recorded at 30 hz will always show elevation and bearing tapes that sometimes do not change from frame to frame.

I'd say why but the honest answer is worth about 40 badboy forum points.

Those setting profiles and overrides already exist. You can turn FFB on and use FFB off trim methods for helicopters in the per-module options. Ask ED how to implement the same. This is why this is a Phantom problem and not an any other modules problem.

The the suggestion here is to apply the dynamic slot menu to the right-hand mission editor bar as an F10 map client feature. Pros: Less obtrusive window that has future compatibility with evolution towards DTC and other possible mission or server administration features, such as viewing, selecting, or modifying waypoints and templates as is done in the mission editor for uploading to aircraft as a data cartridge. Cons: This would require Spawn Slots (not Dynamic) to present their player, unit, tail# etc vertically instead of horizontally, or in a table under the slot name. In other words, a mild layout redesign of the original non-dynamic slot choice UI to fit the slim window.

What exactly is it about my response that is acting like a kid? Are you going with name calling because you can't address the point? Most people operate DCS on a decent PC and HOTAS, what's usually a $2000-$3000 investment. I have a top of the line PC, several VKB sticks, and a custom made and working FFB project made of wood, 3d printing, and helicopter motors. I'm a little more than $5000 invested for my hobby and work on simulators professionally. You've wrongly assumed I won't spend money, wrongly assumed I don't have an FFB stick, and are probably unaware that I've printed graphs in another thread showing both the physical FFB response and the error response of a non-FFB input against the virtual position. All the aircraft in DCS utilize a rigid virtual pilot to firmly hold the virtual stick where the user is holding their physical stick. They do this because this is the common setup. They sometimes go even further than what is being suggested because developers (HB included) respect accessibility options. They provided some for the F-4 already. You argue the F-4 should be an exception here, that a loose grip of the virtual pilot should be in place to make FFB users have better control of their aircraft, despite them having provided a few accessibility options? Nobody mentioned or requested any kind of game mode, xbox controller support, or anything unrealistic. What is being asked of is realistic virtual pilot modeling. We're talking about the interface between stick reaction forces and a standard HOTAS (not cheap) that almost everyone here uses.

I don't know where you get flight model and xbox from, but I assume you're just committed to being disingenuous or have no understanding of the issue. Like I said before, to some degree the sim needs to be accessible. This sim has a small userbase and the majority of them have limited hardware. Reasonable accommodations need to be made for the use of a standard HOTAS. That means if stick forces are going to be modeled into a non FFB stick, there needs to be a virtual pilot modeled that reacts to those forces reasonably. It doesn't make sense to assume the pilot will always have noodle arms or never brace. It's why you have your helicopter trim release gimmick options, lower details, and a host of many other options unique for each aircraft concerning force, trims, and rudder assistance. I do and can expect the devs to adjust virtual pilot models so that people with a HOTAS aren't limited to an artificially degraded experience.

That's still been my experience. If you want to search and lock for stuff, fly from the backseat.

Why is it defaulting to 0.0 instead of 1.0, and why does the UI often fail to respond to mouse clicks? It usually takes me 10 or so clicks just to open the bomb selection menu, and if I want 0 degrees, I have to set it to a different value and then click it back to 0 again just to get the correct coef.

ok but most people don't go that route. Most people expect they can use standard hardware and won't be hindered to any significant degree because they didn't invest a thousand dollars on an extravagant stick. There are people flying on old computers with tiny monitors, let alone big screens, 4090's, and VR kits. A lot of people aren't even using pedals. It's not hard to devise a virtual solution to make those levels of hardware accessible. In this case, it's as simple as putting the virtual stick closer to the joystick instead of having it flop around like a dolphin just because they didn't buy a $1000 stick. It doesn't matter if the stick is better, it shouldn't be needed.