TheTaker

Would be awesome to finally see wet, glossy runways during rain. I don't know if terrain engine allows it, but if it works on carrier, should probably on ground too. With more water sprays and various dust/smoke from engines during takeoff on wet/old/dusty runways. Like this: There are also random faint smoke/leak effects that could be added around the engines during startup like this:

Hi, I wanted to share my version of FFB stick and rudder build. Here are more photos: https://drive.google.com/drive/folders/12bpjwd_FC87fGMXIHv5ax6Qkvx2cuK4a And description: 1. Electronics. Everything is based on Gigawipf's OpenFFBoard. He shared the electronic hardware and firmware but left the mechanical design to the builder's imagination. I just uploaded his PCB gerber file from Github to JLCPCB and ordered it with SMT assembly (important note: when you order electronic parts from JLCPCB for your boards they don't send them to you. They are only used for assembly and are just reserved for you in stock untill you order SMT assembly.) https://github.com/Ultrawipf/OpenFFBoard Everything worked properly first time. OpenFFBoard connects with PC via USB and sends control signals to Makerbase ODrive 3.6 dual motor controller via CAN. OpenFFBoard can use also different motor controllers like VESC or a Gigawipf's own board. I decided to use MakerBase ODrive clone because it's cheap and somewhat reliable. 2. Motors. 6,5" cheap hoverboard motors rated for 250W at 36V. I power them with 48V, and set current limit to 13A which gives around 600W per motor. They are not even warm. And for rudder motor it's 16A. 3. Encoders. I use CUI AMT103 incremental encoders + endstops for homing. With ODrive you can program startup homing procedure, when after finding encoder indexes the axis move towards one endstop limit switch, and then move back set amount of turns. Effectively making stick always center itself at startup. When using incremental encoders the motor controller always needs to find index at startup. And with this kind of design where rotation is limited to narrow angle it has some serious drawbacks: ODrive can move to search index (that is one specific point of full 360° rotation of encoder) just in one set direction. If the axis meets mechanical endstop and cannot move more it still tries to rotate until it finds it and cannot change direction on its own. I don't need to tell what happens next if you don't turn it off. So I set that indexes mechanically somewhere before endstop, and then put on the drive belts. This way I'm making shure it "always" finds the index. But that makes another drawback - I need to put the stick in specific region/area before indexes. (for example fwd-left quadrant) If I put it somewhere else, where gears are close to specific endstop but AFTER indexes it will never find them and try to snap the belts. I will probably change to absolute magnetic encoders that don't need to search for index signal. For the rudder pedals i bought even cheaper Makerbase-MINI with integrated absolute encoder (AS5047P) and it don't need to calibrate each startup, but it still doesn't remember the center position after power loss, so a homing procedure with endstop is needed. Another weird thing with ODrive: endstops are active all the time, and not only when homing. If I move the stick to the limit of any axis it recognizes limit switch and turns itself off. You can tell that touching a limit in a stick is nothing bad, but ODrive is just programmed that way and there no workarounds inside software configuration. But I found a workaround. Very stupid but it works . I connected both limit switches GND pin to programmable timer relay switch. It disconnects them roughly after time the startup procedure is done, and reconnects after power restart - so after next startup when homing needs endstops it can have them for a while. 4. Mechanical design. For the stick mechanics I decided to make something like lazerwing FFB project with 2 actuators parallel to each other. This design idea is probably taken from FWD cars gear change lever where 2 parallel cables move perpendicular axes. I used 10mm ball end rods from aliexpress for linkages. Bearings are 72x50x12mm. Left motor moves Y axis, right motor moves X axis. There is some drawback im this design, because at high deflection the stick moves a bit in X axis when moved only in Y (hard to describe it). But it's very little in my case, totally not noticable. For rudder pedals mechanics it's simple, just 2 parallel axis on bearings. I don't have access to CNC machines but I have manual mill and lathe so I made everything what I can with 2,3,4,5,6mm aluminium sheet metal, and for other parts, like bearing housings or belt pulleys I use 3D printing. Motors drive the 25mm wide HTD 3M belts, gear ratio is around 1:6,5. Motor gears are 23mm diameter and are made of steel, bought from CNC shop. Big axis pulleys are 147mm diameter and are 3D printed with PLA, with high 50% infill and 8 perimeter outer walls. I think it's enough for this torque. For connecting stick with base I made part similar to Virpil or thrustmaster but thicker. I just put it in each other and secure with large nut. There's round electronic connector inside for buttons. OpenFFBoard works with shift registers up to 64 or 128 buttons if i remember, so in the stick there is another Gigawipf's board with few shift registers and SPI protocol (5-pin). Also belts and pulleys will be hidden below 3D printed covers, that are not ready yet. And the rubber boot is from some old car gear lever cover. I think that's all.

We have nice exhaust flame on some aircrafts, but distorted air would be a nice and easy to implement addition.

I played with ReShade MXAO plugin (Marty McFly's Ambient Obscurance), here are the results: Reshade preset attached. MXAO.ini

In latest Wags video we can see updated water on Marianas map. Rather matte than glossy with smooth reflection up to the horizon. And even with some soft cloud shadows

I also have exceeded recommended hardware and on: Ryzen 9 5900X 4,9GHz 32GB RAM DDR4 3600Mhz CL14 GTX1080 Ti Samsung 980 NVME SSD I got only 40FPS over Guam. On 2560x1440, with flat shadows, 2x MSAA... not so high settings I always play with track IR, so 60FPS Vsync is must for me. Every drop goes down to 30FPS and head tracking is unusable

I also have worse performance. The worst of all maps. Especially bad around the airports. 40-55FPS while 90-120 on Syria, Caucasus

But it rains in opposite direction to the wind

This snaky-swirly behavior that happens in upper part of smoke looks very weird and unnatural. V10 was better in this case.

Is it possible to reduce amount of smoke when firing unguided rockets? I always got massive FPS drop when I shoot lot of S-8 for example.

I know it's not top priority, but c'mon guys, we have almost 2020. Those chutes just poping up from highly detailed models look ridiculous. With today technology we could make realistic material animation. Maybe not full physical deflection to wind,engines thrust, airplane moves, but just little more 'organic' look.

Why not something in-between Full fidelity and FC3? I cannot understand why they cannot give a MiG-29 something more complicated like APU starting, or SOME systems turning on/off rather just one SHIFT+L. It will not be a full fidelity, but more fun to use, and not violate any TOP SECRET DATA.