John Dowson

No - this file is from 24/03/2023 and from FSUIPC7 version 7.3.19, whereas your FSUIPC7.ini file is from version 7.3.20 (the latest version). If you cannot see the FSUIPC7.log file, you probably have windows explorer set to hide the extension of known file types. Then, if you have set the logging as I have asked, then either the extension is hidden, as with the FSUIPC7.log file, or the lua script is not running. How are you starting the HidDemo.lua script? I see no [Auto] section in your FSUIPC7.ini that starts this. So, please check that the lua script is actually running. Then, once you have confirmed that it is running, please provide the files I asked for with the logging asked for (and no other logging). For your parking brake issue, please also attach the ini file for the aircraft/profile that you are using, and please keep the test as short as possible, i.e. load your aircraft, press the button to activate the parking brake, then release. Then exit FSUIPC7 and show me the files requested. Note that you have two issues, and I expect to see two sets of files, one for each issue, as they are not related. In future, please create a separate topic for each issue. Looking at the in you attached. it looks like you are trying to comment out lines by using the double back-slash '//'. Those characters do NOT designate a comment in an ini file. Use the semicolon ';' instead. Also, change to i.e. use substrings for your aircraft profile names John

No, you should use the number.

Sorry but I don't understand. What is a 'chassis crane'? What do you want to do?

