Pete Dowson

I've moved your question from the FAQ subforum ,where is clearly states "Not for support requests" so it can be answered! This has to be done through a Lua plug-in. An example is included in the Lua examples ZIP included in your FSUIPC documentation. Check the "Rotaries.lua" example. Pete

Ah, that I'm not sure about. You'd need to test. It's possible that it searches for one then, when found, does it and ends. If so you'd need two cancels. Or two separate functions with one calling the other. Thank you! You too, and thanks for all the contributions and help you offer other users on this Forum! Pete

It looks like you are mastering more esoteric stuff in Lua than I've ever done. Arrays of functions eh? I didn't know that was possible. But if it works on one sim how's another sim going to change it? The Lua interpreter is the same. As an aside, If i needed to do what you'd describe I'd have just had the one master function, always called for the offset, which in turn calls a whatever function is currently selected, like with a C/C++ switch statement.. Pete

You need to do some logging to see what is being sent. That is more important that the INI's though both log and INI are needed if you want advice. Enable even logging and axis logging in the Logging tab. But don't do this till you are ready to try turning on the A/P, then turn that extra logging off soon after -- otherwise the log will get very large. If you don't see anything which explains it to you, attach the LOG and INI here -- but I think you will need to ZIP them. Pete

Use profiles. In separate profiles you can have separate assignments and calibrations. The calibration operates not on the controller axis but on the assigned axis. So there is only one calibration saved per axis per profile. It might be easier to understand with a little history. Early versions of FSUIPC did not offer assignment facilities. The calibration facilities were first. The addition of button and axis assignments was done when we determined that their are a lot more such controls we can expose than available in the FS/P3D user interface. Once we had assignment facilities it was natural to allow them to be dependent on which aircraft is being used. Especially types -- prop - turboprop - airliner - stunt plane or fighter. Hence "aircraft specific" superseded by "profiles". You need to tell us about that latter problem as I can't think what axis that might be. Basically the answer for you is that if you want to do all assignments in the sim you should stil be able to calibrate in FSUIPC. But then you don't get different controller assignments and calibrations according to aircraft. The main rule is either assign everything in FSUIPC and disable controllers in FS, or vice versa. Don't mix (at least in FS or P3D -- currently MSFS is a bit different due to current omissions in the interface for external programs). Use whatever you wish for assignments, but again it is probably best not to mix. And if using FSUIPC, uninstall any specific software provided foryour controllers. Well, you can have profiles for anything, but you'd need to change selection which is of course tied to a list of aircraft. If you want to automatically change the actions of an axis in specific flight conditions then in FSUIPC that would be done using Lua plug-ins. There is a thread here somewhere about someone wanting to be able to change the calibrated response curse ("slope") on the fly, and John added a way of doing it in an interim release. Pete

It depends how they are defined. If you can select a runway as a starting point in the sim, then it has a "start" as that's what those are for. For example I have the third party add-on scenery "UK total strips" for MSFS and even the smallest farm strips have start points. Otherwise users would not easily be able it use them for takeoff (or landing maybe, at least in the route selector). So, please check. I think you'll find you don't need a different file (which is what it would have to be). Pete

As John says. Do NOT type it. Just use copy and paste on all 3 parts. Don't try to split the 12 digits. Paste into the first box and the other two with sort it out. When the registration is rejected in means any one of the three entries are wrong, NOT just the 12 digit value. Ccopy and paste all three. Pete

That checks out fine and the registration works perfectly here, with exactly the correct details entered, for FSUIPC 4.975a. ALL THREE PARTS must be exact. I think you must be making a mistake. Cut and paste all three parts! Pete

If there are no assignments in FSUIPC, and you are running no Lua plug-ins or other FSUIPC client applications, then FSUIPC cannot possibly be responsible as it isn't doing anything. Anyway, if ProSim-AR aren't able to help, other than blaming FSUIPC, all we can do it check your settings. But you need to supply your FSUIPC6.INI and FSUIPC6.LOG files -- from a session in which this problem occurs. You should know that with a proper 737 simulation like that provided by ProSim there are lots of reasons why the autopilot might disengage. Simple things like a jittery yoke axis or one which is badly calibrated (in ProSim) can do it very easily, as also will not having it properly trimmed.. I've been using the last ProsimV3.01 Beta. I have 3.01 proper installed now, but have not had a chance to fly it yet. I have noted some problems with ProsimV3 + CPFlight hardware on the Prosim Forums. Pete

Yes, you set the number there, somewhere. Sorry, my system is off at present so I can't take a look. I want more items than appears cto be allowed, and even the number allowed won't show correctly because the fuel quantity gauge window covers it up -- albeit only with wasted black space. I keep asking Humberto to adjust that so more can fit without obliteration. I like quite detailed check lists. So some, with only room for 5 or 6 per display, take several 'pages' to get through! Pete

