Pete Dowson

That's really even weirder than anything before, because the Loader is so innocuous. It does nothing until SimConnect calls it, and then simpy loads FSUIPC4 like SimConnect would do. Since the loader isn't even logged as being loaded, what on Earth has SimConnect and your video system got against FSUIPC in particular, and not any of the more complex DLLs you say you have no trouble with? Of course there will be no FSUIPC log -- the loader produces no log. I'll leave the option in to use the Loader as it will probably help with the "trust" bug. I'm afraid I have no answer for the "nvidia surround" bug. BTW, I have nVidia with a 3-monitor system here, but it is using the Matrox Triple Head 2 Go which works splendidly. I also have a dual monitor system with nVidia treating both together a one big screen and that works too. I'm not really aware of an "nVidia surround" system., nor why it would be so problematic. Regards Pete

Ah, sorry. My mistake. The facilities I was talking about (and Gypsy Baron too I think) are for FSUIPC4 in FSX or P3D. For FS9 please see the Advanced User's guide, the section entitled "Facilities for multiple INI installations" (it's listed inb the Contents list). You need to choose a name for yourself and add it to the FS CFG file (in your case presumably F339.CFG) as shown. Pete

Any news yet? I'll need to make changes to the Installer if the separate Loader method is needed, and I'm on holiday from Tuesday for 10 days. I'm aiming to release 4.85 tomorrow (Sunday) if possible. Thanks! Pete

Ah, sorry -- to me, one thread, one subject. I didn't even notice change of author. You don't when answering so many threads per day. Anyway, all the answers are now provided for both questions. Regards Pete

That's catered for by having renamed INI, LOG and KEY files. Take a look in the FS9 Modules folder. What FSUIPC files do you see? FSUIPC always uses an INI file and if you didn't rename yours it will have generated another with a name to match your renamed FS9.EXE. All you'd need to do is delete the new one it made and make a renamed copy of your original with the same name. You'll need to do the same with the KEY file too, unless you've already re-registered. Rather than a name like FS339.exe you should realy choose something like FS9fabio.exe - something appended. It will ake for clearer naming of the other files. Pete

I'll try to clarify some of this if I can. But apart from the variety of options FSUIPC provides so so many different aircraft types can be programmed correctly, I'm not sure what you find difficult or confusing. Maybe it is something about the fussiness of the particular aircraft which makes the choice so narrow and therefore more difficult to determine? Doesn't the aircraft work with normal FSX assigned throttle? I can't imagine they'd design an aircraft with FSUIPC dependency built-in. But please note that if you don't actually disable controllers in FSX it is liable to re-assign automatically, especially if one time it thinks the device is newly connected. I'm not sure whay you need to assign the same axis to both throttles there, when you could, as documented, just map the first onto the second in the calibration tab (page 3). Maybe you are using an out-of-date version of FSUIPC which had a problem with the mapping in some configurations? The current version is 4.84, with 4.85 due to be released this weekend. Any throttle lever can be set with a reverse thrust zone if required, though I know many with the Saitek quadrant use the button engaged at the full back position to activate the "throttle decr" control for reverse instead of losing some of the lever movement. Both are documented. The filter attempts to smooth out severe jitters, those caused by a bad power supply rather than dirt. It isn't recommended otherwise because it can affect responsiveness -- not a good idea on a fast aircraft! The exclude options at the bottom are special fiddles needed for some add-ons, and all i can say about those is try it and see -- It depends on the add-on implementation. Regards Pete P.S. You may like to re-post your helpful notes in the "User Contributions" subforum, where it will remain as a reference for others. Messages here scroll out of easy reach quite quickly.

I'm sorry, but the basis of the entire thread arose from you asking about threads. Remember? About this, though: It won't be more than "one instance of FSUIPC". FSUIPC is the DLL running inside FS and there can only be one of those. You just mean FSUIPC open links. And for one process there's only one, no matter how many FSUIPC_Opens you make, UNLESS you change the interface code to alter the name of the Memory Mapped File each time. All you are doing is making multiple uses of the same Memory Mapped File for different loops -- it is only one link to FS. The file name is generated from the Process ID. That is necessary to ensure it is different from those used by other applications running at the same time -- otherwise data from different processes would get mixed up and corrupted.. You'd need to add something different to the name to make more than one. The only reason the data doesn't get mixed up and corrupted in your case with a single thread but separate loops is that the Read and Write access to the Memory cannot occur simultaneously or overlap -- the single thread runs consecutively, no concurrency. Threads, like Processes, are different. But there's absolutely no point. This discussion is really futile. You can't make things run any better, only worse! I don't understand why you persist after all I've explained to you. Regards Pete

