FusRoPotato

Seems like I and two friends are also seeing this, though I have only seen it once and they see it as often as once per hour. Commonality is C0000005 and resource exhaustion warning, ran out of virtual memory, consumed 30 gigs of ram and 51 gigs of virtual memory. This is another memory leak.

Are they using some kind of voxel-like spacial partitioning to optimize the search algo? Because that might result in a fine altitude problem by putting a virtual terrain block on one side of the unit. Usually when I run into this, the vehicle can't be spotted from one cardinal direction but maybe from the opposite direction.

Yes I've had this happen many times. I've been swapping seats a lot because not much regarding jester or the radar seems to be working well in multiplayer environments.

Yeah my best success with the radar on that plane so far is to very quickly get in the back seat and work the scan myself. I think Jester himself is actually locking up. Sometimes he even stops responding until a minute later and starts spamming no-can-do's.

Most of the time, he sees contacts that I can't see, or can't see targets that are very clear. Other times I can't see the ground or clouds, but can still see contacts, or the radar fails to grab CAA in perfect conditions. When CAA does grab something near where my target is, the lock floats up towards the sky and into the sun even though the aircraft is nowhere near it. I can only imagine something under the hood is going out of sync. Wait till you see what happens when you attempt to lock onto a target head on, it fails, you attempt to sling a sparrow as if it had successfully locked, but it refuses, and then replay that track file.

Yeah the response in the non-FFB stick returning to center is extreme. Notice I'm hardly even pulling up to 0.5 positive on the stick (on the blue line), but when I release it to center, it bounces down to less than -0.5. That's further into the forward position than it was originally held back. I'm not buying the idea that was reviewed by any SME. That is literally throwing the stick and letting go of it, like they programmed a dampening force that diminishes at the center letting it whip right through with 100% of its momentum.

Yeah? It came back for me in multiplayer PVE and now I can't get it to go away, even in fullscreen. The priority fix isn't helping either. I thought jester was fiddling with gains to cause the background static to go away but I don't think that's it. I've come across a few instances now where all the background noise vanishes but I can still see clear contacts when I'm close to the ground. It's as if terrain rendering just stops working. Lifting the gain eventually turns the whole screen green, but no sign of terrain. When I can see contacts, jester often can't and ignores commands to change modes. He will confirm a request go to narrow for example, you got it boss, but never change. I'm constantly having to get in his seat and fix settings and grab targets. I am also having extraordinarily poor luck grabbing air targets in any mode other than scan. CAA and bore-sight just don't seem to connect with anything unless I'm in a singleplayer mission. It's as if some background process is just constantly getting stuck.

No, I suppose it's possible within the few seconds of starting that mission that Jester cranked the gain. It's also very possible that improved accuracy with fullscreen may be entirely placebo. Without any debug tools, it's going to be challenging narrowing down the cause to what was shown in the video. Whatever occurs, it happens in video but not on track. That might be the best clue we can get and I assume points to occasional hickups in the background radar sim that are not consistently strained when repeating the playback. I know from experience that by having multiple monitors, I sometimes get background processes that lag out or get forced to lower frame rates because that's just how my video card manages prioritizing the game's rendering. (7900XTX) Is there any way to view a debug of the radar's frame rate performance, or frametime of the background simulation that's dedicated to the plane's systems? There may simply be a core or affinity conflict that loosens up with fullscreen mode? I am often getting locks on aircraft that appear to freeze in place as if the aircraft hasn't moved from its position when clearly it has. I noticed a process called HeatBlurUI.exe that has a component with a lot of CPU time and an idle priority. Maybe I will experiment with elevating that and see what happens.

I've tried limiting my framerate to 30 instead of 165, reducing the FFB gains in the options to several different settings including 0, increasing the force limit option, enabling and disabling the blending option, running Fullscreen, and varying the update rate of vjoy between 100 and 1000 hz. Unfortunately, the stick is the same hot dog in all conditions with FFB off. The only productive thing I've discovered so far trying to figure out if there might be a condition that reduces the effect is discover that the deadzone setting for the AB detent is completely non-functional. New and unrelated bug. Just to clarify, if you pull back hard on the stick and then quickly release it to center while in flight, the in-game stick does not dramatically wobble around for you? It's not clear to me if you are seeing wobble with FFB on, or not seeing wobble with FFB off.

If you think there's a bug associated with views and recording, please upload a track showing the problem so that it can get fixed. You might have to reinstall windows 11 a few times to make sure it captures correctly.

You're going to have to improve your bug reporting system if your policy is to reject the only forms of help you can get. We need a clean line of communication established between the reporter and dev. You and your volunteers, in an attempt to help or appear helpful, are only impeding progress. The last dozen or so bugs I've helped to get resolved all went through significant road blocks and took far longer than appropriate to get resolved, including server exploits.

