Pete Dowson

You add a command by editing the INI file and typing the command on its own line. You seem to have managed to add RunReady commands, so what is so hard about adding DelayReady commands? I don't understand your difficulty. "DelayReady1=10" says, as clearly documented, delay for 10 seconds after loading the RunReady1 program. Isn't that what you want? What's the problem? Pete

The main differences having FSUIPC running are really only the coninuous reading of weather data from SimConnect. That can cause crashes which wouldn't otherwise occur if the weather data or the weather station list files are corrupt. I've known that to occur through bad or interrputed weather downloads. The stationlist is called "wxstationlist.BIN" and is in your User AppData\Roaming\Microsoft\FSX folder. I think if you delete that a new one is created. Otherwise it could be in one of the .WX files associated with flights loaded from the Flight Simulator X Files folder. The only other thing FSUIPC will be doing, assuming of course that there are no applications actually using it, is scanning your devices. Well, that suggests more that it could be some rogue or corrupt device driver. DINPUT is of course Direct Input. Regards Pete

Yes, but they won't be detected in the calibration section unless you actually assign them -- either in P3D or in FSUIPC's axis assignments sections. The calibration section merely calibrates the FS controls which result from assignments, they are nothing to do with detecting specific axes. Your INI file shows that the devices are detected and known: So all you need to do is assign them. Regards, Pete

Sounds like something may be up with the settings then. Did you carry forward your INI file from 4.74 days? A lot has probably changed in two years. If so, can you try renaming it so a default is created? Let me know. If it then works, please paste the older FSUIPC4.INI into a message here and I'll take a look to see how that might happen. Oh,either way please paste the LOG file too (All files are in the FSX Modules folder). Also please tell me what version of Windows you are using. Unfortunately I'm out all day tomorrow so I may not respond so quickly. Regards Pete

There should be no change at all from the previous version. What did you update from? The so-called graying out only stops assignments to non-existent axes -- it needs to actually detect them to assign to them! They are simply inactive till then, obviously. FSUIPC sees exactly the same devices in exactly the same way as FS itself. And it hasn't been changed since FSUIPC4 was first released in 2006. It sounds like your devices are not seen by Windows. Please check Windows game controllers, and see if FS itself sees them. Pete

Next to WideClient.EXE, of course, wherever you put that. There is documentation for WideFS too which you might find useful -- it would be in the original WideFS ZIP you downloaded. Pete

Sorry, what are you searching for? Don't look for "simconnect", I don't know why you are doing that. There are no entries at all in Event Viewer - Windows Logs - Applications? Nothing? Or do you mean no errors at all listed for FSX? If so then something is playing tricks on you, because there's no way you'd get that error message otherwise. That's not true! If it is current it will at least show how far it got. There are certain places which are significant. And the fact that there is a current log means that it isn't that SimConnect problem -- FSUIPC must actually be getting loaded. So it is more likely a hardware or driver problem, causing difficulties in the joystick scan. If so then I can tell you how to ( a ) prove it, and ( b ) get more information. Pete

