Red Dog

Same Mate, your A-10 build is phenomenal Cheers

Recently I switched the pit to Virtual Reality Quest 3 - Virtual desktop Passthrough with openkneeboard Here's my first ramp start in te pit with the new VR system - far from perfect but glad I reached that level already

Kind bump for this to be added please

great communication I must say

Interested Would you consider shipping to Belgium?

indeed, that"s the solution Thanks Luckily I do have a suitable counterweight

Thank you all for your input, I decided to go DIY route and found a collective base and a Kiowa grip that suited my plan. The collective base is from the well known Rato's design found on printables.com. It was printed as offered, I just adapted the controller plate as it was designed for the blue pill but rather preferred to use a Leo Bodnar or even the GVL224 that goes with the hall sensor designed for this hardware (also from GVL224) The design is great, well done and relatively easy to print (I printed this SLA) one small issue with inserts holes being just a bit too large and inserts not gripping as they should. but it may be my prints. The same author offers a Apache Grip to go alongside its base but flying the apache sounds way too complicated for now so I wanted something more simple for a Kiowa which I found on Cults3D for a very small fee. Again the SLA printing process was not overly complicated. I just had a few issues with the thread size (as always with 3D printing) but I'll blame my inexperience in the 3D printing field. The grip in the process of being populated with a mix of real switches and 3D printed ones. A 25mm tube connects the base and the grip and I added a motorcycle damper to try to overcome the weight of the grip. Unfortunately the collective does not stay up only with the damper (although it's set at the highest resistance) and it slowly moves back to its resting position. https://youtu.be/yDFkxhw-dSc I need to fix this friction issue first as you really can't use a collective that constantly lowers the angle of the blades can we? If you guys have any idea on how to fix this, don't hesitate to let me know Many thanks

thanks, any link to that hoverboard mod?

one question comes to mind: Should I look into a 2 axis or 1 axis collective? What's the most needed in DCS? I'd go two considering who can more can less but is it really worth it? Thanks

Thanks mate Kiowa screams at me

Thanks guys for all your input It will be a separate setup, I'm not going to compromise the F-16 pit. So I'm starting from scratch but the idea is having a quick setup suitable for civil IFR flying with a G1000 probably and helicopters controls for some DCS kiowa fun. So the cyclic and rudder will be for both the helicopter and civil flying. I plan on having a throttle for the civil on the right side and the collective for the helicopter flying on the left side alongside the seat Cyclic will probably be a conversion from a warthog or something simplier The rudder is a very old hydraulic flight link rudder system. I still have plenty of those And the real question id indeed about the collective As I said I can do DIY but I don't have to. I also don't mind getting something simple off the shelves for the collective. Are there commercial solutions for a nice military style collective yet? Force feedback, I should try then but it's really not a critical part of my plan really Thanks again for all the guidance

Thanks for your input. I already have tested with my setup and it kinda kills it and doesn't reflect the enjoyment I might have. I fly a full F-16 cockpit with an old Cougar modified to a pressure gauges (FCC3) and a real F16 throttle. So flying a chopper in there isn't really accurate enough for me to enjoy it. Even flying a F-18 or an A-10 is on the edge I am building a second setup to get back into IFR flight sim and that setup would be used for flying chopper more seriously than what I did up to now. So I'm looking to invest into specific helicopters controls. Nothing crazy like the F-16 setup but something more easy to use and more flexible. Hence my initial question Thanks I am into DIY but not a big fan of force feedback. I confess it's been a while I haven't tested force feedback but back when I did it was nothing close to what I feel flying for real, so I abandonned that feature long ago.

Hey guys, old head flying the F-16 might contemplate switching to rotorhead for a while Can't really do that with airplane controls, so what would be the best course of action for specific helicopters control in the HOTAS sim industry these days? I really can't say it will stick so I'm not sure I'll invest high amount, but I'm ready to invest wisely anyway. Any advice, best route of action welcome. I can DIY and 3D print to a certain extend as well being a pit puilder Many thanks for your time

I doubt it's for the D only. Aviation philosophy is to test everything possible, why would you not be able to test the AR system when flying a single seat aircraft and being specifically able to test this from the rear seat when flying a D. Sorry but from a pilot perspective it doesn't make any sense at all Beside, If that's the case, why do the regular checklists mention the AR check as explained above regardless of C or D model ?

Point 5 is actually partially incorrect. A long TMS left initiates TDOA but a short TMS left displays the coordinates in the DED. Hence making you believe a steerpoint could easily be created if not already Mayve a M-SEL should make that an active steerpoint (untested) like any other markpoint It would be interesting to know if the threat ring would magically appear in DCS for the host if these coordinates are made into the relevant system SPI Logic is much better knowing the threat ring over the network is an error on DCS implementation side. It kinda solves the inconsistency indeed Can't wait to have a solid DTC in DCS because all these lines, PPt and threat rings are dearly missing - even if they are not updated with TDOA

it has nothing to do with public unclassified evidence It has to do with pure logic and common sense.

@Lord Vader I understand what you're saying which is indeed logic. But I'd like to know from an operational point of view how the mechanisation of what you explain is efficient from a SEAD pilot perspective.... in DCS Starting a SEAD mission, we don't know where the mobile or hidden SAMs are. And that's expected. We love that So I understand that the SAM rings are not accurately placed. Matter of fact they are not placed at all since we do not have DTC allowing us to place PPT, Lines and SAM rings on the HSD But When a guy locates an emitter with the HTS pod He doesn't get the SAM threat rings. But if he sends that emitter through the network to his wingmen, then these guys have the SAM threat rings For the guy having sent the position of the emitter to have the SAM threat ring, a wingman who has received the data through the network has to send it again to the original guy. Then the original guy gets the SAM rings in his aircraft. Or is there something I didn't get? Realistically thinking, and with the danger of SEAD business, Do you guys really think it's been planned like that in the real F-16? It seems very dangerous, quite unefficient and way too long to avoid being shot down. Food for thoughts .

Doesn't work in DCS - you cannot test AR on the ground as when you do it, the NWS button doesn't disconnect but enables the nose wheel system... This is mandatory if you want to refuel on the ground as it depressurize the tanks and allows to fill them correctly Failure to open AR door in DCS before refuelling on the ground will provide abnormal fillup which is indeed a good point

I'm not a VR user but I do have mouse related issue in DCS as well. I think I found the solution. Might be interesting to you guys The issue I have is that my mouse cursor is erratic when I am in the UI of DCS. It doesn't happen all the time, just sometimes for no particular reason. When it happens the mouse cursor slighly oscillates and drift for a very long time before stopping (withou me moving the mouse) When the mouse cursor stops drifting, it's not where I placed and I have to move the mouse to get the cursor on the UI button I want, and the problem starts again. While that happens, DCS in the task manager is using a lot of ressources and is red coloured, which is not the case when that particular issue doesn't happen. I'm sure you can imagine that setting up a mission is a nightmare in such condition. particularily in MP Anyway, I have been searching issue for this for a long while and only whne I read this post I realised it might be a mouse setting. I have a Razer Basilisk V2 mouse. You can adjust the mouse cursor speed with specific mouse buttons And yesterday I found out that the issue is only happening when my mouse cursor is too fast. When I decrease my mouse cursor speed with the Razer settings, the problem in DCS disappears. Slow mouse speed = OK in DCS Fast mouse speed = NOK in DCS For records, I do not have such problem in other sims (FS, Xplane, BMS etc it's only in DCS and I run multiscreen in all of them I haven't found the specific mouse speed threshold yet but you guys indeed might want to decrease the mouse cursor speed to avoid the framerate hits Hope that helps and hoep that ED looks into that mouse cursor speed issue

I'd say it doesn't happen for TDOA Master. Not specifically flight lead but rather the guy initiating TDOA

I can't find that one either LeCuvier, at least not in the default. It's one that you have to custom add and redo after every update. It would be great if all of these indeed could be added in the default install. - PNEU/ ELEC (currently assigned in my system as a DX entry) { down = alt_commands.ELEC, up = alt_commands.ELEC, value_down = -1.0, value_up = 0.0, cockpit_device_id = devices.AAU34, name = _('Altimeter Mode Switch ELEC/OFF'), category = {_('Instrument Panel')}}, { down = alt_commands.PNEU, up = alt_commands.PNEU, value_down = 1.0, value_up = 0.0, cockpit_device_id = devices.AAU34, name = _('Altimeter Mode Switch PNEU/OFF'), category = {_('Instrument Panel')}}, - EJECTION SEAT ARM/SAFE (currently not assigned (left empty) -- Self added Sept2024 { down = iCommandPlaneEject, pressed = iCommandPlaneEject, up = iCommandPlaneEject, name = _('Eject (press once)'), category = _('Systems')}, { down = cpt_commands.EjectionSafetyLever, cockpit_device_id = devices.CPT_MECH, value_down = 0.0, name = _('Ejection Safety Lever, SAFE'), category = {_('Systems')}}, { down = cpt_commands.EjectionSafetyLever, cockpit_device_id = devices.CPT_MECH, value_down = 1.0, name = _('Ejection Safety Lever, ARMED'), category = {_('Systems')}}, { down = cpt_commands.EjectionSafetyLever, up = cpt_commands.EjectionSafetyLever, cockpit_device_id = devices.CPT_MECH, value_down = 1.0, value_up = 0.0, name = _('Ejection Safety Lever, ARMED/SAFE'), category = {_('Systems')}}, - FUEL QTY TEST momentary (currently assigned in my system as keyboard "CTL ALT w") {down = fuel_commands.FuelQtySelSwTEST, pressed = fuel_commands.FuelQtySelSwTEST, up = fuel_commands.FuelQtySelSwTEST, cockpit_device_id = devices.FUEL_INTERFACE, value_down = 0.1, value_pressed = -0.1, value_up = 0.1, name = _('FUEL QTY SEL Knob - TEST Button Special'), category = {_('Instrument Panel')}}, Please ED, do something about it.

Thank you very much.

problem solved LeCuvier I restored the default file and all problems disappeared Many thanks for pointing me to the source of the issue. I doubt I would have thought about the default file being the culprit You help is invaluable. Many thanks

I do. after updating I always add a line to default key and joystick LUA; doing this for ages? But maybe I did something wrong in the last modifications. I do have backups too. Joystick default modification for missing PNEU/ELEC default (joystick) for adding PNEU switches to BU0836A (D:\DCSWorld_OpenBeta\Mods\aircraft\F-16C\Input\F-16C\joystick) line 138-139-140 -- Self added January 2024 { down = alt_commands.ELEC, up = alt_commands.ELEC, value_down = -1.0, value_up = 0.0, cockpit_device_id = devices.AAU34, name = _('Altimeter Mode Switch ELEC/OFF'), category = {_('Instrument Panel')}}, { down = alt_commands.PNEU, up = alt_commands.PNEU, value_down = 1.0, value_up = 0.0, cockpit_device_id = devices.AAU34, name = _('Altimeter Mode Switch PNEU/OFF'), category = {_('Instrument Panel')}}, keyboard default modification forCorrecting FUEL QTY TEST default (keyboard) for correcting bug on FUEL QTY TEST (D:\DCSWorld_OpenBeta\Mods\aircraft\F-16C\Input\F-16C\keyboard) line 289-290 -- Self added feb2024 {down = fuel_commands.FuelQtySelSwTEST, pressed = fuel_commands.FuelQtySelSwTEST, up = fuel_commands.FuelQtySelSwTEST, cockpit_device_id = devices.FUEL_INTERFACE, value_down = 0.1, value_pressed = -0.1, value_up = 0.1, name = _('FUEL QTY SEL Knob - TEST Button Special'), category = {_('Instrument Panel')}},

here's a specific example Trim nose down is supposed to be SHF+CTL+F3 Here's what I have in the config First I see more assignation than the single SHF CTL F3 I see a RCTL; having been inserted before my own custom declaration, it wasn't so before. The line ressembled the trim left and right which apparently don't see to support the issue and when I click on that keybind to see where it is declared twice: It's empty, usually I see where it is declared another time, here nope. It's getting weirder