
John Dowson
Members-
Posts
13,253 -
Joined
-
Last visited
-
Days Won
270
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by John Dowson
-
Btw, are you using any other WASM modules? If so, maybe temporarily move them out of your MSFS Community folder so they aren't loaded for the time being.
-
New one posed, valid until 20th August 2021.
-
This is very strange - you have a connection to the FSUIPC WASM module so there must be a log file somewhere. Can you try searching for it? If you don't have Everything, I recommend you download and install it from https://www.voidtools.com/ and use that to try to find the location of this file. I need to see this (maybe also with Debug logging enabled, or maybe Trace) as the issue looks to be in the WASM module as no CDA config data is being seen by FSUIPC7. Did you try this? Are you sure you did this? The [General] settings haven't changed.... Maybe also try with FSUIPC7 started before you start MSFS - although it shouldn't make a difference when you start FSUIPC7, it is still worth checking. You also tried to list the lvars a couple of seconds after the WASM connection was obtained. Doesn't matter in this case, but best to wait 30 seconds or so (more if you have the WASM LvarScanDelay parameter configured in the WASM ini) after the aircraft is loaded (or FSUIPC7 started) before you start to use lvars or hvars.
-
Just took a look at the C208B and I got 95 lvars when spawned cold & dark: So it does sound like something specific to your system. As I said, please try with and without Linda to see if that makes a difference. John
-
It will be under C:\Users\eliag\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\packages\fsuipc-lvar-module\work (please see the Advanced User Guide, P44.) I'm not sure why you also have an FSUIPC_WASMIF.log file - have you been modifying the FSUIPC_WASM.ini file (if so, please show it to me) or using the WASMClient? Anyway, could you enable Debug logging in the WAPI by adding the following to your FSUIPC7.ini file under the [WAPI] section: LogLevel=Debug Also, please delete everything under your [General] section and let that get rebuilt, as you have a lot of old and no longer relevant settings there. Then, start MSFS and load an aircraft and try again. If you still get 0 lvars, also try issuing a Reload command from the FSUIPC7 WASM menu. Then exit and show me your FSUIPC7.log, FSUIPC7.ini files, and FSUIPC_WASM.log files. I see you are also using Linda. May be a good idea to disable that for the time being (i.e. rename the lua script that start it) while we try and determine why the lvar details are not being received. And how are you starting FSUIPC7 - via the auto-start method or manually?
-
No sorry, that is not possible. The only thing you can do at the moment is to use different profiles for the C172 based upon the name, using one with the G1000 assignments and the other without. If you want to use the G100 assignments in another aircraft, you can manually copy the assignments in your FSUIPC7.ini to another profile, remembering to change the index numbers if needed. I have thought about this issue, i.e. to have common assignment blocks for AP systems that can be used in different profiles, but there are two many issues to handle. For example, on some aircraft you can change the AP systems on-the-fly (via a flypad or EFB). This means I would have to look into how to determine when the AP systems have changed and update the assignments dynamically, which would be very difficult if not impossible at the moment. Its also difficult to manage such assignments via the assignments dialog (e.g. where to save assignments to - general, profile or common block, when/how to trigger a common block load, etc) You could also use multiple FSUIPC7.ini files(e.g. FSUIPC7-G1000.ini, FSUIPC7-G540.ini, etc) for different AP sub-systems, and rename them to FSUIPC7.ini before starting (or before reloading assignments if already started) to use them. John
-
I'm not sure without seeing your files your log files - can you show me your FSUIPC7.log and FSUIPC7.ini files, and also your FSUIPC_WASM.log file. Someone has reported that the lvars weren't available until after the engine had started, but I haven't been able to reproduce this. John
-
But FSUIPC is started by MSFS via the EXE.xml file. Even if you delete/change or don't use the shortcut, FSUIPC7 will still be started by MSFS if the entroes in the EXE.xml aren't removed. To do that, you need to uninstall and re-install without the auto-start component selected. I don't think so, but I don't use MF. By using the EXE.xml to auto-start FSUIPC7, MSFS should start it at the correct time, when it is ready to except the SimConnect connection requests. Anyway, go with whatever works for you! Regards, John
-
The 1.8.15.0 update released yesterday also contains the following in the release notes: Aligned pressure altitude simvar and pitot static altitude calculations to prevent wrong altitude information for external Live ATC services ... Known issue In-sim ATC service radar can still report incorrect altitude (fix expected in World Update 6)
-
I think this is a know issue after the SU5 update - see https://forums.flightsimulator.com/t/altimeter-problems-altitude-hold-and-atc-altitude/433209 https://forums.flightsimulator.com/t/help-with-incorrect-high-altitude-altimeter-setting/429439/4 And from that second link: From the Asobo post about the hotfix: ATC Incorrect Altitude – The pressure altitude has been brought in line with the new altimeter simulation and ATC should no longer ask you to get to your current altitude if you’re already there. This is addressed in the hotfix. Further improvements to the altimeter and ambient pressure system will be coming in World Update 6. John
-
If you assigned in FSUIPC7, then thy should not have been "lost" as they are independent of MSFS updates. So I think something else must be going on. If you are not using the latest version, v7.2.6, then please update and try again. If it still fails or already using that version, show me your FSUIPC7.log and FSUIPC7.ini files.
-
How to assign multiple L:vars to one button.
John Dowson replied to Crashcast_E's topic in FSUIPC Support Pete Dowson Modules
To assign multiple actions to a button, whatever the action (e.g. controls, macro actions, lua scripts, etc) you have to comment out the currently assigned action by editing your FSUIPC .ini file. Find the assignment line in the .ini file (in an editor such as Notepad++), and place a semi-colon character after the index number of the assignment and save the file. Then, in the FSUIPC buttons assignment dialog, click the 'reload all buttons' button. This will reload the edited ini and remove the assignment, allowing you to add the second assignment. You can save (i.e. click Ok) and repeat as many times as you like to add multiple assignments. When done, edit the .ini file again and remove the semi-colons previously added and save the file. Then reload the update .ini once more from the button assignments panel, and you will now have multiple assignments to that button. You will only see the first assignment in the UI, and this will be grayed-out and un-editable. To make any further changes to multiple assignments, you have to manually edit the .ini file. John -
I have moved your post to the main support forum as it will attract more attention there. The User Contributions sub-forum is intended as a place to access such scripts, and isn't really the place for such requests.
-
Yes...! Good, I'm glad - happy flying, John
-
That depends on how you start it. If you double click the FSUIPC7.exe, that will just start FSUIPC7 and nor MSFS. If you opted to install the auto-start component, then FSUIPC7 will be started by MSFS when that is started. If you opted to install the desktop link, that starts MSFS, not FSUIPC7. When started, FSUIPC7 resides in the system tray, not the task bar. You can use the default hot-key Alt + F to show/hide the main window. Please see the provided documentation, especially the Installation guide and the user manual (installed under your Windows Documents folder, in a folder called FSUIPC7). John
-
Strange, don't know what happened....! You don't seem to be using any of the registered facilities of FSUIPC7. You are using the FBW A320 events (file) but are not actually using it for anything. And you don't have the FSUIPC7 WASM module installed, although you have the WAPI activated for some reason. Not that it matters... Btw, your [General] settings could do with updating. I suggest that you delete everything under the [General] section of your FSUIPC7.ini and let that get re-generated. Also, the log file you attached wasn't complete - you started a continuation log. Best not to do or use this function for generating log files for support, as I need to see the complete/full log file. Just for future reference. John
-
Hi Frank, do you have your assignments in MobiFlight or in FSUIPC? If the former, then you should ask on the MobiFlight Discord forum (https://discord.com/channels/608690978081210392/749561155424354374) and/or the FBW discord forum (https://discord.com/channels/738864299392630914/750095266937438258). They may know more if there are issues with MF/FBW after the update. If you are assigning in FSUIPC, are you using the MF events or the FSUIPC7 WASM module, or maybe a combination of both? Either way, I would need to see your FSUIPC7.ini and FSUIPC7.log. If using lvars or hvars, also check that they are still available as I have had reports of lvars not being loaded until the a/c is started, although they seem ok to me in the few stock and add-on aircraft that I have tried since the update. I don't use MF or FBW myself, but have it installed on my development system to look into issues on using this with FSUIPC7. I haven't updated to v9 yet - I'll do this next week and take a look. Until then, please report back if you find anything. Cheers, John
-
V7.2.5 ipc.display() not works anymore after update
John Dowson replied to achwodu's topic in FSUIPC7 MSFS
No problem. Attached is an example lua script using the wnd library. John FPS_MonitorW.lua Note that when using the wnd library, the position and size information is only used the first time it is ran. The information is then written to the FSUIPC7.ini, where it will be taken on subsequent iterations. You can move and resize the wnd windows dtnamically using the arrow keys and arrow keys + shift or Ctrl (can't remember which!), and the new size/position will also be remembered. -
This has been reported many many times now, and my answer is always the same.... If MSFS crashes, it is a problem with MSFS that mist be reported to Asobo. FSUIPC7 is an executable, a separate process to the FS. If FSUIPC7 crashes, it should not affect MSFS. What is more likely happening is that MSFS is crashing, which then causes a fault in FSUIPC7 (as the SimConnect connection is no longer available). FSUIPC7 detects this (and a windows event is raised) butt then exits gracefully. You can verify this by checking your FSUIPC7.log file - it should show that GSUIPC7 has exited gracefully as MSFS us no longer detected. If it doesn't, then please show it to me. Another way to verify this is to start FSUIPC7 manually before the MSFS, and deselect the option 'Exit with FS'. Doing this, when you start MSFS you will get an error (which you can acknowledge and ignore) sating that FSUIPC7 is already running if/when it tries to auto-start FSUIPC7. But when MSFS CTDs, FSUIPC7 will disconnect and keep running. Therefore, please verify that it is MSFS that is crashing, and if so, please check the Asobo forums and/or report to Asobo via zendesk. John Later... Btw, also check the event log for an MSFS crash event before the FSUIPC7 fault event. This should be sent to Asobo, together with the crash report/dump if one is available.
-
V7.2.5 ipc.display() not works anymore after update
John Dowson replied to achwodu's topic in FSUIPC7 MSFS
But there has been problems with ipc.display since MSFS launch, so I'm surprised it was working at all for you! As stated in the FSUIPC Lua library documentation: Just checked the SDK documentation on the SimConnect_Text function in the latest SDK version, v0.14.0.0, and it now states: So I don't think there is anything I can do. You should look into using the wnd library, as the documentation recommends. John -
Yes, yesterday. I'll post a new one in a couple of days.
-
Here and me! There are so many similar support requests on this now, and - to be honest, I am getting pretty fed-up of responding to those that keep posting for this and have not bothered to read the manual. So, have you read the 'Installing and Registering FSUIPC7.pdf', section Invalid Key Problems? If not, please do that, and follow the instructions provided. If that does not solve your issue, please let me know your order number and I will verify your details here. John
-
Did you get to the bottom of this issue? Did you check the logs of your acars programs? You FSUIPC7.log file looks ok, although you could change your stall settings in your FSUIPC7.ini as you did have a data stall issue (but not important). Btw, 7.2.6 was also released this morning so please update to that version.