Pete Dowson

Each byte contains only 8 bits, and can take signed values of -128 to +127 or an unsigned value from 0 to 255. Axis values are usually 16 bits, so need 2 bytes or 16 bits, which would accommodate a range signed -32768 to +32767, or unsigned 0 to 65535.. To split 66C0-66FF into 2 byte values you can only use every other byte: 66C0, 66C2, 66C4 and so on. Please take a look at this FAQ subforum thread: Pete

Oh, it might do. Sorry, I don't know any of the supplied packets except those for C and ASM. The others are contributions from users. And most are very dated now. A gauge runs inside the Sim so it uses a subtlely different interface and a different library (the Module one). Sorry, this is now beyond me. I suggest you look at using the Module users LIB file, or incorporate the raw code directly. I don't think we provide .NET examples as such. I was talking anout Paul Henty's .NET language DLL, which is aimed at making interfacing to FSUIPC much simpler. it also provides many powerful functions. But I think that's only for external programs, not gauges. C++ is one of the .NET supported languages, of course. Is Borland still going? In those days i weas using WatCom. Pete

It looks like you are using the C library provided (FSUIOPC_User.lib). What value is returned in pdwResult. That's supposed to be the error number and should give a clue. // Error numbers #define FSUIPC_ERR_OK 0 #define FSUIPC_ERR_OPEN 1 // Attempt to Open when already Open #define FSUIPC_ERR_NOFS 2 // Cannot link to FSUIPC or WideClient #define FSUIPC_ERR_REGMSG 3 // Failed to Register common message with Windows #define FSUIPC_ERR_ATOM 4 // Failed to create Atom for mapping filename #define FSUIPC_ERR_MAP 5 // Failed to create a file mapping object #define FSUIPC_ERR_VIEW 6 // Failed to open a view to the file map #define FSUIPC_ERR_VERSION 7 // Incorrect version of FSUIPC, or not FSUIPC #define FSUIPC_ERR_WRONGFS 8 // Sim is not version requested #define FSUIPC_ERR_NOTOPEN 9 // Call cannot execute, link not Open #define FSUIPC_ERR_NODATA 10 // Call cannot execute: no requests accumulated #define FSUIPC_ERR_TIMEOUT 11 // IPC timed out all retries #define FSUIPC_ERR_SENDMSG 12 // IPC sendmessage failed all retries #define FSUIPC_ERR_DATA 13 // IPC request contains bad data #define FSUIPC_ERR_RUNNING 14 // Maybe running on WideClient, but FS not running on Server, or wrong FSUIPC #define FSUIPC_ERR_SIZE 15 // Read or Write request cannot be added, memory for Process is full And, additionally, the following data should already be available to you if the Open successed: // Globals accessible from main code extern DWORD FSUIPC_Version; // HIWORD is 1000 x Version Number, minimum 1998 // LOWORD is build letter, with a = 1 etc. For 1998 this must be at least 5 (1998e) extern DWORD FSUIPC_FS_Version; // FS98=1, FS2k=2, CFS2=3. See above. extern DWORD FSUIPC_Lib_Version; // HIWORD is 1000 x version, LOWORD is build letter, a = 1 etc. You might also want to check out Paul Henty's more modern interface for .NET languages -- see his SubForum above. Pete

No idea. i assume it's something in the way PSXT works (which is what? i don't know what either PSXT or RT stand for i'm afraid). Pete

Sync Pos isn't "Slope" -- the latter is the response curve you select, if not linear. Sync positions are recorded in a list against the "SyncSlope..." parameters. If there are none there then your earlier syncing is not interfering with anything as it isn't being done. If it is there are any you can delete them if you no longer need them. From what you say it is something else, and probably related to the way that particular aircraft reads the throttle values. Pete

Without calibrating? Did you go into the calibrations and RESET them? Otherwise FSUIPC is really doing pretty must the same thing. Is the problem the same with default aircraft? If not, then I suspecte that the Phenom 100 is another of those aircraft (like some PMDG ones) which cannot work with FSUIPC's "direct" method, as the atter bypasses the route they use to get the values themselves. what would then happen would be double conflicting inputs, same as if you had them assigned in the sim and in FSUIPC. Take a look in the settings file, the INI file in the Sim's modules folder. I see John has just replied so he has probably mentioned this. Pete

I use ProSim, and the only components which you need to run when the Sim is ready are the main Prosim EXE program, and (possibly) the MCP. All the others will connect fine when things are started and ready. Pete

Well, probably neither really. But if you already have assignments in FSUIPC then they will change. You should enable Joy Letters first (as I mentioned earlier). Pete

