RoboPhred

I was able to set up multiple dead zones in my tracker mapping so that the view will latch when looking down at the left and right consoles, and a small latch for the center console. This works rather well, and keeps the camera steady for those areas while still allowing fluid movement when looking up and out of the cockpit.

Thanks for the feedback! I am in the process of building a few bits of hardware for a homepit, and its been interesting trying to figure out how to pull data out of this game.

You might be hitting the range of the HUD SPI marker. When slewing the marker on the HUD, it will show an X through the square if it cannot resolve the target the marker is over, which mostly is due to range. Try setting the marker down, so it covers something closer to the aircraft.

It's nice to see this working! Did you reference my solution at all? Specifically, the second half of http://forums.eagle.ru/showthread.php?t=152171 It should be possible to run the same math in reverse when HELIOS pushes the values back into the sim as well, eliminating the need for replacing the rotary encoder swap. I have not gotten around to this yet, but may give it a try later on.

You built helios with visual studio, right? Have you tried running it through the debugger and seeing what is crashing?

Interesting, I didn't update my exports with the new version, and I can still get the slowdown when running the current release... At any rate, you may not want to up the gExportLowTickInterval, that controls the update rate for most of the switches, and will just add to more cpu burn and fill up the network socket. Too much in there will start to slow HELIOS down again as it has to deal with the backlog of data.

I started playing around with the source to HELIOS, and made a bit of progress on bringing back VHF AM/FM radio freq functionality. The relevant bits are under https://github.com/Gadroc/helios/tree/master/Helios/Interfaces/DCS/A10C/Functions and are named VHFRadioEncoder VHFRadioEncoder1: xx0.000 VHFRadioEncoder: 00x.000 VHFRadioEncoder3: 000.x00 VHFRadioEncoder4: 000.0xx The code connects these to devices 139 through 142 respectively. I started trying to map the new values over, and managed Encoder4 just fine. However, on starting on encoder 1, I get values that repeat before the numbers do... Input : DCS Value 03: 0.40 04: 0.50 05: 0.60 06: 0.70 07: 0.80 08: 0.90 09: 0.00 10: 0.10 11: 0.20 12: 0.30 13: 0.40 14: 0.50 15: 0.60 Notice how at 9 it rolls over, and the values 13 through 15 are the same as for values 3 to 5. I have not tried sending values yet, and I do not know what values the repeated numbers will resolve back to. In order to get full control of the radios, this will need to be overcome. I am at a loss on this part, as this is the only approach I know of to set the frequency from scripts. Read-only access however is looking a lot more shiny. As an experiment, I modified the Exports.lua generated by HELIOS to return the actual frequency in the same way it reads the UHF repeater frequency: -- VHF AM local vhf_am = string.format("%.03f", GetDevice(55):get_frequency()/1000000) SendData(139, vhf_am); SendData(140, vhf_am); SendData(141, vhf_am); SendData(142, vhf_am); I also disabled entries 139 to 142 in the "gEveryFrameArguments" object found above it. With this in place, I modified HELIOS to calculate the frequency correctly, and was able to fix the display. It is even possible to throw some math at the problem and perform these corrections inside Exports.lua, essentially backporting the data to what HELIOS expects. Unfortunately, this will not fix the rotary encoders, and attempting to change frequency from HELIOS will still result in strange behavior. Can anyone shed some light on where these device argument values come from? Is this internal to the engine, or are the arguments for these devices defined in lua somewhere?

I had the same issue using the released version on gadroc's website, but building the current version at https://github.com/Gadroc/helios seems to not have the same issue. I suppose we need to wait for an official release of the next version.