John Dowson

The "InputEvent received but not known:" messages were logged as no input events were received. This was because they were being requested to early - I have corrected this in the next update which I will release shortly. in the beta announcement thread. Please update and try this when released. And please remember to report any issues in the beta release thread, not here. John

Please post any issues with the beta version in the announcement topic (as it says). Can you please repost your issue in that thread. I will look into this tomorrow (and install the improvement mod to check here), but I will respond in the beta announcement topic. John P.S. No point extracting and/or sorting log entries. If a log file is too large to attach, zip/compress it. I always need the full log file.

Thanks for this detailed and well explained contribution! The best way to do this would be using a preset (calculator code). The calc. code of the preset would have to scale the axis value range (usually -16384 to +16383) to the lvar value range before setting the lvar. You can assign an axis directly to a preset - as long as the preset contains a parameter placeholder ($Param or the @ symbol). Regards, John

Yes, but not your FSUIPC7.log file, which I also need to see for this problem...

Yes, there will be. For example, for the TOGGLE_MASTER_BATTERY event: So the parameter is the index of the battery.

This feature has now been released in the latest beta, 7.3.26f. John

In the next release, I will update to log multiple parameters when available. I have tested this in the DA62 with the Left Engine Master On switch, and this is now what is logged: Note that the easiest may to control this switch via assignments is to use the Input Event ENGINE_Master_1. Assignment to Input Events is a new feature and currently only available in the latest beta release, from this topic: I will update the beta available there in the next couple of days with a version that will include this additional parameter logging for events/controls that have more than one parameter. The official release date of this version (7.3.26) is still TBD. John

I would leave the Pollrate and just increase the FastTimeLimit. The rotary script should work reasonably well - if it isn't, try and understand what the script is doing, and try and work out what is happening. As I said. logging is your friend - use it. You can also add additional logging statements (using ipc.log) to help you understand what is happening. If your rotary is a two-phase type rotary switch, thus lua script may not be the best option - see the Advanced User guide om how to handle such rotary types. Otherwise, try to see what is happening yourself using the logging facilities provided.

What do you mean? Your ini file shows that the following 6 controllers are recognised: For some reason, you also have a rudder axis assigned on your Bravo, and a left brake axis assigned on your T.A320 Pilot: Please explain more clearly what your issue actually is, and also show me/attach your FSUIPC7.log file. John

Most toggle events don't take any parameters, but some do in MSFS. Two values are shown, the control/event number, and the parameter. Both numbers are shown as decinmal integers with the hex equivalent after this in brackets. Sime toggle events do have parameters -this is obviously one that does. Only one parameter/indices is currently logged. There currently seems to be some confusion between the events that take multiple parameters and those that don't, and also a similar confusion between standard controls and *_Ex1 controls. This is rather technical, but multiple parameters for events are only seen when received as *_EX1 events. not as standard events. And many EX1 events don't take multiple parameters and are received as standard events, not EX1 events. I will look into trying to log multiple parameters for events when such parameters are received. But note that it is only possible to send events with multiple parameters/indices by using calculator code.

License sent. John

Please find a trial license for FSUIPC7 attached, valid until 1st December. Just save this key file to your FSUIPC7 installation folder and you are good-to-go. Note that time-limited/trial licenses are not validated by the FSUIPC7 installer. Regards, John FSUIPC7.key

License sent. John

Ok, very strange....I don't understand how that can solve your issue, unless your 5.3 client got corrupted somehow, but your symptoms were very strange if that was the case. Thanks for the update. John

Lua scripts are only started once you have an aircraft loaded and ready-to-fly. The log you attached ends after 65 seconds and shows that you were not even connected to MSFS. Please try with an aircraft loaded. There is also an error in your [Auto] section: Should be: As I said, can you please at least check your logs before posting for support - there is no point in showing me your log files until these lua scripts are running. If you are unsure if they are running or not, add the following to the end each of your ButtonBox.lua script: ipc.log("ButtonBox.lua running and waiting for events") and a similar log line to your BU0836X-2.lua script. You will then see that line logged when the script is running. As I said, logging is your friend - please get into the habit of using this to try and solve your own issues. In the button assignment window, so that you can assign to them as you would a normal button However, as these are controlled by the lua script, that needs to be running, which means that you need an aircraft loaded and ready-to-fly. John

If you had noticed that earlier when I asked to check the properties it would have saved us both a lot of time! You should remove anything you manually installed - WASM, Documents, FSUIPC7.exe (you can keep your key and ini files) and run the installer to install correctly.

Yes, FSUIPC numbers buttons starting from 0, not 1. As long as you are using the correct numbers in the Rotaries array, it shouldn't matter. Are your lua scripts running? If so, are they opening your devices correctly? If not, you should see this logged: Could not open HID Try with one lua script running first, for one card, and get this working before you correct and start the 2nd lua for the 2nd card. First make sure the script is running and is opening your HID device. Once you have confirmed that, you can then use additional logging (Lua Plugins) if it still isn't working. Note also that, in the 2nd script, you need to change this: offset = 0x3340 as you need to use unique offsets in each script. Try changing to 0x3350 in the 2nd script. Also your Vendor/Product specification is not correct (so the device could not be opened, and the message 'Could not open HID' would have been logged)t: If using the hexadecimal VID/PID values, specify as: Vendor = 0x1DD2 -- Leo Bodnar Product = 0x2202 -- BU0836X Interface 2, Version 1.39 Otherwise use the strings: Vendor = "Leo Bodnar" -- Leo Bodnar Product = "BU0836X Interface 2" -- BU0836X Interface 2, Version 1.39 Can you also try checking your logs before posting - logging and the log file are your friends - use them. John