Hmmm. Sudden behaviour change could just possibly be registry corruption, but that is unlikely. It sounds more like a dodgy USB connection. Is the quadrant plugged into the yoke using a non-standard plug/socket? If so then the only thing I can think of is to change the latter's connection to the PC -- i.e. another USB socket. If it is a quadrant with its own USB plug, do the same with that. But note that changing USB sockets may change Joystick ID numbers, and therefore your current assignments, so before doing this make sure you enable "Joy Letters" in FSUIPC (a one line parameter in your FSUIPC INI file to enable automatic letter assignment -- change No to Yes). If you are already using letters than you are okay. FSUIPC should be able to match the new details. The other thing is power. If you are using a USB hub it should be a powered one. And also go into Windows' Device Manager and make sure power management is turned off on every USB hub or device listed which has such an option. Pete

This is not really specifically a question about FSUIPC assignment -- the same problem would occur using direct assignment in FSX, and also in the Windows' Game Controller app. It is caused by a bug in the Saitek installation and, because it crops up frequently with Saitek devices, it is the subject of a thread in the "FAQ" (Frequently Asked Questions) subforum. Hhere's a link: Pete

Yes. If FSUIPC has actually been run (whether registered or not) then there should be an FSUIPC.LOG file. I think you may be looking in the wrong place! Maybe you are actually running FS2000 from a different folder, not the one with that Modules subfolder in it. Please show us your FSUIPC Install log in full, not just the last few lines. And also tell us the full path to FS2000 shown in the Properties of the Shortcut you are using to start it. Tne other possibility is that you have FS installed in the Program Files folder of Windows, which is protected. None of the earlier versions of FS like that (such protection occurred long after FS2000 was written). If this might be the case, try running FS2000 "as administrator", or, better, set it to run like that in the Properties-Compatibility menu. Pete

As John says, PM = Private Message. You can send those by clicking on the addressee's name or icon on the left of his message, then selecting "Message" with the button near the top. No. Your WideFS key has the same name exactly and that works. Also the replacement key sent works fine. Use cut and paster on all three parts Pete

Does that mean you also tried Thoms's first suggestion, the one to see if FSX-SE ean okay with "NoWeatherAtAll=Yes" set in the [General] section of the FSUIPC4.INI file? This is important to show once and for all whether it is related to weather corruption in some way. Then we know whether to look elsewhere or not! You should also cettainly try testing without that Weather prtogram running in any case. It may be due to something it is asking FSUIPC to do, after all! Pete

Well the log, which shows a session only yesterday (the 14th) does definitely show that FSX-SE loaded with FSUIPC and did not crash. Everything terminated normally. However, FSUIPC did not progress to the point where it was doing very much. It looks like your default flight (Carenado 690B.FLT) loaded and FSUIPC started reading the weather. How it then managed to proceed to a normal close i can't imagine, but we do know that corrupt weather files can result in corruption inside FSX-SE, and it is probably a result of that. The crash report you showed was merely for " FSUIPC4.dll_unloaded" -- in other words FSUIPC had closed but something in FSX-SE was still trying to call a function in it. You said you deleted the wxstationlist.bin file but nothing about the .WX files which are actually much more likely to be the culprit. It might only be the one associated with your default flight, so try either deleting or renaming Carenado 690B.wx Pete

Is no FSUIPC4.LOG being produced in the FSX-SE Modules folder? Did you look? if there is one, we need to see it. If not, then please use Windows "Event Viewer" to obtain the details of the crash and provide those instead. We cannot help diagnose problems without information. If the crash was not "immediate" I would say it is likely you have a corrupt weather file -- a .WX file in your Flight simulator Documents folder, or possibly the wxstationlist.bin file in the same folder as your FS-SE settings (the AppData folder). deleting both would help in that case. The reason is that FSUIPC reads weather through Simconnect and a corrupt file causes crashes and other errors. FSUIPC 4.974 has been the current version for FSX, FSX-SE and P3D3 for a long time now. Pete

Yes! Each line is concerned with both the start and end of the specific program. I already said this! Why didn't you read what I said? I'll repeat, and with emphasis to show what you should have read! Also PLEASE PLEASE read the documentation section about this. It does say: CLOSE closes the program tidily (if possible) when FS is terminated. KILL forcibly terminates the program, if possible, when FS is terminated. and READY delays loading and running the program until FS is up and ready to fly Why isn't this obvious? Is it a language problem? Please just go and get on with it. Pete

The "KILL" is like "CLOSE" and to do with what to do when P3D closes. If is different from "READY" which is to do when to start it. They are just parameters to tell FSUIPC what to do!!! Please do read the documentation on this! Is isn't at all complicated -- much simpler in fact than ProSim and flying an airliner! I think you should just get on with it. Neither of us should spend all day here Pete

