John Dowson

Ok, but that is strange. Usually once an offset is allocated to a simvar (or sim event for writes) it doesm't generally change. \in the documentation I have, viewpoint piyvh, bank and heading are at offset 0x83D4 and marked as 'FS2004 only' (i.e. FSUIPC3!). Yes. They are offset addresses into an FSUIPC byte array. No. They are populated from FS memory locations in earlier version of FSUIPC (i.e. hacked) , but from FSUIPC4 onwards they are populated using the SimConnect SDK. Once an offset is allocated for a particular simvar or function, we try to keep that offset allocated for the same simvar/function across all versions of FSUIPC, although this sometimes isn't possible. Cheers, John

Are you using an MSFS version from Steam or the MS Store? If using a steam version, please see the README.txt file included in the zip file you downloaded: If you are using an MS Store installed version, delete this file: C:\Users\Pc\AppData\Roaming\Microsoft Flight Simulator\UserCfg.opt Also, please make sure that you extract the files from the zip file you downloaded before running them. From the log file you attached, it looks like you are trying to run the installer directly from the zip file (windows allows you to do this for some reason) - this can cause issues: John

Yes, better to use one function rather than two. However, two (or multiple) events on a key or button shouldn't be a problem really, but I cannot confirm that for FSUIPC3 - that may be restricted to a single event per keysytoke/button (and per lua thread). John

May not be there in FSUIPC3 - best to check. This really isn't the place for programming basics... The values are passed to the function via its parameters. The third parameter contains the downup value (hance this is why we call the variable that holds this downup) as an integer (not a bit), with possible values described in the documentation. Not sure what this means - 'bypass the downup function'? there is no 'downup function'... And event handling functions don't return anything. Did you not see my example above: I suggest that you look at some of the example lua scripts provided, or check out some of the user contributed lua scripts (see the User Contributions sub-forum). John

Thanks for sharing. Could you possibly create a post in the User Contributions section and attach your wiring and configuration diagrams directly to the post rather than linking to a shared (google) drive? The problem with such link is they tend to not last that long. You can also reference this topic for further details. Thanks and regards, John

I don't know why you have attached 3 useless log files.... Can you please not start a new log file, there is no need. Your axis assignments now look very strange: You have multiple assignments to mixture 1 set (13 - 2 assignments), mixture 2 set (14 - 4 assignments), etc And your calibration looks even stranger: There is no calibration to the axes you have assigned (e.g. mixture 1 set), and you have strange throttle calibration which you haven't even assigned. I suggest that you read the user guide and start again. Read the section 'The Easy Step-by-Step Way to Calibrate Your Controls'. If you want further help after trying to assign and calibrate your controls correctly, show me the updated ini and a single log file where you have activated the correct logging (i.e. axes controls if your issue is with axes) and showing your issue (i.e. move the assigned axis through its full range) together with a relevant description of the problem. The set-up for ax axis assignment for the Honeycomb Bravo is exactly the same as you would do it for any other device, such as your old CH throttle, so I really don't understand why you are having such difficulty. John

Exactly - you need the hex value as offset 0x311A is a BCD value - Binary Coded Decimal. So, as the example given in the offset status document, a value of 0x2345 would indicate a frequency of 123.45. If you use the decimal value, you will get the wrong frequency. If you want the frequency as a decimal, use offset 0x05CC instead. It is a value that will be stored in the variable. If you use "(apple, peach, spaghetti)", the downup value will be stored in the variable 'spaghetti'. Always better to scope variables. Functions have parameters that are passed to them. How would you know the value otherwise? You could declare a 'downup' variable in the script, but it won't have the downup value needed when the function is called/triggered (unless you declare that again as the correct function parameter). John

You shouldn't need repeat, as the key is assigned to press & hold on the client. Also, using the same key (F1) to send from the host to the client and also to activate PTT on the client works ok for now, but I recommend that you use a different key. Currently its ok to do this as I remove the keyboard focus on the client before I send the PTT key, so there is no loop (i.e. the key press being sent by the client is not received by the client), but this could possibly change in the future, although I have no plans to change this at the moment. John

👍

Can you please try with the attached FSUIPC7 version below, v7.3.2a. To set up PTT on a client PC with P2A, follow the following steps: 1. Assign a hot key in P2A for PTT. For this example, I will use the z key. Note that this IS NOT the key that you will use to activate PTT, but the key that FSUIPC7 will use. 2. In FSUIPC7 on the client PC, go into the 'Key Assignments' panel and assign the key you want to use for PTT to the 'Key Press/hold' event on keys pressed, and to the 'Key Release' event on keys released. You will need to know the virtual keycode number of the key assigned in step 1. I used the 'z' key, which has a vk code of 90, so my assignment to the 'T' key looks like the following (left-hand side, note also check for 'No Repeats'): If you do this, PTT should activate when using the assigned key ('T' in this example) on both the MSFS host PC as well as the client. I also fixed the focus issue, so it shouldn't matter where the input focus is on the client PC for this to work. Let me know how it goes. John FSUIPC7.exe

Also, maybe try just one event function, e.g function keyUpDown(keycode, shifts, downup) if downup == 1 then ipc.lineDisplay("Key Down") elseif downup == 0 then ipc.lineDisplay("Key Up") end end event.key(k,0,3,"keyUpDown") And if you don't want key events handled in lua to also be forwarded to the FS, use the LuaTrapKeyEvent ini parameter: John

