Pete Dowson

Yes, I know about them. Are you saying PM doesn't provide any controls for these via its offsets? Have you checked? What about 542A? Well, you can of course use KeySend, but why not use it as it is designed. Why are you trying to bypass things and use 330F etc directly? I don't understand. Pete

It is reserved for use by WideFS for the KeySend facility. It does actually say that in the documentation. How it is used is not documented as it is only ever written by WideServer and read by WideClient. I'm not sure why you are making all this so complicated. How are you programming this hardware? If you can program it to write to offsets, why not write direct to the PM offsets and control PM directly that way? It would be much more efficient! If you can only program the setting of a single bit for each of your switches, make them Virtual Buttons -- set different bits in the offsets starting at 3340. Each bit is recognised in FSUIPC's "Buttons" options and there you can program for PM controls, PM offsets or, yes, if you really want to use keypresses still, KeySends. (But why use keyboard control when direct control is available?). Regards Pete

Sounds pretty awful to me. What's the application? Considering the intended and main use of GPSout (and the best in my opinion) is to feed position to a moving map program on another PC, and that this can best be done via WideFS rather than COM ports, I wouldnt have thought any expansion of direct COM port connections would be worthwhile at all. Regards Pete

Not "selected", but just pressed once to de-select and user options for weather filters -- and only on the Client I should have thought. You don't "select" a button, you "press" it. When you press the button it will change the weather filter options, if you've set any, there and then. It is not a "setting" at all. You are mixing up ACTIONS caused by BUTTONS with SELECTIONS operated by checkboxes and radio-buttons. There is no selection being made to be saved. Those are BUTTONS not checkboxes! When you press them it merely selects or deselects assorted options in all the weather Tabs (assuming you have a Registered version -- if not you won't see those Tabs). The buttons do not show any particular selection, and the only meaning of your statement ""Default settings" button is selected" is that it is the first Windows sees when the dialogue appears, and is the one "pressed" if you use the Space bar (assuming you don't use a mouse). Tab steps to the next element in the dialogue, and so on. None of this is unique to FSUIPC dialogues, it applies to ALL dialogues, as it is a function of Windows. In any case, all the "default" and "minimum" weather buttons do is switch some of FSUIPC's weather filters off or on -- as documented. I don't know what source of weather you are using, but if it is FSX's own weather, or downloaded weather, then none of those options have any effect whatsoever, in any case, unless you enable that option in the Miscellaneous tab. I suspect the only reason WidevieW instructs you to use the "minimum weather" option is for the WidevieW CLIENT(s) only, so that the weather it is trying to copy from the Server PC isn't altered by options in FSUIPC. None of the options in FSUIPC can be responsible for WidevieW failing to copy any weather at all. You'll need to go to WidevieW support for that. Regards Pete

Correct, that looks fine. We'll just have to wait upon the OSP author, then. Regards Pete

Really? Sorry, not noticed. The only ones I may have listed are those whose author asks for an Access Key. Checking my list I seem to have nothing with "OSP" in, nor "Offline", but I do have listed these two, from way back in 2003, for BAV: "bavschedule", BAV Schedules, Ferry van Aesch, UZE6VA62LRZK "bavschedule_np", BAV Schedules, Ferry van Aesch, 3GRAONR1HVZI Of course, just because I've been asked for, and provided, an access key (not needed since 3.71) doesn't mean I know anything at all about the program or what it does. Well, rather than simply "chuck it back" I think it would be better to try to encourage whoever has written and knows what OSP is doing to contact me to discuss what it can possibly be doing which is producing the difference in results. Seeing that it identifies FS2004 correctly ("when it starts up the information in the Flight Monitor Window shows [FS2004 FSUIPC3.719]"), but not FSX ("[unknown2 FSUIPC4.07]"), Maybe it is just something very simply, like it isn't recognising the code for FSX and so gives up with a misleading message. However, you did also say that "When I first ran FSX in early December the OSP worked fine", so I don't see how that can be it. You then said: "the ONLY change I had made was to change my anti-virus software (from AVG to Avast)" .... so are you actually sure FSUIPC4 is running? Is there an Add-Ons menu with FSUIPC listed? Have you checked the FSUIPC4.LOG file to see if there's any errors listed? You also said "I reinstalled FSX on my brand new machine" .. did you also check that FSUIPC4 was actually running okay? Possibly you forgot to turn WinXP's firewall off or at least enable FSX? I'm not sure how a possible SimConnect block could cause OSP to report that another monitoring service was running (that certainly doesn't seem logical at all), but it probably needs checking, nevertheless. Regards Pete