I want to chime in and say I've been experimenting with detection of a long line of Mig-21's and have been noticing a lot of strange artifact in the returns of the Mig-21's and what appears to be a lot of clutter and noise existing where it isn't expected. I switched to full-screen mode and this noise went away. Targets were generally much cleaner and easier to spot. Windowed Mode Fullscreen Mode DT bombing mode also has been significantly more accurate in fullscreen. Otherwise they behave like in the video, nowhere near close.

It worked. I set the curve in the options to 19 low and that brought my trim to roughly center. I then recorded it. However, flying like this is a little impractical because there is no way to trim when there is no trim force. The result was, zero oscillation. The virtual stick matched my non-FFB stick exactly. Eve though there is a little pike present at the end of every change in position, that was my fault physically trying to bring my stick to a sharp stop and over correcting. Pitch Response non-FFB with FFB option enabled for F-4E release @ ~ 400kts ISA

I couldn't figure out how to fly non-FFB stick with the FFB option enabled. The FLCS and trim wouldn't let me trim level flight and it became really difficult. Kept wanting to pull up really hard. I'm not sure yet what to do with that. At center, it was pulling up harder than what I pulled in the tests, so in order to replicate it, I have to hold the stick in 3 different forward positions, but it was very hard to hold it. Wobbling all over. However, I was getting the impression that the oscillations might not have been present. It felt like it was more direct. I just couldn't control or trim it. Actually I have an idea, I'll try trimming it with the in-game curve profile... after my BBQ

This is the critical point here that I made earlier. When producing compensation for non-FFB users, the general outcome of control smoothness and accuracy should be similar or better than the outcome of users flying with FFB. Otherwise, you end up simply punishing a user for not having expensive hardware. The strength and dampening effect from the arm of the virtual pilot needs to be able to hold the virtual stick firmly as would someone in the real aircraft, or in the sim with a correctly recreated FFB system. According to mil standards, the forces produced by that stick, including those by momentum of the weights, cannot exceed certain values to prevent control difficulties like this, and thus, the aircraft doesn't kick back very hard. What we should be feeling is approximately what we feel in DCS simulated with FFB, and we are able to hold the stick quite firmly in that case and the sim correctly represents that. The problem is the weak pilot arm for non-FFB that cannot hold the stick as expected. The loose grip allows for a larger expression of the force feedback without the expected compensation. Based on a little bit of data logging at various speeds showing consistent and smooth response frequencies at all deflections including center, I assume most all of this reaction is coming from reaction-torque about the bob weights. As you shove the stick forward, you are not just attacking the force of the weights, but also adding rotational kinetic energy. Bringing the stick to a stop while in motion thus requires extra torque. This is easy to feel and counter with and FFB stick but the non-FFB simulation lets it pass and this is what turns into the unwanted oscillations you see that you also can't easily counter. This is also why those oscillations occur at every position, not just center, but are likely exacerbated near center due to how most non-FFB sticks "snap" as they hit center. For people with extended sticks, this may be less apparent as the stick may often not be moving as fast, thus less kinetic energy stored before coming to a stop. The drop in oscillation amplitude I'm seeing after turning on FFB drops around 90% ish, even though my accuracy to bring the stick to a perfect center with FFB is a little more difficult. That is a big difference. The fix for this problem is straight forward: Fly the aircraft in such a way you can enable and disable FFB, record the pitch response, Increased arm strength and dampening when FFB is disabled until it starts to match the results recorded with FFB on. I grabbed stick position and recorded data with and without FFB enabled in the game settings. This can be done through export lua using the code testfile = io.open("B:/Users/username/Saved Games/DCS.openbeta/Logs/FlightRecord.txt", "w") if testfile then testfile:write("Log Start") end function LuaExportAfterNextFrame() local Controls = GetDevice(0) Controls:update_arguments() local pitchCommand = Controls:get_argument_value(2) -- was 3002 local pitchmessage = string.format("%.4f\n",pitchCommand) testfile:write(pitchmessage) end function LuaExportStop() if testfile then testfile:close() testfile = nil end end And this is the compared result: I start at 400 kts IAS conditions and simply pitch forward and back over and over. Notice how the squiggle at the end of each pitch command change is much smaller when using FFB. This is because I can fight the force response physically. Without FFB, I am not allowed to do it and the pitch oscillates.

