Pete Dowson

Sounds like there's something very slow saving files on your disc system. Maybe it's getting full? Mind you, Windows should cache files for writing -- unless you have caching turned off for that drive? One of the probably slow downs too is that when a complex aircraft like the PMDG one detects a flight save, it also collect up settings and writes its files, so there are more files and more activities going on which could prevent SimConnect activities. BUT, and this is a big but, it shouldn't get worse over time. And if you increase FSUIPC's SimConnect timeout to allow for the flight saving time, then it shouldn't really fail at all. Pete

No, it is 99.9% dependent on SimConnect. Pete

Did you read it in the Plan-G documentation, perhaps? I don't know Plan-G I'm afraid. Do they have a support forum? Pete

Your first post had a "Flight Simulator has detected a problem" window citing FSUIPC4. You then said the problem resolved itself. Since then there has been no further description of any problem. You say "FSX crashes". Why do you point to FSUIPC4 now? Have you got the same Window reporting this? Did you check the details in the Event Viewer as I asked? I can't help with no information. The log just shows FSUIPC loaded okay and was running happily. no more. That's only part of the answer. The rest depends on more information about what is happening and what Windows says about it. don't you see that? I'm not peering over your shoulder, I need you to describe things and get information. Bed time now. I'll be on late tomorrow, things to do in the morning ... Pete

But what is the log about? Why are you showing it to me? It shows no problems, why do you think there is one? Pete

You posted a log with no comment, no description of what you want to know. And it isn't even complete. You need to close FS to get a complete log, as there is more info in the concluding lines. Pete

Thank you! ;-) Pete

Well, of course, they do -- as many users can attest. There's just something wrong on your setup. Did you bother to follow my suggestions at all? How do you mean? There are many options as you can see from the documentation. But it uses SimConnect. It has to. If SimConnect stops providing information, stops responding to requests, that's it, it cannot function. Are your other SimConnect applications, like the weather program, still operating correctly? Generally, if SimConnect stops all of its clients stop working too. It isn't FSUIPC's doing. Pete

Please don't post unnecessary screen captures! The screen goes black because that's the way SimConnect's menu selection works. it doesn't matter whilst you are in FSUIPC options because FS is not running then, everything has stopped. You can't press or click anything other than in FSUIPC options. If, having started macro making, given a filename, and OK'd out of the FSUIPC options, you don't get the "transparent green screen" when clicking on switches etc, it simply means you can't make macros with those gauges. I told you this 6 days ago, and you appeared to have accepted that. And I suggested other things to look at, so why suddenly post this waste-of-time and space picture? :-( Pete

I don't understand what you want. The altitude in the 64-bit value at 0570 is the ACTUAL altitude above mean sea level, not above ground. If you want the true AGL just subtract the current ground level from that (i.e. the value at offset 0020). The current atmospheric pressure doesn't change your altitude above ground at all. You can also read the AGL at lower levels, when the radio altitude instrument is valid, at offset 31E4. If you really want to know what the ALTIMETER shows with the QNH set to the value in offset 0330, then this is given at offset 3324. If you want the PA (Pressure Altitude), ie the altimeter reading when the pressure is set to STD (1013.2 hPa), then this is at offset 34B0. I can't imagine what else it is you might want. Pete

Such protection is already there as far as I can do it. It shouldn't crash, as it checks the hook positions every time and simply doesn't put the hook in if it doesn't get a binary match to the position. But it can't work miracles. For example, it also calls a number of functions by ordinal. If you insert another function in such a way that all the ordinals afterwards change number, there's no way I can detect that and avoid calling the wrong function. Similarly if, on a recompile, a function being hooked internally uses different registers for parameters or, worse, pointers, I can't detect that either. All I can do it try to fail gracefully. Currently it only checks the version number of the EXE. If you only release actual changed modules, so that unchanged ones stay with the same version number, then I could, instead, check the specific modules I link into. That doesn't solve the problem, but it might make it a lot easier to deal with. There is another way, one whch could remove the need even for FSUIPC to check versions, other than >= 62607. That is ( a ) providing the hook entries I need by exported names ( b ) exporting the function ordinals I need by name instead. I did discuss this with the Prepar3D team, and they were going to do something about it, but seem to have become too busy doing other things. Originally, all the things I am doing were on Dave Denhart's list for attention in developing versions of the SimConnect interface, but that was before the money men took over at Microsoft. If you want to discuss all this further it might be better to do so by email: petedowson@btconnect.com. I'd really be delighted if we could solve this together. I don't want to have to keep doing these forced updates forever ... getting too old! ;-) Pete