I don't think they could make a taxiway go missing altogether. Might mean there are little gaps in them. But if you look at my last pic above you'll see complete missing sections. Would the odd missing link do that? I suppose it might where the missing bits are straight sections. But the missing curved bits must have lots of defined points to describe the curve. Actually there appears to be only one short curve missing. Maybe your 13 missing links are enough for the 6 or 7 straight bits missing and that main curve? Email sent. Pete

Thanks. Would it fix them automatically though? I've not got much confidence in my graphical abilities. Pete

Well, I cannot make any decent taxiway set from the ADE BGLs included in either 2.0.2.0 EDDB or the latest 2.0.3.0. With 2.0.2.0 which i used before updating I got the taxiways shown in my earlier pic. Okay, but with only one of the taxiways linking the two runway areas included and no way for AI to get from many of the centre gates to either runway. With 2.0.3.0 set so that the "DUMMY" (EDDB2) is off (.bgloff) I get no links between the parking areas at the old Schonefeld area, but I get decent links between the runway areas and a path from the centre gates, as shown in this pic: If I enable the DUMMY bgl (EDDB2) and instead disable the main OP01 BGL, then the result is no taxiways, no gates, nothing. Of course that may be due to the illegal ICAO ID. But then, in that case, how come it messes up the main file when included? Conclusion: I believe the best course, assuming 29Palms don't fix this (or possibly Oliver Pabst, who seems to be the AFD guru in Aerosoft), is to put up with the above illustrated stuation (i.e. with the DUMMY EDDB2 BGL switched off). Those who are familiar with ADE could fill in those few missing linking taxiways. If anyone here does find a way to sort this, or can add theose taxiways, please tell us your solution and, if possible and allowed, include the fixed BGL. Thanks, Pete

It looks like the problem is down to a change in the DLL Humberto is using for his FSUIPC interface. There's a thread about it I started on Paul Henty's DLL subforum above. I've notified Humberto. Pete

It looks like the problem is down to a change in the DLL Humberto is using for his FSUIPC interface. There's a thread about it I started on Paul Henty's DLL subforum above. I've notified Humberto. Pete

Aha! That is what is happening with PSU. He did send me a little bit more code that what I posted earlier: Definition: Private FSControlParam As Offset(Of Integer) = New FSUIPC.Offset(Of Integer)("FSControls", &H3114) Private FSControlNum As Offset(Of Integer) = New FSUIPC.Offset(Of Integer)("FSControls", &H3110) so no "Write-Only" flag. Thanks! Pete

Hi Paul, I wonder if you can clarify something regarding your module please? If a program does this (for example): FSControlParam.Value = VK (this is the key code variable)FSControlNum.Value = 1070 FSUIPCConnection.Process("FSControls") would both offsets always be written, even if their content is the same as now being written? I ask this because a program ("ProsimUtils") is using this sequence to set offsets 3114+3110 in order to send keystrokes via FSUIPC to P3D. The first attempt succeeds, but, from logging supplied, it seems the second attempt only writes the 3114 (the VK value) -- so the keystroke is never triggered. They all say this use to work. I've checked John's FSUIPC6 code for 3110 actions and I can't find any change there. PorSimUtils has been revised recently to deal with ProsimV3, and may be using a new version of your esteemed DLL. I wonder therefore whether that has changed. Just trying to track this down. I've asked both parties to try setting 3110 to 0 between attempts, to see if it being unchanged is the problem. Thanks Paul. Pete

Okay. I use PSU, but only for the plan and performance data. It supports my thermal printer in the centre console as well. Very useful. I used to also use its checklist facilities, with display on the EICAS, but gave up because the wasted (black space) part of the fuel gauge window reduced the number of actual items displayed to about 5.5! Any more were hidden by the wasted black area which is part of the fuel gauge window. I asked Humberto to reduce that window size to just fit the image. I've not had time yet (with Prosimv3 ) to check if that was changed. Pete

You could also test my theory by having a temporary button or key assignment in FSUIPC to reset offset 3110 to 0 (using control Offset word set with parameter of 0) after the first instance of requesting the menu or whatever. If PSU is only refraining from writing to 3110 because it looks the same then this should "fix" it. Pete

Thanks for the logs. You had IPC write logging on, so they were more useful than the OP's to pinpoint the problem. Both logs show only one instance of the 3110 offset being used to instigate a key press action, and in both cases this was successful. The first log shows also a write to offset 3114 but no more to 3110, so the keypress action was not instigated. If that's what PSU is doing then it is not surprising that only one keypress is being actioned. Maybe it is seeing the 3110 is still the same as it wants, so doesn't bother to write to it. Unfortunately it is the writing to 3110 which is the instigator. Pete