All those errors are from custom events (i.e between 32768 - 65791). Are they trying to use custom events which haven't been made known to FSUIPC via a *.evt file? FSUIPC will only report the lvars it finds, with a maximum of 2044 lvars. If they are not all initially received, then increase the LvarScanDelay parameter in the WASM ini file. John

That looks like it should be ok (except it looks like you are using 'o' instead of '0' for the shifts parameter....) but it is always better to attach your full lua script so that I can check it. Rather than using ipc.linedisplay, its easier to use ipc.log and keep the logging console open when debugging lua scripts. You can then also use the log Lua Plugins function to see what is happening when debugging lua scripts. And always better to follow the documentation, and so your handling functions should be of the form: function keyDown(keycode, shifts, downup) ... end This is not correct - you need to use either 0x311A or "311A" This is also incorrect - use the string.format function to get a hex representation of the string and then prepend the 1 - something like comDisp = string.format("1%04x", ipc.readUW(0x311A)) Not sure what you mean by this, but its really up to you. You can have an assignment to a key/button in FSUIPC and an event on the same key/button if you like, although that is a a strange thing to do (but can sometimes be required). You would usually either use an FSUIPC assignment or a lua event-based script, not both. If you are controlling via lua, you don't need any assignments. You should auto-start event-based luas from the FSUIPC ini [Auto] or profile [Auto.xxxx] sections. Not sure what you are trying to say here, but I do not support SPAD. John

See the Advanced User Guide, the sections on Compound Button Conditions and Adding Offset Conditions - more likely the former for what you want to do. John

This can be done using compound button conditions - see the Advanced User guide. I don't know why they would say that - do you have a link to this so that I can comment? I posted on how to set-up the bravo for this with standard FS controls (not using the more complex lvar/hvar.calc code or presets that you will need to use for the CRJ). You can take a look at this and then adapt (i.e. set up a CRJ profile and adjust the controls used for this aircraft) - see Check the MobiFlight Hub Hop preset list (https://hubhop.mobiflight.com/) for the presets to use for the CRJ. John

I have this working now, but with a caveat...it is only working when FSUIPC7 on the client PC doesn't have the window input focus - the focus can be on any other window except for the FSUIPC7 main window. Not sure why this is at the moment, I will look to see if I can correct this. The solution doesn't use lua, but you need a new version of FSUIPC7 with keyboard input/forwarding activated on the FSUIPC7 client (this is currently disabled). I will look into this further tomorrow (have to finish now) and I'll post you an updated version to test with instructions on how to set this up. John

It looks like you either don't have the FSUIPC7 WASM module installed, or it is installed but not activated. Presets use calculator code that require the WASM module installed and activated. John

Ok, but that image shows you using 0x66D0, which is an offset free for general use (and not 0x000), which is fine... Ok, glad that is now solved. I understand the issue but cannot really advise on this. You could maybe ask about this over on cockpitbuilders.com. Sounds like the same issue posted in this thread (but unfortunately no solution): https://www.cockpitbuilders.com/index.php?topic=2412.msg18528#msg18528 and https://www.mycockpit.org/forums/showthread.php?t=17573 John

I don't understand this... you cannot use offset 0x0000, and 0x0000.0 doesn't make any sense...and what is 'Servo Output'? No, as I don't understand what the issue is....what are 'servos'? If you think your issue is with FSUIPC, then I need to see your FSUIPC log and ini files. as well as a description that I can make sense of...You seem to be using various components that I am not familiar with... John

Only the latest version of each FSUIPC version is supported. Please get the user to update to V7.3.1 and try again. John

A link would have been useful...but I found that post... What does this mean? I don't understand what 'half a stroke' means, sorry... Are those the read-outs from the 'on' values? If so, that seems reasonable to me...generally axis ranges go from -16383 to +16383, so you are missing a bit at the extremes but otherwise it looks ok. Have you calibrated your axis in the windows game controller app - you could try this to get the full range. The 'out' value will depend on the axis control you have assigned to, if you have defined a reverse zone or not, and any calibration that is applied. Also, the issue you described over on FlightSim.com is different: This sounds like its going from -16256 to +16256 for the first half of your axis, then jumping from +16256 to -16256 half way through the momvement and starting again....that does sound very strange and I really can't see how that can be happening... Maybe you can attach your ini and log files. For the log, activate axis logging and move your throttle, prop and mixture axis each through its full range and back again. This should show what values are being sent to the FS. John

This is usually due to the fact that the installer detects a steam installation when you are in fact using a MS Store installation, or the MSFS UserCfg.opt file cannot be located. Can you attach your InstallFSUIPC7.log file please and I can take a look. Also, please update to the latest version, v7.3.1. Only the latest version of FSUIPC7 is supported. John

Hi Andrew, No, I'm afraid not. Allowing additional simvars to be added once the simconnect connection has been opened and simvars already requested poses many issues that I am not willing to look into at the moment. It will have to be up to the user and the software developers to handle this correctly. I could allocate a specific offset area (i.e. not in the 'free for general use' offsets) for use by LINDA to prevent the same offsets being used by other utilities, if that helps. If you let me know the size required, I can take a look and see if I can find an area to allocate for this. Cheers, John

Could you also attach your FSUIPC7.log file as well as your complete FSUIPC7.ini file (not just an extract), with logging for buttons and events activated, and showing an assigned button press. If you aren't loading the aircraft 'CRJ700ER Horizon Air N613QX' then that profile won't be loaded. You should use a substring in your profile to catch all versions, i.e. [Profile.CRJ] 1=CRJ700 John

To receive button presses and release, the format is: event.button ("H" , 2 , 3, "my function") The downup is a parameter and should be one of the following values (as described in the documentation): John