FusRoPotato

G is vertical acceleration on the hud. At 0 deg/s, it will be 1 in level flight, 0 in vertical climb. The value of G will vary for every deg/s depending on velocity and angle, so there's not much of an intuitive correlation.

That graph isn't in G's, it's in degrees per second. Unfortunately, I didn't record G's back then so I'd have nothing to compare it to. Furthermore, I honestly don't care anymore. If I'm going to repeatedly see so much careless disregard from our community managers in shutting down topics without even trying to review and understand the content, I don't care. The problem was an obvious mix-up between western and eastern axis conventions in the lua file, verified by setting the largest value of inertia (yaw 85,185 kgm2) to 0 and observing the pitch response spaz out. If the numbers had been in the correct array index, zeroing out that number would have resulted in yaw spaz. Someone recorded a video step by step to verify this and prove it. It was explained carefully and meticulously across two topics, but BN and NL sat on that discussion for months, ignored the content despite posting in it several times, never viewed the footage, ignored the main question, mislabeled it 3 times, engaged with people derailing the discussion, and locked it twice. I... just don't know the words for this? Honestly, what's the point reporting, scripting, and testing anything in here if they don't care? Doesn't seem to matter if you're an engineer, if you have proof, video, milspecs, or just good reason.

Well I took some measurements and compared to much earlier results: No change in delay, still 60 ms. Should be near zero because those systems were either using an analog or digital signal at 400hz. No apparent change in response gains or inertia. The value in the FM file is untouched. Change in amplitude, which may be from a faster release but is more likely a general reduction of max controller gain. Something changed. I'm not sure what, but whatever it was, it has nothing to do with inertial response or input latency. The curves leading up to release and settling behavior looks to have very similar behavior and frequencies. Maybe one of you can clarify what you mean by overshoot from 5G to 1G? I do notice there is a hump at high speed where, when returning to 1G from higher G's, it briefly stops short. I don't know if this is correct behavior or not because I have not created or found high quality state and control matrices to apply the FLCS schematic to, nor do I think it will really matter much because it is a very brief motion. At very slow speeds, you can see it does get stuck a bit and continues to climb for a while before settling back to 1G.

Can confirm. Something is still wrong with weight, inertias, or base FM logic. At some point in flight, the aircraft becomes super twitchy and unstable, usually at Winchester. It's as if extra weight is being removed from some component and creating negative mass.

It was never a specific enough claim to begin with. There are plenty of conditions where it would have undershot and overshot returning to 1 depending on speed, altitude, and loadout. I once thought in a previous patch that they did something to improve pitch control, but what it ended up being was just a curve adjustment. The pitch response, delay, and overshoot behavior was completely identical. I haven't gotten around to measuring this update, but nothing feels different yet.

So what exactly is the problem here? It's not clear. Do they not have enough power? Too much drag? Lack burn time? Maneuvering too quickly at apex? Did anyone make graphs of the expected behavior (and with axis labels)?

No, hasn't been touched as far as I can tell.

HAH that seems to work, too bad I already did all of it through DCS. Might need a new mouse button now, that was a lot of clicking...

lol believe me, I've been trying to figure out how to do that in a way that's quicker and easier than just resaving them in DCS, but I haven't figured out one. Explorer and a few other explorer like programs I have automatically remove the leading space.

Input.zipdcs.log I had to move DCS and the Saved Games to a new SSD. In doing so, it appears to have added a space in front of both my joystick names. Otherwise everything went smoothly. That input zip has 50% of my profile recreated with that space because I was in the process of trying to fix it. I did try rescan devices btw

I changed my Saved Games folder and DCS decided to ignore all controller profiles for my joysticks only. It did not affect other controller, mouse, or keyboard. When loading the original profile, it creates a new file with identical name but has a space in front.... It would be nice to know if there is a file somewhere that points to a fixable pathname or accepts the new file. In my case, the only thing that changed was the drive letter and I have no idea where DCS stores that.

Code question here, does this mod work simultaneously with TheWay? I'm curious about some things concerning lua. Both files define functions that have the same name, such as LuaExportAfterNextFrame() for example. How does this work? Are functions within a lua file automatically "local"?

