John Dowson

"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.

Delete the Window=... entry from the [General] section of your FSUIPC7.ini (when FSUIPC7 is not running) - this is the ini parameter that holds the window position and size.

Its a 1-byte or 8-bit address. Bit 1 (counting from 1) holds pump1, bit 2 holds pimp2, etc You need to read as a byte and use the logic library, e.g. n=ipc.readUB(0x3125) pump1 = logic.And(n, 0x1) -- 2^0 pump2 = logic.And(n, 0x2) -- 2^1 pump3 = logic.And(n, 0x4) -- 2^2 pump4 = logic.And(n, 0x8) -- 2^3 Offset 0x3104 only holds pump1, so that should match the state of the first bit in offset 0x3125. But that is not correct should be n=ipc.readUB(0x3104). You need to precede offset values with 0x, or use the string form, i.e. n=ipc.readUB("3104") John

The comment on offset 0x0B7C says: Fuel: left main tank level, % * 128 * 65536 So for a full tank, write 100*128*65536 as a an unsigned int. i.e. ipc.writeUD(0x0B7C, 838860800) John

It is compatible - no update needed. John

Ah, ok.... But there are already various ways to do this: - run the script you want to log with LuaDebug, and run the others without - run without lua logging and add ipc.log statements to the script you want to debug - include the ipcDebug.lua script in the lua file you want to debug. A lua function to control this just doesn't make much sense to me as the current lua log options are global - I think it would confuse people and would eventually result in further support requests, e.g. "why isn't my lua script being logged when I have set Log Lua Plugins?". Better to leave the global options as they are and use something specific (i.e. one of those 3 options mentioned above) for the script you want to debug.

For all issues with auto-start, please see the following FAQ entry: I am locking this topic. John

@yindengxie Not only is your question not related to the subject of this topic "FSUIPC7 doesn't start with MSFS2020" , it is also a question on P3D and this is the sub-forum for FSUIPC7. Please create a suitably titled post for your issue in the correct forum.

As does setting the Log -> Lua Plugins option. Why is the saitek script filling the log if you are logging your luas in separate files? If there is a separate script for polling your Saitek devices, this should be logged in a separate script. You can also start some scripts in debug mode, using the LuaDebug control. There is no ips.runluaDebug function. Otherwise, you could include the ipcDebug.lua in the scripts you want to debug. This is included in the provided lua example scripts (in your documents folder. If you take a look at that, you can see how the lua debug logging works - by setting hooks. You could also use this and add your own functions to both set and clear the hooks, and so enable/disable the debug level logging. I am busy the next few days but I can look into this further next week if needed.

Ok, so they work - that is interesting, and rather surprising. The SimConnect_CameraSetRelative6DOF function is no longer documented in MSFS, so shouldn't be available, although it does still exist. It was previously documented as "No error, No response" (i.e. not working), not sure when it was removed. i won't be making any changes to this, except maybe in the documentation. John

Also, please see the following for the simvars that can be used to read (and update/write) the camera state: https://docs.flightsimulator.com/html/Programming_Tools/SimVars/Camera_Variables.htm You can add these to free FSUIPC offsets it you want to access them. John

No, sorry - there is currently no camera interface in the MSFS SDK and the 6D0F functions are also not available - those offsets shouldn't be used. I will mark them as such. Ok, that is interesting - I will check this and mark it as available.. John

Do you mean for this to: 1. turn off lua debug/trace logging, or 2. prevent the logging of ipc.log statements? If 1, then I don't think this is a good idea as all lua activity, including the polling, should be logged. If you want to control the logging in the script itself, you can use ipc.control with one of the logging settings controls - from the Advanced User guide: if 2, I don't see that much need either, although maybe useful to turn off logging statements added for debugging purposes when developing a script, but then you could also remove or comment these out when done. So I don't think this would really add much. John

Here (and attached) is a sample lua script for the GF-T8 lights for the Cessna 172. I have assigned the switches in the same order as in the aircraft - beacon, landing, taxi, nav and strobe. The current light switches positions for the C172 are held in lvars, so I am using the lua event.Lvar function to pick-up the switch position and set the light accordingly. Note the call to gfd.SetBright - this is necessary to set the leds to full brightness (when on). The logging statements have been commented-out - you can re-enable these for testing purposes, if needed. To use this script, make sure that it is running by adding it to your FSUIPC7.ini's [Auto] or (better) profile-specific [Auto.xxx] section, e.g. If you need help in modifying this for another aircraft, let me know which aircraft you are using, as well as your switch assignments, and I can take a look. John GFLeds.lua

You didn't set the custom logging for auto-save, as advised... However, looking at your files I don't think that it is FSUIPC that is initiating the panel state save. The file being saved is called ACARS Flight.sav - do you have an acars system also running, possibly an FSUIPC client application? If so, please check this. That file name must be coming from somewhere, and its not FSUIPC... John