John Dowson

If the problem is with FSUIPC7 not running, please see the README.txt or the Installation and Registration guide - you will need to update your VC++ redistributables to the latest combined package. Otherwise explain your issue with FSUIPC7 if that is the problem, or contact the support for your smartcars program. I can only support FSUIPC, not the programs that use it. And please take care to post in the correct forum for the product you are using. I have moved your post to the FSUIPC7 support forum. John

The SU13 update has just dropped, so I will get back to you after I have updated and checked things (tomorrow sometime). In the mean-time, can you activate Debug level logging in the WASM and show me/attach your FSUIPC_WASM.log file, as this will show what is being received and applied in the sim. See the WASM section in the Advanced User guide if you don't know how to do this. So do I - this is normal in the Volocopter. Different events are continually send for many MSFS aircraft. You can stop these being logged by using the DontLogThese ini parameter, preferably in your Volocopter profile. Again, see the Advanced user guide for details. Or you can safely ignore these. John

I can't really help if using PM - you should try PM support. Having said that, your issue seems to be similar to this (very old, but still valid) post: You can also try logging: set logging for Events (non-axis control) and also offset monitoring for the PM APU offsets (560F, 5624 and 5625). If you keep the logging console open (check Send to console window), you can then see what events (if any) are being used and how those offsets change when you operate the switch on the PMSystems screen. You can then try and duplicate that behavior. This is quite common for spring loaded switches - they only have one (single direction) or two (dual direction) buttons. If you need to send another value to an offset (or a control, or whatever assignment) when it springs back to the central position, then this should be assigned to the button release of the 2 buttons for the non-central position. Pete retired several years ago now. Cheers, John

For the Garmins (if they are functional/working in the Volocopter), both Asobo and WT, you can use the MF presets that are also included in FSUIPC7. You can use the MF HubHob site to search for the relevant preset:

@Oodi MenakerSorry for the delay. Could you please test the attached dll: FSUIPC6.dll Thanks and regards, John

Ok, so its the Pro Desk Sim add-on package that is providing the detents - that is what I was missing! Try the settings I gave and adjust as needed. As it is difficult to get an axis range value when using such a detent add-on, its probably easier to adjust the detent ranges in ini file directly (and reload afterwards - as per my previous instructions). Your problem is because you are using a specific axis value (FlapsStart = FlapsEnd) for each detent. an axis with 32768 values is never going to hit that value exactly every time on each detent, which is why you need a range around the (central) detent value for each detent. Ok, thanks. Pete didn't mind attached or pasted - the problem with pasted is that many people just post extracts, and pasting makes the topic a lot longer and IMHO more difficult to read. With an attachment, you know its the whole unadulterated content. Ok, no problem. John

Ok. Make sure that you understand what those lines are doing before you duplicate, as you will need to use the correct flags for each button, and get the parameter for the clear flag control (1004) correct to clear the flag for the button you are testing. John

The velocity uses the Lvar XMLVAR_VOLOCITY_COMMANDED_VERTICAL_SPEED for the throttle. To use this, add the following line to a file called myevents.txt in your FSUIPC7 installation folder (you must create this file if not already present): Velocity Throttle# $Param 16384.0 / (>L:XMLVAR_VOLOCITY_COMMANDED_VERTICAL_SPEED,·Number) The lvar holds values between -1 (full down) to 1 (full up), so as my throttle axis goes from -16384 to +16384, this code is dividing the axis input value ($Param) by 16384.0 to get the desired range. Adjust this if needed, depending upon your axis values range. Once you have created the myevents.txt file and have added that line, restart FSUIPC7 (no need to restart MSFS). Then assign your throttle axis to that preset - check the Select for Preset box and assign with Send to FS as normal axis and you should see the preset Velocity Throttle listed. John

It is easier for me if you attach files (rather than pasting contents), and also provide me with the log file I asked for... Presuming 5 is the Auto button, you need to duplicate and add a condition to entry 47. First try with the button flags, so use: You may also need to clear the button flags manually when you go back to the Auto position. If you need to do this (try without first), instead use: Not sure which way around it should be either - if its the opposite way, switch the 72471 and 72472 parameters around on lines 47.48 (first case) or on lines 47,49 (2nd case). John

