Pete Dowson

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

So, there's nothing to tell us why it doesn't work when it doesn't! The log shows it is okay. One of the programs you have removed is obviously conflicting with it. Have you found out which one? I really think this is not getting anywhere like this. Comparing a log with a working program on one PC with a log from the same working program on another PC is not very fruitful. It works, great! If you still have a problem to solve I think it is really now a matter for Markus to help you with, and possibly the author of whichever program it is which afflicts the ACARS program when it is running. Regards Pete

I tested the re-direction problem you had when using the older version (4.05) but with version 4.06 and I could prove that it was actually fixed, so you would have been okay with that. I'm not sure where you got 4.05 from -- it was only available for a week or so in November, being withdrawn when 4.06 was released in November, too. In version 4.07, now available above, there is an option offered at the end of the eventually successful Install process to correct the Registry entry for you, in the case where you had to find the right place during the install. You might want to take advantage of this when installing 4.07, as it will certainly save you getting problems with future add-ons. Regards Pete

What language or program is that from? Have you asked the author of whatever it is you are using? I don't recognise it at all. Sorry. I would assume that the parameters inside the () are the offset (0x0D0C for lights), the size (2 for 2 bytes, or 2 x 8 = 16 bits), and then the value to be written. Unfortunately all the lights are represented by separate bits in the same 2 byte section, so you need a facility to AND bits out and OR bits in, otherwise you'd be switch all of the lights all of the time. I've no idea if whatever it is you are using supports such facilities. Is there no support place for the program or hardware you are using for this, or a manual or something telling you more about it? Regards Pete

Seems the FSX installation is very prone to going wrong. Please see the FSX Help announcement at the top of this Forum for re-installing SimConnect. Regards Pete

No. I don't understand. are you saying that the program now works without the other add-ons? Which one is conflicting then? Unfortunately the log is a continued log. Why? The earlier reads being logged here don't correspond with those Markus shows as being used by the ACARS program. You appear to have some other program reading a batch of stuff every 5 seconds, thus: 105953 READ0 3364, 1 bytes: 00 105953 READ0 3365, 1 bytes: 00 105953 READ0 0264, 2 bytes: 00 00 105953 READ0 0560, 8 bytes: 00 00 52 BD 31 6E 50 00 105953 READ0 0568, 8 bytes: 00 00 DE 51 28 82 06 A9 105953 READ0 0570, 8 bytes: 00 00 73 EC 83 00 00 00 105953 READ0 0D50, 8 bytes: C0 19 B7 D8 B1 75 50 00 105953 READ0 0D60, 8 bytes: D2 4D 62 10 D3 00 00 00 105953 READ0 0D58, 8 bytes: 00 54 55 55 F5 44 06 A9 105953 READ0 3122, 1 bytes: 80 105953 READ0 8330, 2 bytes: 80 01 105953 READ0 034E, 2 bytes: 95 22 None of that relates to anything Markus's program is doing, according to his logs. What other program or DLL or Gauge are you still running? Later in your log: 167922 READ0 3304, 4 bytes: 00 00 10 37 167922 READ0 3308, 4 bytes: 07 00 DE FA 167922 WRITE0 (failed, read-only!) 330A, 2 bytes: EC 03 This is the part corresponding to the Open, occurring a good minute after you stopped and restarted logging (I'm still none the wiser why you are doing that). Then, these batches: 169062 READ0 0238, 1 bytes: 10 169062 READ0 0239, 1 bytes: 00 169062 READ0 0366, 2 bytes: 01 00 169062 READ0 11C6, 2 bytes: 00 00 169062 READ0 31F0, 4 bytes: 03 00 00 00 169062 READ0 0580, 4 bytes: 58 21 39 00 169062 READ0 0574, 8 bytes: 83 00 00 00 91 EF B8 FE 169062 READ0 0BC8, 2 bytes: FF 7F 169062 READ0 02B4, 4 bytes: A9 01 00 00 169062 READ0 023B, 1 bytes: 00 169062 READ0 023C, 1 bytes: 00 169062 READ0 0264, 2 bytes: 00 00 169062 READ0 0C1A, 2 bytes: 00 01 169062 READ0 0894, 2 bytes: 01 00 169062 READ0 092C, 2 bytes: 00 00 169062 READ0 09C4, 2 bytes: 00 00 169062 READ0 0A5C, 2 bytes: 00 00 169062 READ0 0AF4, 2 bytes: 00 06 169062 READ0 02B4, 8 bytes: A9 01 00 00 01 00 00 00 169062 READ0 030C, 4 bytes: 00 00 00 00 169062 READ0 31E4, 4 bytes: 0F 23 01 00 169062 READ0 0B74, 4 bytes: 00 00 00 00 169062 READ0 0B78, 4 bytes: 00 00 00 00 169062 READ0 0B7C, 4 bytes: B2 9D 7D 00 169062 READ0 0B80, 4 bytes: 1B 00 00 00 169062 READ0 0B84, 4 bytes: 00 00 00 00 169062 READ0 0B88, 4 bytes: 00 00 00 00 169062 READ0 0B8C, 4 bytes: 00 00 00 00 169062 READ0 0B90, 4 bytes: 00 00 00 00 169062 READ0 0B94, 4 bytes: B2 9D 7D 00 169062 READ0 0B98, 4 bytes: 1B 00 00 00 169062 READ0 0B9C, 4 bytes: 00 00 00 00 169062 READ0 0BA0, 4 bytes: 00 00 00 00 169062 READ0 0BA4, 4 bytes: 00 00 00 00 169062 READ0 0BA8, 4 bytes: 00 00 00 00 correspond okay with those that Markus's log shows. Even the Write to 0262 to release Pause is there. So, what was the problem? Regards Pete

