John Dowson

As I said in my previous post, if you don't want to see the splash screen, don't use or even install the desktop icon, by deselecting the checkbox on the end of the installation process. All the desktop icon does is start MSFS and display the splash screen for 30 seconds or so while MSFS is starting. FSUIPC7 does nothing with start menu's, so if that is bringing up a splash screen then something else is doing that. You can easily create a desktop shortcut to just start MSFS if that is what you want to do.

You have one Community folder, under R:\FS11\Community\. The C:\Users\alhar\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\packages\ folder is for the Community apps read/write storage area. These different locations are explained in the WASM section of the Advanced User guide. I don't have any experience with the Volocopter - I loaded it the first time (or maybe second) to look at your throttle question. I don't know much, if anything, about this aircraft. Getting warm here - outside temperature in the shade is 25C, and feels a lot hotter in the sun.... Have some gardening to do later, but I will wait until 7pm or so when its cooler...! Glad its now working. Cheers, John

Check any anti-virus software you are using (including WindowsDefender). I cannot see any reason that it won't run unless it is being prevented somehow, especially as you were able to re-run it previously. Also reboot first, just in case that helps.

The screenshot says its version 4.934, so you need to update. If FSUIPC is crashing on start-up, then this is normally due to a corrupt weather file. Try disabling weather by setting NoWeatherAtAll=Yes to the [General] section of your FSUIPC4.INI file. If this solves it then either your wxstationlist.bin file is corrupt, or one of the .wx files saved with scenarios is bad. To resolve this, delete all of the .WX files from your FS Documents folder (where your flights are stored), and the file "wxstationlist.bin" in your <user>\AppData\Roaming folder for FSX. If that doesn't solve your issue, please show me/attach your FSUIPC4.log file, and also your InstallFSUIP4.log file if this issue only appeared after updating. Why won't it run? What error do you get? If it ran previously, I can't see why it won't run again, You can try re-downloading the zip file, unzip it (don't run it from the zip file) and try again, And there is no need to delete any files.

This happens every now and again, but I am not sure why it happens to this version and not the previous version... If you can report this to McAfee, they should be able to check the file and once confirmed it is virus free they can add an exception so that it passes. Thanks for reporting. John

You assign to an axis in the left-hand side of the axes assignment tab (This side to send an axis value) : The right-hand side is to send specific controls/presets when entering/leaving axis ranges, and the axis value is not used (This side to send button controls). The Select for preset checkbox applies to both sides. It is positioned there as I initially only intended this to be used on that side, but as a side effect it can also be used for axis values, such as in this case. There is only one Community folder used by MSFS...I think you mean you are using the addonlinker program to control what is there.... John

What do you mean by this? Please give details. How are you doing this? What do you mean by "another 747"? Can you please attach your FSUIPC6.ini file so that I can see your settings. Also a log file showing your issue would be useful, with logging for Events and Axis controls enabled. The log file will probably be quite large so will need compressing/zipping. John

Before anything else, please make sure that you are using the latest (and only supported) version of FSUIPC, which is 7.3.20. If not, please update first and try again, and then attach the log files if the Volocopter throttle isn't working.

Can you please attach the full log files...and its the FSUIPC_WASM.log file I need to see, with Debug level logging, not the FSUIPC_WASMIF.log. I don't even know why you have that file - under normal conditions, the WASMIF/WAPI should log to the FSUIPC7.log file. Where did you find that file? And only set logging for Events in FSUIPC7 (and no other logging), and also set Debug level logging in the WAPI as well.

Just checked that throttle preset in the latest update and that is working fine here - please show me your FSUIPC_WASM.log file. As for the AP/Garmin in the Volocopter, I am not sure what that is (is it even a Garmin?)...I am not sure if it is possible to control this from external applications at the moment... John

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.