Pete Dowson

Sorry, you have come to the wrong place. None of the products you mention are supported here. This is my Support Forum for my software -- primarily FSUIPC and WideFS. I don't know FSBUILD at all. Pete

The "direct" method does exactly what it says. The axis value doesn't get to FS at all until after calibration, when it is effectively injected directly to control that aspect of FS. The FS control method is exactly the same as assigning to the same axis control in FS itself. The control is sent directly to FS for processing. If, and only if, you also calibrate that axis, then FSUIPC intercepts it afterwards and then calibrates as before. So, assignment to FS control and calibration are two independent actions. Calibration can be used no matter where you do the assignment. The direct method is more efficient and is generally the best way, being simpler and more directly effective. However, some add-on aircraft don't like this. The PMDG NGX and 777X, to take prime examples, also intercept the FS axis for some things, like throttles, and assigning direct in FSUIPC bypasses this. I think the more sophisticated Airbus models from Aerosoft are similarly adversely affected. So, you use direct where it works, and FS control otherwise. In fact the PMDG examples probably don't take kindly to FSUIPC calibration either, because they would then be trying to use two throttle values -- the original the model intercepts and the post calibration value from FSUIPC. This might not notice too much if the calibration is basically linear and the input values from the joystick already cover the entire range. Using different profiles for different aircraft allows you to choose whatever works best for each, without having to constantly change assignments etc. Pete

I'm afraid the way SimConnect operates that process can often do more harm than good. I've known cases where the only answer was to re-install Windows. Does the log show the SimConnect's installed? If the log is identical to the last one then they are not! FSUIPC does'n even need a fully correct install of SimConnect, unlike most other SimConnect add-ons. All it needs is to find the actual SimConnect.dll file. It connects by direct linking, not going through the very frail WinSxS system. So, check folders named like this in your Windows WinSxS folder (you will have to make sure you have Windows explorer to show all files including system ones): C:\Windows\winsxs\x86_microsoft.flightsimulator.simconnect .... without ".cat" or ".manifest" at the end. There should be one such folder for each installed version of SimConnect. As an example, my latest FSX-SE SimConnect is installed (as "simconnect.dll") here: C:\Windows\winsxs\x86_microsoft.flightsimulator.simconnect_1ed9da73c880e429_10.0.62615.0_none_69960aa860d87067 The parts in blue may be different on your system. FSUIPC ignores those in any case. The important part is the bit in red. That's the version number -- this example is for FSX-SE build 62615. Just the existence of a simconnect.dll in such a folder is enough for FSUIPC, but it might not be for any other programs you try to use. In the end unless you can get DTG support to help I think you may face a reinstall of Windows. I had to bite that bullet once after experimenting with uninstalling stuff in order to see how a user got into a similar mess. Pete

Yes: your SimConnect installation is corrupted: But you should have the Steam edition of SimConnect installed, or at very least the FSX SP2/ACC version: 281 NOTE: SimConnect Steam is supported, but it isn't installed. 313 NOTE: SimConnect Acc/SP2 Oct07 is supported, but it isn't installed. 344 Trying to connect to SimConnect SP1 May07 ... I think your Steam edition has been improperly installed. Have you altered anything yourself, like trying to move it or uninstall and re-install it? You probably need to contact DTG support, or at least try running the check and repair options in the Steam (right click on it on the left of the main Steam window, select Properties -- Local Files -- Verify integrity of game cache). Also try repairing the Steam SimConnect. First go to Windows Control Panel and select Programs & Features. Find each SimConnect entry ("Microsoft Flight Simulator SimConnect Client ...") and select it and uninstall it. Then find the FSX folder inside Steam\SteamApps\Common, and install at least: FSX\SDK\Core Utilities Kit\SimConnect SDK\lib\SimConnect.msi and SDK\Core Utilities Kit\SimConnect SDK\LegacyInterfaces\FSX-XPACK\SimConnect.msi Some applications may also want the FSX-SP1 version installing too. Pete

