Vertigo72

Its an extremely perfect circle ;) Okay, maybe its really an ellipse. I dont have a problem with them. I think they are great and recommended them. Though I wouldnt mind having toe brakes and I prefer to push pedals away from me in the horizontal pane instead of down in the vertical pane, and mounting them to achieve that is tricky. Hence my preference for pendulum rudders.

Neither does my pic. Its a parallelogram with two pivot points, exactly like the MFGs and every other pedal set that uses the same geometry. You still get a circular motion. Those arms dont get any longer as they rotate around their pivot, they cant move linearly. I could have drawn a third circle in the middle and it would perfectly describe the motion of the center of the vertical lines, ie, where you attach the foot rests.

Also, try using those kinds of pedals with your knees tied together, and you will discover you are not really using your feet, but your legs. Thats what makes it awkward to me.

Im not doubting you when you say you arent seeing the same issue fat creason; but clearly others are, as there are a fair number of confirmations in the other thread and keep in mind that the issue is subtle most of the time. In my tests and videos Im making extreme movements to highlight/trigger the issue, but if you are gentle on the stick its not noticeable 99.9% unless you keep staring at the input overlay and are yanking the stick. I even read about it, and then posted I didnt have the same issue, as I dont tend to yank my stick around and simply never noticed. I had only noticed the occasional delayed and stuttering zoom input. Its like the wing snapping. Its not a problem for most of us, Im not sure I ever did it accidentally, but some ppl complain about it happening all the time. I dont think they are imagining their problem, there probably isnt anything different other than how we handle our sticks. Anyway, as I wrote in the other thread, for some weird reason I can alleviate the issue by mapping my FFB2 controls onto a virtual vjoy joystick, and using that as input in DCS. Sounds like a stupid idea to begin with, that can only add latency, but I read it worked for some Kerbal players in early versions of the game where they had the same problem (not with FFB, but some joysticks in general particularly some saiteks), and it does really seem to work in DCS too. And if I double map the roll and pitch controls, I get to see both diamonds in the control input overlay, with the ffb one often lagging the vjoy one. I can not begin to think of an explanation for it. I dont have any drivers or anything installed for my FFB2. I do have joy2key installed, but dont use it in DCS. (anyone wondering how I could tell them apart, I reversed the vjoy input in a test. So if I moved my stick left, the FFB2 indicator would go left, often with a slight delay, the vjoy one would go right with no meaningful delay. The inputs cancel out, but you can even sorta fly the plane based on the delay difference alone!).

Ahem. Nope. Those are exactly what I dont like and what I meant by "rotating pedals": anything where your feet move in a circular motion as if you are controlling a steering wheel with them. edit: when Im wrong, Im wrong. I said I didnt know any real plane that used such a geometry, but it turns out the spitfire maybe did: https://goactionstations.co.uk/wp-content/uploads/2016/03/R19-NH341-4-Fuselage-controls.jpg Although I cant tell for sure if the those pedals moved in an arc around the center pivot or linearly relative to the mounts at the bottom or "both". Given the width of the central pivot arm vs their limited movement, it probably makes little difference and much less than with crosswinds and the like.

Thats a beefy laptop you have. A cheap second hand desktop isnt going to beat it. Lets start with GPU; I looked up the mobile 2070 and was genuinely surprised its really only a hair slower than the desktop one. 10-15% slower than a desktop 2070 and that is still fairly high end and not something you will find second hand very often. A 1070 will be slower, not by much, but it will be. So for a (modest) upgrade you'd need to look for a 1080 really. There there is the cpu. You have a coffee lake with a boost frequency of 4.5Ghz. Most modern desktop cpus will outperform that in benchmarks that use all 6 (or more) cores. because a laptop is power limiited and will need to clock down. But DCS is essentially single threaded, and I would expect your CPU to maintain its boost speed on one core and you are doing to struggle to find anything that is meaningfully faster than a 4.5Ghz coffee lake. Especially second hand. The only area where you can have a non trivial advantage is the memory. I looked it up, your laptop has DDR4 2666 MHz. In my testing (on an AMD ryzen) I found performance scales almost linearly with ram speed. The effect might be smaller with intel cpu, but I would still expect a desktop with good 3200 - 3600 DDR4 to give you a very decent boost. But that its still top of the line stuff, not what you are going to find in a dumpster. Bottom line; a desktop that will just match your laptop is going to be pricey and no amount of money is going to give you something that is >30% faster. Maybe you should just buy a docking station or something?