If the timer loops were in the same thread there's no problem with sharing the same memory space for the accumulated requests as the Read ad Write requests cannot overlap. You were asking about threads were you not? Pete

If you mean two "FSUIPC_Open" instances, then both will be using the same Memory Mapped File space so you'd run into trouble if both "loops" wre trying to add Read or Write requests at the same time -- they'd corrupt each others data. No, not really any at all. All the Read and Write requests do is add a request to the data. The only call which does anything taking any time is the Process. Not normally, and certainly not compared to the inherent transaction time, that of sending the message, switching processes, processing the message and swapping back again when completed. With most normal data sizes, ranging from a few hundred to a few thousand bytes, there's no data size differences. Anything likely to slow that down will be requests which actually cause some action to be invoked in FS, like saving or loading files or sending weather requests off and waiting for results. You can experiment with data sizes and so on quite easily using FSInterrogate, from the SDK. You can actually select the entire set of offset, nearly 64kb, and have it transfer a short intervals. The main thing then slowing things down is its display updating, not the transfers so much. Regards Pete

You could, but not using the library, because the FSUIPC_Open, will, each time, try to open the same shared memory area. The C source is provided, however, so you can make your own interface code with each thread creating its own memory mapped file with a unique name. I realy don't see the point, though. Why would you want to do such things? The most efficient way of interfacing to FSUIPC, for both your program and for FS performance, is to do a single regular FSUIPC_Process once per period, with that period being at most frequent something similar to the FS frame rate. A single specialised thread doing the FSUIPC operations and storing the data for the other threads is surely the most efficient. I would hope you are not considering each of your threads doing individual FSUIPC_Processes for individual reads or writes? That is extremely inefficient. Remember, each time you call FSUIPC_Process you are forcing Windows to transfer control back and forth between processes, an immense waste of time if done needlessly. Regards Pete

Okay. After you've tried 4.844c, and if it doesn't help, download FSUIPC4_Loader and place the included DLL into the FS Modules folder. Then edit the FSUIPC4 entry in the DLL.XML file to read FSUIPC4_Loader instead of FSUIPC4. If this works I'll change the Installer so that further updates (e.g. 4.85 due this weekend) will not cause the DLL.XML revert to loading FSUIPC4 directly if it sees it already set for FSUIPC4_Loader. This is truly my "last gasp" in trying to solve this, so ... fingers crossed! Regards Pete

The interface from an application process into FSUIPC doesn't care about threads, but when you open the link (FSUIPC_Open) only one shared memory area is used for all of the exchanges. So you either must keep all the Reads and Writes in one thread, or synchronise them so there is no possibility of an overlap. The best thing to do is have a thread running which does all the FSUIPC_Read and FSUIPC_Write actions, with one FSUIPC_Process call per cycle. There's no point in having multiple threads reading and writing separately. Only the Process call actually does anything -- all the Reads and Writes are doing is building the request list in the shared memory area. Regards Pete

There are no other reports of such a problem here, and FSUIPC is most certainly in use with many PMDG 737NGX users. So, it is something specific to your system and I need more information.if I am going to even have a small chance of assisting. * FSUIPC4 log file from the Modules folder. * FSUIPC.INI file from the Modules folder. * Windows error log information showing reason and offset of crash. * DLL.XML and EXE.XML files. You can paste all these into a message here. Let me know if you need help locating them. Regards Pete

Any luck with 4.844c? Pete

Writing that did actually give me one other idea: an FSUIPC4 loader DLL. A small DLL loading in a different place, called "FSUIPC4_Loader.DLL" (say), which you reference in the DLL.XML instead of FSUIPC4 and which itself does then FSUIPC4 loading. If the problem is related to the memry position or size of FSUIPC4 (and I can't think of any other reason for it being singled out for this clash), then this might do the trick. Anyway, before that I had one other slightly less complicated idea. Currently FSUIPC tried to always reside at a fixed offset in FSX process menory. It does this really for ease of debugging, but these days it makes less difference, and I do log its actual offset in any case. I'm wondering if this little difference from most DLLs makes a difference to what happens when SimConnect tries to load it. I'll remove this restriction for you to try -- download version 4.844c. ... It's a bit of a thin straw, but if that doesn't do the trick I'll look at the separate loader DLL method, a slightly thicker one! ;-). Regards Pete

Your settings aren't touched. The installer only replaces the DLL, that's all. No. You are expected to keep up to date as old versions are not supported. Download the current version, the full Installer version, and run it. There are Installation instructions provided inside the ZIP, but it is really no more than that. Pete

