Pete Dowson

We never did get to the bottom of your problem in Registering FSUIPC4, but please now download version 4.25, from the FSX Downloads Announcement above. The Installer is now responsible for handling the registration, so hopefully it will have the necessary privileges. It certainly managed to do everything else correctly on your Vista system. Let me know please. Regards Pete

And did you insert the path to FSX where it says to? Check that you got it right. SimConnect won't give any log at all if it doesn't manage to create the file, and if the file path provided is invalid, it cannot. If you got the file correct SimConnect cannot fail to create a log file, as many folks before you can attest to. Regards Pete

Well, if your dwResult is where the stuff you are reading is supposed to end up, that will certainly give strange results. However, are you sure "dwResult" is not simply an error code, returned when the function fails for some reason? At least, it is certainly like that in the C/C++ version of the interface. As I said, I don't know C# at all. There is no "token" or "FSUIPC_Get" in the C/C++ interface, so I assume that's something to get around the problems with pointers in a Managed environment. Are you sure the result isn't returned somewhere else than the dwResult you are using? Well, that would certainly happen if my suppositions above are correct. If I were you I'd either change to C or C++, or see if you can find some examples or documentation for C#. Isn't there an example in the FSUIPC SDK? I'm sure someone contributed something on that. There's also an improved C# interface in the client DLL offered in the sticky entitled "FSUIPC Client DLL for .NET - Release Version 1.3", above. Why don't you look at that? Regards Pete

The default value is what I think is the most reasonable, smoothing the wind enough to avoid any problems, but not stopping it changing so much that it is never what it should be. This may be a symptom of exactly the faults in FSX which folks were complaining about and for which I added the smoothing. Sorry, I don't know. but generally, in my experience and at least in Europe, the problems mostly occur with disparate weather at nearby stations, OR when you are flying at a level close to the boundary with a very different wind layer. If all of your weather stations on all sides, and all of the levels, above and below, show similar winds, and you are getting opposites, I'm afraid I've no idea what is happening. It is something no one else has reported at all. I suggest you ask HiFi Simulations. Maybe you have some ASX settings wrong. Regards Pete

Sorry Thomas, but that's the altimeter reading, not necessarily the aircraft altitude. Regards Pete

Okay. I'm a bit lost with C#. Is that "dwResult" a 64-bit integer? You are correctly reading 8 bytes (which is 64 bits), but it looks like you maybe are only using the first 32-bits, which would be the fraction of a metre in 1/(65536*65536) ths. Also, in the line double acalt = dwResult/ (65536 / 65536); Does your compiler convert the "dResult" to floating point first, before the division? It would need to, but it doesn't seem likely. Finally, you are dividing by 65536 / 65536 which even I can compute in my head as being equal to 1. Why divide by 1? Three possible errors already, in not as many lines? I don't know C# I'm afraid. Maybe it is all good code, but it doesn't look like it! Why not try using FSInterrogate to see what you are really supposed to get? Regards Pete

What are you using to "get the altitude out of FS"? Incidentally, don't you mean "Shift+Z" not "Ctrl+Z"? Take a little look at what you posted. Don't you see that more information is needed here? How do you expect any useful answer? Why are you even posting in this particular forum? Are you referring to something in FSUIPC, or in some gauge or cockpit or what? Pete

Okay. Good. It isn't anything to do with my software then! ;-) Assuming for "PFC" you mean the "PFD" screen, that does certainly sound like a bug in either the PM MCP or GC software. I must admit to never having seen such. But I'll try it -- tomorrow now. Ah, so by "roll back" you mean "twiddle the knob to force the GC to correct itself". And if you left the MCP showing .79 and the PFD showing something different, which speed is the A/T system striving for, the MCP-displayed value or the PFD displayed one? Obviously if it's the PFD displayed one then, since it is the MCP program which is controlling the throttle, it points to a bug in that one, or possibly a mismatch of versions. Okay. I have the same except CDU 393 (an intermediate build said to "fix a major bug" according to the main update page), and PFD 452. You are right, your PFD version is 34 builds out of date -- probably years! I don't think PM support users with such disparate levels. There are bound to be changes which make those conflict with each other! Regards Pete

What smoothing rate have you selected? The default rate of 2 degrees per second would allow 180 degrees over one and a half minutes (90 seconds), obviously. You can slow it down a lot if you want, making it take a very long time to change indeed. Though if you make it too long the wind might never reach the correct target values before you leave that weather zone and come under the influence of another set of weather stations! Anyway, how do you class changes occurring ovr minutes as "wildly shifting winds"? Variance is variable wind direction inposed because that's what the weather report requires. That also suppresses the minor directional changes, very fast ones, you get with turbulence. Not sure why you'd want to suppress either. I thought ASX, like all FSX weather systems, only showed you what the nearest WX station weather report says. If you are in between a number of weather stations with different weather conditions the weather you get might not accord with any of them. This can be very bad when some of the stations report weather at different times to others. Neither. It doesn't give you any weather. The smoothing does what it says, it SMOOTHS changes in FSX so they are not sudden and cause loss of control. It most certainly would be totally unrealistic. Why on Earth would you want to do that? Maybe you need to fly in more deserted areas where the risk of conflicts between different nearby weather station reports would be far less. Regards Pete