Why? The preset is a name, and the documentation for this function is: The only number needed is the parameter, if the preset uses one (most don't). John

Can you not do this yourself? Why don't you just try running it, and use the provided debugging facilities if you have any issues. As you are not using the double press, then you should at least remove the following line (as it will create an error if you do double-press): ipc.control() Or, better still, remove the code that handles a double-press completely if not using this. John

Activate logging for Events (Log->Events) and open the logging console (Log->Open Console) and see if anything is logged. However, at the moment, since the latest SU release, many events are not logged as they are now using the new *_EX1 event system. I have an update for this to be able to catch such events, but this is not yet released. This will be in the next release (7.3.21). Also note that only standard events/controls are logged. You will not see any preset names being logged, as these are not actually used by the aircraft. The code for a preset mimicks what happens when a VC control is activated.

No, that won't work, as you are changing the variable value. You can use one script if you know what you are doing (I am not going to explain this to you...!), but it is probably easier to use a separate script for each button. What don't you understand? Your script contains the following lines to execute the control/event: ipc.control(67279) So that sends the control AUTO_THROTTLE_DISCONNECT. To send a preset instead, change that to: ipc.execPreset("presetName") where presetName is the name of the preset. Or add the parameter if the preset uses one, e.g. ipc.execPreset("presetName", param) John

For presets, just use ipc.execPreset instead of ipc.control John

No, mouse macros are not possible with MSFS2020.

Take a look at the TripleUse.lua script which is included in the lua examples (zipped in your FSUIPC7 Documents folder). There is also a more advanced version of this lua script available in the User Contributions sub-forum: You should be able to adapt either one of those for your needs. John

The presets provided are a community effort, led by MobiFlight. If there are currently no presets available for this aircraft, it is because nobody has yet submitted any. You can define your own presets if you like, using the myevents.txt file (see Advanced user guide, WASM section). You should also submit any presets you create to MF, so that they can be used by others. However, looking at the Headwind A330, it does say that it is based on the FBW A32NX, so you may find that many of the presets for that aircraft also work with the A330.

To enable debugging in one script, just restart it by using the LuaDebug control. If you want to be able to turn debug logging on and off in a script without restarting it, add the following code to your lua script: Then, to turn on/off debugging in the script, you can assign a button or key press to the control LuaValue <scriptName> (where <scriptName> is the name of the lua script) with a parameter value of 1 for turning on debug logging, and 0 to turn it off. You can also change the debug logging function or the type of hook to suit your needs - again, see the ipcDebug.lua script for an additional debug logging function, and see the lua documentation on the debug library and the sethook function.

I am still not 100% sure in what you are trying to achieve.... If you want lua debug logging active in one script only, I have explained how to do that, If you want to be able to turn debug logging on and off in the script itself, this is not possible as things are. However, if you want to do this, you can add two additional functions to the ipcDebug.lua to add and remove the debug hooks, and then include/require that and use them. You can even use the ipcPARAM parameter to determine if debug logging should be enabled or not when you start the script, if you so wish. So, anything should be possible really. Just take a look at the ipcDebug.lua script, and look at the lua documentation for the debug.sethook function.

Whatever you want - this value is just passe to the lua script in the ipcPARAM variable.

"Debug mode" just means that the debug hooks have been activated in the script. This is done by either: - setting the Log -> Log Lua Plugins option. Will enable debug mode for all lua scripts started after this option is set - starting the script with the LuaDebug control - including (i.e. require) the ipcDebug.lua in the script. I seem to be saying the same thing again and again. I don't understand what you don't understand... Please see the FSUIPC Lua Plug-ins document.

Once a lua script is running in debug mode, you cam only stop the debug logging by killing the script and running it again. Similarly, if a script is running and you want to start debug logging for it. you need to kill it and restart it in debug mode. You can assign a button or key press to both Lua <script> and LuaDebug <scriot>. Starting a lua with such a control will kill the script, if already running, and restart it either without or with debugging, depending on the control used. Other than that, I am not sure what you are asking, If you don't want the cursor.lua script to log lines to the console, don't run it in debug mode and don't set the log option to run all lua scripts in debug mode. If you just want one (or more) scripts ran in debug mode, start those scripts with LuaDebug, or include the ipcDebug.lua script in them, as I have said,.

Please read the comments in how to use the trial license, If it is nor working ok after correct installation, you probably need to update your VC++ retistrubutables (instructions included in documentation). Otherwise, please post more info , including logs... J0hn,.

To use for read or write? To write, you can use the lua function ipc.control with the Offset Byte Set control - from page 33 of the Advanced User guide: x0100zzzz Offset Byte Set (offset = zzzz), hexadecimal As the offset holds the value for (up to) 8 doors, you need to read the current value, change the bit for the door you want to control (using the lua Logic library) and then write the value back. To read, just read the byte value and use the lua logic library to test each bit for the door needed. To get events on change, you can use the event.offsetmask function. However, this assumes that the aircraft is actually using this simvar... It could be, but many aircraft add-ons (and provided) don't actually use this simvar, and use lvars instead. So. before anything, try logging that offset (as an Unsigned Byte in hex) and see how it changes when you open/close the doors. If it changes as expected, then should be ok to use, but also be-aware of the note on this offset: Doors' states depend upon aircraft position (e.g. ramp, gate, or connected to jetway) and don't respond. Further information / Asobo support required. Seehttps://forum.simflight.com/topic/90252-door-offset-not-functifor further info. Sorry, but I don't have the MD11F so cannot look into this further for you. I will update the title of your post - please always include the aircraft if it is an aircraft-specific issue. John

Are you sure the lua script was running? Can you set Logging = true in the HidDemo.lua script, set Log -> Log Lua Separately in FSUIPC7, and show me both your FSUIPC7.log and HidDemo.log files, as well as the HidScanner log file. For this issue, please set logging for Buttons & Keys and Events and generate a short FSUPC7.log file showing your issue, and attach that as well as your FSUIPC7.ini file. John

Assignment facilities are only available in a registered/licensed version. If you don't have a license, and want to try these facilities, there is a trial license available in a post oat the top of this forum. If you have a license, you need to register it at the end of the installation process. John

Compare each bit position: bit 0 - first number has 1 in this position, second has 0 - and (&) them and you get 0 bit 1 - 1 1 1 bit 2 - 0 0 0 bit 3 - 0 1 0 result: 0010 But this is not the place for a binary logic tutorial - please try google!

Yes, of course, as that is the bit value. 0 is always off, and:: 1 = 2^0 (bit 0) 2 = 2^1 (bit 1) 4 = 2^2 (bit 2) 8 = 2^3 (bit 3) ...etc But this shouldn't matter. When testing bits. you just want to know if its off (value = 0) or on (value != 0).

Yes, I noticed that as well and will update. As a sided-note, its also more common/useful to start counting bits from 0, as then bit 0 is 2*0 (1), bit 1 is 2^1 (2), bit 2 is 2^2(4), etc, so the bit number corresponds to the power of 2 number.

The log shows the keys alt+ctl+2 being sent to the FS (both key presses and releases) and also being received back by FSUIPC. Is this key combination assigned in P3D, or in other software? The key combination is only sent to the FS. And it us never a good idea to use the alt key as a modifier, as this has a special meaning in windows for menu operation, which is why it was removed in FSUIPC7.

You should have received an email with your key details (for FSUIPC4). Your key details are also available in your SimMarket account. You can download FSUIPC4 from SimMarket, from fsuipc.com, or from the Download sections of this forum.