John Dowson

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

Your lua scripts are not running. You need to have these running, normally started from an [Auto] section - add this to your FSUIPC7.ini: You only need to change the device number if you have multiple devices with the same Vendor and Product ids. As your product ids are unique, you do not need to change these, leave them as (or put them back to) 0. Note also that you have assignments to missing devices: This is usually caused by a GUID change for the device. To correct this, you should review all your assignments to these device letters (E and F) and either remove them or update the letter to the now correct device letter, id you can determine what that should be. John

What A320 are you using - Asobo, Fenix or FBW (dev/stable/experimental)? You are updating an lvar ( ipc.writeLvar) and then reading its value directly afterwards (ipc.readLvar). Due to the time it takes to update an lvar and the asynchronous nature of the request/communication (a request is sent to update the lvar, and later the updated lvar value is passed back to FSUIPC), you will be reading the original value of the lvar and not the new value, i.e. it will be the same as old_para. To prevent this, you can add a delay between the write and read (e.g. ipc.sleep(200)), or just assume that the update/write request has succeeded and just set 'new_param = ipcPARAM'. But isn't it the case that whatever value is set, the previous value must have been either 10 higher or 10 lower? So, if the current ipcPARAM value is 0, the previous knob position must have been 10, if the current ipcPARAM value is 10, the previous knob position must have been either 0 or 20, etc. So You only need to either increment or decrement to change the knob one position at a time.

It is what it is - a programming API. You scale each RGB value to 16, not divide. This is because the wnd library was initially in WideClient only. It was later incorporated into FSUIPC. I would like users to at least consult the documentation before posting, and at least try for themselves. FSUIPC contains a lot of features, and I know there is a lot of documentation and it can be difficult to find and understand relevant sections, and the documentation can certainly do with an update/overhaul in many areas. Many support questions are covered by the documentation, but I always try and explain and point to the relevant section of the documentation. If the documentation is not clear, I will update it to try and make it more understandable, as I would like to try and reduce the time I am spending on support, so I can spend more time on improving the functionality and also improving the documentation.

I do not understand why you are trying the EXACT same thing as before, but for a different offset. Offset 4532 is in this area: You CAN NOT invent an offset for your own use (although you can use offsets marked as 'free for general use' for your own purposes). As I have already said, virtual joystick button states are held in offsets 0x3340: Please read and understand that. Also note that it only holds space for 9 joysticks, 32 buttons each. You cannot use (imaginary) joystick 17, that is not supported. Not sure what this means ('280,10''?), but if you want to have different functions in a button depending on the state if another button, use compound button controls - see the Advanced User guide for details. John

Yes you can, but not using that offset- see offset 0x29F0 which provides a facility to set/clear/toggle virtual button flags. The flags themselves are stored from offset 0x3340. By writing to offset 0x3328, you will be writing to this: You should always consult the FSUIPC Offset Status document before reading/writing to offsets. John

And the installer still doesn't work after this change (and a reboot)? Do you still have to run it twice before it starts? Can FSYUPC7 be auto-started with MSFS? Can you try setting this up - you will have to manually create and entry in the MSFS EXE.xml file - instructions can be found here: It will be running as a background process when in the task bar. Me too.... Did you manage to create your key file and get access to the registered/licensed facilities? If so, and FSUIPC7 is auto-started ok by MSFS, we can manually istall the WASM and Docuementation, as well as any other components you may want (SDK, WebSocketServer, Event files, etc). John

Anything that relies on text (or menu) display using the SimConnect_Text function will not be functioning correctly, including lua plugins and offset controls. From the README.txt: Yes, as its says in the README.txt, and as I indicated in my previous comment: As it says in the documentation: So 0xF00 would be red, 0x0F00 would be green, and 0x00F would be blue, and combine different quantities of each colour for other colours. What is WideConnect? Do you mean WideClient? As I said, there is no reason to use WideClient on a server PC UNLESS you want to use the button-screen facilities. Just use FSUIPC to run your lua scripts. No - and I don't understand why you would want to do this, and why you are using WideClient. Why don't you just use the wnd facilites in lua script on the server? You should be able to exchange the wnd window reference between scripts running on the sane server (process), but not between WideClient-controlled lua scripts and FSUIPC-controlled lua scripts. You can use ipc.get/ipc.set to exchange data between client/server lua scripts. but with restrictions, and should be used sparingly. Handles, such as wnd handles, can be passed but they will not be useable as a handle created on a client will have no meanung on the server, and vica-versa. I would just use the logging facilities for this, either via ipc.log or using FSUIPC's (offset) logging facilities. And you can also keep the logging console open so that you can see what is being logged in real-time. John

Then why post in this topic? All licenses are purchased from SimMarket. Your license/key details will be in your SimMarket purchase email, and also available in your SimMarket account. John

I do have some ideas to replicate the SimConnect_Text function in the WASM (using jsp) and switch to using this. There is a lot of new APIs I need to understand before I can do this, and need quite a bit of time to study and play around with this. Maybe I will have chance one day, when I get less support questions. It is VERY difficult to get any development done as I am spending 90% of my time on support at the moment..... John

No, and they never will be - they have been deprecated by Asobo. You need to use the Wnd library to display text. None of this will work (reliably) as the SimConnect_Text function is broken. Use the Wnd library for the time being. You can run WideClient on the server, but no point if just for text display purposes as these are broken. The only possible reason that you would want to tun WideClient in the server would be to use the button page facilities. No - no point.