Those are not messages from anything of mine, and I am afraid I have no idea what they mean. You need to talk to whoever wrote the program you are using to ask them what they actually mean -- in other words, what are they checking and finding wrong? I don't see any point in that -- all you are doing by deleting that is losing all your settings and making FSDUIPC revert to defaults. I'm afraid I don't even know what "OSP" is or stands for at all, and I therefore have no idea what its messages mean. Possibly there's some difference in FSX which it doesn't like or understand, and possibly it is something I should "fix" in FSUIPC4, but without information about the program, whatever it is and whatever it is finding wanting, I cannot really proceed. If you can find the author and get him to talk to me about it I am sure it could be resolved, but nothing can be done without more information I'm afraid. Regards Pete

The latest is available in the Announcement above called "Other Downloads", but, for a full release pack first, always go to http://www.schiratti.com/dowson , where it has been provided now for over 7 years. Pete

FSUIPC4 reads AI data from SimConnect. If SimConnect does not classify the traffic which VoxATC injects as "AI aircraft" then FSUIPC cannot see it. I've no idea whether the AI aircraft SimConnect tells me about have flight plans or not, although if they do not have flight plans, even merely saying "A to B", how on Earth are they being flown? FSUIPC does not see ground vehicles, ships or ferries, because it doesn't ask for information on these. Even the ferries follow "flight plans", though the others may not. I don't know. Perhaps you could ask the VoxATC author exactly what these "AI" aircraft are that it creates and how they get from place to place with no plans. He evidently has dug into the depths of FSX more than I. FSUIPC4 uses the facilities Microsoft provided via SimConnect. If this is important, please ask him to contact me to discuss it. Regards Pete

I don't remember it well, but wasn't "Real ATC" merely a lot of pre-recorded ATC stuff played as adventures? It certainly wasn't an FSUIPC program, and support for Adventures using the old adventure programming lanuage (APL) was discontinued by Microsoft a long time ago -- 5 years ago, in FS2002, I think. As for AETI Pro flight In Command, I don't know that one at all, but it sounds like it is adventure based too. Don't you have any documentation for any of this antique stuff? I'm sure it would say if it needed FSUIPC, and whether it needs installing IN FS, in which case it almost certainly will NOT be compatible with any other version, or is simply run as an external program. Many add-ons for FS98 were updated for FS2000, and the same from FS2000 to FS2002 and FS2002 to FS2004, but jumping from FS2000 all the way to FSX it seems most unlikely that anything would transfer at all, and even those things that would work are probably not worth it, as the FS technology and capabilities are so far in advance now. Why not try flying FSX for a while, investigate the lessons and the missions, see how far it has all come on since FS2000 days. I think you'll find most things you were adding in FS2000 are either already there now, and in a much improved way, as well a new things like the built-in ATC, other aircraft and ground vehicles, and excellent weather capabilities. Regards Pete

Thanks for the files. Please update your copy of FSUIPC -- you are NOT using 3.71 but 3.70 as clearly shown in the Log ********* FSUIPC, Version 3.70 by Pete Dowson ********* Running inside FS2004 (FS9.1 CONTROLS.DLL, FS9.1 WEATHER.DLL) There's a later one (3.719c) available in the Other Downloads Announcement above, too. That will be released as 3.72 next week. As long as you are using Win2000, or XP, or Vista I recommend you keep up to date. If you are still using an old Windows system (WinMe or 98 ) then you cannot update beyond 3.71. I cannot support old versions. Sorry. Regards Pete

