Pete Dowson

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

Unfortunately, installing that BGL here doesn't cause any problems at all. It processes perfectly normally. Here are the results in the Runways.txt log file: ============================================================================= TestScenery\scenery\AF2_UAFG.bgl ============================================================================= Airport UAFG :N42:38:52.5106 E077:01:53.6307 5496ft Country Name="Kyrgyzstan" State Name="" City Name="Chelpon Ata" Airport Name="Chelpon Ata" in file: TestScenery\scenery\AF2_UAFG.bgl Runway 34 /16 centre: N42:38:50.8909 E077:01:48.7192 5496ft Runway 34 closed for take-off Runway 16 closed for landing Computed start 34 : Lat 42.642120 Long 77.032560 Start 16 : N42:39:07.3796 E077:01:41.5092 5496ft Hdg: 162.0T, Length 4100ft Computed start 16 : Lat 42.652817 Long 77.027835 Hdg: 342.000 true (MagVar 4.000), Concrete, 4100 x 110 ft *** Runway *** UAFG0340 Lat 42.642120 Long 77.032562 Alt 5496 Hdg 338 Len 4100 Wid 110 *** Runway *** UAFG0160 Lat 42.652817 Long 77.027832 Alt 5496 Hdg 158 Len 4100 Wid 110 COM: Type=6 (TOWER), Freq=128.00, Name="×åëïîí Àòà" Taxipoint #0, type 1 (normal): N42:38:31.8430 E077:01:57.1923 -- Forward Taxipoint #1, type 1 (normal): N42:39:10.1007 E077:01:40.3137 -- Forward Taxipoint #2, type 1 (normal): N42:38:57.3697 E077:01:45.9286 -- Forward Taxipoint #3, type 1 (normal): N42:38:58.2768 E077:01:49.9358 -- Forward Taxipoint #4, type 1 (normal): N42:39:07.0233 E077:01:41.6685 -- Forward Taxipoint #5, type 1 (normal): N42:38:33.3008 E077:01:56.5580 -- Forward Taxipoint #6, type 1 (normal): N42:38:54.3895 E077:01:52.3740 -- Forward Taxipoint #7, type 1 (normal): N42:38:58.0824 E077:01:51.0559 -- Forward Taxipoint #8, type 1 (normal): N42:38:55.2317 E077:01:52.0278 -- Forward Taxipoint #9, type 1 (normal): N42:38:54.6810 E077:01:52.2466 -- Forward Taxipoint #10, type 1 (normal): N42:38:55.5557 E077:01:51.9008 -- Forward Taxipoint #11, type 1 (normal): N42:38:56.1712 E077:01:51.6431 -- Forward Taxipoint #12, type 1 (normal): N42:38:56.3655 E077:01:51.5644 -- Forward Taxipoint #13, type 1 (normal): N42:38:57.1106 E077:01:51.2650 -- Forward Taxipoint #14, type 1 (normal): N42:39:00.5768 E077:01:49.9615 -- Forward Taxipoint #15, type 1 (normal): N42:39:00.8683 E077:01:51.2828 -- Forward Taxipoint #16, type 1 (normal): N42:38:59.8641 E077:01:51.7300 -- Forward Taxipoint #17, type 1 (normal): N42:38:59.5402 E077:01:50.4186 -- Forward Taxipoint #18, type 1 (normal): N42:39:00.3824 E077:01:49.1504 -- Forward Taxipoint #19, type 1 (normal): N42:38:58.4064 E077:01:52.3224 -- Forward Taxipoint #20, type 1 (normal): N42:38:59.3458 E077:01:49.5429 -- Forward Gate 1 [#G0]: N42:39:00.3824 E077:01:51.5016 Type 3 (GA Ramp Medium), Size 14.0m, Hdg 162.3T Gate 2 [#G1]: N42:39:00.0585 E077:01:50.1802 Type 3 (GA Ramp Medium), Size 14.0m, Hdg 162.2T Gate 3 [#G2]: N42:38:59.2486 E077:01:51.9989 Type 3 (GA Ramp Medium), Size 14.0m, Hdg 341.5T Gate 4 [#G3]: N42:38:58.9247 E077:01:50.6938 Type 3 (GA Ramp Medium), Size 14.0m, Hdg 341.8T Gate 5 [#G4]: N42:38:57.3050 E077:01:52.1857 Type 3 (GA Ramp Medium), Size 14.0m, Hdg 72.4T Gate 6 [#G5]: N42:38:56.3655 E077:01:52.5478 Type 3 (GA Ramp Medium), Size 14.0m, Hdg 72.4T Gate 7 [#G6]: N42:38:55.4261 E077:01:52.8742 Type 3 (GA Ramp Medium), Size 14.0m, Hdg 72.4T Gate 8 [#G7]: N42:38:54.5190 E077:01:51.4050 Type 2 (GA Ramp Small), Size 10.0m, Hdg 72.4T Gate 9 [#G8]: N42:38:55.3289 E077:01:51.0589 Type 2 (GA Ramp Small), Size 10.0m, Hdg 72.4T Gate 10 [#G9]: N42:38:56.1712 E077:01:50.7421 Type 2 (GA Ramp Small), Size 10.0m, Hdg 72.4T Gate 11 [#G10]: N42:38:57.0134 E077:01:50.4298 Type 2 (GA Ramp Small), Size 10.0m, Hdg 72.4T Taxipath (Name #0): Type 1 (Taxi), Start#=2, End#=3, Wid=15.24m Taxipath (Runway 34): Type 2 (Runway), Start#=4, End#=2, Wid=33.53m Taxipath (Runway 34): Type 2 (Runway), Start#=4, End#=1, Wid=36.58m Taxipath (Runway 34): Type 2 (Runway), Start#=5, End#=2, Wid=33.53m Taxipath (Runway 34): Type 2 (Runway), Start#=5, End#=0, Wid=36.58m Taxipath (Name #0): Type 3 (Parking), Start#=8, End#=G6, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=9, End#=8, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=9, End#=6, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=9, End#=G7, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=10, End#=8, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=10, End#=G8, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=11, End#=10, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=11, End#=G5, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=12, End#=11, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=12, End#=G9, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=13, End#=12, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=13, End#=7, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=13, End#=G10, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=13, End#=G4, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=14, End#=G1, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=15, End#=14, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=15, End#=G0, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=16, End#=G0, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=16, End#=G2, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=17, End#=16, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=17, End#=G1, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=17, End#=G3, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=18, End#=14, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=7, End#=3, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=19, End#=7, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=19, End#=G2, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=7, End#=G3, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=20, End#=18, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=20, End#=3, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=17, End#=20, Wid=12.19m Taxiname: #0 = TaxiWay : G6-8-9-6 TaxiWay : G7-9 TaxiWay : G8-10-8 TaxiWay : G5-11-10 TaxiWay : G9-12-11 TaxiWay : G10-13-12 TaxiWay : G4-13-7-3-2 TaxiWay : G1-14-15-G0 TaxiWay : G0-16-G2 TaxiWay : G1-17-16 TaxiWay : G3-17-20-18-14 TaxiWay : G2-19-7-G3 TaxiWay : 20-3 FSM A/P UAFG, lat=42.647919, long=77.031563, alt=5496 So I'm afraid is looks more complex that this, and so far very specific to your system. I've never had any other similar crash reports for MakeRunways at all. Unless I can reproduce it I don't really have much chance of finding it. But one last stab. In the case where it crashes with this file enabled you should still have a partially completed log (Runways.txt). I know you said it was too large, even ZIPped, to send, but could you at least extract the last few entries so I can see where it got to? Pete

