Durham

Recently got a Rhino FFB joystick primarily for force trim on AH-64D. Got that working and it really is transformative having the cyclic behave as the manufacturer intended. However, have experienced the uncontrollable roll (usually to the right) which sometimes ends up in inverted flight. Nonetheless, spent two hours last night trying and failing to replicate, irrespective of how irresponsible I was with the cyclic roll. Reasonably convinced by the discussion above that it is more to do with the controller(s) fighting the SAS system, so now have that up and am monitoring. Will try again tonight messing around with load out, density altitude to see if I can predictably induce the uncontrolled behavior and will update here if I succeed. What does seem obvious is that if you fly carefully, blip the trim repeatedly, she flies in a very believable and predictable manner, but sometimes, if you fly like an idiot, it will bite you and if you are low to the ground you crash and burn. Yet to have it affect a squadron multi-player mission, only when messing around flight testing in single player have I lost control. Ho hum.

And they likely pre-compute on mission/session load? So chat with Austin required?

Here is the code to determine the wind direction and heading at two points - one a vehicle on the windward side of the mountain, the other on the leeward. --functions region function round( x ) local f = math.floor( x ) if (x - f) < 0.5 then --round down return f else return f + 1 --round up end end--function round function getHeading( windVector ) local result = 0 local heading = math.atan2( windVector.z, windVector.x ) --default_output_file:write("Done heading math!\n") if heading < 0 then heading = heading + 2 * math.pi --put heading in the range of 0 to 2 pi end heading = heading * ( 180 / math.pi ) --convert radians to degrees result = round( heading ) --spin the heading by 180 to conform with aviation norms! if result > 180 then result = result -180 else result = result + 180 end return result end --getHeading function getSpeed( windVector ) local result = 0 local speed = (windVector.x^2 + windVector.y^2 + windVector.z^2)^0.5 --m/s speed = speed * 1.94384 --to knots result = round( speed ) return result end --getSpeed --say you're starting trigger.action.outText('WindTest starting...' , 5 , true) --get the location of each of the units --groups local unitWindward = Unit.getByName('Windward-1') local unitLeeward = Unit.getByName('Leeward-1') --positions - vec3 local posWindward = unitWindward:getPosition().p local posLeeward = unitLeeward:getPosition().p --log write the positions log.write('WINDTEST', log.INFO, 'Pos_Windward: x = '..posWindward.x..'; y = '..posWindward.y..'; z = '..posWindward.z..'.') log.write('WINDTEST', log.INFO, 'Pos_Leeward: x = '..posLeeward.x..'; y = '..posLeeward.y..'; z = '..posLeeward.z..'.') --increase the altitudes by 10m posWindward.y = posWindward.y + 10 posLeeward.y = posLeeward.y + 10 --surface heights - number - currently unused --[[ local heightWindward = --land.getHeight(posWindward.x, posWindward.z) local heightLeeward = --land.getHeight(posLeeward.x, posLeeward.z) log.write('WINDTEST', log.INFO, 'height_Windward: = '..heightWindward..'.') log.write('WINDTEST', log.INFO, 'height_Leeward: = '..heightLeeward..'.') ]]-- --winds - vec3 - for the two units local windWindward = atmosphere.getWind(posWindward) local windLeeward = atmosphere.getWind(posLeeward) --windspeed and heading for the two units local windspeedWindward = getSpeed( windWindward ) local windspeedLeeward = getSpeed( windLeeward ) local windHeadingWindward = getHeading( windWindward ) local windHeadingLeeward = getHeading( windLeeward ) --log.write the results of the loop log.write('WINDTEST', log.INFO, 'Wind_Windward: x = '..windWindward.x..'; y = '..windWindward.y..'; z = '..windWindward.z..'.') log.write('WINDTEST', log.INFO, 'Wind_Leeward: x = '..windLeeward.x..'; y = '..windLeeward.y..'; z = '..windLeeward.z..'.') --log.write speed and heading log.write('WINDTEST', log.INFO, 'Wind_Windward: heading (deg) = '..windHeadingWindward..'; speed (kts) = '..windspeedWindward..'.') log.write('WINDTEST', log.INFO, 'Wind_Leeward: heading (deg) = '..windHeadingLeeward..'; speed (kts)= '..windspeedLeeward..'.') --write results to user trigger.action.outText('Wind_Windward: heading (deg) = '..windHeadingWindward..'; speed (kts) = '..windspeedWindward..'.', 5 , false) trigger.action.outText('Wind_Leeward: heading (deg) = '..windHeadingLeeward..'; speed (kts)= '..windspeedLeeward..'.', 5 , false) --say you're done trigger.action.outText('WindTest completed.' , 5 , false) WindTest.lua 4 KB Here are the log results: 2023-01-22 02:30:47.957 INFO WINDTEST (Main): Wind_Windward: x = -20.213688330495; y = 0; z = 32.348655590497. 2023-01-22 02:30:47.957 INFO WINDTEST (Main): Wind_Leeward: x = -20.66910287424; y = 0; z = 33.077471069346. 2023-01-22 02:30:47.957 INFO WINDTEST (Main): Wind_Windward: heading (deg) = 302; speed (kts) = 74. 2023-01-22 02:30:47.957 INFO WINDTEST (Main): Wind_Leeward: heading (deg) = 302; speed (kts)= 76. So even with a big mountain between the two the windspeed is identical, give or take the 2kts because one unit is higher than the other. I agree with the previous comments that computing this only the fly is going to be ridiculously expensive, however, as the wind doesn't change over time, other than the altitude slope, then could pre-compute with mission load? WindTest_NTTR.miz

