Caput_58

Ya, I think that's giving the physics simulation waaay too much credit. And I hear you on the disconnect between control input and ffb output, heck that's how you can get such violently unstable behavior with the wrong spring/damper/friction settings in configurator. I did consider that maybe I'm making tiny movements around the center due to the rather extreme sensitivity, but I'm pretty sure it's not the case. I can turn master gain to 0 and just fly looking at the control diamond and trim diamond. If I trim max right roll, I have to move the control diamond about 1/3 left to keep from rolling. I've attached some screenshots. In all three I've neutralized roll, but in all three the stick has to be held in a completely different position depending on there the trim is. nullSide note: How do you like your FFB pedals? I've been thinking about trying the crosswind FFB conversion myself. Second side note: have you noticed that the stick you see in cockpit does not move linearly? It's movement is very sensitive around the center, but it moves only slightly at the extremes. No curves applied, but makes me wonder if they are trying to model pilot strength is some way.

Thanks for the reply! Very strange. My rhino behaves appropriately with all the other modules, except possibly the Chinook. 1) Yup, axis setup is correct. 2) Never touched DCS pitch axis. 3) Did invert pitch in FF Tuning, which did correct stick movement. That is to say, trimming for nose down makes the stick return to a pushed forward position. 4) I've already tried with TelemFFB on and off. I may try a DCS repair, just because this really feels like both trim modes are active at once. Extra odd, I'm pretty sure it behaves as expected for roll. (edited: roll has same problem) Also tried toggling FFB off and on for DCS. Retested with controls indicator open. The control diamond should have to be held in the same place for stable flight, no matter your trim settings (aside from the near negligible pitch force generated by trim tabs themselves). Instead the position to hold steady flight varies with the location of the trim diamond. I think this should be pretty independent of anything the VPForce software is doing since I'm basically ignoring stick forces and just locking the stick in place. Or rather if TelemFFB or VPConfigurator were doing anything, I would see that reflected in movement of the control diamond position. Just to confirm, if you hold your stick firmly in place and trim up and down, your corsair doesn't pitch?

Flipping the axis did help, but trim is still quite broken for me on my Rhino. It feels like enabling force feedback isn't disabling the standard form of trimming. I can see this because if I hold the stick absolutely centered and don't allow movement, pitch trim still moves my nose all over the place, just like it would with a non-ffb joystick. I realize the trim tabs have minor (and opposite) aerodynamic effect, but that's not what is happening here. I hope this gets fixed soon.

Just a quick note to say how impressed I was with the relative ease of setting up Skyeye on a home machine. It was less than 30 mins work, mostly because I couldn't remember how to change my server's Tacview settings. I'm still shocked that it hasn't been adopted by more mp servers. When it's processing a transmission, I notice the CPU usage spikes up to 100%. Does that mean Skyeye is spreading the load effectively over all cores? Assuming I stick to local processing on a PC, would it benefit from a threadripper or other CPU that's big on core count? Does anyone else have other ideas on optimizing response time other than using the quicker language model? Thanks again for all the work. It's another example of the strong community support that brings life to DCS. Oh, I just remembered my other question. Is Skyeye impaired at all by that radio effects simulation of SRS? Surely decreased sound quality of a simulated radio transmission is making Skyeye work harder to understand what's said.

After a little more study I found the files DCS uses. They have files at 5 year increments from 2025 to 1985. Presumably they are interpolating. And presumably it all falls apart when extrapolated to 1972. I'm trying to understand the files now to see if additional years could be added.

If you set the year to 1944 and restrict to historically available equipment, the Japanese vehicles and the Essex all vanish. I suspect they have the wrong availability date set.

Is magnetic variation over time being modeled currently? I've located a few historical charts from the the 70's, and even with the date set appropriately, the magnetic headings are 7 degrees off.

Tested the Shrikes a bit today. They track on SP, they track with a locally hosted server, but they don't appear to track when used on a separate dedicated server. Testing conditions were an SA-3 at about 200ft MSL. F-4 flying at 22k, with 49 mod1 loft seekers, using ARM and AGM mode. Nose dipped when SA-3 nails first appear, probably firing around 12nm or so with nose up and donut showing. Phantom stays in sight of SA-3, and SA-3 is tracking during flight of shrike. On SP and locally hosted server, you can see the tail fins of the shrikes deflect to track on terminal phase. On dedicated server the tail fins never deflect and the missiles continue a ballistic path. I had some concern that my lofts hadn't been precise enough for seeker FOV, but in the last test the missiles landed quite close to the SA-3 site. Naturally, the track doesn't work, but I've attached the tacview of the failed test. You can notice that the missiles stay 0g throughout their descent. I realize this is probably a problem on ED's side of things, but we'll have more luck getting it fixed if Heatblur is involved than if I try and convince ED on my own. Would welcome any feedback from others who have seen different. I've been quite anxious to be able to use shrikes, so I'd be happy to be proven wrong. Tacview-20241208-220038-DCS-Host-temp.zip.acmi