First NEVER split off every single FSUIPC Write into a separate Process. Each time you call FSUIPC_Process you are causing a switch to FS. It is grossly inefficient. The whole point of separating the Read and Write operations from the Process is for efficiency. You build up a list of all the reads and writes you want to do in each of your program's cycles, then send them all to FS in one FSUIPC_Process call! Second, you cannot and must not write to 3210 unless you know that slot is free -- otherwise you could be destroying some other program's ability to capture keys it wants. Please read the documentation. You need to search FROM 3210 to find an empty slot. Best to read the array of 32-bit integers at 3210, then find one which is all zero. That will be free to use. Write a 32-bit integer to it, not a series of single bytes. In your case, for Shift+Z the 32-bit value is hexadecimal &H0000015A, or in decimal (1 x 256) + 90 = 346. That's the initialisation. In your code you seem to think you can write the request then immediately read it back to detect the key press, but how is that going to work? There's zero possibility of the user being able to press Shift Z in zero time and at the precise instant between you writing the request and immediately reading it back. Later, somewhere else in your program, and once each cycle (say every second or half-second or whatever) you read back the value to see if the key has been pressed yet. Not the "byte at 3213" but the one at 3 + the offset you found and wrote to. Once you've detected the keypress you need to write 0 back to that byte to detect the keypress again. Really, from the code snippet you have posted, it looks as if you aren't a programmer (yet). Is this right? If so I really would suggest getting some practice first doing a different project, as what you want to do here is not something for complete beginners, even using VB. I am not familiar with VB so I cannot even do it for you, but possibly some other VB programmers visiting will be able to help you further. Regards Pete

