Pete Dowson

Okaythanks! I'll add the link to the Help announcement. Regards Pete

First off, never use FSUIPC_Open() when inside the FS process -- the shared memory area will be shared by all such callers and they'd corrupt each other. Only use FSUIPC_Open2(), and supply the memory area for the exchanges your self. Apart from that, I'm sorry, but I've no idea why you aren't getting the information. I'd need to know more, like: 1. Version of FSUIPC4 (always needed)? If not the very latest (4.435), try that first). 2. Log results? Go to the Logging tab in FSUIPC options -- enable IPC Read logging, get your problem, close FSX, show me the FSUIPC4.LOG file. Regards Pete

Okayfixed in version 4.435, in the Updates announcement now. Thanks for finding this so quickly after 4.433 was released. I wish all the feedback on interim versions was so fast and complete! ;-) Regards Pete

Thanks! I've managed to reproduce the problem and I think I know what it is -- it only occurs when changing the user aircraft before the flight has finished loading to the point you are ready to fly. It looks like the user aircraft ID changes but by the time SimConnect tells me I've already requested data using the original ID. If you only change aircraft in the Aircraft menu, after the flight has loaded, it's okay! So that's a much quicker "work around" than the one you suggested. Normally I never even see the opening screen which you are using. I load all my aircraft and flights and so on using the normal in-flight menus. This is why I never saw this one. Thanks -- I'll get it fixed tomorrow. Look out for another update. Regards Pete

You OPEN the link to connect to FSUIPC. You do as many READs and WRITEs as you want for one cycle, with one PROCESS call to process them, per cycle. When your program finishes you do a CLOSE. That is the sequence. There is no more to it. Your program does not need to know where FSUIPC.DLL is -- it is running inside the FS process. The Open call connects to it using shared memory. You never call anything in FSUIPC.DLL directly. It sounds as if you haven't even downloaded and looked at the FSUIPC SDK, which contains all you need -- including example programs and LIBraries to link to, if you use C/C++. Please go get the SDK if you want to interface to fSUIPC. Regards Pete

Okay. It might be worth trying the latest version, 3.871, from the Updates, as I suggested. There's been quite a lot of work done since last November. However, I suspect that area is mainly one I attended to in the FSX version, FSUIPC4. Are you testing this in FS2004, or an earlier version of FS? It may make a difference! Right -- that's always been how it worked, since FS98 at least. But in my latest copy of the Offsets list, Have you checked 0896 at all? Oh, no, don't worry. I see it gives the same as 0898. I think that is what misled those who told me about these values, since FS98 days. Checking in the FSUIPC4 Offsets, I see this fact was already discovered for FSX, because the RPM Scaler offset includes this comment (in red): (On turboprops this will give the shaft RPM, since there is currently no Gear Reduction Ratio available to fix values on such aircraft. I will fix this when I can) I also remember putting the request in to the FS team for the Ratio to be provided, via SimConnect. I didn't realise the same problem applied to FS9 and before too -- I will have to add the same comment to the documentation. Oh, that's easy enough. You read the AIR file pathname. The CFG file is in the same folder, so just strip of the filename part and append 'aircraft.cfg'. Hmmm. I wonder where the panel gauges get the value from -- or probably they don't need the real value, just the percentage of maximum, which is what the values provided really are? The graphics would be designed with the scaling in mind ... Regards Pete

FSUIPC_Open, as described near wherever you found FSUIPC_Read and FSUIPC_Process. When your program finishes, use FSUIPC_Close. Pete

I'm sure they will apply the current conversion rate from Euros to Dollars when you purchase it. They do convert to GB pounds when I buy things, and they have thousands of US customers, for sure. That's a question for Project Magenta. From SimMarket or from Project Magenta, if they have your details and do bundle it -- though I would have thought in the latter case it would have been part of your original purchase whenever. Pete

Seems odd. I'm sure there are plenty of apps using FSUIPC and getting the correct RPM for their instrumentation without having to use such means. Perhaps it is limited to just that one aircraft? What is "the latest version", then? PLEASE give version numbers! They are not so hard to find, after all. Why the reluctance? Folks have said "latest version" and they meant the latest they've seen -- once that was a year old one! Do you really mean you've gone to the Updates announcement as I asked and downloaded the one from yesterday? And which version of FS? FSX, ESP, FS9, FS2002, FS2000 or what? I can check things for you, but you need to answer my questions, please! Pete