Not sure what you mean...so each position gives a unique button press? How about the button release? How you program a 3-position switch depends on the releases as well as the presses. For example, if there are 3 buttons, 0 ( centre), 1(left/up), 2 (right/down): 1 <--> 0 <-->2 Moving from 0-> triggers button 1, so you would assign the appropriate mouse-click (left mouse) to button 1 press. If moving from 1->0 gives a button 1 release, then you can profram the right-mouse click for the release of button 1. Similarly you can assign to button 2 press/release, but with the mouse-click/codes reversed. If moving from 0->1 gives a button 1 press and release, you cannot do it this way, and the problem you then have is how to assign the centre 0 button/position, as this would need to trigger either a left or right change, depending upon where it came from. To do it this way, toy would need to overload your assignments (i.e. have to assignments for the 0 button), and a conditional test in each to determine which is used. If this is the case, you can initially try adding conditions to the button latch flags for buttons 1 and 2. That may work, but this again depends on how the buttons work. If it doesn't work with latch flags, you need to either find an offset or lvar that holds the button position and use that as an offset condition (you can add the lvar to an offset). Otherwise, and maybe easier, you can use your own offset and overload the assignments to button 1 and 2 to also update/set your own offset, and then you can use this with an offset condition on your overloaded assignments (you will have two, one for each direction) to button 1. Please see the Advanced User manual in using conditional assignments (actually called COMPOUND BUTTON CONDITIONS in the manual), as well as on using button flags and offset conditions. You can use logging for Buttons & Keys to determine when button presses and releases are triggered. Give the documentation a read and give it a try. I recommend you do this with the logging console window open so that you can see the logging in real-time. If you get into difficulties, show me what you have so far (i.e. attach your FSUIPC6.ini file) and also attach a log generated with logging for Buttons & Keys and Events (non-axis controls) activated where you just load the aircraft and then move the switch through its positions: 0 -> 1 -> 0 >- 2 -> 0 John

Further to my last comment, as you say: This would indicate that the detent settings are off. Try the following settings: and then adjust as needed. Note that you can edit the ini file directly if you like, but make sure you do this when the the FSUIPC window is open and showing the axes assignment tab, and then click the Reload button to load your changes. Then close the FSUIPC window and test. Repeat until you get the ranges correct for your detent positions. John

I am not sure about the FSLabs airbus as I don't have this aircraft, but with the PMDG aircraft you have two ways of using custom controls, one of which is to use the Rotor Brake control with a parameter that includes both the custom control number together with the mouse option needed, and the other way is to use the custom control number itself, and the parameter for this can be a specific position/number, as well as using the mouse operation codes. So first check if this is possible for the FSLabs. Note there are FAQ entries for both of these methods for the PMDG aircraft. If you are stuck with using the Rotor Brake in/dec functions, you will need to find something that holds the current switch position, so you know what needs to be sent to change it to each other position. You can then use conditional assignments to program the switch (i.e. what controls it sends can be dependent on its current position based on an offset or flag value). Assigning for 3-position switches also depends on what buttons the switch reports. If, for example, you only see two buttons for the up and down positions, the central position will be off for the two buttons, as described in this post: John

Yes, that's fine. Make sure you copy across the [Profile.xxx] section (where xxx is the name of the profile), as well as all the [yyy.xxx] sections, such as [Buttons.xxx], [Axes.xxx], etc. First, can you please attach your files rather than pasting their contents. This is a lot better/easier for me and keeps the posts to a reasonable length. And what is this "ProDesk Sim hardware"? Your flaps are assigned to the Honeycomb Bravo, and I your initial issue is that the flaps axis was registered as a digital on/off axis. For your Bravo flaps configuration, you should read and follow the flaps detent calibration instructions, if you really want to calibrate with detents, on page 46 of the user manual, as you don't seem to be following the instructions. For example, For the minimum detent (Flaps off),: So minimum is only when the axis lever is exactly at -16384, whereas the instructions state: i.e. you want an axis range around the detent position if using detents. Similarly, your "Flaps full" range is 16383-16384, and all the detents in-between are for fixed positions only. Compare this to the example given in the manual (also for the 737), where you see ranges around each detent: Also consider if you want to use detents at all - also from the manual: John

You need to run everything at the same privilege level - if one program needs to be ran as admin, then you need to run everything as admin. Even when MSFS is ran as admin? if so that is strange - I would ask about that on Prosim support.