Without any more details, which you seem reluctant to supply, it is difficuilt to help you. You say "SimConnect only has a problem with FSUIPC", which implies that you have other add-ons using SimConnect. Perhaps you could please list them? Normally, if the message you are getting is the one I think it is (and it isn't easy to tell from what you say), FSUIPC isn't even being loaded, so it cannot possibly cause a problem by the time you get the message. If FSX actually proceeds but then hangs if you allow it to load FSUIPC, then if FSUIPC is actually loaded there will be a LOG file in the FS Modules folder. So please do three things: 1. Provide more information about the actual error initially reported. All you've said so far is "I get a message advising me not to use it.". I need more details than that. Check in the Windows error log, see what errors it details from FSX.EXE. There will be more details there. The error log can be seen by entering "event viewer" in the Start edit field, then selecting Windows Logs -- Application. 2. Look in the FS Modules folder. There will certainly be an FSUIPC4 Install log file. Paste that here. And see if there is an FSUIPC4 Log file. If so, paste that here too. If not, tell me -- that means FSUIPC has never actually been run. 3. Get a SimConnect log file. There's a FAQ subforum thread on how to do that. Paste that here too. Regards Pete

As far as FS and FSUIPC is concerned there's no difference between left and right. It's just one continuum. It can't be a calibration issue if you can reach both extremes of aileron movement, so it sounds like it's your device which is faulty or dirty. Try a switch cleaning spray on the pot. Regards Pete

FSUIPC is downloadable from the Schiratti site, where it has been now for many many years, and here in Download Links. There's no separate "free" and "paid for" versions. They are the same downloads. The only thing you get when you pay for it is a key to unlock the user facilities. That's all SimMarket supplies. You have never needed the key to download it or install it. And nothing else? No information, nothing? No option to continue? Best refer to the FAQ subforum, then, where there's a thread about that. SimMarket doesn't provide FSUIPC. It simply provides a link to the Schiratti site where you can download it, as you can at any time. In fact you are expected to keep it up to date if you want support. It have been updated many times per year for the last 14 years, and ALL of them have been downloadable from the Schiratti site. You found your way here. How did you do that? If you can find your way here how come you can't find out where to get FSUIPC from? Have you ever looked in the documentation at all? Did you read the Installation guide which tells you where things are? Pete

I moved your post to the Support Forum, because you put it into the "User Contributions" sub-forum, where it won't get answered. I think you seriously misunderstand. FSUIPC is not a hardware driver. There's no wiring involved, you just plug you USB device into a USB socket. FSUIPC's "intterface" is for applications and plug-ins needing access to FS's innards. The user facilities do include axis and button assignment facilities, as an alternative to those in FS, and calibration facilities for more accuracy. But it relies on DirectUInput exactly like FS. Pete

Yes.The only thing I see wrong is a corruption in what looks to be a duplicated entry for the "AirbusNewHUD" module, unfortunately just before the FSUIPC4 entry. Looks like some installer or other muckedthe file up, maybe it crashed or something? Using a plain text editor, like Notepad (NOT Wordpad), correct the file by deleting this part, towards the end: Regards Pete

I moved your message to the Support Forum. For some reason you posted TWO identical copies in the Download Links subforum, where it won't get answered. I've deleted the duplicate. 4.91 is the earliest supported release for FSX and P3D. What did you actually 'upgrade' from? Did it give any reason? Did you run it in any case? Are you sure this is not the occasional but annoying SimConnect problem which is covered in the FAQ subforum? You don't need to purchase FSUIPC4 again if you already purchased it. You get lifetime updates (upgrades) free. So why did you pay again? Or are you now moving to FSX from FS9 and therefore changing from FSUIPC3 to FSUIPC4? That isn't an 'upgrade'. They are different products, each with its own price. Pete

Sorry, I don't use Saitek and I am therefore not familiar with SPAD. Why not read up about it on ther site? Pete

I think this must probably be SPAD (http://fstools.weebly.com/), or maybe even LINDA, though I think the latter is probably more for VRInsight devices. Pete

Of course, anything further away than around 10 nm doesn't get displayed and is only processed an infrequent intervals, so I don't think you'll notice any difference really. It's the imaging which really hits performance. Those not in the immediate vcinity only get a max 4 fps also. It'll either be the negative (i.e. -id) or that plus or minus 1. TrafficLook can show the IDs I'm seeing, for comparison. Pete

You should be using Profiles, so you can have different assignments and/or calibrations for different aircraft types. You can, even now, create one Profile specifically for the NGX and change all your settings there. The user guide tells you about Profiles. The reason for disabling controllers in FS is simply that if you assign axes in FSUIPC and any are still assigned in FS, they will conflict. It is possible to unassign them in FS, but it has the habit of occasionally re-assigning them automatically on a re-boot, or especially if the device becomes disconnected. You don't have to assign axes in FSUIPC to allow them to be calibrated in FSUIPC -- the calibration works for FS assigned axes as well. But you don't get all of the assignment options in FS. there are lots of threads and recommendations all over the place about how to do things properly in PMDG aircraft. It certainly is possible with all assignments in FSUIPC -- some will have to be to "FS controls" not "direct to FSUIPC calibration". But I'm afraid I'm not the person to advise on this as I don't have the NGX installed. Regards Pete

Yes, but the important part there is this: "FSUIPC takes action when it sees the ID being written, so make sure the other bits are either written at the same time (same FSUIPC Write), or beforehand." You had them in the wrong order in any case. Really, when using something like C/C++, which is so good with arrays and structures it would be daft to be less efficient than you can be. One call to FSUIPC_Write is all that's neded for a structure or array. If you are using SimConnect to read AI details, why not use it to delete them too? SimConnect's AI ID codes are not the same as those used in FSUIPC. The ID FSUIPC needs it the one from its AI arrays. I think one is the negative of the other, but I'm not certain without delving into code which I've not got time to do at present. Not just opening and closing, but also Process. You should build up a block of Write requests and do one Process. It is extremely inefficient otherwise as you are cauing process switching each time, as well as an excess of messges being queued. You've not been programming long, then? How numbers are represented, whether in binary (1010), hex (A) or decimal (10) or even octal (12) makes absolutely no difference -- in the computer they are all binary. Binary 1010 = hex A = decimal 10 = octal 12. This is a fundamental thing to understand in any programming! You provide whatever representation is easiest to use or understand, depending on the circumstance and how you feel at the time. Use my TrafficLook program to compare the IDs you are seeing with the IDs FSUIPC would supply. Also bear in mind that FSUIPC only handles the nearest 96 ground and 96 airborne traffic, so probably many of those you get from SimConnect may not in fact be known to FSUIPC. Whether the correctly transformed ID will still work for deletion through FSUIPC I really don't know. I've never mixed things. Pete

What? If you don't see the menu, just below the title bar, it isn't my program at all!!! It's ALWAYS had a menu! The menu has "File" and "Help" entries - File providing options to Print the table, show Ground or Airborne traffic, refresh the display or enable auto-refresh mode. The Help merely gives the usual About display. Maybe that dispaly shows SCHEDULED not ACTUAL time, or maybe it is using Local Time not UTC? Pete

Yes, and that is now unsupported. it was superseded by 4.91 as I said. There is no point. FS cannot use more than 4Gb as it is a 32-bit program! The OOM never means you are out of physical memory in any case as Windows is a paged system -- it swaps less-accessed areas out to a page file on disk. Really? You've not looked far then. It is one of the most discussed topics on many Forums. Check the appropriate threads in the AVSIM FSX Forum. You will learn a lot. One of the things to do is turn down some of the sliders in FSX's graphics settings, for instance. There are many causes and many ways of reducing their occurrence. But adding more real memory is not one of them! Pete

Sorry, there are really no other options. The INI file mainly contains recorded data for your setup -- order and size of columns, etc. You can tailor those in the usual Windows way by dragging their borders or headings around in the headers line. Same for the sort order. All that is per standard Windows programs. The menu lets you select whether Ground or Airborne AI are shown. I usually have two instances running, one for each, from their own folder, with them sized to sit nicely next to each other showing only the data I'm interested in. The [Ground] and [Airborne] sections of the INI are created to save your settings when you close them after setting it up as you like. It wasn't really written as an end-user utility, more as a test of the traffic reading facilities in FSUIPC. It dates back at least 10 years.. For really good information I use "SuperTrafficBoard", a commercial program which uses SimConnect (on FSX) directly, and so is capable of displaying ALL traffic at an airport or generally, not just the nearest 96 ground and 96 airborne. Regards Pete

There is no way FSUIPC can cause OOM issues, it is merely reporting them. You have something else going on. You'll need to undertake a series of eliminations of your add-ons and scenery installations. Also if you haven't upgraded since May then you are out of date and using an unsupported version. The earliest currently supported version is 4.91, and there's a 4.911 interim update already released since then. The "disable" button it there to disable it should you need to. When disabled it changes to an enable button to reverse that action. It does what it says. Pete

Oh dear, I shouldn't need to repeat the documentation here. :-( Offset 2900 is 12 bytes long, exactly as documented. It is a structure (or an array) of 3 4-byte values (DWORDs will do), and should be written as one entity of 12 bytes. As for "WHATGOESHERE", do you not see that the FSUIPC_Write command has a BYTE pointer in that position? You simply need to put a pointer to the structure there, and cast it as (BYTE *). If you are managing to read the AI data I would have thought that you'd already discovered you had to point to where you want the data read into. The write is no different, you point to where you want it written out from. They are exactly alike, it is only the direction of travel which changes! For example using arrays: DWORD dwCmd[3]; ... dwCmd[0] = id; dwCmd[1] = 0xFFFF; dwCmd[2] = 0; FSUIPC_Write(0x2900, 12, (BYTE *) dwCmd, &writeResult); ... The command will be sent on the next Process call. If you are new to programming I suspect C/C++ is rather like jumping in the deep end. Did you not consider something simpler first? Regards Pete

Yes, of course it does. That's why I pointed you to offset 2900. Did you not look it up? You can send assorted commands to it, and also delete it. It's written up in black and white. Regards Pete

If the two cards are identical and offer no differences ot Windows it could be that Windows is mixing them up. By default FSUIPC merely goes by the numbers assigned by Windows. It doesn't change them, Windows does. If they have different GUIDs (see the FSUIPC INI file where there's a list of devices) then you would have been okay if you'd used the joy lettering facility. It's listed in the contents of the User Guide. If you have multiple devices it is ALWAYS important to set that facility so that FSUIPC can keep proper track of them. If they gave identical names and GUIDs, or get ASSIGNED guids only when connected, then you will have to make sure they are never unplugged. Regards Pete