Pete Dowson

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

I'm afraid you still misunderstand! :( FSUIPC does not list any keyboard controls. In both the Keys and Buttons tabs you can find a drop-down list of FS controls, plus some additions by FSUIPC for things like Project Magenta and a few otherwise inaccessible operations. The only control which FS provides for the doors is the one I mentioned already to you, which is listed in FS's own Options-Controls-Assignments, as I said, so you can certainly reprogram it there. It does feature in the FSUIPC drop-down as well, as "Toggle aircraft exit" I think. There is really no advantage in using one method over the other. There really is nothing else which can be done. As I thought I carefully explained, the actual selection of the particular exit after using the control is done by the 1, 2, 3... keys, just as it is with the Engine selection and the Pushback direction selection. This is hard-coded into FS. Well, likewise, I hope that if you now re-read my last reply and the above repeated explanation it will be clearer to you. :wink: Regards, Pete

Sorry, I have no idea. You need to check with your suppliers, or PFC. The PFC devices supplied for use with Microsoft Flight Simulator most certainly do work splendidly with Flight Simulator, but PFC also make similar devices for other people who use their own protocols. Isn't "OnTop" a different flight simulator? For PFC FS devices you would install FSUIPC and my PFC.DLL driver, into FS. It takes care of all of the PFC devices that I know about and which use the standard PFC protocol. Regards, Pete

Well the global weather offsets or interface is the same for both FS2002 and FS2004, but you cannot set local weather in FS2002 and global weather doesn't work too well (read "doesn't work for long") in FS2004. Yes, the command is there: #define AW_CLRALL 0x050000 // Clear all weather It is used in WeatherSet.exe (not Weatherset2 which uses the NWI) -- see the menu entries. WeatherSet.exe uses the AWI, WeatherSet2 uses the NWI. This will depend upon the "automatic clear weather" option in FSUIPC -- see the parameter "AutoClearWeather" in the Advanced User's guide. It might be informative to read that section. There's no special order. The FS98 faciliries are limited though, compared to the capabilities of FS2002 and FS2004. They only deal with as much of the weather as was implemented by Microsoft in FS98 days -- i.e. two cloud layers (three if the lowest is a thunderstorm), no rain/snow, limited wind and temperature layers. I couldn't say why your wind, temperature and pressure values aren't setting -- check your work via FSUIPC IPC Write logging (FSUIPC logging page) and also use FSInterrogate and WeatherSet to view the changes. Regards, Pete

Sorry, you are seriously misunderstanding something here. FSUIPC does not "add keypresses". It provides a way of programming them from buttons, though mostly you are better off using the FS controls directly where possible.. The Shift+E combination will be re-programmable in FS -- use Options-Controls-Assignments, scroll down to find "Select Exit", and select something different. Most FS keyboard commands can be re-assigned there. Actually, of course, the RC commands can be reassigned, which is by far your best option. You will need to select something other than the plain 1-9 keys. I use Ctrl+Shift+ number instead. There is no way to re-assign the door selection key (your "2"). Like the Engine selection and Push back direction selection, it seems the way FS is programmed for these is to enter a mode where the program is looking for those keys being pressed (before any other control arrives) then actioning it based on the keycode, not on any re-assignment. I don't think there's any way at all around that. Regards, Pete

This is for FS2000 or FS2002, right? Not FS2004? All the advanced weather facilities are documented in the Advanced Weather Facilities package in the SDK (UIPCAWI.ZIP), which includes the clear weather commands and much more powerful weather commands than the old FS98-compatible ones you are considering. This interface operates with Global Weather only and works in FS2000 and FS2002. It will work to some extent in FS2004, but the localisation of weather takes over, so the results are not wat you might expect (see all the chat about this in this forum and in the FSUIPC documentation). For FS2004 only there is the "New Weather Interface" which is included in the SDK as "New Weather Interface for FS2004.ziip". This is much more sophisticated and allows local weather settings, needed really in FS2004. Please browse through the README.TXT file in the FSUIPC SDK which does mention the basic nature of all these parts of the complete package. Regards, Pete

Surely motion platforms are normally not designed to give the ACTUAL pitch/bank/yaw of the aircraft, but the feedback to the senses of the pilot. The pilot cannot sense ordinary constant velocity except visually, the body senses changes in velocity -- i.e. accelerations. You surely therefore need to read the 6 accelerations (XYZPBH), all available in FSUIPC offsets, and try to produce motions which emulate such accelerations without actually ever needing to achieve the real pitch/bank/yaw of the simulated aircraft. I am in no way an aircraft or motion engineer, but this part seems rather evident. I don't think you want that, you want accelerations only, surely? I think such an approach is seriously flawed. The movement of a joystick and effects on the aircraft are infinitely variable depending on many factors and can never give any realistic effects. This is precisely why the simple way some force feedback joysticks are so unrealistic. The feedback should relate to what the aircraft is doing, not what the control input is doing. Honestly, I think you need to look at acceleration values only. Steady movement is irrelevant, it is the changes that matter, and the six acceleration values give you good measures of those. Regards, Pete

Actually I think it does, but the change from using the standard Windows API to the DirectInput method, which occurred in FS2002, meant that Button controls are only recognised s buttons, Axis controls only as axes and POVs only as POVs. Sorry. It should work assigning any otherwise unwanted axes, but you need to assign them in the FS Options-Controls-Assignments, as well as giving the numbers in the FSUIPC.INI file. FSUIPC doesn't interface to the joystick drivers, it merely "steals" the controls inside FS when they are being sent to the Simulation Engine. The same was true in FS2000 but then it was easy to edit assignments to do whatever you wanted in the FS CFG file. I'll have to try to remember to update the User Guide on this matter. So much to do :wink: Regards, Pete

But he is the programmer. If you ask for the altitude in character format taking 5 gitis he might say, as the programmer, that is daft and he will instead provide is as an integer in 16 bits. I don't think anyone should dictate to him exactly what format to use for anything. Yes, you may list the information you need to access, but the format and therefore the space needed is surely part of the program design. Exactly. He should. But some folks seem to make the mistake nevertheless. Yes, if it is freeware then it can have a free key. That way he only need build one version. He can build the key into the program. Regards, Pete