Yes provided you use FSUIPC to start it. Same goes for all other programs you need for P3D. I run all these that way: [Programs] RunIf1=AM=x88,CLOSE,MIN,"E:\REX Sky Force 3D for Prepar3D v4\rexskyforce.exe" RunIF2=AM=x4C,KILL,"E:\mcp\pfcmcp.exe" RunIF3=AM=x3C,READY,CLOSE,"E:\ProSim737\prosim737.exe" RunIF4=AM=x4C,READY,CLOSE,"E:\ProSimMCP\prosimMCP.exe" RunIF5=AM=x48,KILL,"E:\pmsounds\pmSounds.exe" RunIF6=AM=x24,CLOSE,"E:\ProSimAudio\ProsimAudio.exe" RunIF7=AM=xC4,CLOSE,"C:\Program Files (x86)\HiFi\AS_P3Dv4\AS_P3Dv4.exe" RunIF8=AM=x50,CLOSE,"C:\Program Files\AivlaSoft\EFB2\Server\AivlaSoft.Efb.Server.exe" RunIf9=AM=xA0,READY,CLOSE,"C:\Program Files\FSPS LTD\FFTF Dynamic P3Dv4\FFTF Dynamic P3Dv4.exe" RunIf10=AM=x48,READY,CLOSE,"E:\SimSounds\SimSounds.exe RunIf11=CLOSE,"C:\Program Files (x86)\RivaTuner Statistics Server\RTSS.exe" The assorted values for AM= are designed to spread the load across the 8 cores of my 9900K processor (without HT). I use "RunIf" rather than "Run" just in case I re-reun P3D and one of those programs did not actually close from the previous session, even though i tell it to above. Where I use "KILL" instead of "CLOSE" it is because those two programs, unique to my cockpit setup, sometimes get stuck on the close down protocol with the hardware. Pete

Check in the FSUIPC Advanced User's document in your FSUIPC Documents subfolder -- the section entittled "Programs: facilities to load and run additional programs". It is listed in the contents and starts on page 43. Best to use the reference so that you get the format and options set as you desire. The "AM=" parameter, as described in the section I just referred you to! Just assign any EVEN number -- core 0 is the odd bit. If you have HT (hyperthreading) left enabled on your PC, use any number divisible by 4 so avoiding core 0 completely including its other thread. No -- it is best to let P3D use whatever cores it likes. Pete

That's what I would recommend, yes. You might also want to try ProSimMCP on the main PC too -- but either way should work fine. Make sure the Prosim EXE is started after P3D. I run it with a Run parameter in FSUIPC5's INI file, with 'READY' set too so it starts when P3D is ready to fly. I also assign it a core afficinity mask (AM), stopping it running on core 0, which is normally the main one used by P3D. The IP address for the Server needs setting in each ProSim component's config -- if you had them all on the one PC they are probably all set to 127.0.0.1 which just means "this PC". Instead you need the IP address of your main sim PC. Pete

With ProSim v2 I would very strongly recommend you run it on the main Server PC. All other components of ProSim can be on clients, and for the displays and CDUs that is certainly best. But the v2 EXE is now so much dependent on good fast interaction with the P3D system that to have it on a client PC is robbing you of much of the benefit of moving from v1 to v2. I also run ProsimMCP on the main PC, but that is so that it retains good aircraft control even if I, on occasion, 'cheat' and use time acceleration. It's okay on a client up to x2 but x4 and above, forget it. it loses the plot! Pete

Is Prosim running on the Client, or on the main sim PC? If the latter then Prosim has a problem and your only recourse is their support forum. Not sure what you mean by ‘bare’. Rare perhaps? Prosim v2 must be started after P3D. If you are running Prosim on the client then only start it after WideClient is connected or you will get problems, even crashes. You can start it on the Client using RunReady in the client ini. Pete

And how many threads are you going to post identical messages on? Kindly desist!

Thomas outlined the ones in red to show you exactly what to edit, so why try to edit something else? The right-hand side is a readout, a place to scroll through, using the Next and Previous butons, to view your existing assignments. There's a User Guide for FSUIPC in your FSUIPC Documents sub folder which has pictures like the above and explanations. Pete

One of the buttons on your first-connected Saitek Throttle Quadrants is continually signally "pressed" amd "released". I'm not sure which button on the quadrant is number 7 (maybe the one pressed when you pull one of the levers right back). See if you can stop this happening by actually pressing each button (and moving levers) on the quadrant(s). Otherwise the quadrant in question is suspect and needs fixing. For the time being perform your other assignments with the culprit disconnected. Thanks. That was useful to identify joystick device #1, but really your INI file, with your settings, would have been more useful. Generally it is best to supply both. Pete