You are attaching this message to one almost 3 years old! What happened in between? Lots of things have changed since then! Please state version number of FSUIPC, and if not the very latest (see Updates Announcement), try that first. Also, state version of FS as well, please. FSUIPC3 works with anything since FS98 except FSX/ESP and CFS3. Pete

Yes, please could you post the fragment of FSUIPC4 log file which you get up till the crash? Just paste it into a message, please. Also, if you have time, could you enable SimConnect logging (see the FSX Help announcement above for instructions) and obtain a SimConnect log leading to the crash? That will probably be quite large, so ZIP it up and email to me at petedowson@btconnect.com. Please include your FSUIPC4.INI file, from the FSX Modules folder too, in case it is some configuration dependent thing -- I'd need to set mine up like yours. Thanks. I'm not sure I understand. Do you mean that effectively you get the same flight, the default flight, loaded twice instead of once? Can you not successfully load aircraft whilst in flight mode, direct from the Aircraft menu? So far I've not managed to create any crash here, no matter what the default flight aircraft is, and I've tried selecting both the PMDG 747X and the Level D 767. But I am using the Aircraft menu to select aircraft, as I normally do, rather than ending a flight. Perhaps I should try that instead? Otherwise if you could give the exact actual sequence you use which guarantees the crash, I'll try exactly that ... Thanks. That should prove very useful. I'll work on this tomorrow (Monday) as I'm tied up this evening. Regards Pete

Yes. some of the [General] parameters won't apply, but they won't do any harm. Certainly, because FSUIPC4 uses DirectInput for Axis Assignment, the axis identities may change. X and Y are always okay, but the others are often assigned slightly differently. But I wouldn't recommend ditching and re-programming. The differences should be quickly determined, if indeed you get any. Actual joystick numbers for USB devices only usually get changed when you unplug them and re-pug them in differently, OR when you change the version of Windows (eg XP to Vista). That sort of thing would affect FSUIP3 and FSUIPC4 alike. To get around that both FSUIPC3 and FSUIPC4 have new facilities in the updated versions these last two months or so to identify joysticks be an assign letter (A-Z) and assign the letters to numbers via the joystick name known to Windows. Details of all that are in the CHANGES documentation in the Updates announcement. Regards Pete

Sounds like a timing problem in SimConnect as none of those FSX-designed add-ons use FSUIPC -- but they are all SimConnect users. There's no interaction with FSUIPC. What updates have you installed into FSX -- SP1 and SP2 or Acceleration? There were quite a few bugs in the original SimConnect, and really I wouldn't trust anything before SP2 for serious use. When you say "every time I loaded any Wilco Aircraft 737, Airbus, Level D 767, and PMDG 744 and MD11 as soon as the program started", can you explain please? what is the DEFAULT aircraft being loaded before you change to one of those others? Are you loading FSX to the selection screen, or does it go direct into flight mode and then you change aircraft? Can you provide any details about the crash at all, please? Like module name reported, and address -- from the details offered by Windows. Regards Pete

4.433. The "AllowSuppressForPFCQuad" parameter will be added to the currently active [JoyStickCalibration ...] section only -- FSUIPC doesn't read inactive sections till they are activated by loading the associated aircraft. If there isn't such a parameter, then as usual you can add one yourself. The warnings will only appear if you have the PFC driver running AND that "suppress possible interference ..." option is set -- if it isn't then there is no need for the warning. The warning is a little extra text next to the affected axes in the appropriate Calibration tab pages -- Throttles and Reversers only (reversers using the FS throttle axes too of course). The reason the suppression is ONLY for throttles is that it is only variations in those which cause autopilot problems for FS -- e.g. the A/T disconnecting. Regards Pete