Yes, and the reason for the problem is clear: It seems you missed the pinned thread at the top of this Forum stating: P3D Version 3: FSUIPC menu entry not appearing You will see there exactly what action to take! Pete

The log you supplied is the Installer log file, NOT the FSUIPC run-time log file. I need to see the FSUIPC4.LOG as originally stated, please. And please include ALL of the lines in the Log -- you omitted the first line in the earlier post with the wrong log file. It should begin with something like: Installer for FSUIPC4.DLL version 4.949f Also please remove the FSUIPC4_Loader.DLL and re-run the installer to return the installation to normal. Pete

Any "clues" will be found in the FSUIPC4.LOG file, from the FSX Modules folder. It's plain text. Paste the whole thing into a message here. Pete

Okay. Thanks for clearing it up here. Pete

What is "Fusion"? FSUIPC is nothing to do with the PMDG 737NGX FMC. I thonk you have yo use its menus to reload its data. I'm afraid I don't use PMDG aircraft and can't help. You really need to refer to the PMDG documentation, or else go to the PMDG support forum. Pete

Sorry, I don't understand. What do you mean "has a similar line above"? The "dynamicfriction.lua" is optional and supplied in the Lua examples for folks to use if they wish. And yes, you need to add the correct stuff to the INI file. It isn't there by default. As for your brakes not working, that would be another matter. Pete

I've added an interim 'fix' for this L-M bug in version 4.949g of FSUIPC. You simply need to set FixATCselect=Yes in the [General] section of FSUIPC4.INI, and FSUIPC will convert "ATC Select 0-9 controls into 0-9 keypresses. I hope this will be a temporary need, but if you want to use it download FSUIPC4849g.zip from the Download Links subforum. Pete

It should do. It's a long-standing FS error really. It may even be fixed in P3D, but I doubt it. Pete

Are, you mean to assign letters manually, instead of letting the AutoAssignLetters mechanism work? Easiest way to check is to arrange them next to each other, thus: 0=Saitek Pro Flight Rudder Pedals A=Saitek Pro Flight Rudder Pedals 0.GUID={A908DB30-D445-11E5-800B-444553540000} A.GUID={A908DB30-D445-11E5-800B-444553540000} 1=737YOKE-LE by ACE B=737YOKE-LE by ACE 1.GUID={A9090240-D445-11E5-800D-444553540000} B.GUID={A9090240-D445-11E5-800D-444553540000} 2=JetMAX 737 Throttle C=JetMAX 737 Throttle 2.GUID={A9095060-D445-11E5-8011-444553540000} C.GUID={A9095060-D445-11E5-8011-444553540000} Looks pretty good to me. BTW the main advantage of doing it manually is getting to assign more meaningful letters, like P for the Pedals (or R for Rudder), T for Throttle and Y for Yoke. But if you've already run FS since you had the letters assigned it is too late to change without a lot of editing, as it will have used the A, B, C assignments already. Pete

It sounds like you are on the ground at the time. That is normal in FS -- being on the ground triggers the ground spoiler action if the spoilers are armed. Test it in the air, not on the ground! The rest of the post is about the same question I think. Pete

If that is what FSUIPC reads from your Registry, why shouldn't it be right? Mine is different. Everyone's is different. GUIDs are different all the time. That's the point. They are intended to be unique. Why the question? Pete

That can really only mean that it is getting no answer from the Server. It's probably simply because things are still pretty busy at that end. You could do similar logging in WideServer too (the parameter goes into the WideServer section of FSUIPC4.INI in that case), but I'm not sure how much you'd learn from it. Pete

Apart from the fact that you are using a VERY old version of FSUIPC, which hasn't been supported now since January 2014, over two years ago), the registration is good. The current version is 4.949c and you need to update. If ProSim still doesn't like it, you'll need their support. Maybe you need to update Prosim as well. My Prosim system is running fine, with modules spread over 6 PCs. Pete