Okay. 02C8 is the current V/S, and 030C is a copy of that until the moment of touchdown, at which time 030C is no longer updated. In the 4.943 log the touchdown detection appears to be here: 6488472 Monitor IPC:02C8 (S32) = -911 6488472 Monitor IPC:030C (S32) = -911 6488488 SimRead: 02C8="VERTICAL SPEED" [also 0842] [also 030C] FLT64: -3.56170797639 because 030C is not updated later than that. In the 4.949 log the same point is reached here: 1991446 Monitor IPC:02C8 (S32) = -149 1991477 Monitor IPC:030C (S32) = -149 1991477 SimRead: 02C8="VERTICAL SPEED" [also 0842] [also 030C] FLT64: -0.584607480251 So, yes, when touchdown is detected the V/S is lower in the later version. Now the V/S figures after both of these occurrences are very low indeed. In the 4.943 log it decreases to -0.55, -0.13, -0.10, -0.09 .... remaining very low for the rest of the time, though still changing. In the later version the same applies: -0.35, -0.10, -0.01 etc, also remaining very low for the rest of the time, though still changing. The place in the 4.949 log where comparable touchdown speeds are seen is here: 1983459 Monitor IPC:02C8 (S32) = -911 1983521 Monitor IPC:030C (S32) = -911 1983521 SimRead: 02C8="VERTICAL SPEED" [also 0842] [also 030C] FLT64: -3.56359434419 which is a full 8 seconds earlier, and the aircraft is still descending at a decreasing but similar sort of rate thereafter for quite some time. So it really isn't as if the detection of the touchdown is being delayed by an inordinate amount. Now all this is directly using the V/S figures being provided by FSX-SE via SimConnect. There's really no way I know of that FSUIPC can actively change those values. So it is rather inexplicable. Something else is different too, though, looking at the log. In the 4.949 case you appear to be running ASN. In the 4.943 case it looks like something different, because these lines indicate a different weather control in operation, one using FSUIPC I suspect: : 5928943 NWI weather clear actioned 5928943 External weather discarded ASN's hooks are definitely there in the 4.949 log: 3541 ASN Running? Smoothing is by ASN Perhaps you need to make things more equal in order to get a comparison. It looks like with ASN the aircraft is floating very gently down to touchdown. Try with no weather control program at all. In fact no weather (clear it before the test) to ensure conditions are identical. Pete