The name and address (email or street, it doesn't matter) with which you purchased the key identifies you as the owner of they key. There cannot be two different owners, one for WideFS and one for FSUIPC in use at the same time. It does point out in the user guide that you need to use the same details. Active Sky Advanced does not use FSUIPC at all for FSX connection, so any problem you have with that is completely unrelated. You need to deal with HiFi Simulation on that -- probably it needs at least FSX SP1 installed and you haven't updated your installation? Yes. you need to get one of your keys changed to match the name/address for the other. Go to SimMarket and raise a problem ticket and explain to them your mistake and what you wish to do about it. Sorry, ASA is a HiFi Simulation product and it is their job to support it. I do really have enough to do supporting my own programs! I'm sure you understand? Regards Pete

Okay, version 4.433, now available, has these facilities -- the warnings in the Calibrations sections for all throttles and reversers (because that is all it affects), and an extra JoystickCalibration parameter "AllowSuppressForPFCquad" parameter, which can individually override the suppression, even if it is enabled in the PFC driver, for all or specific aircraft. The default is "Yes", so it acts as it did before this version. The same changes apply to 3.871 for FS9 and before. Regards Pete

Aha! An external application -- an .EXE. Sorry, I misread it as you wanting to make a DLL. There's only one version -- the difference in operation is based on their registration unlocking extra USER facilities -- that is facilities for the user to set and change in the FSUIPC options. The facilities offered by FSUIPC to applications, those that you will be using, are not dependent upon user registration -- they work with or without the user paying for FSUIPC. For freeware applications you may also package FSUIPC with your program, though i'd really rather folks downloaded it for themselves so they get the current version. Regards Pete

Duh! I'm getting senile as well as old! :-( The option IS still available, in the PFC driver!!! I don't need really to add anything to FSUIPC -- but I'll carry on now I've started as it makes it possible for FSUIPC to automatically suppress the non-PFC throttle quadrant when switching aircraft. I'll also add a warning "but using PFC" against the throttle, prop and mixture axes in the Calibration tab when the axes are being suppressed. Please, delete those extra logging entries, then run FSX. Go to the PFC options, not the FSUIPC ones, and right there, on the Main tab, UNSELECT the option "Suppress possible interference from Game Port throttle assignments". I'll need to re-word that on the next PFC update, as obviously Game Port isn't the right term these days -- USB wasn't around when I did the first PFC versions. The obtions is not selected by default, and this is why I couldn't repro your problem. I clean forgot about that option and never looked once at the PFC driver! ;-) Please confirm this is the correct diagnosis, at long last! Regards Pete

I've heard of FSSound.dll, but i've never used it and don't know what it does or where it is from. I've never heard of SOARRec.dll I'm afraid, so I've no idea. Since I don't know what they do or where they are from I'm afraid I cannot comment on whether you "also" need FSUIPC. Regards Pete

Good, thanks. Found it. And in fact the crash actually helped, because following the logging which SHOULD have happened I found the one which crashed FSX was in an exception routine which sets out deliberately to suppress other throttles when PFCFSX has detected a throttle quadrant! It's actually not a bug but a facility i incorporated years ago and evidently clean forgot about. It was added into FSUIPC2 many years ago, and was originally optional, but became "compulsory" shortly afterwards after too many folks were getting into trouble. Humble apologies. I shall add a new parameter to the Joystick calibration section(s) of the FSUIPC4.INI file to allow folks to disable this suppression. Provided they then take care to assign a blank quadrant to the relevant aircraft, things should remain perfectly flexible. I shall have to document it in both the PFC and FSUIPC packages. I don't remember which PFC unit you have. Is it the cirrus? If so, it is the mags and fuel selector on that. The PFC controller sends the state of some of those switches even when you don't operate them. It helps keep them in sync, though oddly they don't do that for all latching switches. No need now ... ... I'll add the parameter facility you need and give you further details when the revised FSUIPC4 is ready. Meanwhile, remove those logging lines. You shouldn't need them now. Watch this space! Regards Pete

Ouch! Were there no details of the crash reported by Windows -- module name, address? Yes, that's okay. hex 808 is the same as decimal 2056. It concerns me greatly, that trying to get details of the route followed by your throttle changes actually crashes FSX. That is unexpected, and may be related to the problem you have. Okay. I'll look at that to see what it might show me ... That's the only good way to do it. In other words: 1. Run FSX. 2. Change the axis assignments to suit the test needs. 3. Test. 4. Close FSX (if it doesn't crash!). 5. ZIP up the FSUIPC4.LOG file (also, please, the FSUIPC4.INI file with it -- then I can be sure it is set okay), with an appropriate name for the ZIP. Yes. In actual fact, if the quadrant was interfering I wouldn't expect it to be only the throttle that's affected. After all, there are 6 axes there. Yet you did prove that everything was fine when the PFCFSX module was removed, did you not? On to the log, which I'm afraid never gets as far as showing much of any operation of any axis, be it Mixture, Prop or Throttle. You seem to start the test by using a control to "PAN_DOWN", then operate the Magneto/Starter switch "MAGNETO1_SET" and the fuel selectors "FUEL_SELECTOR_SET", etc. and then again some more "PAN_DOWN"s and a "PAN_LEFT". Are all these operations needed before you try moving the throttle lever? It would simplify things just to move the throttle, nothing else if possible. Anyway, there is one sequence which helps me: 118547 Axis 0Z=-16123: Action=4 (direct to calib) 118547 Direct Axis 4, Ctrl 65765=-16123 : in calibration ... 118547 ###JOY### Event seen, ID=65765 (0x000100E5), Joy=3, value=-16123 (Direct) This is AXIS_THROTTLE_SET. Then it crashed. Which test was this from, do you recall? All the hard work seems to have been done -- it has seen your axis "0Z" change, sent the raw value, -16123 to the calibration routine, and should then calibrate is and send it on...the arbitration with any other axis is long past, so that explains that my correctioon to the code there didn't help/ Best not to do the tests again, yet, till I work out how to stop or detect the cause of the crash. It isn't just the logging selection, as that doesn't cause a crash here ... Later. Pete