I don't think this will help much as, as I said, the delay seems to be with the lua unpack call. To confirm this, could you provide another log file for the client lua script, but this time without the lua plugin logging enabled (and don't run with lua debug) and amend the script slightly as follows to log in the scrip itself: The time it takes for the UDP packet to be received is difficult to measure though. But if you keep the FSUIPC logging console window open on the client and monitor this, you should be able to gauge how long it takes between the button press to change the lights state on the server, and the data being received in the client. You can also add similar logging to the server broadcast lua, and also turn off Lua Plugin logging there. However, looking at the server log, it also seems that the lua pack call is also taking around 3 seconds: So that is roughly 3 seconds to pack the data, and 3 seconds to unpack the data. Given this, I don't think switching to TCP would help, especially as UDP is generally considered faster than TCP. So I think it would be better to see if it is possible to eliminate or find an alternative to using those pack/unpack calls from the vstruct library.

Ok, thanks for the update. As I said (or hinted at) in my previous post, I do not know what could be causing such a delay. I will emulate your lua broadcast/server and reception/client scripts here to see if I also get such a delay. However, looking at the lua client script log, it seems that the issue is not with the UDP broadcasts itself (although adding additional logging after the udp2:receive call would confirm this) but is taken up by the vstruct.unpack call: So that is around 3 seconds to unpack the received data....I am not sure why this is so slow...I will investigate, but those are standard lua libraries and not provided by me so i am not sure if anything can be done. I will investigate later this week and report back, as I said. John

Ok...so the server lua is sending the offset changes via a udp socket, which is picked-up by the client and duplicated, and then the offset changes are picked up by the Dlight.lua and the corresponding lvars are set. For @GSaldenwhere this isn't working, I can only assume that this is a network issue and the client is not receiving the broadcasts. Check the host and port are correct in the BCastMemSvr.lua, and that firewalls are either disabled (I know you said they were, but please check again on both client and server PCs, as well as in any routers) or have an exception to allow the host/port to be accessed. You could also try using a different port number. May also be related to your router config - check any UDP related settings there. For @Sky Blue Flyer, where this is working but there is a 4-5 second delay, I don't know what to advise really...not sure what could be causing such a delay in sending/receiving UDP packets. It could be a general UDP issue relating to ARP message exchange, but I am no network expert (maybe try google), Have you thought of switching to TCP instead? One thing that strikes me as strange is that you are using the lights offsets 0x5301 and 0x5303 as unsigned bytes (UB), but have set events and are broadcasting them as unsigned words (UW). Not that this should make much difference...but maybe better to use UB throughout. And I really don't understand why you have this in the [General] section of your FSUIPC7.ini files (both client and server): This is similar to what goes into a [LvarOffsets] section, which adds lvars to offsets for both reading and writing. However, you cannot currently do this for specific bits - but I like this idea and may implement this in a future release. Note that if the lvars were added to the offsets (bits), then you wouldn't need the Dlights.lua as any offset change would automatically trigger the corresponding lvar to be updated. I can't see how this is needed and should be removed - unless you can explain to me what this is doing (and by what)? I don't really have experience in such a set-up and so cannot really advise on this any more at the moment. I will try and duplicate a similar set-up here, with one PC on windows 11 and another on windows 10. However, I cannot duplicate exactly as I only have one license for MSFS, and so would have to run FSUIPC on one PC as a client version, but the lua socket communication between the FSUIPC versions should be the same. I will try and similar offset exchange (broadcast and receive) via UDP to see what delay I experience, and will also try with TCP to see if that gives better performance. I won't have time to do this until later this week though. I will report back once I have done this. John

Sorry - these are available in the link to download. I will take a look... John