No, there's no need at all. If there's a problem it is not going to be anything to do with any of that. We need to comparewhat you get normally (when it works) to what you get when it doesn't. That is why we need to compare side-by-side your results and your problem user's results. Your part is here. We wait on your user. This part: 114094 READ0 3304, 4 bytes: 00 00 10 37 114094 READ0 3308, 4 bytes: 07 00 DE FA 114094 WRITE0 (failed, read-only!) 330A, 2 bytes: EC 03 is the standard FSUIPC_Open() sequence. After which you appear to do a batch of reads every second: 115203 READ0 0238, 1 bytes: 0E 115203 READ0 0239, 1 bytes: 22 115203 READ0 0366, 2 bytes: 01 00 115203 READ0 11C6, 2 bytes: 00 00 115203 READ0 31F0, 4 bytes: 03 00 00 00 115203 READ0 0580, 4 bytes: 6E E6 38 00 115203 READ0 0574, 8 bytes: 83 00 00 00 3A 4B 1E FE 115203 READ0 0BC8, 2 bytes: FF 7F 115203 READ0 02B4, 4 bytes: 00 00 00 00 115203 READ0 023B, 1 bytes: 16 115203 READ0 023C, 1 bytes: 22 115203 READ0 0264, 2 bytes: 00 00 115203 READ0 0C1A, 2 bytes: 00 01 115203 READ0 0894, 2 bytes: 01 00 115203 READ0 092C, 2 bytes: 00 00 115203 READ0 09C4, 2 bytes: 00 00 115203 READ0 0A5C, 2 bytes: 00 00 115203 READ0 0AF4, 2 bytes: 00 06 115203 READ0 02B4, 8 bytes: 00 00 00 00 00 00 00 00 115203 READ0 030C, 4 bytes: 00 00 00 00 115203 READ0 31E4, 4 bytes: DA 22 01 00 115203 READ0 0B74, 4 bytes: 00 00 00 00 115203 READ0 0B78, 4 bytes: 00 00 00 00 115203 READ0 0B7C, 4 bytes: FD 9F 7D 00 115203 READ0 0B80, 4 bytes: 1B 00 00 00 115203 READ0 0B84, 4 bytes: 00 00 00 00 115203 READ0 0B88, 4 bytes: 00 00 00 00 115203 READ0 0B8C, 4 bytes: 00 00 00 00 115203 READ0 0B90, 4 bytes: 00 00 00 00 115203 READ0 0B94, 4 bytes: FD 9F 7D 00 115203 READ0 0B98, 4 bytes: 1B 00 00 00 115203 READ0 0B9C, 4 bytes: 00 00 00 00 115203 READ0 0BA0, 4 bytes: 00 00 00 00 115203 READ0 0BA4, 4 bytes: 00 00 00 00 115203 READ0 0BA8, 4 bytes: 00 00 00 00 The Write entry for 0262 (ensuring the Sim isn't Paused) is a one off I assume. If we see what your User gets, the problem should become obvious. If he gets nothing, then I'm afraid there's something happening in your program before the FSUIPC_Open() is even reached. I won't be able to help with that, you'll need to consider adding some diagnostics to tell you. Regards Pete