I've no idea. Sorry Let me explain. According to the PM CDU / RCDU documentation, the CDU keys used fir those functions are the actual Keyboard Codes as follows: Page Up == PREV PAGE Page Down == NEXT PAGE Return/Enter = EXEC Delete = DEL Backspace = CLR The change in WideClient for the Checklist was specifically to "hot key" those keys. i.e. intercept the Page Up, Page Down, Delete, Backspace and Enter keys, and, if the Checklist is being displayed, to instead manipulate bits in its control offsets in FSUIPC so that it did its job. If the Checklist is not shown, the keys are instead used to manipulate the CDU or RCDU program according to its FSUIPC offsets. The only exception is that if the Backspace key is seen within half a second of the Delete key, or vice versa, the "show Checklist" command is sent to the Checklist's offset. Now the only hardware CDU I have access to is the PFC one, which is basically a little PC with the CDU Keys being its keyboard and the little screen being its video screen. I perhaps mistakenly (?) assumed other hardware implementations would be similar in nature. Is the one you use different? If it is merely a matter of Hot-Keying different keys that is easy to do. Let me know. [LATER} Aaarrrggghhh! I've only just noticed this part of your message. Sorry: How on Earth does it work via a COM port? Is the RCDU program directly controlling the screen and the keypad? How do you get the Checklist showing there? If the keyboard sends signals direct to the RCDU program, I don't know how to intercept them and use them I'm afraid. If this is how such hardware CDUs are implemented I think the only solution will be to ask Enrico for a facility in the CDU/RCDU program to do the same as WideClient when the Checklist is loaded too. [LATER STILL] Oh, I must learn to read these messages more carefully. NOW I notice this: ND? The facility in WideClient is designed to allow the Checklist to be used on the CDU, not the ND. If the CDU is displaying its own details, there's no way I would want to steal any of its keys to drive an ND display in any case. That would be totally wrong. If you are using the ND for the checklist I would say you should be using buttons or switches on your main instrument panel to drive it -- you can program them to operate the Checklist offsets directly, using the appropriate FSUIPC Offset controls as Thomas has documented. Regards Pete

And are both the PFC MCP and PFC Jet Console daisy chained to the same COM/USB port and driven by my PFCFSX, or is the PFC MCP connected direct to the PM MCP and only the Jet Console connected to PFCFSX.DLL? You see it makes a considerable difference as to which piece of software is actually responsible! In my setup the MCP is controlled by PM's MCP software, so I've really not had a great deal of exposure of my own MCP handling in PFCFSX. It was tested very thoroughly in the FS9 version, PFC.DLL. And in any case, version numbers of all the software components being used are still vital. You seem to have forgotten to mention them again. And I still don't understand that -- how do you "roll back" the value of .79 you said was displayed on the speed window on the MCP to .79? That still makes as little sense as last time you stated it and I asked the same question. No, sorry, you seem to have missed pretty much all of my questions. If you could please consider answering the questions maybe I could set up a similar arrangement here and see what is happening. But without knowing about how you have things connected, what version numbers of FSUIPC, PFCFSX, MCP, GC and CDU programs you are using, and how you actually manage to roll back a value of .79 to .79, I can't do anything at all. Sorry. Regards Pete

If you have a 64-bit integer in your compiler's facilities (in VS 2005 C/C++ I can use _int64), then that is easiest. Just take your floating point value for altitude (in metres) and multiply it by 2^32 (i.e. 65536 * 65536), convert it to a 64 bit integer, and write all 8 bytes of it to 0570. Otherwise, yes, you have to deal with the fraction and integral parts separately -- just be careful of the sign (there are places in the world with negative altitude). Regards Pete

I don't use it, but its job is to synchronise any number of copies of FS on separate PCs on a Network so that the outside view can be shown on multiple screens without jeopardising frame rates. That is its purpose. Therefore its main job is to synchronise position and attitude. I don't think it necessarily replicates all the correct gauge values, but as you said, that is what your (other?) program is for. Did you find out what was wrong with your program's writing of the altitude? Did you use the GSUIPC logging? I assume you are writing the altitude to offset 0570 (a 64-bit int with 32 bit fractional part)? Regards Pete

It can only be because the aircraft is moving. As I said, unless you pause it, set it in slew mode or set the simulation rate to zero, the simulation engine in FS is still operating. Things don't stand still. The value you are writing to FSUIPC is wrong, then. Check it with the logging. Regards Pete