Not sure that I understand this... If you are running FSUIPC on both server and client, these are both full instances of FSUIPC with their own offset area and there is no communication between them FSUIPC running on a client PC receives all data via simconnect, as does FSUIPC on the server. I thought the only issue now was that there was a 4-5 second delay when turning the lights on via the client PC, which is not present when done in the server PC. Or maybe this is the issue for @Sky Blue Flyer and @GSalden does not have it working at all on the client? But if FSUIPC7 on the client isn't running, the lights still work in the server? If so, then it is the server PC that is controlling the lights. And I now assume you are also running MSFS on both client and server PCs, no? I am not sure how this type of set-up works... For example, the client and server logs you posted show different numbers of ;vars received: from the server: and from the client: Note that as more lvars are being received after the initial set of lvars is being received, you should increase the LvarScanDelay WASM ini parameter by 5-6 seconds, However, this is only really relevant if the lvars the lua scripts are using need those lvars - if it is the lua scripts that are creating the additional lvars, then no need to increase this delay. And I don't understand what the lvar lines in the [General] section of both client and server ini files is doing - what reads these: ? If something in your set-up is using that, then it should be in a separate file and not in the FSUIPC7.ini file... You also have WideServer running on both the client and server PCs. This is a bad idea - you should only have one copy of WideServer running on a network. I am not sure what will happen with two instances of WideServer running, so maybe disable one of those - or both if not using WideClient (which you shouldn't anyway as you are running FSUIPC7 on both server and clients). Ok, this helps...although it is still not 100% clear. The offset areas in the client and server PCs will be distinct, with each being populated from the MSFS instance it is connected to. And the available lvars are also different and independent on the client and server PCs. I do not know how WidevieW syncs these two instances of MSFS... Maybe you could show me the lua files which would help: BCastMemSvr, BCastMemClient, Dlight, ipcReady (for both client and server, although I assume that this just starts the other lua files). Note also that you can run FSUPC7 in a client PC and have it connect to the server MSFS instance. This is what I assumed you were doing when you said that FSUIPC was running on a client PC. Doing it this way, the lvars (and most offsets, but not user ones) would be the same on both client and server. John

If you gave assigned your throttles in the FS (or elsewhere outside of FSUIPC), FSUIPC may still calibrate the throttles, if instructed to do so. You can remove the calibration by going into FSUIPC's calibration tab and clicking the Reset button in the Throttle calibration sections on page 1 (for general throttle calibration) and page 3 (for separate engine throttles). If you still have issues after this, please show me your FSUIPC .log and .ini files. John

No, you were not instructed to do that - that is the vendor id for Saitek. As I said: The VID for the Honeycomb Bravo is 294B, and the PID is 1901 (as reported in your FSUIPC6.log file). So please try with those. If you still have issues after that, please attach your FSUIPC6.log and FSUIPC6.ini files (and not paste contents). John

I don't want to see anything related to WidevieW. I have said this several times now - FSUIPC and WideClient have nothing whatsoever to do with WidevieW. I have never used this and know next to nothing about it. Please restrict your questions and attached files to those that I need to see, i.e. those relating to FSUIPC and WideFS. Ok, so its either a WidevieW issue, or something related to how WidevieW uses/interacts with FSUIPC? This sounds more like an issue for WidevieW... So there is now no issue apart from the delay? And this is on a client, but the client doesn't use FSUIPC or WideClient, only Wideview? Then this again sounds like an issue for WidevieW. I don't see how I can help here, as the issue is on the client and that isn't using either FSUIPC or WideClient. And id this is present regardless of FSUIPC version, what has changed that has caused this issue? As this set-up seems to be using lvars, it could be related to the delay in initial lvar scan and the automatic re-scan for new lvars, although I doubt this very much if the issue is present regardless of version. You could try with the FSUIPC7 logging console window open (Log -> Open Console), and/or monitor the number of lvars available in the message in the FSUIPC7 main window. If you see this continually increasing, performance issues can be seen if new lvars are continually found amd reloaded - but this should affect both server and clients. For complex aircraft, you may need to increase the WASM ini parameter LvarScanDelay so that more time is allowed before the initial scan for lvars is performed. You can also adjust or disable the time between scans to detect new lvars. See the WASM section in the Advanced User guide for details. But, if the issue is on a client that is not using FSUIPC or WideClient, then I'm not sure I can help. In FSUIPC7 on the server, you can also enable logging for IPC Writes and IPC Reads, and again keep the logging console window open. This may help identifying when any request from an external application (i.e. WidevieW) is received. Interesting. That offset area is actually documented as being assigned to "Mark Hastings B777 Systems Simulator", not that it matters...! You could also monitor those offsets using FSUIPC7's offset monitoring facilities, and send the monitoring to the normal log file. Again, with the logging console window open, you should be able to see when FSUIPC7 receives these requests, and be able to determine where the delay is coming from. I suspect that this is a network issue, or maybe related to anti-virus or firewall software somewhere in the mix... John

Its the same version. You just don't need to register it to use the additional functionality provided by having a license and registering during the installation process. John

What have you tried? I have nothing further to add on the topic of auto-start that is not already in that FAQ entry I have referenced. Please read that carefully and make sure that you fully understand what I have said there. If MSFS is not obeying a correct EXE.xml, then it is an issue for Asobo/MSFS, and that topic also provides an alternative method to start FSUIPC7. I really have nothing more to add to this. and will therefore close/lock this thread. Any posts on auto-start will be referred to that thread as I have nothing more to say about this that has not already been said already. John

You need to check Pilot2ATC requirements to see if that uses the free or registered versions. I doubt very much that it needs the FSUIPC WASM only... I see you have also posted in the trial license topic, so you can try that if the free/unregistered version doesn't work. John