evaamo

Hi there, has any of you been successful at mapping a custom key in FSUIPC to the numeric keypad "Enter" key. This key is usually configured in FSX as "Rudder Right", and I have already deleted this assignment in the simulator. The problem is I'm unable to assign any function to that key via FSUIPC even when it has been unassigned in FSX. Any clues? cheers -E

Thank you Pete, I will try ipc.set and get again. I was getting a strange error using ipc.get yesterday, but I will only bother you with that if I'm able to reproduce it. For the moment, enjoy your holidays! cheers -E

Hi Pete, I recently created a small Lua script to control the Aerosoft Airbus X Extended throttle (FADEC) and rudder using FSUIPC. The reason I'm writing to you, is because the script that controls the rudder is using a workaround which I'm not sure is actually safe, with regards to the FSUIPC offset ecosystem. To make a long story short, as the Aerosoft Airbus X Extended is controlling the rudder in a way that makes it impossible to use the keyboard, after many attempts I found that the best way to force incremental rudder travel was to feed FSX via the Lua script through the additional FS control for the rudder (64103) when the users presses a key, then read the FSX rudder offset to add some more rudder input and so on until hitting the +/- 16383 boundary, which would mean the rudder is full to whatever position the user commanded. However, reading the rudder offset was a failure (I imagine due to Aerosoft's programming), and the only way to keep track of the rudder setting was to use a "free" offset to store the data (signed 32bit). As you may imagine, I used the 0x66c0 offset. Now, considering my workaround, how much of a bad practice is it when using such a "free" offset to store the rudder value and what ugly scenarios can you picture from the use of such? Should I change anything? use different offsets? If you want to take a look at the scripts, you may find it here: http://bit.ly/VRULND Thank you! cheers -E