Pete Dowson

Since the only thing my "fixer" for FSX does is put the InstallPath or the AppPath parameter into the Registry in the correct place, and that is also exactly what the Flight1 fixer does (assuming you ran it "as administrator"), I don't think it will make any difference. you evidently have something twisted in the Registry which would need sorting out first. Pete

Just add the parameter line also provided in the document you are reading. Why only look at part of the instruction? Here's the whole parameter for Prosim737. I've emphasised the part you didn't read: "We've added support for Active Sky Next. To enable Active Sky Next integration, you will need to make sure that FSUIPC writes its radar data in a file called 'radar.bin' in the ProSim737.exe folder. This is done by adding the following parameter to the [General] section of fsuipc4.ini: ASNwxRadarPath=<path of prosim737.exe>\radar.bin" Pete

How do you do it on the aircraft panel? Only with mouse, or are there key presses? Does the add-on have its own autopilot values, separate to those in FS generally? If not, just use the standard FS controls to Increment and decrement those things. Also, check the User Contributions subforum here to see if anyone else has submitted answers for the add-on aircraft. Pete

Sorry, but i don't know. The GPSout output is standard NMEA format serial data. You have two things to investigate -- first, does JeppFD accept standard NMEA data, and if so which sentences (you can select the sentences to be sent in FSUIPC), and secondly, how does the serial data get out from the PC into your iPad? You'd need some sort of serial connection ro a USB connect which looks like a serial port on the PC. Pete

You'd need to have your Lua on the Client. If your button is on a device on the server, in the client Lua just act on the relevant button bit (offsets 03C0 - 03FF). Use event.offsetmask. Pete

For FS9 you should certainly NOT be using the FSUIPC4 document. The correct reference is the one supplied for FS9 and before, the "FSUIPC for Programmers" document! However, in this case the FS9 entries are the same as those in FSX, altough I think the FS9 loadings don't correctly affect the aircraft balance or other weight values correctly until you go into the Payload menu in FS and ok out. There's a note to that effect. I don't understand what you do not find clear in the description. Do you not see, in offset 13FC (actually immediately preceding the Payloads table) the count of actual stations available? Then, from 1400, there are that number of 48-byte entries, structured precisely as described -- i.e. each entry has 4 double floating point values (= 64-bit floats) and a 16 character name. 4x8 + 16 = 48. What isn't clear? Of course it is all read-only except for the weight values, the first double in each table entry. You can't move or rename the payload positions. Pete

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