Try using "sound" instead of "Sound". Lua, like many programming languages, is sensitive to both case and spelling and "Sound" is not the name of the "sound" library. If you refer to the Library documentation you will see them all shown correctly. Pete

Why not simply send the "Reload Aircraft" FS control? That's what I do! Works very well! I think trying to do this by macro would be very difficult, unwieldy and maybe impossible. Have you looked at Lua plug-ins instead? There are plenty of examples provided. Or just use Reload Aircraft, as I said. Pete

Why did you post about six messages with nothing but "Hi Peter" in them? You are using the wrong version of FSUIPC -- you need 4.738a. Pete

Of those it could only be the PMDG add-on (777?) or the Weather engine, I think. I don't know VPilot. But since you don't have many, it shouldn't take too long to isolate the culprit. Changing the timeout might allow it to run a bit longer before the queues pile up too much again. It might make FSCommander's map following and other activities a bit jerky when the earlier stalls were happening, depending how many seconds SimConnect's responses then take. It won't affect non-FSUIPC applications, and FS Real Time shouldn't be a problem. BTW, you don't have FS Real-Time doing automatic checking and corrections, do you? That could make it worse if it is having to readjust every so often, as that would cause a lot of internal shuffling in FS. Pete

Oh dear. You should have abbreviated it much more and simply said "and so on". Things aren't good from the start: 525969 Starting everything now ... That's where FSX and FSUIPC are "ready to fly". Just 24 seconds later, SimConnect is stalling already: 550891 **** No SimConnect events or states being received! Re-connecting now ... **** After that it seems to show bad signs at intervals. Here, 6 minutes later: 907969 **** No SimConnect events or states being received! Re-connecting now ... **** and then 11 minutes after: 1567734 **** No SimConnect events or states being received! Re-connecting now ... **** then more frequently, in fact every 1 minute 1621516 **** No SimConnect events or states being received! Re-connecting now ... **** 1682000 **** No SimConnect events or states being received! Re-connecting now ... **** etc until eventually no responses at all! Now FSUIPC's timeout for responses from SimConnect is one second. That may seem short, but it is actually a LONG time when you consider many systems use FSUIPC's data to update hardware gauges and so on. Imagine how jerky they'd look at 1 second updates! Normally FSUIPC expects data from SimConnect at the fS frame rate, at the minimum. However, you can change the timeout. It is this parameter in the [General] section of the INI file: SimConnectStallTime=1 It's in seconds. Increasing it might alleviate your problem, but it won't really solve it. Something else you are using is really clobbering SimConnect so much that it cannot cope. Its requests are queuing up and its workload developing to an impossible level, and it then stops serving all or some of its clients. You need to work out, by a process of elimination, which of your add-ons (or add-ins) is responsible. You could try using SimConnect logging (instructions are in the FAQ subforum), but if you thought the FSUIPC4 log was large, you just won't believe the size of a full SimConnect log! And it would be you analysing it, not me, thank you very much! No, I think you need to cut out add-ons until you find the culprit. Regards Pete.

Not at present. Are you volunteering? ;-) I suspect I might shuck off 64-bit when that (inevitably?) comes to Prepar3D. Any volunteer will have a hard job with my code. I gave up commenting code many years ago. Too much typing! ;-) Regards Pete