I couldn't agree more with your post. Having the filepath default to last is fine. Having the filename default to "newmission" or "untitledmission" is fine. Letting them save "newmission" or "untitledmission" or whatever the default is set at is stupid - just check for the default and throw an error box asking for a new filename. Having the filename be equal to the last filename that you saved is moronic, and just begs for the user to overwrite a mission they have spent hours on with a new one they have spent minutes on!! And I have been bitten by this dog before, so please remove the teeth from the dog.

Mine arrived today in Miami. Needed a bit of WD-40 and pre-screwing to get the four big screws (M5) in - electronics came up immediately - plug and play. The units report to Windows as either Right or Left, and of course I hadn't plugged them in, so had to swap - so top tip, plug one in and see how it reports and tag as L or R. Also the paper screens don't slide in like the TM Cougar, so put them underneath before screwing the panels to the mounts. DCS programming was a breeze with a little help from the US Army manual: T = Top - buttons are L to R, same for B = Bottom, R and L are top to bottom. Only difference is that B1 is the black button labelled M. Of course DCS made me invert the four BRT and VID axes for the potentiometers, as well as initially programming them to the cyclic, because its controller detection/suggestion is not the best. They are bloody big (the diagonal is 50% greater than the TM Cougar (29cm v 19cm), I had to clear out two additional desktop mounted throttles to make room for them, so goodbye X-Plane with the Honeycomb. In VR, mounted pointing up they seem about 3-4" higher than in the VR cockpit, so mounting them hanging down from a desk would be worse, as they would be around 6" too low, and might interfere with your knees moving the rudders. Button pushing is way better than the Cougars with a real click, instead of just push and hope. Will take a few hours to get faster than head pointing and using my HOTAS mouse buttons, but highly confident I will get faster over time than that solution. So, in summary, really cool product, and with the EURO dropping below parity, an absolute bargain for USD buyers. Now just waiting for a VP Rhino to become available to sort out the trim issue , and then VPC to make an AH-64 grip and collective!

Start by disabling the GPS module NS430 wherever you have it (standalone, MI-8 etc) - there is a conflict that causes a crash and we are yet to figure it out.

I remember researching it and thinking it perfectly achievable in lua as the logic is not that hard. Start here. and then you remember you will be using this scripting function to check the surface type of the nodes about the unit https://wiki.hoggitworld.com/view/DCS_func_getSurfaceType to make sure your tank doesn't drive into a lake. First be careful, because ground units are controlled at the group level so even with the controller object working properly, you can have issues with the unit children driving into lakes as they maintain formation. Second, be careful that pushing tasks to a controller sometimes does not give you the immediacy you want, so better to figure out the route and then push it once, rather than endlessly check and push new routes endlessly.

Virpil - the base is excellent, the desktop mounting system works well, and the ability to hotswap the two TM sticks (Warthog, Hornet) with their own stick closes the deal.

Working on keys for my streamdeck - does anyone happen to know what the font used inside the F-14 is, or its closest equivalent in Windows? I am getting reasonably close with Arial and Sans Serif, but they are obviously not the exact one used. Many thanks.

DCS-Hawkeye Video Here is a video highlighting the main features of my project, DCS-Hawkeye Comments, suggestions and criticism gratefully appreciated.

sgray - That sounds great - have been looking for an SME for some months without success. Look forward to hearing from you.

Mule - You are welcome to a demo if that would be of interest. Let me know.

Sgray - do you have any former E2 backseaters in your squadron, as I really need help on the deeper functionality - ie to understand what the buttons at the top do! Many thanks. Durham

E2 Hawkeye simulator I am in late stages of building a simulator of the back seat of the E-2 Hawkeye, which is currently in alpha with my squadron, the 16AGR. If you want to join the squadron and only play when I am running the server (there is currently only one copy in circulation at present, because the database is not yet multi-tenant), then fine, otherwise, I invite you to look at the screenshot below and await the beta release, which may or may not come before the Tomcat. For obvious reasons, being that it flies off US carriers for the US Navy, it only works with Blue, and is much better suited for carrier defence operations over sea, than air to ground operations. Functionality currently implemented: 1. Mission time; 2. Unit tracking for air and rotary; 3. Multiple location formats - lat, lng (deg, min, sec & decimal), utm, mgrs 4. 40/20nm range scale on lh side varies with zoom; 5. Handles the world - so all four dcs maps; 6. Map matches hawkeye displays from public sources, as best as I can; 7. Unit selecting, which populates primary window, with location and target identity data; 8. Bullseye shows on map as blue target icon; 9. Bra and bullseye data for calls; 10. Unit hooking; 11. Callsign comes through for players in JTIDS equipped platforms (modern US ones); 12. Callsign, unit type can be amended by client; 13. JTN can be allocated by user and displays next to unit icon on map; 14. Label giving basic unit data (callsign, JTN, course, speed altitude) on mouse hover; 15. Can be used by multiple clients simultaneously with user amendments flowing through from one to all; 16. Map refresh rate stable at ~5 seconds; 17. And some other stuff I cannot think of at the moment. Lots of features still to add, but the current version provides a pretty intense experience in multi/multi player air-to-air engagements, and would seem to add considerable value to the flyers, in terms of situational awareness, which is the whole point of the platform.

Thank you For all the manic hard work you have invested to get the server to its current state. I have every confidence that you can advance it further, as you are the maestro at finding workarounds to the limitations/constraints of the current user-facing API, that flummox me and many others. Thank you and best of luck. :thumbup: