Pete Dowson

Perhaps, then, more related to the Aircraft definition -- RC will be reading aircraft details for the ATC exchanges it does with them. That's why I said "or whatever", not just textures. And also why I suggested doing the IPC logging, to see what RC was doing with FSUIPC just before the crash. With such logging the log'll get large, but there's no need for whole logs, the last entries would do, 40-100 lines or so. In fact if you know when the crash will (probably) occur, dstart a new log (click new log button) just before. Best though to make sure no other FSUIPC-using apps are running, to cut down on logging confusion. eg. EFB2. Pete

It may just be that the reduced traffic level eliminates the one with the bad texture or whatever. So a test with traffic limited instead by moving half of the AIM-OCI scenery BGLs to a "saved" folder, one half then the other, might help distinguish between the rather too simplistic "too many" (what would that mean), and there being a "bad" one. FSUIPC in any case limits the amount that RC can see, asit only has room for 96 ground and 96 airborne in total in its tables. Are you setting the time the same for each test, or allowing that to vary now? Pete

As you can see, the initial crash is in P3D's DLL called "Facilities.DLL". I think the fact that it only occuured after you enabled WideFS is misleading. WideFs doesn't use anything at all in P3d, and FSUIPC only interfaces through the official SimConnect and PDK interfaces. The succeeding crashea end with Application: Prepar3D.exe Framework version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception information: System.AccessViolationException with <Module> .UIInterface.UnmanagedMapViewer. {Dtor} (UIInterface.UnmanagedMapViewer *) with UIInterface.MapViewer.! MapViewer () with UIInterface.MapViewer.Disex (Boolean3.D4.exe) .16.27077 is no longer responding to Windows and has been closed. Interesting that it looks like .NET Framework is involved. Neither FSUIPC nor WideFS uses that. Version 4.0.30319 sounds odd though. 4.7.2 is the current version. I don't even have a 4.0 installed, so perhaps that needs updating. It appears to crash in a "Mapviewer" function. Either way, I am sure you have a problem in your system -- either a corruption in P3D or some problem in Windows. I use P3D on a Win10 Pro system with 8 WideFS clients happily connecting and running applications for P3D. I have prevented Win10 updating itself since 1803, but I do know of other users who have a fully updated Win10 (to 1903, recently released) without any WideFS problems. Pete

But it did in the old version even though the macto itself was bad and not executed? It might be related to timing. Try programming them separately, the Start to the button press and the release to the button release. That would be more realistic in any case. Try making a separate mouse maacro for the release, assuming you have to press t again somewhere to release it. Otherwise have one macro do the 13 and the other the 16. Why, in any case, is there no "press"? I wouldn't have thought a "left release' would first press it, so what presses it? Seems to me you need a simple left click. Did you try following the instructions for programming a macro, including using TAB to test it before naming it? I really can't help you further. The functions listed for the mouse are all that are provided. Pete