Hmm. That's interesting, because it's okay doing that here. Did you add it right at the end? Maybe I need to move its loading position. Pete

Is this Lua script saved as "Initial.lua"? If so then it is run when WideClient is started, which could be long before there's even a connection. If you have named it something else, then whilst 18 seconds seems a long time, it can be significant. There is always a lot of things being exchanged between Client and Server when things start up and the connection is made. On top of that the Server is struggling to get enough time to run because FS signals that it is "ready to fly" quite early, before things have really finished fully loading. If you want to see all the things happening in WideClient when it connects, set Log=Debug in the [user] section of the WideClient.ini file. For you need to have 66D5 initialised to 150 at the start, I'd strongly recommend you do that on the Server, in the ipcReady.lua plug-in, which is automatically run. I do all of my offset and other initialisations there. This simplifies matters for all Clients. Pete

Yes. All macros are actually executed in the main FSUIPC/FS thread, not in the specific Lua thread. The Lua coding actually executes ipc.macro using the offset request method, at 0D70 and 0D6C. However, that said, it could theoretically still be precarious. The actual machine instructions to write the string to 0D70 and then the length to 0D6C (which triggers the action) are distinct with no critical enveloping, so there is a very small chance that control could switch to another thread and by sheer coincidence that be at the similar level, of writing to the same place. This is extremely unlikely (the threads are all equal in priority and general only lose the processor when they voluntarily do a cooperative "sleep(0)", between each Lua instruction), but it is there. If this was likely to be a problem I would have written 0D6C and 0D70 as one structure instead. I can still change that, but I don't think it is worth the change. Pete

Are these macros being instigated by buttons or switches being operated by the pilot? If so, how is it likely that he will operate several buttons or switches at exactly the same time? If this is somehow likely, or if you are talking about operations being performed automatically by program, then yes, for one aircraft you are better off having one Lua module. The only downside is a larger file needing compilation each time it is invoked. You can get over that by having that Lua program pre-loaded using the event system instead to fire off the macros -- using event.param or event.flag to allow easy assignment to buttons and switches using LuaValue or LuaToggle assignments. I think that method gives you the best solution in most cases. Pete

Aha! Typo in the Installer. Should be 12th of course. Thanks. Pete

Thanks for the information. I can see the location of the error, but the error data makes no sense. I think something s causing some sort of stack corruption. But I still need to reproduce the error before I can specifically nail it down to either a data problem in a BGL or a true bug in the code. If I think of something I'll get back to you, but meanwhile I think I'll have to leave you to use the work-around you've devised. Pete

Aha, at last -- some crash data. I wish you'd found this in the first place. It pinpoints the place in the program. But can you now confirm you are using MakeRunways version 4.694? If not could you please update and find the crash information in the log for that version -- otherwise the data isn't useful as I only have the current version source. Also, can you look at a log from when you stop that scenery being scanned and tell me what the very NEXT BGL file examined is? Because from the above it looks like it does actually finish the rogue one successfully. Pete

Ah, this time it is very different. here are the two places with the touchdown: 4.949 log: 2538760 Monitor IPC:02C8 (S32) = -175 2538760 Monitor IPC:030C (S32) = -175 2538760 SimRead: 02C8="VERTICAL SPEED" [also 0842] [also 030C] FLT64: -0.688175557532 4.943 log: 2067980 Monitor IPC:02C8 (S32) = -61 2067980 Monitor IPC:030C (S32) = -61 2067996 SimRead: 02C8="VERTICAL SPEED" [also 0842] [also 030C] FLT64: -0.240790455818 So now the 4.943 log has the lower v/s recorded on touchdown. I think this shows conclusively, it isn't any difference in FSUIPC. I suspect it is just your aircraft handlind. Maybe it is better with the smoother weather provided by ASN. ;-) The equivalent fpm values are: -0.688 m/sec == 129 fpm -0.240 m/sec == 45 fpm Very smooth landings! You want to try dropping the aircraft harder just to show higher values! ;-) Pete