At the end of the day, its still plastic, and weaker even than most injection molded plastics because of limited layer adhesion. Or its not plastic when you can print polycarbonate or nylon, but then you get other problems like warping and shrinking and bed adhesion, especially with something as big as those parts. IMO thats only going to be feasible in abs/pla/petg and abs might be tricky already. BTW, for those who prefer snowboarding style pedals, you can DIY those too: https://www.thingiverse.com/thing:3475445

There are picture of actual printed ones on there, I think they look great. And they would sit under my desk anyhow, so its not like I really care. And if you do, you can finish these prints so they look indistinguishable from factory made stuff. More concerning is durability. It does look a weebit fragile to be made mostly out of 3d printed plastic. But it you dont use overly strong springs (and I like light rudders anyhow) and you dont have a habbit of stamping your feet in frustration, it may work. Wouldnt expect it to last quite as long as those massive metal TPRs though. Im waiting for the designer to publish a metric version, as finding imperial sized tubes and bolts here is tough. Once he does, Ill just try it. Its gonna cost me next to nothing, filament is cheap, I have plenty of bearings and I should have some teensy or leobodnard boards somewhere.

Im not a fan of typical "rotating pedals", doesnt feel like anything Ive ever flown IRL (which, mind you, doesnt include any military jets). Probably great for snowboard simulations though :) My brother has VKB T-rudders, which suits me much better and feel a lot more natural and closer to real airplanes: https://vkbcontrollers.com/?product=vkb-t-rudders-mk-iv No toe brakes though, which is a bummer Thrustmaster TPR with pendulum pedals is even more what I would like to have,... but that price tag is hard to swallow. So I may build my own TPR replica based on this: https://www.thingiverse.com/thing:4407778

I may have found a solution: https://forums.eagle.ru/showthread.php?p=4400525#post4400525

I think I may have found a workaround. Got the idea from kerbal space program forum of all places. I installed vjoy and UCR. Created a new virtual (ffb enabled) joystick with vjoy and then mapped my ffb2 pitch and roll axis on to this new virtual stick using UCR. In DCS I unbound the ffb2 and used the vjoy stick instead. And taadaaa. Its not completely lag free, there may be some ~100ms stutters or delays when going from one extreme position to another, but its much much better and completely a non issue when flying. I only tested this for 10 minutes or so, its not 100% conclusive, but it does seem to solve it or at least dramatically reduce the problem. For whatever weird reason.

No Im not. But lets do the math. 4 frames at 60FPS is 0.066 seconds and half as much at 120 FPS where I have the same problem. Again, that may matter to professional gamers, but Im not going to notice it and its certainly not gonna bother me in a flight sim. A one second delay would mean ~100 buffered frames. Thats why I said, this isnt caused by vsync or buffering or anything like that

I would pick 32GB for sure. Only exception, if you only fly offline, no VR, no channel map and want every last FPS, than 16GB of fast ram may give you slightly better FPS. And the advantage that you can add another 16GB later. But the latency difference between normal and ultra low latency ram really isnt that great, and I dont think we have even established cas latency matters to DCS. I just suspect it does, but it may just care about bandwidth instead. So if the choice had been between 32GB @2666 MHz ram and 16GB @3866.. Id have a harder time answering that. Probably "neither", 32 GB @3200 :).

Its not a USB issue. It cant be when other apps running simultaneously with DCS, and polling the exact same directx input device show no delay. USB 2 or 3 doesnt matter either (its in a USB 3 port, but our sticks dont even support that). Even USB 2.0 controllers have to support 125 μs polling interval. That is 0.000125 seconds or 8000Hz. Professional gamers may be able to tell a difference between a 250Hz and 2000Hz mouse, I sure as heck wouldnt but Im seeing delays of up to entire seconds, or ~10 thousand times more. Powered hubs can help if you have trouble with devices getting power and getting disconnected or not working reliably. My joystick works reliably in every other app and module it even works perfectly fine in other apps at the same time as flying the F14 in DCS. (and MSFFB2 draw their power from the wall socket, so are unlikely to cause a USB power problem anyhow). Id appreciate that, but I thought the trial was over. There is another thread where 5 or more people have confirmed the same issue with the F14+FFb, so its not just me, its a matter now if figuring out why it affects some and not others so hopefully HB can reproduce it