Maybe, but it would certainly put off a lot of casual simmers, or 'gamers'. And such an increase, assuming that sales remain the same, would only generate another $1500 or so per month. Certainly not enough to pay someone else to work on this, even if someone with thee required knowledge/experience could be found. I really should have changed the licensing model, only giving one years support + updates on the initial price, and charging an additional yearly fee for support and updates. A lot of software is switching to this licensing model. FSUIPC has been going for 20+ years as a one man operation, preciously my father, and I took over from him around 5 years ago when he retired. I was completely new to flight simming when I did this and it was (and still is!) a steep learning curve. My dad could not find anyone with the required knowledge/experience to take over and so I agreed to give it a go.... No, this discussion has already gone on far too long as far as I am concerned. I know you mean well, but these type of conversations are just another distraction and of no help whatsoever. Not sure why this is relevant. I have been living (mainly) in Spain for the past 25 years... None of this has anything to do with the topic of this thread, so I am closing this now. John

Unfortunately this is not an option. The current income from FSUIPC barely supports me, and increasing the price would mean even less sales. And don't forget I also support other products for other sims (FSX and P3D, all versions) both freeware and payware. It takes a lot of time just keeping up with beta and official releases of MSFS and P3D, although at least MSFS is more stable now and there are less breaking changes in each update. The first 2 years after MSFS was released was a bit of a nightmare, just keeping up with the changes, fixes and bugs introduced in each version. And don't forget that these are user support forums. The idea being that users should help each other out, not just me. It would be a lot easier for someone with in-depth knowledge about a particular aircraft or subsystem, or how a particular controller/joystick works, to answer many support requests rather than me. However, there seem to be very few users who respond to other peoples requests. Many users also seem to assume that I know how every aircraft works, every subsystem, as well as how to map this functionality to ANY controller. I don't - it can take me quite a while to understand requests when it comes to specific aircraft and subsystems, and details on how these are modelled.

User guide - save to the folder with the other docs: FSUIPC7 User Guide.pdf

Oh - and here is the documentation: FSUIPC7-Docs.zip Unzip that somewhere, usually it would go under your Windows Documents folder. I have removed the User Guide from that zip file as it made the file to large to attach - I will send that separately....

Ok, at least you have it now working. Attached in this WASM module - save this to your MSFS Community folder and extract the files (then delete the zip), and you will have access to the facilities provided by the WASM (access to lvars, hvars and calculator code). I have also attached the events.txt file - save this to your FSUIPC7 installation folder and this will give toy access to the MobiFlight presets. Cheers, John fsuipc-lvar-module.zip events.txt

Can you please show me/attach your InstallFSUIPC7.log file. Are you using a steam or MS Store version of MSFS? Do you know the location of your UserCfg.opt file?

Auto-connect and auto-start are two completely different things. You should have auto-connect set, but I would like you to try the auto-start, to see if MSFS can start FSUIPC when it is started. This will prevent you from having to manually start it from the command line. I thought that you can still not tun the installer at all, even via the command prompt, and that you can only start FSUIPC via the command prompt. As you see the Assignments menu, your key file is correct and you are running a registered version. All registered facilities will be available. I still think you will be better off trying to determine why the installer cannot run, and why you cannot start FSUIPC7 via windows Explorer. But I cannot help you any further with this. If you can confirm that the auto-start works, you can install the WASM, documentation, and other components manually. This should give you a full working FSUIPC installation which you can use, while you try and figure out the issue preventing the installer running.

But your initial post said 'FSUIPC allows imaginary buttons to be used,...' and also 'I started using imaginary joystick 17' so I assumed that you were talking about virtual buttons. And also note that only joysticks 0-15 are supported, not 17. Yes, that is for the InitialButton directive. Also page numbers are fixed. If you are seeing different page numbers on different PCs, then you are looking at different versions of the document. Yes - these are parameters for controls, and nothing to do with offsets. Just because the parameter to control a button flag is 3871, that does not mean that offset 3871 is available to control the same button flag. Do not confuse parameters with offsets. Of course, a parameter CAN be an offset address, but only if/when stated. No! You were interested in seeing the status of the button flag for joystick 13, button 0. 3328 just happens to be the parameter used when you want to toggle/set/clear the flag for this button. It has nothing to do with offsets. The state of button flags are generally not held in offsets. Well, if that was your issue you should have posted that earlier. Looks like at least that 2nd 'F+13' should be 'F-13', similar to the second working assignments, where you have also changed to use joystick 14 for some reason. But if its now working, no point in revisiting the assignments that are working. You should be able to see the difference between the two and figure out why it wasn't previously working...