Right ... that's realy odd, then. It appears that SimConnect and your video mode are somehow causeig a clash just by virtue of SimConnect starting to load FSUIPC? Sorry I don't think there's anything I can do about that. The DLL.XML way of loading DLLs into FSX is the only way there is. I assume you've tried different video drivers? Is it possible to delay the change to surround mode or isnt' it that switchable? What happens if you've closed FS in Windowed mode so it starts up like that next time? Then just use ALT + ENTER to go to full screen mode afterwards? Regards Pete

Actually it looks like the DLL.XML content has little to do with it, at least in this instance. It is those processes being launched by the EXE.XML which might be responsible. Look: The failed attempt: then nothing more. One of the above three EXE programs is involved. It could not at all involve FSUIPC or even the attempt to load it, because look at the sequence in the successful attempt: Only after that last line is FSUIPC even present. Exactly. You could try renaming your EXE.XML file so it doesn't get used. If that works, then try adding the EXE programs back one at a time. Even if you can't run them automatically via the EXE.XML at least, being separate programs, you can always either start them later -- or even get FSUIPC to load them (but this needs a Registered install of FSUIPC and I see you aren't registered). I've got other evidence that the changes I made in FSUIPC 4.844b do get around the "Trust" verification problems some folks have, so i will be building a new release this weekend -- FSUIPC 4.85. Please rpelace your 4.844b when that is available. Regards Pete

66C0 and 66C2 are 2 bytes apart (66C2 - 66C0 = 2, simple arithmetic). 66C1 and 66C3 are also of course 2 bytes apart. But why start at an odd number like 66C1? It's not what you want, it's what FS provides. Many needles used in FS default gauges only have a max of 255 steps. Some less. Pete

Correct. But make sure you disable controllers completely in FS itself, otherwise next time it sees one connected it will make assignments automatically. The thing which changes when connecting to different ports is the joystick NUMBER, which is the reason for moving away from that to lettering. I'm not totally positive about GUIDs because I don't know when or how they are generated, but if all your devices have different names the GUIDs won't matter. They are really only there to distinguish between devices with the same name. Yes, but you may prefer to choose your own letter assignments to be more suggestive of the device concerned, rather than A, B, C ... etc. Regards Pete

I don't understand how your CFS1 and CFS2 can possibly work without the Modules folder. I have re-checked this by reinstalling them, and both clearly, by default, not only have a Modules folder but one with most of what constitues the simulator's code in it (the usual DLLs). No version of FS or CFS ever needs FSUIPC to run properly, but most certainly all before FSX excepting CFS3, certainly need the Modules folder. (Note "Modules", not "Module") FSUIPC1 and FSUIPC2 were made to support CFS1 and 2 because users requested they do, and it performed the same function for them as it does for the mainstream FS versions. It is nothing to do with them "needing" FSUIPC to operate "properly". I've no idea what you mean by that. No, it would have been Adam Szofran's FS6IPC. For FSW95, the first Windows version of FS it would have been his FS5IPC. The only use of FSUIPC on FS98 was for Logging, and I made that work on FS98 purely so I could ensure compatibility of the Offsets for FS98 applications used with FS2000. But you are misunderstanding the most major use of FSUIPC as it is and has been for many years -- not as an aspplication interface, which has hardly changed at all for many years, but as a more flexible way of interfacing hardware controls and external indicators, and, via the Lua plug-in facilities, of extending the FS capabilities and subsystems. The actual application interface, via the offset provision, for which it was originally designed, has barely changed in many years at all. The only reason FSUIPC3 has reached 3.999s has been for all the other aspects now supported which I assume you are not actually aware of and perhaps don't even use. The naming is not relevant. The only restriction on the version numbering is in its application-readable counterpart, via a 4 byte offset. The convention there only allows 3.nnnX where nnn are decimal and X is alpha. Pete

No, sorry. You need a logbook reader application. Regards Pete

You could probably do that with button flags, but not simple multiple entries for the same button because they would be either/or conditions. The best and easiest way for things like that would be a lua plug-in, with the button action assigned to that Lua. e.g. if ipc.readUW(0x281C) == 1 and ipc.readUW(0x0366) == 1 then ipc.control(2984,0) end[/CODE] Save that as, say, "PMNDoff.lua", in the Modules folder, and assign your button to it. (If FS was running already, press the "reload" button in the assignments tab to get the Lua plug-in recognised). Regards Pete

Good. But only "probably"? If the FSUIPC4.LOG file is actually produced, yes, because it can tell me how far things got. SimConnect logs have to be made especially though, and can be very big, so only those on request -- if you refer back in ths thread I did request this. Regards Pete

Okay. I think this is my last attempt as I can't think of anything else to swap around. I've changed the way it starts up fairly drastically internally -- though provided nothing's wrong you shouldn't notice. So, please download FSUIPC 4.844b and try it. Let me know please. Regards Pete