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:

That is a clever idea. I will give it a quick test to see if I can get hold of the Controller and pass waypoints and arming as the client loads in. I still doubt it will work as I am pretty sure the Controller only works with AI units/groups, but worth a go as it will be a lot easier than the nightmare I have in front of me of effecting a merge on two mission files! Thanks for the idea!

See my post at CombatFlite for an update. https://forums.eagle.ru/showthread.php?p=3415991#post3415991 I know I can crack blowing waypoints to the .miz file by editing the mission file, but there seems to be no way to do so with clients post mission launch - ie after the game engine has loaded the .miz file components. I have had exactly the same issue with integratring Amazon Polly into DCS, in order to avoid having to do canned voice-overs. While I can get Lua to Amazon to create a speech stream/file, the only files that will play in dcs are those that are present in the .miz file at mission load. I have now got it to work going directly to the sound card, but it only works once. It is a three step process: Lua --> C++dll --> C# dll. One of the first two is not releasing as I can call the C# dll multiple times from a C# windows forms application. Developing in DCS is not for the faint of heart is all I can say after another weekend of achieving nothing.

No, I gave up as the AI units did not seem able to take in the new waypoint quickly enough to enable formation flying - they would just got to a point, stop, think, and then set off to a new point. I found putting them in a group in the ME was better than what I could do.

So, I got it to work. However, the problem is that when I pushTask or setTask with the new derived waypoint, the ship slows to 0kts and then has a think and then sets off at max speed to new waypoint. I logged every step of the way with the deltax and deltay and the trigometry and all seemed to work. However, in order to take a new task the ship seemed to have to go to 0kts. They followed all of their leader's turns, but it was like a Battle of the Atlantic rerun where the escorts would sprint and then stop to listen. I think I will put them all into a DCS Group and then get the lead to turn into the wind with carrierOps = true, and then return to route when carrierOps = false Best D

Maybe you would like to help me finish off my DCSFlightPlanner application, which is designed for pvp mission planning. The squadron that did not create the mission - the aggressors - write their own mission in the mission editor using TeamViewer, Zoom or some other conferencing screen sharing software. That creates a .miz file. The application reads the mission and dictionary files within the .miz file to extract the units and routes of a given side, red or blue. It is a lua parser written in C# that unzips the .miz file and then reads the relevant files, puts the units and their routes into classes and then writes them back to the api language. That is then converted into a Lua file that will create the units and waypoints on mission start. Send the Lua file to the other squadron and have them add a trigger to DOSCRIPTFILE xxx.lua at mission start, and there you go. As long as there is very little lag between giving the other squadron your file and starting the mission, there should be only a small window for viewing and deconstructing the lua file. Anyway, if you don't trust your opponents not to cheat, then why are you playing with them in the first place?

Thank you so much Grimes. That will make everything a lot easier. D

Back doing this again using MIST, which makes things so much easier. Trying to get speed from: leaderSpeed = mist.vec.mag(leadGroup:getUnit(1):getVelocity()) where leadGroup is a group object. According to DCS, group is sailing at 11kts and I get a return of 5.65, which increases as the ship accelerates. I expected a return in knots and cannot think of another unit of speed that has a lower result than knots, so do you know what is happening? Given that all I care about is relatives, should I care. However, in order to predict cartesian co-ordinates one time period in the future, I need to get back to meters per second. Thanks for any advice you can provide.

My flight planner uses a LuaParse class to strip everything out of the mission file. Unfortunately it is not much more efficient than your engine as each time it returns a "LuaObject" which doesn't give you any data until you are at the end leaf of the tree. So the C# reader is not much different from foreach in coalition, foreach in country, foreach in category etc... I tried with NLUA and luajson, but that still did not give me an object on which I could use either xpath or LINQ. Happy to share. Best. D

I was using your heading function which used unit:getPosition(). I remember seeing the .p extension either in my code or yours. I am with you on getGroupRoute, because then (if absolutely necessary I could group:destroy and then coalition.addGroup...). I can just stop the ship, wait until the fsm says that formation is true and then give back the waypoints to the lead ship. As always, thank you so much Grimes. Best. D

And having thought about it more - at present the only solution I can come up with is to use my C# DCS-FlightPlanner application which reads a .miz file (application written for other reasons) and then write back the lead unit (carrier) as a new unit to the mission with its route, and pass its starting position to the mission on mission start, so that the followers can set their initial waypoints accordingly. I also need collision avoidance, but I would like to see whether the low level DCS C++ AI handles that, as the ships get into formation, before doing it myself.