The thing is, there isn't much claim to modeling it accurately because it's not a model of the plane or its components that is producing the effect you're seeing. It's a modeling of a virtual pilot who is receiving force from a stick. In mission validation, we normally only hit the required stick free and fixed stick analysis because it covers all we need to know. What degree of impulse the stick absorbs due to an imparted reaction force from a lax and unsuspecting pilot's arm might be considered for something in stabcon, but there are no feedback reactions here from aerodynamic forces. What we are seeing in this F-4E module is probably close to what you'd get in such a case, but the thing is, it's unlikely a pilot would be so lax all the time, especially during combat or moments when precision is desired. Fixed stick should have been assumed at all times, what is described as the tightest a pilot would hold it. Based on how the descriptors of the torque responses are in the manual and video, it's really hard to believe the stick would be moving that much with anything other than a very loose grip or the arm of a 97 year old pilot.

I don't know but I thought it was a little funny to see someone who decided comments aren't worth carefully reading point a finger at said comment with a much higher vote count and say they're in the minority.

I don't think anyone here is talking about control surface force. We're talking about the pitch oscillations that can be avoided with FFB but not non-FFB sticks, supposedly of which come from these weights and bellows. I can make mine behave like a normal spring stick and see clearly what is being talked about. The stick is very wobbly around center without FFB. Turns out it doesn't seem like any modelling is necessary @kablamoman, at least for the oscillations. The extra motion can be mostly removed with a constrained PD according to my tests so far.

The correction would be off-center so it'd be disabled most of the time.

You've installed a virtual pilot between the virtual stick and spring stick who decides where to hold the virtual stick based on the position of the spring stick using a blend of position and force demand. This is why the stick goes limp, why it moves when uncommanded, and why people are having difficulties. I would normally commend that but the outcome must be that someone without FFB should have similar controllability to someone with. The lack of sensory is the disconnect you've refused to acknowledge. Just because a pilot would prefer to frequently trim to keep forces neutral doesn't mean you should force someone playing a sim to trim like mad because it otherwise results in unexpected movements of the stick they can't feel. If they are that adamant about sticking with this approach, we could develop a feedback solution of our own that nearly nullifies the effect using vjoy. I imagine we could model the response fairly easily through some fitting and then close up the gap with a PD controller to match the FFB experience.

You must have overlooked what I said? I flew around it for a while and he couldn't spot it while it was alive. It was the last vehicle destroyed at the field and the active JTAC focused target (hence smoked). I flew up close to get a picture of its orientation and placement after it was killed because that's when it was safe to get in close to look at it. Of course he's not going to spot it once it's dead. He always fails to spot a few targets out in the open, even ones that are actively shooting at someone else.

I've been getting similar results with all the parameters entered correctly. That's way too big of a discrepancy in results for those parameters being slightly off. I would expect a few meters of inaccuracy, not more than a mile. I assume there has to be something wrong happening in the radar or alignment.

See that's just the thing, you're not helpful but think you belong here. There's no argument for you. I can't offer a track. It's that simple. Either verify the problem yourself or do a vanishing trick.

Yeah, and while I feel like I can get "used to" this control scheme, I think it will always leave room for desire if it remains this way. It's more realistic in the sense of: Here is what would realistically happen if you did not hold your stick properly or anticipate its forces. It's not the stick force modelling that gets me, it's the virtual pilot's response to it. I have noticed similar problems when just performing basic maneuvers in a tight radius. I can get to a point where I'm pulling back on the stick further and further to maintain the same circle. Its as if weakness is being modeled into my arm.

Been there, done that. Accurate tracks would be very helpful, but should be appreciated, not demanded with a sense of entitlement. It's far from professional behavior because the responsibility for a products quality would be placed on volunteers. It's already been established by many that tracks can't be recorded much past a minute before they become corrupted. It's a common complaint and the result I get with a fresh clean install. It's not simply compatible with my controller hardware and has not allowed me to provide tracks that ED will accept. Continuing to pester for something I cannot provide is not going to work and it's far from your place to do so. The amount of people who come here not having witnessed the problem, without up-to-date experience with the module in the same setting, or any capability or intention of contributing speculation, expertise, or strategy towards isolating the problem, but instead come here to antagonize people for their reports and call names because they can't respect the complex issues this software has is entirely shameful and inappropriate. I can recognize the difference between someone who's frustrated about a game and the presence of members who did little other than fester toxicity about them. If ED can't handle their bug reports in the standard way other companies do, that will reflect in their product's quality. The proof is very very in-the-pudding on that one. Everything with this module was working fine up until they updated Petrovich to change his spotting logic. Now several people are complaining of the same issue. There's no need for a track file on that. All that's needed is for anyone who's in charge of the module's function and quality is to hop onto a multiplayer server and attempt to quash a few airbases with the Hind. That's all it takes. He can't spot 1 out of every 5 units that are out clean in the open.