Good. I forgot that some of these things can be hidden under those "Wow6432Node" things. Wasn't so in my case. I don't know why ... my regedit doesn't show that layer. Maybe it's to do with privileges, UAC or some other option which I've disabled. The layer isn't used in programs accessing keys like that either, so I think it is solely concerned with protection -- otherwise known as "confusing users"! ;-) I still don't understand how the wrong link ended up there. Must have been some sort of hiccough during Steam FSX installation. Regards Pete

Yes, but because FSUIPC has hooks into FSX code it has to be modified every time you recompile with even minor changes. I have to check where the code has moved to and whether different registers, parameters, returns are being used. This is why it will tell the user, during installation, that the version is greater than any known to FSUIPC and asks him to check for an update. It will still install, and may partially work -- or may crash FSX-SE. If you kept the version number the same despite there being changes it would be disastrous as FSUIPC would have no idea what to do and I no idea why things are going wrong or crashing. No, you must update version numbers, of course. Pete

Is there any more information? Check the FSX Modules folder for an FSUIPC4.LOG file -- this will at least show (a) if FSUIPC4 got to run at all, and if so (b) how far it got. And use the Windows "Event viewer" to look for the windows-detected crash which must have led to this report in the first place. One of the more usual reasons for this sort of error to occur is a corrupted WX (weather) file, or a corrupted "weatherstationlist.bin" file. The problem with those is that, being binary, they aren't properly checked and when FSUIPC asks SimConnect to supply the weather, bang. Pete

The only way that can happen is when SimConnect stops responding. The problem will be an overloaded or failed SimConnect interface, probably caused by other add-ons. The details of what is going on will be shown in the FSUIPC4.LOG file. Please find that file in the FSX Modules folder, and paste its contents here -- use the <> button above the Edit area to enclose it. Pete

You cannot have assignments in FSUIPC and leave controllers enabled in FS or P3D because it will still auto-assign things now and then. Do one or the other. You can still calibrate etc in FSUIPC even if you assign in FS/P3D. There are various Mouse facilities in FSUIPC. which include panning, zooming and moving your eyepoint. Why not use those? Have you not read the documentation or browsed the options on screen? Check the options on the Miscellaneous tab. The Mouselook and Mousemove facilities were added over two years ago, in version 4.84 (July 2012)! If you must enable controllers in P3D, you must use P3D for assignments rather than FSUIPC if you don't want periodic trouble with double assignments when P3D does its automatic thing. Pete

Apologies. I'm afraid that FSUIPC is now so complex, and old (FSUIPC4, the 4th incarnation) has now been continuously developed now for 9 years -- and every update with no extra charge, mind -- that an old man like myself (well over 71 now), who should have stopped years ago, doesn't remember everything all the time and sometimes makes mistakes. But I do try and make up for it. Believe me, there are plenty of bug reports here which the reporter "definitely shows is caused by FSUIPC" which are nothing of the kind and in fact are mostly shown not to be later on. Problems which come and go with FSUIPC's presence are often much more complex than you'd think, what with the resulting different memory arrangements plus so many applications, be they inside and outside FS, using it when it is detected. Apologies again, and do have a very Happy Christmas! Pete

That just means you have them assigned to more than one thing, in different places. Most likely is that you are trying to assign in FSUIPC without disabling controllers in FS. Either do all assignments in FS, or all in FSUIPC. It doesn't matter where you do them, just only in one place! You can calibrate in FSUIPC, if you wish, no matter where you assign them. If you assign in FS you simply select the reverse option there to reverse the direction. If you calibrate in FSUIPC the reverse is the REV option. But don't reverse in both places or they will cancel out. And calibrate AFTER selecting reverse, not before! There is a User Guide supplied with FSUIPC, in the FSUIPC documents folder. Take a look sometime, it will help. Pete

The Forum is accessible through the same Steam app you used to download / install / start FSX-SE. Check the right-hand side. For registry editing, use Windows Start - Run. Type Regedit <ENTER> and you'll get an Explorer-type window where you can open up HKEY_LOCAL_MACHINE, then SOFTWARE ... and so on. When you find the entry above, just make sure it is highlighted and hit Delete. Pete