You are not loading the default P3D flight, but a previously saved one, which you have presumably marked for default loading: C:\Users\Usuario\OneDrive\Documentos\Prepar3D v4 Files\Defecto.fxml This means a possibly corrupt .wx file is being loaded. You should have deleted all the .wx files in that folder too. But for the proof that it is a weather corruption you should really have followed John's instructions. Specifically this: Also, whilst you posted the .Log file (thank you) which also points to a weather file problem, you needed to also post the details of the crash from the Event Viewer, as John also requested. Incidentally, we have had a number of weather file related crash reports and the freeware P3DWX program seems to be a common factor. You might like to view the solution in this thread: Seems that he found that starting P3DWX before P3D solved the problem. Pete

The only way to stop weather info being loaded is to delete all the .wx files beforehand. The .wx files contain all the world's weather and accompany every saved flight including the default one. If you've never saved a flight then the default .wx file is probably ok, so the most likely candidate for corruption is the wxstationlist.bin file. Most of the weather crash issues we've had reported do come from such add-ons. It won't be when it attached this time, but what it did the last time you ran it. If you'd like to supply your wxstationlist.bin file (ZIP it first) then we can check it, but really your best bet id to delete it before running P3D again. It will be replaced automatically by P3D. Find the wxstationlist.bin file in your C:\Users\<your name>\Appdata\Roaming\Lockheed Martin\Prepar3D v4 folder. Yes, most certainly! Pete

It is best to always ZIP files before trying to attach them. If they are small enough you can just paste their contents into your message. Pete

You use the big "New Topic" button, on the right at the top of this part of the Forum! What was the name of the file you downloaded, and where did you get it from (what website?). The one here and the one on FSUIPC.com gets you a ZIP file with these files in it. Read the document (pdf). The installer is the file called "Install FSUIPC4.exe". If your ZIP doesn't look like this then you've downloaded something else, not the file we provide.

Perhaps he assumes that PSU is being run on the same PC as FSUIPC? As a test, try PSU on the P3D PC. I use a button screen on a WideFS client with buttons to deal with GSX -- the GSX menu and its other messages gets shown on another little screen next to it in my cockpit. The ButtonScreen uses FSUIPC's virtual buttons, and those in turn are assigned to the same control, 1070. And all that works fine with GSX. Thanks for the Log. Looking at that I do see that you ARE running PSU on the same PC: 250500 Run: "C:\Homecockpit 737\ProSimUtils\ProSimUtils.exe" so there should be no problem (and I assume Humberto thinks that too -- he is bound to have tested it. Looking through the Log I can see an ATC menu being shown several times, apparently in response to Shift+J assigned to a button. The sequence for that is: [Buttons] 3=P64,0,K74,9 SendKeyToFS(0004004A=[shft+J], KEYDOWN) ctr=0 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=2 Sending WM_KEYDOWN, Key=74 (Scan code 36), Ctr=1 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 .. Key not programmed -- passed on to FS KEYDOWN: VK=74, Waiting=0, Repeat=N, Shifts=1 .. Key not programmed -- passed on to FS The corresponding KEYUP actions are logged less than 100 mSecs later. The equivalent for the GSC menu, the Ctrl+F12 send by PSU shows: FSUIPC Control Action: Ctrl=1070, Param=635 SendKeyToFS(0002007B=[ctl+F12], KEYDOWN) ctr=0 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=2 Sending WM_KEYDOWN, Key=123 (Scan code 88), Ctr=1 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=2 .. Key not programmed -- passed on to FS KEYDOWN: VK=123, Waiting=0, Repeat=N, Shifts=2 .. Key not programmed -- passed on to FS So, the exact equivalent, also with the KEYUP actions less than 100 mSecs later. But, oddly, I see [GSX] Departure clearance requested with no action logged to instigate that -- no Keyboard or Button used? Did you click on screen with a mouse button instead? Then you apparently use the P3D menus for something: 834047 KEYDOWN: VK=18, Waiting=0, Repeat=N, Shifts=4 834047 .. Key not programmed -- passed on to FS Keycode 18 is the ALT key. The Sim stops and when starting again it goes through further initialisation by ASCA and Active Sky. THEN the GSX pushback menu! Then the Ctrl+F12 sequence is pressed, but apparently not via the 1070 control (time 1019922). In fact, after the one I list above (at time 792813) the facility to send the 1070 control does not appear at all, so it seems nothing is sending this. I think that needs checking by Humberto. The only other thing I notice is that you are using an out-of-date unsupported version of FSUIPC. I think you should update and re-test. Pete