Not sure why i said I didnt have this issue, because I do. But its usually not bad enough to be really annoying. Ive done a fair bit of testing and posted that in other thread, but its probably better to keep it all here. First some evidence: the top window overlay is from a joystick testing app that shows in real time my joystick position. It is not delayed. You can see sometimes it matches the DCS stick pretty much perfectly, sometimes there is a rather significant delay. Check the end of the video for the best examples. I have encountered worse than that, but not be able to record it. What Ive found so far in my testing: - a similar if not identical issue affects zoom and switching views (internal/external), which also sometimes reacts very slow. I have zoom on my hotas throttle and views on the keyboard, so it appears "input" in general is slow, not just the MSFFB joystick. - It doesnt happen when you stand still. Its only when the plane is moving (taxiing or flying) - It doesnt happen with Su25 or TF51. - Im not sure if it happens with the BF109 it really confuses me, It doesnt happen on roll but I think the 109 has a stall prevention thing that delays elevator input past ~50% depending on AoA. See here, again particularly the end: That makes it really slow sometimes, like 5-10 seconds before I achieve full deflection, but that seems to be a feature, not a bug? Unsure. Never really flown the 109 yet. - Unplugging my TCWS throttle doesnt make a difference - Disabling "F14 FFB trim" setting doesnt make a difference - removing my finger from the grip sensor (disabling FFB), doesnt solve the problem. However: - when I unplug my FFB2 USB connector in flight and plug it back in, once the joystick is detected again, I have no force feedback anymore but also no more delay. That does "solve" the problem. It also solves the sometimes sluggish and stuttering zoom and view switching. I have to conclude the issue is somewhere with the F14 module and the way it handles FFB. To help narrow down why it affects some and not others - I use steam edition, open beta (can anyone with a FFB2 confirm they do not have this problem with steam+OB?) - trackir (disabling it doesnt help) - SRS, no other mods - very average PC setup (ryzen 2600+, nVidia 1070, 16GB ram, nvme drive). Dont see a difference with this issue when <40 FPS or >120 FPS

Some more findings: - I can not reproduce it in the Su25. There is no lag there - Unplugging my TCWS throttle doesnt make a difference - Disabling "F14 FFB trim" setting doesnt make a difference - removing my finger from the grip sensor (disabling FFB), doesnt solve the problem. However: - when I unplug my FFB2 USB connector in flight and plug it back in, once the joystick is detected again, I have no force feedback anymore but also no more delay. That does "solve" the problem. I have to conclude the issue is somewhere with the F14 module and the way it handles FFB. To help narrow down why it affects some and not others - I use steam edition, open beta (can anyone with a FFB2 confirm they do not have this problem with steam+OB?) - trackir (disabling it doesnt help) - SRS, no other mods - very average PC setup (ryzen 2600+, nVidia 1070, 16GB ram, nvme drive). Dont see a difference with this issue when <40 FPS or >120 FPS

I disabled vsync because it costs less time than explaining why -honestly- this is not, and can not be the problem. But I tried it, same problem. I also disabled AFCS, no difference. But I do have some more data that may be interesting. Its related to the throttle position somehow When standing still on the ground, there is no delay, joystick and game stick are pretty much perfectly in sync. When I open my throttle, the issue comes and goes, even when still on the ground and barely have any speed. Later in take off roll I close the throttle (and desperately try to save the plane) and there is no delay. OPen it again, and it stutters again. Once airborne, closing the throttle doesnt seem to solve the issue. I mostly tested roll this time, because it exhibits the same issue and is somwhat easier to see. Usually its fine, but occasionally it seems to just forget changing my stick position or does it really slowly. Worst effect around 1:45, but take off roll is quite interesting too: When its reacting slow, switching views from cockpit to outside is also slow. You cant see that because you cant see when I press the buttons, but it took 1-2 seconds. All the while my framerates are 60+ So I tried the Bf109. I admit I havent really flown it yet, so maybe there is something I dont understand about that module, but its even weirder. Joystick response is as good as instant on roll, no problems. Its also instant on elevator, but only for a small range of the BF104 stick. If I pull back full on my joystick, the ingame stick moves only ~1/2 or less. It seems to have a stall prevention system in there that doesnt let me pull the stick all the way when Im too slow. when I insist, and keep the joystick back anyhow, it slowly feeds in the last part of elevator until its also full back in game. Confusing as heck. Have a look: This does seem like a feature not a bug (?) but either this is the same "feature" as in the tomcat, just 10x worse (?) or its a bf109 specific "feature", but then the theory that the overlay shows raw input data then cant be right.