We've been working around this bug for a long time now by just doing as you say, limiting waypoints to less than 26. Anything over that corrupts them and this kind of play on markpoints is not possible. The numbers on display will be correct but are not usable. I think the ideal solution would be to figure out why the TGP and weapons are using the previous waypoint coordinates instead of the new markpoints, for the sake of polished logic.

When looking at Harrier exhaust with FLIR, framerate hits rock bottom. This can lead to destruction of the aircraft if caught at the right moment. Easiest way to replicate this is to grab a Harrier, lock a ground target with the TGP, put it into FLIR mode, and fly directly over it. As you pass and the TGP looks back, it will capture exhaust in frame and bring the game to its knees. If nozzles are full back, they may have to be masked before you notice it. Pointing the nozzles down will trigger it sooner. I suspect this is related to whatever caused the Vikhr smoke to tank FPS. Something is wrong with the exhaust rendering when in FLIR. This was posted about in RAZBAM's room, but I assume it's not actually a RAZBAM problem.

Framerate drops to like 2 fps whenever the TGP is in FLIR mode and has harrier exhaust in the view field direction, even if it is masked. Can be verified by viewing other harriers nearby. Does not happen if the TGP is in TV mode. The problem is the rendering of the IR smoke effect of exhaust.

Fresh server start - no players - same slot chosen. Perfect setting for a benchmark and it's why the ram values and fps hardly deviate. The randomness is in loading time, not capacity. Can't really call it multiplayer in this case or claim variables.

It was a multiplayer server with around 30 aircraft and 350 ground units, many of which are shooting and pathing about, loading onto a super-carrier slot with about an additional 5 aircraft parked on it. I was using the core and livery packs and loading into the Caucasus map. Load times are definitely off the wall, long, and seemingly random regardless of the mod.

I'm getting about a 7% reduction of Vram and Ram usage from this. Can't tell if there's any improvement in loading times. There appears to be some kind of bug with DCS that is causing load times to be quite long and random. Somtimes my load times were better, sometimes they were not.

Stopped passing IC when they blocked the dots mod.

This is kinda possibly unrelated, but also possibly related ? When dropping these bombs, the right-hand side of the aircraft does not -lose weight-, resulting in the right side of the aircraft being very heavy when both bombs are released. I'm wondering if spelling mistakes have lead to phantom problems here like this, but I didn't dig into the mission files to diagnose it. Another fun bit, if you bug out the fuel status with infinite fuel, you can force the left wing to fill up leaving the right wing empty and it mostly balances out against this bug.

Nor arming fuse time apparently. For this era, the 904 should be configured to 6 seconds (though 2-20 are possible). Though, I believe this is a likely a DCS problem and not a Razbam problem. The audio suggests all the bombs detonated. That should not be happening and is a bug.

I'm seeing a lot more ram activity, but at slower rate than normal on performance monitor. Suggests something changed on a fundamental level, like perhaps a debugger got left on by mistake. Even our servers are taking a lot longer to boot, respond, and occasionally suffer from lag spikes. Something is dragging everything that's related to loading/caching, but frame rate seems unaffected. It's very much like when a game is run behind a lot of antivirus software...

I've not seen any evidence that any hard limit ever existed for any block. I think it's just some nonsense someone made up on a forum somewhere and ED rolled with it. It's certainly not like it'd be the first time...

I can get the menu to show again by hitting com1 PTT, but in order to get it to show again, I have to hit com2 PTT. Basically alternate back and forth to open the comms menu. Weird bug, perhaps there is something wrong in the control commands file like an overlapping definition.

I'm having the same problem and having difficulty figuring it out. The issue is, co-altitude returns at zero elevation appear but then disappear when entering super search. I've been using slow erase while scrunching the bars and azimuth and skipping through half action as fast as possible as a workaround, but I don't know if the game is broken or I'm doing something wrong. What I do know is, I can reproduce it quite often. When in pulse mode, it paints the terrain the same either way, but only the contact disappears as soon as I hit half action.