Came here to ask the same thing....

Running MT 2.9.7.59073 I keep making a mess of the lag roll, and choose repeat through the F10 menu. I end up in the end mission screen. If I click "refly" I restart the mission from the ramp, cold and dark. I've tried twice now, and given how long a cold and dark start takes with full alignment, I'm starting to get a bit frustrated. Am I missing something about repeating a section? Other than that, I've love the structure of the missions, especially the chalkboard briefings before each section.

Well I've solved my own problem. Turns out the secret was spending countless days troubleshooting every possible fix, then give up and post to the forum. Right after I made the above post I tried two more things. One, I updated some windows stuff, including net framework stuff. At the same time, I also decided to dig into the scripting Hooks directory. I figured most mods were already removed by renaming the Mods dir and eliminating all the references in export.lua. I was wrong. Renaming the hooks directory fixed the problem completely. I drilled down a little further to figure out which file exactly was causing the problem. Turns out it was the gunner export .dll and .lua that the otherwise excellent OH-6 mod added. With them re-added the problem was back, with them gone everything is fine. I like that mod, so I grabbed the newest version, which just released a few days ago. They must have updated the .dll or the .lua, because with them back in hooks I'm still stutter free. Well, as stutter free as anyone is in DCS. Hope this helps someone else out there. Also, it should would be helpful if DCS had a safemode with options to boot with an alternate (and empty) Saved Games\DCS directory.

Hey guys, I'm reluctant to start yet another stutter thread, but my problem seems a bit distinct from the usual DCS performance issues. What I'm seeing is a very regular simulation time spike that occurs. The spike is very narrow, and while the spacing is different between servers, it's very regular in a given server. Anywhere from every 3 seconds to every 10 seconds. After sampling about 10 busy servers, I've noticed that it doesn't appear on Enigma's Cold War Server, or a chopper SAR server, both of which don't have much AI plane activity. It's also present in SP with a busy enough mission. Also present in a locally hosted MP setup. It does not occur as a MP client when you F2 around while not spawned in. I didn't notice this problem at all a few months/patches ago. Something very similar also shows up when refreshing a server list, though I'm not sure that it's related. Curiously it only shows up when I'm not filtering down to my 12 or so favorite servers. I run a reasonably beefy system, 5700X with 4090 and 64gb of RAM running W10. DCS is on SSD, with swap drive on different SSD. Things I have tried so far: Changing core affinity and process priority. Setting graphics to silly low stuff. Updating nvidia drivers Changing between frameless full screen and dedicated full screen Disabling g-sync Changing mouse polling. Leaving TrackIR off. Disconnecting all controllers Disabling CPU Parking. Turning off/on HAGS Removing all mods. Removing all applications in export.lua except SRS Disabling Tacview Running on secondary monitor Trying various Modules Removing the Super Carrier Using the old single threaded .exe Rebooting Router Making sure DCS folders are in exception list for Windows Defender. Disabling Power Management. Disabling Trackfiles. Turning off/on various fps caps and v-sync Checking dcs.log for error/warnings (always some, but no new ones being generated during the performance hits) Doing a full repair Anyway, I'm running low on ideas. I'm mostly hoping to find others with the same problem so we can compare hardware and software settings. null

Sounding this out to see if anyone else has seen similar. On a multiplayer server, when I go back to search mode from cage or DTOS, Jester will often call out every single radar contact that is in azimuth, including ones 150nm away. Not actually sure if he's revealing actual aircraft, or just misidentifying a bunch of terrain features, but it results in a minute or two of non-stop contact calls. Typically the radar is in 50nm mode at this time, making his 150nm extra impressive. I assuming that Jester spots radar contacts by evaluating each actual aircraft location to see if the return is apparent vs clutter, but that there might be a brief tick when you go back to scan where the clutter hasn't been generated yet, making Jester spot everything. Didn't see a previous report of same. Can attempt to capture a track if it's of interest.

From what I just read (Arab Mig-19 and Mig-21 Units in Combat), Syria retired their surviving Mig-19's after the Six-Day War, sending what was left to Egypt.

That makes sense, thanks so much for the explanation.