Pete Dowson

There is only one current version (3.30) though obviously products are packed with whatever version is current at that time. There is no "full" version as distinct from a "partial" version. The difference you may be thinking of is whether it is user-registered (for which you pay) or not. A user registered installation gives you full access to all the facilities described in the User Guide and the advanced user's documentation, whereas any version supplied 'free' with a product, including PSS aircraft, merely gives access for that product. Yes, PSS aircraft are licensed, though I think some of the earlier versions of their gauges may have had errors in how they used their keys. There's been no change whatsoever in the FSUIPC registration system EXCEPT to make it clearer when a failure to register actually occurs. Previous to 3.30 (actually I think the change was in 3.20), sometimes a panel or DLL failed to register correctly with no error message from FSUIPC -- it simply didn't work properly and, worse, slowed the system down by constant retries. All that was tidied up in the more recent releases, and also I think the PSS gauges were fixed. Are you sure you have current versions of their panels? It sounds like what you are seeing is something that didn't work correctly in any case now explicitly telling you ity isn't working. If you want me to tell you more about what is going on, please show me the Log. If it is large, ZIP it up and attach it to an email to me at petedowson@btconnect.com. Regards, Pete

Right, sorry. I do try to explain most of these things in the FSUIPC documentation, which is surely the proper place (compared to here, that is). However, program registration, manually, as you have been forced to do, is not really something thati I was expecting to have to explain so much -- it is really the job of the program author. He could easily build in the key for it all to work automatically. If not, at least it should be explained in the documentation. I fear that in this case the program really was intended to be part of a complete suite, all of which is intended to work with a fully paid-for installation of FSUIPC and WideFS. Really, if you have any complaints at all about this procedure, they should be addressed to the source of the program you are using, not to the author of the interface it uses. There are quite a few add-on aircraft and panels which have such sounds (GPWS for exapmle) built in. I don't think they are all pay ware. Regards, Pete

You either need to pay for FSUIPC so that all programs are automatically registered, or specifically register pmSounds in FSUIPC using the appropriate Freeware Key listed in the Freeware Keys list provided near the top of this forum. I thought I said this already? All questions about the PM programs themselves need to go to PM, sorry. It is not my program. Regards, Pete

Have you entered the freeware key to register it with FSUIPC. I don't think it does this automatically, because most of the PM modules are really designed to operate on other PCs via WideFS. Check the FSUIPC log, see what it says. And make sure you are using FSUIPC version 3.30 (or later). Regards, Pete

I've no idea, I've never used it. But you can easily check, either with FSInterrogate (in the SDK) or using the FSUIPC Monitoring facilities (in the Logging page). I would guess that the regular LLAPBH values (latitude longitude altitude pich bank heading) will stay reprtesenting the correct values, but the instrument values, where separate (e.g. whiskey compass, altimeter reading) will be 'incorrect'. There are failure flags in other offsets and you might expect gauges to take notice of those to decide what to indicate in any case. Regards, Pete