If it is only with WideFS enabled then it sounds llike you have a network driver problem, because nothing else is happening except initialisation of sockets listening for connections from other PCs. Though what relation that could possibly have to the functioning of the indpendently operating menus of P3D is hard to imagine. Anyway, you do need to provide data, as nothing can be advised without information. Use the Event Viewer in Windows to get full details of the crash -- or crashes, because there may be more than one in the Prepar3D process withing a short space of time (please see the other thread near here ("P3D4.5 Crash"). Please also supply details such as Windows Version (recently updated?), and any P3D add-ons and add-ins being used. Pete

Sorry, I've no idea. You'll have to experiment. I thought you just wanted the same as 11 and 17 in the P3D3 version. 11 = MOUSE_LEAVE17 = MOUSE_LEFTRELEASE So why not look through the list for P3D4 and choose equivalents? They are MOUSE functions, not "macro functions". The first code gives the Rectangle ID -- that tells P3D where the mouse was. and the second the ouse action which is to happen. that's it, nothing more, nothing less. But that macro won't work on the old file either because, as I said, the format is wrong. It would hve to be Find one from the old file which actually worked! I can't. I've no idea how your APU MASTER STTART switch works because you've simply not shown me how you did it, and nothing you've said about it is making any sense to me at all. Pete

A "Word" is 16 bits, so occupying two bytes. "W66C3" covers 66C3 and 66C4. The byte in 66C3 represents untis (0-255) whilst the next byte is 'worth' 256 times that, so a 1 in 66C4 would have to be represented as 256 which you would add to the value you want in 66C3. But in your examples you are only testing for 66C5 = 0, so just changing your use of 66C5 to 66C4 and the 'B' to a 'W' would work fine. But you seem to have already done it, so why throw it away? After all, you did say it worked well. Lua plug-ins ARE processed by FSUIPC and are in the same place as your Macros. Lua programming can be almost self-explanatory with careful naming of variables and functions, so less commenting is needed. Quite honestly I wouldn't have implemented anything but simple conditional programming for button assignments if I'd thought of implementing the plug-in facilities first. Most things above a certain level of complexity make much more sense in a proper script. The sort of button programming you are doing needs commenting mainly because the formatting is so strict and the notations arcane. Pete

For the 11 and 17 in lines which were wrong and could never have been used. Why if they are never used? Anyway, if you want to use new numbers for old, read the names of those numbers. It is easy to map one to the other. they are only mouse actions! I don't need to do such simple things for you, surely? If there's any ambiguity, choose one and test, etc. I can't do this for you, sorry! Pete

And do these also change next time you start a session and load the same aircraft? Here I loaded up my P3D4 and then the same Mooney, and created these: [Macros] 1=STBY_VAC=RX5000,3 2=PROP DEICE=RX5800,3 3=PITOT HEAT=RX6000,3 4=BOOST PUMP=RX6800,3 5=ELEV TRIM-=RX7000,3 6=ELEVTRIM+=RX7001,3 As you can see, they are identical to yours (except for the names of course). That was with P3D4.4.16, and the Mooney selected in the initial Scenario selection panel. Then I closed P3D down and started it again. this time i let it load with my default Scenerario, then selected the Mooney. All the above macros worked fine. So, next step: uninstall 4.4 client and install 4.5.12. Did same test. Got same results. The macros -- mine and yours, work fine. So, sorry, it isn't reproducible. There's something wrong on your system. I think you'll need to go through a process of elimination. start with a fresh P3D4 install, test it, then add your stuff step by step, tesing each time. Let me add that I'm not surprised the tests showed things are working. If they weren't there would have been a lot nore messages here saying this! Pete

I've moved your SUPPORT message out of "User Contributions" subforum (which is a reference place) to here, the support forum. Please alsways post questions here, NOT to the references sub-forums where they may be missed. Only one Offset condition is possible. You could combine them into on Word by using 66C3 and 66C4 instead, then W66C3=1 would work. One control per line! Just split that into two lines, both with the same conditions. Too verbose for what? You or the computer? The computer doesn't care, so why do you? If you want a neater approach to programming things for FSUIPC, use a Lua plug-in. That's what they are for, to enable you to do things not possible or not easy with rather arcane parmeter lists. Pete

This is not for P3D4 obvously. They are using the old method where FSUIPC placed a hook in the sim's code and called the same functions directly. Those last two lines aren't correct and will be ignored. No lines can start with '='. The = comes afer the 23.1, etc. They can't be automatically added by FSUIPC, so they've been edited directly -- by the same person who got the format all wrong I expect. They are mouse flags defined in the FS Gauge C/C++ SDK: 11 = MOUSE_LEAVE 17 = MOUSE_LEFTRELEASE The lines without a code use 29 = MOUSE_LEFTSINGLE. Please do refer to the documentation -- oage 41 of the FSUIPC4 Advanced User's PDF. Sorry, how does that text possibly relate to the three macro lines?And what on either is a "Mom"? First, that is even more confusing. The 11, 17 in your earlier example (in lines which couldn't possibly work anyway) related to "APU_MASTER_START", not a "Mom". Second, macros for P3D4 are NOT the same as those in 32-bit versions of FSX and P3D. I've already explained how FSUIPC is able to make use of new facilities in P3D. The old method, hacked into vode -- part of the macro encoding is actually an offset into the Gauge code. the macro contains the name of the relevant GAU or DLL file. In P3D4 the encoding is merely a rectangle ID. Anyway, again, you need to refer to documentation. Page 38 of the FSUIPC5 Advanced User's PDF gives you the mouse codes used by P3D4. Pete

The Manager, AIM, might do, but it isn't running. The traffic just consists of regular Traffic BGLs plus SimObjects (aircraft models and textures) -- same, in fact as any other traffic package except for the likes of UTLive which injects its traffic instead of using BGLs. I assume that P3D uses .NET framework, but I'm not even sure about that. One could check on its list of dependencies I suppose (there are programs that can do that), but I'm not sure I'd recognize which of the Windows services it calls upon are supplied by a .NET install and which aren't -- except a few of the latter which I'm certain definitely aren't. Pete

It will be Prepar3D because all FSUIPC does is record the ID which is provided by P3D, and, when it is used, just calls a function which is supposed to reproduce thesame action. The problem will be that we haven't been able to reproduce it so far. Can you reproduce it with a default aircraft panel? If so let us have the macro file and tell us which default aircraft and panel. If we can reproduce it with a default aircraft then a bug report to L-M is reasonable and we can both submit it through our respective channels. They need to be able to reprodice it too, you see. Pete

