FusRoPotato

Why would people want to buy a module that requires more expensive hardware? Why not just make the module optionally more compatible/usable with a standard joysticks?

The only serials with the 107 were D variants, and they were largely temporary. Those things were so useless they just got discarded. Before the APQ-120's were available, they shipped the earliest E variants without any radar at all. They had originally planned for 107's to go in but ultimately decided it wasn't worth the weight. Regardless, CAA was only useless on the first deployment of the 120. The 45 should have been long past numerous upgrades, especially a major one deployed standard in 68 featuring that card. I can't really think of a good reason one would want to model an earlier mismatched version of this radar that can't even perform its functions reliably. It's almost akin to throwing the 107 in for laughs.

Actually they were developed at about the same time. This particular Phantom (1969-70) was only about a year or two older than the first Tomcat. Block 48 (1971) received pulse-Doppler modifications at the same time the Tomcat with the PD updated AWG-9 (1971) came out, and shortly after the AWG-10 was developed, the APQ-120 was updated to incorporate similar look-down/shoot-down capabilities. In fact, I've been a bit confused as to why this block 45 doesn't have many of the upgrade features tested on block 37s that were later implemented for the block 38 that made locking of sidelobe clutter virtually impossible and enhanced a lot of performance aspects of CAA mode. I was speaking to one of the HB reps on reddit a while back and mentioned the modulator card and how it stored return gradients in memory to validate targets against sidelobe clutter during CAA scans. It was one of several components sometimes found on blocks 33-37 for various testing applications. He acted like he had no idea what I was talking about. Sounds like they modeled this block 45 to have the radar of the block 31/32 before they had started modifying it. That's very interesting considering the later model RWR and display that was implemented. Things don't seem to be matching up for their year.

It's not really a non-sequitur. Relative to other sims, nobody flies DCS WW2. The dozens of us don't count, and just because I blame one reason doesn't mean there aren't many more. The WW2 implements within DCS lack a large degree of quality found in sims that are typically considered lower fidelity, like tail-slide center-of-lift shifting, torque, spiraling vortex, gyroscopic and p-factor moment effects, and/or low-speed tail-wheel caster stability mistakes. During a slide, we get this assumed perfect continuous laminar flow effect over the tail no matter how fast we're sliding and just get somewhat stuck, nose up, without any presence of torque spin. The call that implementation. Some of the DCS modules didn't even feature fake scripted versions of the effects for most of their existence like the T-51 and yak. At best they just perform a little wiggle. The evidence of hackery, magical dampers, and mystery coefs used in their methods to fake some of these effects are all throughout their lua files and paint a pretty strong picture of how underdeveloped the WW2 FMs are. Sometimes people who throw praise around are just having a wank. The proof is in the community involvement. You won't convince me people don't play around with it just because it's era inaccurate or costs $100 to get into. Go tell that to a Warthunder player. However, the analogy was intended to target the importance of things that matter. On one hand you can skip a lot of high fidelity components and still have a strong and satisfying representation of a plane's nature and legacy, but if you only go halfway and skip considerations for human-to-hardware interactions, you can get the potential for a worse outcome through a higher offering of fidelity. I think this is why so many people walk away from choppers until they get their pedals. We're not talking about limitations of modern peripherals. If there's no way to setup reasonable controlability without expensive hardware or some kind of elaborate vjoy scripting, then the module/sim itself has a design problem and people walk away.