Thats yet another issue, cpu clock speed. I was talking about memory speed. And to make it even more confusing, there is yet another clock speed that may matter, that is the integrated memory controller. That latter is usually linked to the CPU clock speed, and I wouldnt be surprised that is actually the main reason why "high clock" cpu's are faster in DCS Because the IMC runs faster, which reduces memory latency. That may matter more than the actual cpu clock. Either way Threadripper runs at almost the same (boost) frequency as its desktop counterparts. And it will boost to its max clock all day long if you run DCS and thus only stress 1 core. You're not really losing much there. Where you may lose is memory latency, because threadripper cpu's have near and far memory. The near memory they can access directly, like a ryzen. The far memory requires a hop to another core complex. Easier shown than explained: https://images.idgesg.net/images/article/2018/08/die_top_2950x_updated-100768695-orig.jpg Then again, because you have 4 channels, and because you have a ****ton more L2 and L3 cache, aggregate latency might still go down compared to a dual channel desktop chip. And bandwidth will definitely go up. How all of that relates to DCS performance; we're not gonna know unless someone tests it, but I wouldnt be surprised it actually does extremely well. It seems wasteful to pay for 24 cores when you only need one or two, but I wouldnt be one bit surprised if threadripper is the fastest cpu for DCS. Even if its for all the wrong reasons.

If the indicator shows raw input then the problem almost has to be with DCS, rather than the F14 module, because the indicator overlay lags exactly the same as the stick in the F14. Ill do some more testing if I can reproduce it in other modules. As for being specific to some users; Im open to anything, or any combination of things but not to this being a hardware or USB problem. Did you watch the video? DirectX is getting the correct stick position and in real time, no delays, otherwise that other app would not be showing the correct stick position when DCS at the same moment shows a delayed position. It also doesnt seem to happen when on the ground in DCS, only when flying. There isnt much special about my setup otherwise, except maybe atypical that I run 3 monitors (only 1 in DCS) and a track ir but most of us have that I assume. No curves btw.

The input overlay thingy, that shows control position in DCS, does that show "raw DCS" joystick data that you guys work with, or is that after it has been processed by the DCS module? If for instance the stabilisation augmentation in the F14 (or some fly by wire or even an autopilot ) would change the position of the stick, would it show on that overlay or will that overlay always show the joystick position that DCS reads?

Yes, not much use when our desktop cpu's have only dual channel memory controllers (and therefore typically 2 sticks) Increasing memory speed does two things: it increases bandwidth and it reduces absolute memory latency (for instance a 15 CAS latency stick means 15 clock cycles latency. 15 clock cycles takes more time if those clock cycles are slower, ie if your memory runs fewer cycles per seconds, ie, at a lower frequency. Usually you need to increase CAS latency settings to get higher clockspeeds, but if you do the math, absolute latency in nanoseconds still almost always goes down). They may both matter, which is most important in DCS, I havent tested that. usually latency matters most, but DCS performance is unusual so who knows. You mean size on disk? Thats not how it works. Doesnt tell you anything about ram usage.

Yes, I have vsync enabled, but the "input lag" that creates is not what you are seeing here. vsycn results in delayed rendering which may mean 1 or maybe 2 frames, ie 16ms @60 FPS which only matters to hardcore first person shooter gamers. Its not the 1600ms I sometimes see @60+FPS BTW, its not only the joystick input. Ive seen it with zooming too (I use a slider on my hotas to zoom). Game runs smooth but zooming lags really far behind what I do on the hotas.

How can it be a hardware issue when the joystick monitoring app (ie software ) doesnt show any delay? its running on the same computer and is getting the same data as DCS (and no, that app isnt causing it, I just installed it to be able to demonstrate).

High Gs apparently causes an immediate reduction of your hearing, so that could be easy to implement, just fade out sounds (and maybe fade in hard breathing or heart beat for extra coolness). But I think the gradual G blackout we have is both realistic and helpful, its not hard to maintain ~9G in a turn. Its hard to judge when you begin your pull. Whats also missing IMO, particularly for "keyboard pilots" who are rough with their stick is some feedback when you briefly pull (very) high Gs. There is no instant "penalty" like blacking out or any sort of warning or feedback, you obviously dont feel it even though you may have pulled 20G and you have degraded your airframe and then you may just snap your wings at a sustained 9G turn and wonder why. Maybe having instant onset of blackout/tunnel vision when exceed 8-9G would make pilots more aware of the high G load when jerking the stick, or when beginning their pull

Its not the stick causing latency. That joystick tester app is showing a real time response, it works perfectly fine. Its DCS or the F14 module that is not reacting very fast on my inputs, Havent tested extensively yet in other modules, but Ive only noticed in the tomcat. I may try turning force feedback off and perhaps disabling the F14 stabilisation stuff see if that makes a difference