No, certainly not! How could it be possible to store an altitude in feet in only one bit? One bit can only represent a 0 or a 1. What would that tell you? I'm sorry, but I must have misunderstood your original question. When you said you couldn't find the offset I thought you must have looked at the list of offsets for FSXdidn't you? If not, where were you looking? If you look at the list of offsets, do you not see that the second column shows the number of bytes in the value documented? In this case, because the value is a 32-bit integer, as it says, it occupies 4 bytes (4 x 8 = 32). If you want to display just one bit (though why you'd want to I don't know) you need to extract that bit using a logical "and" operation, with a Mask. The mask for bit 4 is 2^4 which is 2x2x2x2, which is 16. Well, I'd like to understand how you thought that a number of feet could be displayed by showing one bit? ;-) Where are you looking for offfsets? It is rather worrying that you may be using a source which I cannot keep updated. :-( Regards Pete

Don't be sorry for your English, but please please please find the "Caps Lock" key on your keyboard and use lower case letters as well as capitalisation! If you mean that in FSUIPC4 you go to the Switches and Buttons options but nothing then works, when this has occurred before it has been because there is some bad Joystick Driver installed without the joystick attached. Please check your Windows "Game Controllers" (in the Windows control panel, Start -- Settings) and check for this. You'll either need to uninstall it, or connect the joystick it wants, as it is causing Windows to hang when being asked to read buttons. The only other possibility of that type is a bad mouse driver. Sometimes one older Kensington mouse driver has been known to cause problems like this. Otherwise, I am sorry but I don't know anything about the CPFlight hardware. You may need to direct your questions to their support, or probably Project Magenta. Regards Pete

Didn't you look on the My Traffic forum about this? According to Burkhard Renk, the MyTrafficX author, it must be your error because he says the MyTraffic installation instructions are clear, that you EDIT the "DLL.XML" file if it exists, but COPY it if it doesn't. You must have made that error and copied his DLL.XML file and lost the original. That would lose the installation of ANY and ALL Simconnect add-in DLLs and other facilities, such as those installed from the FSX SDK. The FSUIPC4 installer edits the DLL.XML and saves you the bother, so it is easy to recover FSUIPC4 (less so any others). Just run the FSUIPC4 installer again. While you are at it you might as well update to version 4.07, now available. FS2000? Phew. Well, FSUIPC does provide compatibility all the way back to FS98 for program which USE FSUIPC and don't depend on FS itself. FS Clouds is the opposite. It doesn't use FSUIPC, and it is a replacement set of cloud graphics for a very old version of FS -- certainly needed back then when FS's own clouds weren't so good. But why would you even consider replacing FSX's lovely clouds with older lesser graphics, even if you could? Other things which are related to FS, and not normally to FSUIPC, include add-on scenery and add-on aircraft. Though there are some sophisticated aircraft which use FSUIPC they are mostly dependent upon FS itself for graphics, panels and so on. Regards Pete

Well, I'm sending you FSUIPC 4.071, which has these additions: 0318 4 Pressurisation cabin altitude at present (feet, 32-bit integer) 031C 4 Pressurisation cabin altitude set goal (feet, 32-bit integer) 0320 4 Pressurisation cabin altitude set change rate (feet/sec, 32-bit floating point) 0324 4 Pressurisation cabin pressure differential (lbs/sq.ft, 32-bit floating point): set – actual. 0328 4 Pressurisation dump switch (1 = open, 0 = closed) but I can't see much here working correctly. Where are you looking on that awful FSX 738 overhead? The dials which should record these things don't appear to work. The cabin altitude target (031C) changes by some amount on each INC/DEC control, so that "works", but the cabin altitude sems to simply decrease slowly until, in my case , it reached -89 feet, and never changed even with the dump switch set to open (when it should show the aircraft altitude). Worse, the change rate doesn't appear to change with the correct INC/DEC controls, and the differential is definitely wrong. Please, can you explain what you see working, and where? Or are you just being rather over-expectant of what Microsoft have achieved in the initial FSX release? Regards Pete

No, as you can read in the History document, none at all. In fact there have been very few changes between 4.067 and 4.07 in any case outside of the user facilities. If anything there has been a small improvement in performance according to testers, due to the removal of some constraints originally placed on SimConnect (the third item in the list of changes). Can you quantify what you actually mean by "stutters"? There should be no stutters whatsoever over WideFS. Any such would almost always be due to specific networking difficulties or problems on the clients themselves. Maybe you are trying to drive the clients too fast? What sort of frame rates are recorded in the WideServer and WideClient logs? If you want to try re-imposing constraints on SimConnect, which would possibly slow FS down a little and just possibly make the client look better by comparison ;-) , add "UseEpsilon=Yes" to the [General] section of the FSUIPC4.INI file -- then as far as WideFS is concerned it will become identical to 4.067. This also filters out some of the changes which should allow smoother updating of PM gauges, so it is a double-edged sword. Incidentally, what do you have your frame rate limiter in FSX set to? It should be slightly lower than your average frame rate for best smoothness in FSX, and the same smoothness should then relate to clients. Regards Pete

So they do actually do something in FSX? Which aircraft, the 738 and the Airbus? I'll have to have a look. You should be able to do that now by simply assigning the controls I mentioned appropriately. Regards Pete Many thanks Gilles

In which case either the SimConnect re-install didn't fix everything, or more likely you have some firewall or other security program blocking the SimConnect connection to FSX. Please show me the contents of the FSUIPC4.LOG file which you will find in the Modules folder, and check the FSUIPC Read Me text file and the "FSUIPC4 on FSX and Firewalls" Announcement above. Regards Pete