I have a relatively close friend who flew both Phantoms and Broncos. He described the bellows system to be like a marker. It's a lightweight reference to where center is marked for feel, but he said he generally didn't trim too often because it was easier to just plant his arms. This reminds me of the problem with the German warbirds. How do you trim roll? It's easy. You plant your arms, or just flat out use your legs. How do you do that in DCS? There's no trim bind because the plane didn't have trim adjustment, so you have to awkwardly hold a tiny 1% angle on a stick that really doesn't want to sit there, or just wiggle your plane the entire flight making constant dramatic corrections. Well guess what, nobody flies ww2 in this sim because it sucks, because that idea sucks. You have a perfect recreation of exactly what the plane does, but no recreation of what the pilot does that the human user at his desk with his cheap ballsocket joystick can't. For the F-4, it still seems like there's a general lack of pilot response modelling here, especially around stick center. Keep in mind: Most people are using hardware that has a strong center return, a deadzone, does not come up between their legs (their elbows hang or can't be planted/braced/anchored), and does not have force feedback. Physical responses with FFB are almost instantaneous because the arm and stick have to be physically accelerated. Additionally, our mental response to physical stimuli is typically several times better than reacting to what we see. Learning a response frequency by sight is extremely difficult relative to learning it by feel. This is almost perfect with expensive hardware but not with basic stuff. If I wiggle a stick without FFB just a tiny amount, but at just the right frequency, I can get the virtual stick in game to flail around quite violently. How is that reproducible in real life? You should really consider options that compensate for a lack of advanced setups similar to the force blending and max stick force options.

They could probably use a more innovative approach to rendering trees with shaders that would not only fix this, but help performance a lot. They are afterall using patches that define tree density.

This is almost like some kind of feedback haiku. I think DCS has some improper/missing cleanup methods for closing out some lua stuff. For example, used to be able to hang DCS on exit just by leaving a socket open. That's probably still the case, so it's a good idea to go through your export.lua and make sure all the mods using it have all their log files and sockets closed on exit. Many of them like DTC and TheWay don't which can cause that failure to exit. There seems to be a lot of new lua errors with their recent patch that might be leaving behind similar components containing blocking operations.

It's bugged. The NWS steering power is supposed to be reduced while approaching 40 kts based on weight on the nose gear, but they goofed and grouped the aerodynamic rudder force together with it. As a result, the rudder has zero authority until you get enough speed to pull back and reduce weight on the front wheel. Keep the stick held back as a workaround and you might get some control back around 80 kts.

This should probably be merged then, but it doesn't appear this specific case and reproduction is known. The new fuze settings have already been deployed so it needs to be looked at again. This bug was discovered when the bombs were found detonating far too high and overshooting their drop point by miles so it's not just a display issue. The setting also cannot be changed when this bug occurs and renders the bombs unusable. What's most likely is that there's a data structure sizing or indexing error and the data that is supposed to fill those settings is coming from a memory location that has the converted default value. The proof is that 2.23 seconds is 1 metric second.

I can pull back on the stick to releieve nose wheel force and get some minor control authority around 70kts. When the nose gear finally comes off the ground I get sudden strong yaw authority back. It behaves like the NWS is not actually turning off or relaxing, but rather forcing a straight alignment of the gear. However, at the same time, this doesn't explain how slight crosswinds are completely overpowering the yaw authority. When a crosswind occurs, such as left to right, the plane veers right off the runway with full left rudder. At the same time, that kind of crosswind should be causing left yaw regardless because the aircraft is yaw stable in flight. In fact, once the nose gets off the ground, the plane switches from right yaw to left. Maybe a better assumption is that somehow weight on the nosewheel is reducing the vertical stab and rudder aerodynamics. I wouldn't find it hard to imagine that the yaw moments produced by both the gear and the rudder are packed into a total moment before being sent to the statespace integrator. The weight on the landing gear is probably supposed to reduce the gear moment contribution based on speed, but is mistakenly reducing the entire package of moment forces instead.

Can't configure the CBU-97s. The BA is stuck on a bugged value. Others in a multiplayer setting have reported the same problem. Bombing mode doesn't appear to matter, and changing the values doesn't affect it. It remains frozen at 4291 ft, 1 second. Release angle can be changed only. Best way to replicate I've seen so far is to load a dry hot start onto a runway, then use the loadout menu to select a TER-9A pack of 3 on pylons 4 and 6. If you select any other configuration such a singles on 3 and 7, the settings may work correctly. After that, reloading the original bugged loadout may also allow correct settings. Reloading a bugged configuration repeatedly however does not clear the bug. In addition, if you've noticed, when the settings work correctly, the AD matches 2.23 seconds along with the BA of 1500 ft. When the settings are bugged, the page settings show 2.00 seconds and 1500 ft in the control page, but 1 second and 4921 ft on the selection page and 2.23s/1500 ft in the fuse page of the loadout menu.

@Hunter2.1Они сказали, что не будут ничего менять и вопрос не подлежит обсуждению.

I looked up some old patch notes I wrote for some server mission changes that I removed the wind because the M2000's couldn't take off with even a slight amount of crosswind. This was back in Feb 2023, but this was also the time I bought the module to notice it, so I have no idea how much earlier the problem started. I just know that it's an old problem. Depending on the wind and runway, you can sometimes yank the stick back early and make the front gear hop a little. When this happens, you can get some authority back. It's as if the front tire touching the ground magically makes rudder forces go away.

Yes, the tone continues for far longer than expected and drops the bombs miles long.

This is a really old bug. Are they not obligated to fix this even though they got paid for it?

The small size of your private bytes is very different from my own and the report of a friend of mine. It's curious to me how it plateaus so quickly and at such a small value. The heap corruptions occurring suggest that something is interfering with how your game is accessing or writing to memory. This could be due to an antivirus conflict or interruptions in page file access and writing. One thing you could try is to apply your page file to a different drive, ideally a faster one. I might recommend your drive D since it's NVME and not your system drive. If you are already using D, try C. Typically a good practice is to set the minimum to 1.5x (48,000) your ram, and the max to 3x (96,000). This is good for capturing memory dumps on a 32 gig ram system. If you have antivirus, maybe add the game related folders to an exclusion. Oh, and set your radius to 30,000 instead of 100 or 150,000. I've seen instability issues in the past at both extremes.

All of your crash logs say its set to 150,000, so there is a discrepancy between what your menu says and what your game is actually running. ['preloadRadius'] = 150000;

Try a preload radius of 30k instead of 150k. I had a similar problem with an Nvidia card, and I assumed it was because it attempted to utilize shared vram when it was ready allocated to something else. Your settings looks like they'd often breach past your 12 gigs of dedicated vram. Another thing to try might be to use DLSS to reduce vram usage.

ST is awful for me, 35 fps, and this is much lower than ST normally is. MT instead is 165 fps (249 theoretical) I used process lasso to disable SMT (hyperthreading for Intel) and it seems to have helped cut the stutters for now, but I may need to put in a few hours of flight to be sure.

I'm getting the same, extremely poor performance and stuttering all the sudden, nothing apparent in the log files. Sometimes the game stops recording joystick input during a heavy stutter even though background monitor shows them still giving output. Replugging them in fixes the control loss, but it keeps happening mid flight and the stuttering is atrocious.

No. It's because it's correct-as-is according to some very old posts in the resolved section. NWS is off beyond 40 kts and it's 100% rudder authority. Do not takeoff or land with crosswinds.

particularly the glimit switch was fixed. A definition was changed in the command_defs.lua. Easy fix it seems.

It's fixed

This isn't true. By definition, this is a memory leak, although it might not be the kind you're used to seeing. It occurs when memory allocations are not properly managed, and the garbage collection process fails to remove data from the paging file as it does from RAM. This can happen if the system is designed to pull data from game files again later instead of retrieving it from virtual memory. There's no need for the system to continuously store additional data into virtual memory by rotating between the same F2 aircraft views over and over again. What @cnoblenyc is seeing is a memory access violation. If it's trying to pull data from garbaged ram, finds out it's not there but supposed to be in virtual, then finds out it's not there either because it ran out of space, C0000005 will happen. Considering the unusually large amount of virtual memory DCS allocates when loading into a mission, having the error occur right away isn't surprising, especially if the disk their virtual memory is stored on has been filled accidentally by video or track records for example.

A memory leak into virtual memory was reproduced, albeit, a slow one that took a long time for me to monitor. While I haven't datalogged the PC's of the other individuals, they have the same events on record and I am seeing a very slow and gradual climb of virtual memory allocation for this process over time through perfmon, along with some unusual behavior I don't find in other games. After approximately 2 hours on a multiplayer Syria server, resting in an FC3 airfraft, I often saw ram usage floating on average between 12-17 gigs. I also selectively limited my graphics to low textures and relatively low details allowing my 7900XTX to average usage around 11 gigs Vram for 1440p rendering. However, Private Bytes for this app slowly climbed over time to a point of reaching 41 gigs whilst starting at 22 gigs and was incremented by cycling F2 on aircraft sprinkled across the larger map of Syria. The odd thing I noticed was a high amount of shared GPU Process Memory of 2.5 gigs while using 11 actively on a 24 gig card. When using high detail textures and higher settings (but still 1440p), the game initializes loading into a multiplayer server with 32 gigs virtual mem fully allocated before slotting in (as an increase from a point in time prior to loading the game), but 17 gigs ram used. From here, slotting in makes ground textures take more than a minute to load in (invisible ground). Vram usage floats between 18-19 gigs. When using F2 to cycling around between aircraft scattered around Syria, the Private Bytes appears to grow at a much faster rate. After about 30 minutes of cycling between F2 views, I hit the cap of my virtual memory (a low cap automatically set to 52 gigs), received the resource warning event, and earned a new C0000005 in the log file. Some takeaways: Lower settings seem to cause the problem to grow more slowly, possibly allowing the problem to go away. Virtual memory limits can simply be increased, also extending the time until C0000005 There are still memory management issues like perhaps over-committing to page using deprecated data the game no longer needs, then an updated garbage collection method skips those deprecated objects because it doesn't expect them. I'm not seeing cases where the game uses more than 17 gigs of ram, so why is virtual memory climbing away? Maybe there's a relationship between this and some of the new desync issues. I found a third person in my smaller discord of goons who also ran into this problem and decided to just walk away from it. They refused to confirm the presence of similar events. I'm getting the impression people are generally very reluctant to report issues like this for whatever reason, as it was difficult to convince the others to dig into their events. @cnoblenyc FYI, windows key -> Event Viewer -> Windows Logs -> System -> right-hand-side Filter Current Log -> Check Warnings and apply. Look for source types Resource-Exhaustion-Detector. If you see something like that, try increasing your virtual memory using the guide pinned at the top of this forum.