Further to my thoughts above, I've heard from another user with pretty much exactly the same error, but in his case there were actually THREE crashes reported in the Event Viewer, all within a second or two. the first of these was Prepar3D crashing with a .NET framework error. Then there were two FSUIPC crashes. I think the FSUIPC crashes are because separate threads are in use and the crash of P3D is cascaded into those threads before the whole process is closed as a result of the main crash. So, could you check the Event Viewer again -- see if there were actually two or three in a row. If so, it is the first (earlier) one which is truly relevant. Now FSUIPC does not use .NET framework at all. So I don't think it is really to do with FSUIPC. Note that this other user is using AIM OCI Traffic (as am I). He is getting this with P3D 4.5.12 (the "hotfixed" one). Also his Win10 was recently updated. These things might be relevant. I am also using 4.5.12 but I have my Win10 fixed at release 1803 (as far as I'm able, anyway). BTW John will be back to take over this support at the end of the week. Pete

Well, I still don't know what "non-SS" is intended to mean, but I have just looked through the document listing the currently available controls (a PDF in your FSUIPC Documents folder), and do see a lot of "HOTAS ..." controls. Those are new to me, but they should equate to controls you can assign in P3D -- though P3D assignment facilities won't use the actual names (as FSUIPC does). It uses a description instead. FSUIPC obtains that list from the sim -- it does add some of its own, including ones for handling and Lua plug-ins and Macro files it finds in the folder, but the ones obtained from the sim do whatever the sim determines them to do -- so that should be covered in the sim's help or documentation. The quickest way to see what a control does is usually to try it. Of course you'd have to be in a situation and with an aircraft which will actually allow it to do something. Sorry I can't be of more help on this. If don't even know what "HOTAS" means -- something to do with fighters or bombers? Pete

I wonder, then if perhaps there's a corrupt BGL or aircraft in that AI installation. I use the AIM OCI for traffic, with all airlines enabled and kept up to date, but I only fly in Europe so a lot of them won't be seen. The traffic data FSUIPC receives comes from SimConnect, but that in turn will come from the BGL route information and the Aircraft.cfg for the aircraft. I suppose it is possible for something there to be corrupted. Pete

Isn't that just a matter of keeping a copy of the last value sent, and incrementing or decrementing that before sending the result -- with checks on the limts of -1 and +6 of course. If you explain just what it is you need to know I'm sure we can help. Pete

Before we go on, what do you mean by "FSUIPC codes (non SS)"? Where exactly are you looking? I don't know, sorry. What are they? What's a "HOSTA"? Pete

Not in FSUIPC for a user chosen event, no. FSUIPC does intercept certain events so that they can be altered before sending on -- axis events which are assigned to FS axis controls (in the sim or in FSUIPC) -- so they can be calibrated. But this is internal to FSUIPC for very specific events (axes and those controls needing a following "select code", such as Pushback, Engine, and Toggle Aircraft Exit). With the Lua event.control function you can take action when the control event occurs -- eg to counter what it is requesting by sending another to contradict it, or by sending a different control, eg, to a different engine. But you can't stop it being passed on. With PMDG added "custom controls" I have my doubts whether even the sort of interception and forwarding FSUIPC does for those it needs to change will work. PMDG tend to do their own thing, taking the events at the same priority level as my own . This is why it is not always goode to use FSUIPC calibration for all PMDG flight controls, for fear of multiple conflicting events being sent to the sim. Currently, if you really need to intercept those events and stop them going though I'm afraid you'll need to interface direct to SimConnect. Even then, for PMDG, it isn't guaranteed that you'll be able to do it. Pete

Thanks! Pete

I don't know. But he put the script in his first message, with just the error that he tried to use "varget" instead of "ipc.readLvar". So why not try it? Pete

Does it work with a P3D assignment to pan view? Don't forget to test it with a default aircraft. I really don't know whether CAMERAS has anything to do with what Pan View does. I woulsd have thought it simply panned left/right/up/down in whichever view is currently selected. It isn't really something I use. My views are fixed -- a 210 FOV curved screen, simulating the full view from inside my cockpit. Trying to pan or change views would ruin the blending performed on the overlapped projected windows and i'd end up with a mess. Maybe, therefore, you'd get more help in the AVSIM P3D forum. Pete

I've moved your support question from the FAQ reference subforum to the support forum. Please post support questions here in fitire. The subforums contain contributions and reference material. Only after any scenery additions, revisions, or deletions. Or, of course, after an FS update. As just stated, or never if you have no programs wanting to use the data files it generates. You don't name any such programs, No. That data is separate from scenery (airport facility) data and Makerunways does not read it. Pete

FSUIPC is not involved at all in CAMERAS. What are you looking for in the FSUIPC documentation? ... Ah, i see you actually appended your real question as an afterthought: What are you assigning to and where? Do you mean "Pan view" in the axis assignments list? If so, please know that all this does is send that to P3D. So if it works in the Sim it will work when assigned in FSUIPC. Pete

No. It merely traps the events passing through the P3D windows procedure or being sent via SimConnect. Of course it is possible that programs might intercept them and handle them before FSUIPC sees them. The FSUIC "event" logging logs the same things. If your intent is merely to log or display evens as they occur it would be easier to just use the existing logging facilities. If you want to see them in real time, run P3D is Windowed mode and enable FSUIPC's Console Log (or use full screen but move the console to a different screen). Pete