No, not unless their FSX version has been written with shared cockpits in mind. There are some add-on FSX aircraft which work fine that way, I'm told, such as those from Eaglesoft. I don't know about Freeware, but Luciano Napolitano's WidevieW program does a good job. Uh? Sorry, I don't understand. The latitude and longitude identify the scenery location. There's no other way it is identified, so how does it "slide"? Of course. I did ask why you thought time, wind and QNH could possibly affect altitude. You still seem to think it is some environmental factor. Why? Sorry, please clarify. You say you write, through FSUIPC, an altitude value, and that the user aircraft in FS goes to the WRONG altitude? I really find that very difficult to believe. Sorry. All those things are very heavily used and so well tested. Regards Pete

But no MCP? You mention all the things not relevant, but not the thing you are asking about? Where is the PM MCP program and are you using PM MCP to drive the PFC MCP directly, or are you using my PFCFSX program? How am I supposed to advise without any relevant information? You should set the target altitude first surely. Then normally LVL CHG, but V/S if you wish. What do you mean by "pilot's instrumentation"? Do you mean the PFD from the PM GC program? The target or the actual? The target should always follow the setting on the MCP. PM's software is responsible for that. And if the MCP already reads .79, how do you "roll it back" to .79. It doesn't make any sense. BTW, for my software it is always vital to quote version numbers. This query sounds almost 100% about PM software (so this is really the wrong place), but PM component version numbers are just as important too. There are PM Forums at http://www.mycockpit.org/forums/forumdi27981&f=99 . Regards Pete

Don't you have the standard Windows header defined before the FSUIPC header? There are many things dependent upon Windows-defined names and APIs. Very little (nothing) is predefined in the compiler for Windows. DWORD is one of the many types defiined for all Windows programs, like BYTE, BOOL, WORD. WPARAM, LPARAM, and so on. These are used in many Windows APIs. How are you trying to write a Windows program without the Windows header being included? Maybe it is just that you are trying to include Windows-dependent parts before declaring the Windows header? Regards Pete

what is this? how can i put the sim in that mode? Thanks! Pause is by using pause control or setting paused in the FSUIPC pause offset. Slew is by setting slew on, or again writing to that FSUIPC offset. Sim Rate 0 is by writing 0 to the Sim Rate offset. Have you never made FS run at 2x or 1/2x normal rate, for example? However, if you are using none of these modes yet still have everything working well except altitude, I think you should find out what you have wrong with that first, don't you? Regards Pete

Let me understand this a bit more. You are trying to have two PCs running FS with both pilots flying the same aircraft? You know that if you move to FSX you have this facility already built into FS? It's called "shared cockpits", and was one of the big selling features of FSX, according to MS, yet few seem to have noticed it! Not sure what weather, time and QNH have to do with an aircraft's altitude. Care to explain a little more? Obviously the QNH will affect the altimeter read-out, but not the actual aircraft altitude. And how are you imposing this onto the receiving copy of FS? Is that running in slew mode, pause mode or simulation rate x 0 mode? If none of those things, I'm not sure it even works as you are constantly fighting the FS simulation engine. None at all, sorry. If the rest works the altitude should be easy. Sounds like you have an error somewhere. Have you checked what you are writing by using the facilities available -- e.g. FSUIPC Logging? And why do you think weather and time have anything to do with it? They most certainly should not! A difference in QNH will affect the altimeter, but not the actual altitude. Regards Pete

Thanks Bill. Better drop me a note so I can tell you where to pick me up! ;-) Regards Pete

Now this is getting confusing. Are you going way back to that message where we talked about the three SimConnect files there and just repeating yourself? If so, do I assume all you meant by this: is merely you repeating what I know you did a few messages back? Why? It is very confusing. I really thought you'd set about trying to do the SimConnect repair, which was the next step I suggested if you look back. The FSX Help Announcement tells you how to do that. Regards Pete

Great! Thanks! Looking all set for a proper User Release then, when I can catch up with the documentation updates;-) Regards Pete

Not directly, no. It needs FSUIPC4 for the FS interface, and the GFdev.dll driver for the Go Flight units. It doesn't depend specifically on a particular version of Windows or FS, or even of FSUIPC, being an ordinary FSUIPC client. Regards Pete

Well, you need the Key generated using the same email address ,that is true. SimMarket could have done that for you but you have to arrange for that to avoid the automatic generation. Send both the old and new registration details (name, email, key) to me at petedowson@btconnect.com and Ill replace one of them -- tell me which one you want to keep. Regards Pete

Deleting just the SimConnect DLL doesn't help, it's the folder(s) which need deleting, otherwise the installer doesn't seem to effect a repair. Regards Pete