The two values I gave you represent two different offsets, containing different values! They are not joined as a long name! There are 4 entries in the 4 entry table so you can enter up to 4 values! That's the point. You only need to use 2 out of the 4! Up to 4 different offsets can be monitored, but not bundled together! Offset monitoring is documented in the section on Logging in the User Guide. Pete

Oh dear. It is just text. Just look at the log in an editor, such as Notepad. Select the whole of it by dragging the mouse, Copy (Ctrl+Insert), then, in your message, position the cursor with the mouse and press Shift+Insert. This is called "copy and paste" and it is a very useful technique to use in most things to do with file editing and messages! Pete

Show me the FSUIPC4.LOG file from the FSX Modules folder. You can paste the whole thing in a message here. Pete

Well there are only minor changes between c and f, namely: 1. Correction to erroneous error message when assigning buttons 2. Extra logging for ASN WXreadar file problems 3. Fixes for errors in Lua functios to do with setting and clearing bits in values 4. A new Lua ext library function, "hasfocus" and that's it. All those changes only do anything if you are using the mentioned items, no changes whatsoever have been made to anything you would be using in normal running. As I said, sometimes when there is actually a problem occurring, you only actually get a resulting crash when the memory layout changes a little. If the update to FSUIPC really is the change which precipitated the result you are getting then I do think it's a pre-existing problem in any case which simply hasn't before resulted in a crash. You'll need to give me your email address. I'm not uploading one. But please also read what I'm saying above. There was an "e" release too -- 9th February. The "d" release was a test only, and went to specific folks only. Pete

Please ZIP up the BGL and email it to me -- petedowson@btconnect.com. Pete