Really unless there's a god reason not to, you should always use the latest official version of FSUIPC, which is 3.30. I notice from the Log you included that you are using a later, interim, test (Beta) version. This is okay if you need it -- maybe you testing ActiveSky's new version or something? (What is the 'older version' with the PSS aircraft?) What I really cannot do is support (e.g. "interpret log files") from older versions, as the code has changed and things may not relate. There are two likely possibilities as far as I can see them -- either your download or install of the PSS aircraft is in some way corrupt or faulty, or there is an update you need to download and install for that aircraft. However, I am rather bemused by the odd-looking logging you got from FSUIPC (and from as recent a version as 3.317 too), so I would be pleased to see the extra logging as I mentioned in my last reply. Maybe it will show more exactly what is going on, and in particular (as far as I'm concerned), possibly show how I can improve this so as to be less confusing. Regards, Pete

PSS aircraft? Using a PMDG gauge? Something looks rather amiss with the installation of one or more of your aircraft, doesn't it? But this: looks like the result of some module or gauge not accessing FSUIPC using the correct (internal) method. "FSUI.DLL" is actually a standard part of FS and is being identified here by mistake, because of the invald access being made. You need to determine which Gauge is screwing things up. All the standard ones used by current PSS and PMDG aircraft are accredited and provide their access key directly. A process of elimination might help -- temporarily renaming each Gauge file to something else, in turn, until the culprit is identified. You can make FSUIPC log details of the modules and gauges it finds. This will make a large log, so just do it the once -- ZIP it up and send it to me at petedowson@btconnect.com if it means nothing to you, don't post it in a message here please. To make this log edit the FSUIPC.INI file before loading FS, adding these lines to the [General] section: Debug=Please LogExtras=2048 Remember to delete these lines after the test run. Regards, Pete

There's a key for Squawkbox in the list of Freeware Keys near the top of this forum. Didn't you look there? Pete

Okay, I can do it, and have done it. For FS2004 only I can set the entire range from 100.0 to 1799.9. 'twill be in the next FSUIPC. Regards, Pete

I don't remember the details in that thread. Was there any conclusion? Was this before I added support for ADF2. The limitation in the range of the ADF controls I am using dates back to FS98 and before. All the way through to and, I think, including FS2002, FS had an upper limit of 1699.9 on the frequency. Whilst that limit does seem to have been removed in FS2004, the current versions of FSUIPC are still using the controls available to me in the older versions, and those still seem to have the lower limit. It looks like, according to brief experiments I've just conducted here, if I use the same method as I now use for ADF2 I should be able to correct this. Look for the fix in the next version of FSUIPC, if I can do it. Let me know if you need an advanced interim copy for tests. Regards, Pete

I think that is better. José Well, if I get time I may look to see if I can call whatever it is to make them take effect, first. If I can't do that I will make them read-only. Thanks, Pete

Er"pfms" is running in the Ipaq, right? How many COM ports does your Ipaq have? COM2 seems a little unlikely!? No, the FS GPS is totally irrelevant. I assure you that, installed in FS2004, and with an otherwise unallocated COM port set, GPSout will be sending NMEA format data out on your selected COM port at the intervals you say. You can get a serial port monitor and prove that to yourself (try portmon from http://www.systeminternals.com). Your question is, what is happening at the Ipaq end? I have an Ipaq 5xxx (don't recall the number), and it comes with a USB cradle. I've absolutely no idea what "COM port" that would be if, indeed, it can emulate a COM port. I think you need to ask folks like the PocketFMS people. Presumably they will know how to set it up? ActiveSynch here seems to be a USB program and seems to own the link to the Ipaq permanently. This seems to be true even if I terminate it. If I go to the Device Manager and check the COM ports I have, there are still only the two at the rear of my PC -- COM1 and COM2. Regards, Pete

I don't have access to 19 separate switches, though -- I suspect some of those are switched together. The switches in FS which could be programmed in FSUIPC's keys or buttons pages to replace the ones in the panels are all represented by individual bits in offset 0D0C. The FSUIPC control "Offset Word Togglebits" can be used to toggle these on and off. Mind you, I'm not sure what "tail lights" are: logo or nav? Regards, Pete

So I should make them read-only? Easy enough. Pete

Since the code handling all that stuff is in your own program, it depends how you program it. If you are just using the static C library I provide in the SDK then your main problem will be to avoid multiple interleaved access to the pointers to your memory-mapped file area, creating a corrupt data block for transfer by FSUIPC_Process. The only place FSUIPC comes into this is when being called by the Windows Messaging system via the SendMessageTimeout call. If you have one thread changing the same memory-mapped file data area that you just passed to FSUIPC for processing, obviously that will get corrupted. You either need to implement semaphore lockouts around the memory-mapped data and pointer access, or open a separate memory-mapped file for each case (i.e. effectively a separate FSUIPC_Open). However, this latter solution creates another problem -- if you always interface to user-registered copies of FSUIPC there is no problem, but there is no way for FSUIPC to grant keyed access instigated from any thread other than the main process thread. (You could probably get around that by creating all the Open's (i.e. memory-mapped files) you need, one for each thread, in the main thread, and take care to use the right one in the right place. But it starts to get very messy). Anyway, since the complete source of everything about the interface to FSUIPC is included in the SDK, I am sure that you can devise a more elegant solution -- probably by funnelling access through the main thread only, or by maintaining separate data areas and swapping them into a single memory-mapped area under semaphore lockout control. The header file FSUIPC_User.h of course. Where else? Code 13 is a data format error, which one would certainly expect with multiple threaded accesses to the same data area. This is really nothing to do with FSUIPC, it is part of the code provided in the SDK. Everything about everything concerning the interface in your program is in the SDK. The question would be better phrased "why should there be?" As it is the "official" Microsoft SDKs which are published are the results of voluntary work by the FS team, they are certainly not a commitment. There never were any before FS2000 in any case -- everything was hacked. That's never stopped any number of add-ons. They don't officially approve of any such methods of interfacing like this. They seem to believe that if it looked approved it would need support, and they cannot afford to support an open-ended never-ending always-extending interface such as FSUIPC's. Regards, Pete

Sorry, I'm confused (again! :wink: ). "Good method to change the plane weight"? How? I thought this was the problem, that changing these things has no effect? Pete

Oh, I see! You actually have two distinct memory-mapped files for transferring the data between the same two processes! Ugh. How inefficient. But, yes, the specific filename doesn't matter, provided it contains the process ID in the right place. I think that even that doesn't matter if it's only ever used with a user registered version of FSUIPC. Ah. There's some routine that needs calling, then, to get the change distributed to the right places in FS. Does this apply to all three weights (30C0, 30C8 and 3BFC)? Does the balance (trim) of the aircraft change? (CG% at 2EF8)? Sorry, I just mapped offsets to things I found, or found by others and notified to me. If some extra processing is then necessary I would need to trace through what happens after you "ok" the dialogue. Regards, Pete

Sorry, I am certainly not the best person to give such advice. I started programming in 1963, so my view of beginner's guides and languages is going to be no use whatsoever. I personally don't like Visual Basic, and it is noticeable that VB programmers in particular seem to have rather more problems with the FSUIPC interface than others -- but that is no doubt because it is viewed as an easier way into programming, and therefore most beginners use it. The trouble starting with something like VB seems then to be that languages llike C or C++ and Delphi (Pascal) look even more complex and unfathomable. So, if anything, yes --- my advice would be to start with C++ for Dummies, or something similar, and go from there. I hope other, more recent beginners, will jump in here with more down to Earth advice! :) Regards, Pete

Sorry. I'm a little lost. I like the fact that you have solved a problem, but is this something I should deal with in the SDK? Best Regards, Pete

No, I am sure that you have that the wrong way round -- it surely converts Key presses to Mouse movements and clicks. No, not with Key2Mouse doing the job. Sorry. If you want to use buttons, program the Keypress from the buttons in FSUIPC and the Mouse clicks in Key2Mouse. Regards, Pete

The data you need is in the AFD files (the ones also read and made by the AFCAD program. The formats are not officially published -- there were useful guidelines for them in the Scenery SDK for FS2000/2002, and I did suss out enough to make a program which produced a Runways database (used for instance in Radar Contact versions 1 and 2, and my own FStarRC), but I've not had time to do this for FS2004 -- the formats have been changed considerably. Regards, Pete

There's no way through FSUIPC, sorry. You really need to generate and refer to a database. Regards, Pete

They'll need normal Windows joystick drivers and Game Controller calibrations then. They are not the PFC controls I am familitar with, which connect to their consoles using a 15-pin D plug or socket. That's the other way around to the PFC system then. The PFC controller in the throttle quadrant is the bit of hardware my PFC driver talks to. The PFC avionics connect to that. It sounds very much like the firm you have purchased this from have made their own controller, presumably in their own avionics stack, and programmed that to also handle the PFC throttle console, possibly with the PFC protocol but also possibly with the Elite or some other proprietary protocol. That may indeed work, losing the avionics stack facility, but only if the throttle console is using the PFC protocol. On some models there's a switch behind the removable 6-lever unit to allow the protocol to be changed. Regards, Pete

You mean you are not connecting the yoke and rudder through the console? If they connect direct to a game port or USB then I really know nothing about them. I only deal with the COM-port connecting PFC gear (or USB-COM port simulation, using a COM driver for the USB). Everything goes through the PFC controller board inside the console. The PFC Avionics stack is not independent, it connects to the rear of the console and gets its power from there too. It is is running standard PFC protocol then you simply need to install both FSUIPC and PFC.DLL into the FS modules folder, and tell the PFC driver it is a COM1 connection. It doesn't search for it, you have to tell it. Regards, Pete

That facility already exists, and has done for a long time now. There is even a utility program kindly provided by Jose Oliveira to edit the FSUIPC.INI file for you (see http://www.schiratti.com/dowson). Please refer to the Advanced User's guide to FSUIPC, check the section headed "Programs: facilities to load and run additional programs". Regards, Pete