Is the cabin pressure simulated in FSX? What do you want to do with it? The current version of FSUIP4 for FSX is almost as complete in terms of the data accessible as FSUPC3 was/is for FS2004, but it still isn't 100% there because of some shortfalls in what SimConnect provides. There are some additions, where useful-looking data was working and esily fitted in, but on the whole the main aim of FSUIPC4, in terms of its provisions for add-on applications, was to achieve 100% compatibility with previous versions of FS, mainly FS2004. I would have assumed that new applications, taking advanttage of new features in FSX over and beyond FS2004, would be utilising the interface Microsoft are providing -- i.e. SimConnect. Anyway, looking at the SimConnect list of variables said to be available, I do see these: PRESSURIZATION CABIN ALTITUDE The current altitude of the cabin pressurization.. Feet PRESSURIZATION CABIN ALTITUDE GOAL The set altitude of the cabin pressurization. Feet PRESSURIZATION CABIN ALTITUDE RATE The rate at which cabin pressurization changes. Feet per second PRESSURIZATION PRESSURE DIFFERENTIAL The difference in pressure between the set altitude pressurization and the current pressurization. Pounds per square foot PRESSURIZATION DUMP SWITCH True if the cabin pressurization dump switch is on. Bool There are also these controls for changing things -- These are listed in the assignments drop-downs in FSUIPC4's Keys and Buttons tabs already, and you will also find them in the List of Controls installed with FSUIPC4. PRESSURIZATION_PRESSURE_ALT_INC PRESSURIZATION_PRESSURE_ALT_DEC PRESSURIZATION_CLIMB_RATE_INC PRESSURIZATION_CLIMB_RATE_DEC PRESSURIZATION_PRESSURE_DUMP_SWITCH You can of course send via FSUIPC4 these using the numerical equivalents as listed, via Offset 3110. Are these what you need? Do they work? Can you tell me anything about what you want to do so I can understand what needs providing? There are many, many new variables listed in the SimConnect documentation, and I really wouldn't know what to do with most of the new ones, nor whether they work or have any use. I can fairly easily add access to these via new offsets in FSUIPC4 if they are wanted, but I really think I should do this on the basis of need rather than add them all just because they are there. There could be a performance impact, and maintaining values which no one ever use and which may not even work is pointless. So, before adding anything new I'd like the details of what is needed explained, and why, with any details I may need for writing them up in the Offsets Guide documentation. If you do this, I will certainly look at adding the data to the next FSUIPC4 release. Unfortunately I am on holiday from the end of next week for just over two weeks, so there could be a delay, though I may be able to slip them into an earlier interim version for you to test. Regards Pete

You evidently did not look in ths Forum!!! ALL interim updates and many other things are downloadable through the Announcements above, at the top of this Forum. Please ALWAYS read the announcements. That is the way I inform users about updates and bugs and supply fixes. Also please read the messages in the threads you add to before adding another message -- you evidently didn't read my last message telling you about 4.07 at all! :-( Regards Pete

No. FSUIPC3 is for FS2004 and before. FSUIPC4 is for FSX and later. They are totally different programs. If you buy both, buy the FSUIPC3 version first as you can then claim a discount on FSUIPC4. Regards Pete

There should be no relationship between the registration of FSUIPC and the way PFC works -- there's no such thing as a registration for PFC in any case. Please do a complete run, with your Key in place -- start up FS, get the problem, close down FS. Then ZIP up the FSUIPC.LOG, PFC.LOG and FSUIPC.KEY files, together, and send them to me at petedowson@btconnect.com. I'll get to them in the morning (it is 3:40 am here and I'm about to go to bed! ;-) ). Regards Pete

No, sorry. that won't work. The substring is something that must occur, as it is, someplace within the aircraft name. The substring you are giving occurs in none of them. Currently the only way to do what you want to do is to edit the names in each of the Aircraft.CFG files, adding, say, "Helo" to the end, then use that as the substring. I may consider allowing multiple substrings, but it is far from trivial code and I won't be able to do it till later, maybe in March. Please write again then if you think it is still important. I think, but I can't be 100% without re-checking (and, sorry, I don't have time just now), that it would be okay PROVIDED that the longer named section occurred earlier in the INI file -- in other words, it should select the first one which matches. Regards Pete

Please see the "Other Downloads" Announcement and try 3.719. Since uploading 3.719 I've also obtained evidence to show that, with some aircraft, accessing the HSI variables (specifically "HSI Distance") can certainly crash FS9. This is despite using the 'correct' SIM1.DLL procedure calls to obtain them. These variables were added in 3.705 and they are, in fact, at the end of a long list which are obtained on every FS frame using the same method -- none of the others have ever caused any crashes. I am working out a way of protecting FSUIPC against these accesses when they might lead to an error, but it isn't easy for values accessed procedurally. All my direct accesses into FS memory are simply protected by memory access checks, but I've never tracked these values down to an actual data structure. Best Regards Pete