I assume you mean an FS plug-in DLL? Can you make a .NET managed DLL which runs inside FS? It would need some sort of wrapper I suspect -- nothing in FS is "managed", it is all native code. The interface to FSUIPC from inside FS, whether from a DLL or Gauge, is different to the external one. Remember to use the correct library, or the code therefrom. It's the one using FSUIPC_Open2. In this version of the interface, you supply the memory space for the data exchanges instead of creating a memory mapped file, which is only needed to share memory between different processes. FSUIPC doesn't need to be user-registered, but if your application is going to be payware you should write to me privately, petedowson@btconnect.com, to agree a commercial license. Regards Pete

Ah, you are well set, then. For those 'bit' operations there must be another parameter, to provide either the bit number (eg 0-7) or the equivalent value (1-128). Right? And also you presumably have to tell it the size/length of the offset (1, 2 or 4, or Byte, Word or Dword?). To press a button or switch on use "set bit", to release it or switch off use "clear bit". That'll provide you with an exact button or switch operation. Start at 3340, with bit 0 (value 1) up to bit 7 (value 128), that's your first 8 switches/buttons, then 3341 -- another 8, and so on. Carry on until you run out of buttons/switches or switch positions (for multiposition ones). No need to "setup" any virtual buttons. Those 288 are always available. Do the above first. When you've done that, go to FSUIPC's Buttons and Switches tab. When you operate your buttons/switches you will see them identified just like any joystick or GoFlight buttons. Go ahead and assign them to do whatever you like - the OHD macro options or anything else. It's all "normal" FSUIPC button assignment from then on. You don't need to edit the INI file unless you are thinking of doing some clever button programming. Just use the option screen provided for the purpose, it is much easier. Regards Pete

Okay. All that happens in the 288 bits starting at offset 3340 is that each bit (binary digit) represents one button or switch. When the bit is 1 that particular button or switch is pressed or on. When it is 0 it is released or off. Because of how PC processors are designed, the 288 bits are, for access, divided into 8-bit bytes. So that is 36 bytes (36 x 8 = 288, right?). Each byte can be addressed by its offset -- 3340 for the first, 3341 for the second, and so on, up to 3363 for the 36th (36 is "24" in hexadecimal, and offset addresses are in hexadecimal: 3340 + 24 = 3364, all in hex). A byte is the smallest unit you can read or write, so to operate a single button/switch, you actually have to READ the byte, change the one bit out of the 8 which you wish to affect, and WRITE the byte back. If the software you are using can do this (they might refer to it a "toggling" or "exclusive or'ing") then you are all set. It may require you to provide a mask -- 1 for the first bit in a byte, 2 for the next, 4 for the next and so on, up to 128 (decimal) for the 8th. Does the utility provide any facility to change an offset other than simply write to it? For instance, doesn't it provide for incrementing a value? Changing bits in a value? A lot of the FSUIPC offsets are bit-oriented, so it should be something the utility's author made allowances for? Regards Pete

and I don't have this chance. you are getting all this support and haven't even paid for your copy of FSUIPC? :-( Everything can be "changed" according to the filters provided. Please read the User Guide sections on clouds, winds, visibility. Also the smoothing for pressure and temperature in the miscellaneous section. I cannot reproduce it all here. You are free to read it even if you have not paid to use it! Regards Pete