Pete Dowson

Examples? Is there a vertical mode for it to follow? Compare the values with the position of the horizontal FD bar in a default FS gauge. How do the changes relate? Have you cross-checked what you are reading with the values displayed by FSInterrogate, or the FSUIPC Monitor (Logging page, right hand-side, set type FLT64 for both offsets, display on screen by AdvDisplay checkbox)? Regards, Pete

You just caught me. My next message will certainly not be till Monday (well, late Sunday at best). I'm afraid I have no idea what a "Variant" is. If it isn't a 16-bit integer then it is wrong, because that is certainly what 0B4C contains. I think, usually, VB programmers have to use Integers, which are 32 bit, and so have to set them to zero first (otherwise the high 16-bits could contain rubbish off the heap or stack). I notice you label this as "Fuel" -- you do realise that 0B4C contains the ground altitude, in metres, to the nearest metre, don't you? Please look things up in the table in the Programmers' Guide. BTW, one other thing. It is very inefficient to do "Read" then "Process" if you want to read several values. The reason the two operations are separated is so that you can build up your list of requests via many Reads and even Writes, then transfer them to FSUIPC in one Process call. All the Read and Writes are within your own code, but each Process call means a process switch, which takes a lot more time, relatively. Regards, Pete

So, you are using normal fonts in Windows? And you have no other programs installed which may affect Windows? And you even tried to Restore Windows to a time earlier when things were okay? And then you completely re-installed Windows and FS -- and after all of these things it is still the same? Please confirm. After all, these are amongst the steps I suggested and which you have never answered, yet you say you have done them all! I have absolutely no idea, you must take it up with them -- they are wrong, and in any case it is completely unrelated to your problem. I won't say that again, you ignore me in any case. I will not be able to reply again now until Monday as I am away all weekend at the Blackpool conference (see http://www.ifcblackpool.com). Regards, Pete

Maybe if you showed what you were doing even I could hazard a good guess? But please forgive me. I will not be able to reply again now until Monday -- I am away at the Blackpool flight Sim event (http://www.ifcblackpool.com). Regards, Pete

I'm afraid I'm no good in VB, but hopefully others may jump in. If you scan through the many threads here you will probably come across a few examples as well. Also, please make use of the FSInterrogate program will will find in the SDK. Look at the variables you are interested in, see how they arrive and the conversions they undergo. It is very instructive and you will understand more about what you need to do. Regards, Pete

OOPS! I did it again -- sorry. I edited your message instead of posting my reply. that's twice recently, after never before for two years! Senility is setting in rapidly! Ugh. Anyway, you know what you said, so: This means that they are unverified, and possibly won't be maintained in future FS versions. In general these are items that are currently in the second table in the SDK's "Programmer's Guide" documentation. That second table lists things "discovered by accident", as it describes there. There used to be many many more in this category. Gradually the values they contain have been analysed and understood and used. As a result of this they've been gradually moved from the second table to the first, along with explanations, and thus have become "supported". Entries which are "supported" are those which I will give priority to finding in each successive version of FS. Those which are "not supported" may or may not be found, and take a lower priority in any case. That is what that means. Okay? Possibly, eventually, someone will investigate those values more thoroughly, offer explanations, and actually use them for something significant. If they want them in future FS releases they would then need to give me all that information with their request for ongoing support so I can re-categorise them. This process has been ongoing now for four years or more. You will notice credits listed to many folks who have contributed in this way -- browse through the Programmer's Guide document some time, you'll see what I mean. Regards, Pete

No idea. Do you have examples? Pete

The TCAS_DATA2 stuff isn't used by PM, it was added much later. Sorry, I don't know why pmTCAS doesn't show them -- it certainly should be able to if TrafficLook copes. When you say "all traffic except mine" do you have other MP traffic showing (e.g. inserted by AIBridge from SB2, or from SB3 directly)? If not, maybe it is deliberately restricted to only deal with true AI traffic? As a freeware module it may be restricted. I have TCAS in PM's Boeing ND, but not flying with MP traffic I really don't know if that deals with a mixture either. Maybe they only show one or the other? I can only suggest that you send a question to the PM support address, see if they can help. You might also want to try one of the freeware TCAS gauges for FS, such as Lee Hetherington's ILH_TCAS, see if that does any better. Regards, Pete

I only know of the single aircraft door state listed at offset 3367, and that's for FS2004 only. I'm not doing any more hacking into FS2002 or earlier I'm afraid. Life is too short! :wink: I have no idea how the other doors are implemented. If some clever aircraft designer can work out where in FS these things are handled I could maybe have a look, but there doesn't appear to be anything useful about them in any of the Microsoft documents. I'm very reluctant to start hacking deep through a load of the DLL code when I don't even know how to recognise what I'm looking for, and I've been resisting doing any more hacking because it's late now in FS2004's life and I'd only have to start again with the next version, whenever. Sorry! Regards, Pete

Aha! FSUI is the "User Interface" for FS, and is an essential part of the Microsoft product! Best not to delete things in future unless you really want to get rid of them. However, certainly deleting just FSUIPC.DLL is all you need to do to stop it. Regards, Pete

Only the FSUIPC.DLL matters. The others would be a KEY file, with your registration if you registered (don't delete that unless you want to re-register), an INI file, which simply contains all your settings, options, calibrations -- don't delete that if you don't want to re-enter them all, and a LOG file, which is simply a record of important things happening the last time you ran FSUIPC. You can delete that if you like. The "new" one being 3.48? You need to be specific. Updating consists merely of following the installation instructions in the documentation -- i.e. just copy the new FSUIPC.DLL into the FS Modules folder. Nothing else is ever needed. The later DLL replaces the older DLL, no deletion is needed. When you run FS with FSUIPC installed it will, of course, create a KEY file, ready to hold your registration (and the Keys of any manually-registered gauges and programs and so on), an INI file, containing your options and settings, and a LOG file detailing what happens in that session. This is correct and proper. What does "none of my DLLS (modules) will work" mean? What are your DLLs, specifically? Are you programming your own? If you get "errors booting up FS2004" how do you know your modules won't work? If you can explain things a little more explicitly maybe I could help, but you offer no informatin at all. What version of FSUIPC are you installing? Did you actually delete your registration? What modules do you think don't work, and in what way -- i.e. how can you tell they don't work? And last but certainly not least, what "errors" do you get booting up FS2004? That would be a good start, then we can go on from there -- but I'm afraid it will be a few hours from now as it is getting late here now. :wink: Regards, Pete

Download it from where it tells you right in the first few lines of the FSUIPC User Documentation, thus: Then follow the one step in the simple installation instructions a little later in the same document. It is just for such information that documentation is provided, amongst other things. You may also want to peruse the Announcements at the top of this Forum, especially the one List of current supported versions [25th April 2005], where it tells you where to get my programs on the second line. Regards, Pete

I think we have proved beyond all doubt that it is nothing to do with any DLLs being incorrect versions. I have no idea what inaccurate advice Flight1 might be providing. I really don't have time to go looking at all these sites. Enough to say that whatever they said is wrong according to your interpretation. I said this right at the start and I don't like it that you keep repeating it as if they are right and I am wrong. Take it from me, there is absolutely no reason that a registered version of FSUIPC would be worse than an unregistered UNLESS you are using illegal pirated access Keys! I don't care at all how long you take. But if you keep coming back with more questions WITHOUT answering my own previous ones, I cannot handle that. If you are doing things and getting results and not telling me, then you are on your own and should not expect me to keep helping. You have to be fair. I am trying very hard, and you are not answering. You ignore more than half of what I say, or if you are not ignoring it you answer exactly as if you are. You say you have done ALL the steps. So, you have re-installed Windows and a fresh copy of FS and you still get the same problem? Is that what you are saying? If not, what exactly ARE you saying? You do not need to do that. I do not need you to do that. Both of your copies should be registered in any case if you paid. Just use the same details for both! There are no other ways, for if you have not identified the culprit program then it is a Windows corruption problem. A reinstallation of everything looks to be the only answer as you say you have followed all the other steps and advice I gave you. You cannot expect any more. It is NOT specifically anything to do with PFC. You already saw that the exact same effect applied to FSUIPC's menu. both of those programs use standard Windows functions for their menus. There is nothing clever or special about them. I really do not want to hear from you again unless it is to report on the results of things I advised you to try. There is no point unless you do try these things and report on them. You say you do them and don't tell me, but can't you see that is frustrating for me and a total waste of time? Please go back and review all the advice I've given. I am completely exhausted. Pete

Yes, this is a symptom others have reported but I don't know what the common element is. Does it start off okay and get worse over hours of flying, or is this happening quite quickly? Others who've seen this report that it occurs after a period, and suggest something like a memory leak gradually squeezing Ethernet sockets out of memory and into swap space on disk. Certainly there must be queueing of the Ethernet packets going on somewhere -- determining whether it is in the Server or Client or (most unlikely unless you have a hub or switch with memory) en route is probably the first priority. Do you have other Client PCs, or one which can be temporarily brought in? Also, to see if it is related to the PM OpenGL graphics on the Client, don't run the PM module there but something different, like TrafficLook or FSInterrogate (in the FSUIPC SDK) -- you need to try observing something which you can check against the Server screen. Maybe a local FS PC copy of TrafficLook and a remote one too, comparing their readings for the User Aircraft as you slew or fly. There should be a way of checking for memory leaks too. Try the WinXP performance monitor (Ctrl-Alt-Del, Performance tab). In case it only affects TCP/IP you could also try switching to IPX/SPX in WideFS, though I doubt if that would change this much -- maybe it would take longer to accumulate because the IPX/SPX frames are smaller. Regards, Pete

Does that work with WideFS? I didn't think any RealityXP programs used FSUIPC. Don't they interface directly into FS? AhI should have read further! :shock: It is not actually possible for WideFS itself to generate any delays. If WideServer is unable to run for any reason, all that happens is that values changing while it isn't able to send them are lost. When it gets a chance to send something, it only sends the latest current values. Similarly at the WideClient end -- as soon as it receives values, they are the ones provided to the client applications on their next call. Neither end has any queues, or large buffers, nothing like that at all. If there are any hold-ups you get jerking not delayed reactions. Certainly a delay of 10 to 15 seconds in the Server being able to do anything would result in a 10-15 second pause then an almighty jerk in the application program. However, the Client can only process stuff it receives, so if there are delays then something else is operating the queuing -- and the only possibilities really are the Server network software or hardware, the switch/hub, or whatever, en route, and the Client hardware or Network software. As to what could cause it I have no idea, sorry. There have been one or two folks periodically saying that this has been occurring -- all of them using PM OpenGL graphics (oddly enough?), and almost all on the PM support newsgroup/forum (which is therefore a good place for you to look too I think). A theory I did have was that, since in most instances this delay only seems to build up over a long period of flying -- in some reports 2 hours or more -- it might be down to some memory leak in either PC, but probably the Server (you'd beed two or more clients to tell). However, I think others thought it was related to the OpenGL video drivers in the client. Regards, Pete

If you have lost it please just refer to the "sticky" thread near the top of this Forum on what to do if you lose your key. Pete

Okay, I see. I don't know if you can program things like IPC (Inter Process Communication), which uses Windows features like atoms, memory-mapped files, and message sending, but if you can you should be able to do it. Or perhaps XML can use C library code or VB source? Either way, everything you should need as a programmer to interface to FSUIPC is provided in the FSUIPC SDK, see http://www.schiratti.com/dowson. Regards, Pete

It's somewhere in Microsoft's website. Try http://www.microsoft.com/games/flightsimulator Pete

As my document says, they are only operating when the FS FD is active. Did you enable that? Is the FS MCP set to any vertical of lateral modes? FS cannot give flight direction unless it knows what path you want to fly. Don't forget PM is not necessarily using the FS A/P and FD -- you'd need to check with Enrico to see how to get its own indications. Have you looked through the PM offsets list on the PM site? Regards Pete

I'm sorry, but I'm afraid you would need to explain a little more. What plane? What is "Worldwind"? Is this related to Flight Sim in any way? Where does FSUIPC come into it? Pete

It's not so much the bother, that's not a problem, it is just that I am the worst possible person to try to teach basics. I really don't have enough patience and I reach a point where I can't understand why the other person doesn't understand. From then it just gets frustrating for both parties and everything goes too negative. Just ask my children, they'll remember! :wink: I'd just rather it didn't go that far, see? This thread looked like it was turning into an elementary programming class, and that would end in tears or a row where I'm involved. I know this from experience. Sorry. Regards Pete

I thought that's what you meant, and i thought that's how it could work anyway. I'm sure it is something to do with the names, as I said first of all. How else can the multiplayer select the right model to show? I assume you both have to have both the simple (fast) and complex (slow) models, but each with the other's name. Isn't that what I said in the first place? Maybe I didn't say it very clearly. Just discover how the multiplayer selects the matching aircraft. It must be by some entry in the Aircraft.CFG file surely, even if not the title. Maybe the Multiplayer SDK from Microsoft will tell you? I don't see why. Surely it's just the way the aircraft is identified you need to take care of? Why not look at the MP SDK? I'm sorry, this is all completely out of my subject area, I really know nothing more. It's all guesswork without some reference. Regards, Pete

I've no idea what that "IntToStr" function is (it isn't part of any library I use). However, if you read 2 bytes into a 4 byte integer, you must first take care to zero it -- otherwise any old rubbish will still be left in the two high bytes. A 2-byte value is a "short" or "unsigned short" (also a "WORD") in C/C++. You could declare it as such. But equally you can read it into a 4 byte value like an int provided: (a) you preset the value to zero, to make sure no rubbish is left in the two bytes at the top end which will NOT be read into! (b) you aren't reading a signed value -- if you are then the top two bytes would need to be set to all ones (0xffff), to propagate the sign. All in all you would be much much safer reading values into the correct variable types. If you read a 2-byte signed value into a "short", then it will be correct, and if you needed it as a 4-byte int you could copy it safely, i.e int x; short y; x = y; works fine, and propagates the sign for you. Please try to learn a little more about C/C++ and especially its number representations. You seem to be asking basic programming questions, things any programmer certainly needs to understand in any case. I'd prefer it if, here, you'd ask questions actually about FSUIPC than about basic elementary programming, as I'm not a good teacher at that level at all. The throttle value can be negative as well, for reverse thrust, theoretically even in a prop. You should assume that the value is signed, not unsigned. Regards, Pete

No, it isn't. FSUIPC is free for users to use with accredited freeware programs -- i.e. ones which have keys provided. It is normally free to users of payware programs where the payware authors or publishers have come to a commercial licensing agreement and so have access keys programmed into their products. It is payware for users of all of the extra features, as documented quite clearly. Developers normally have to pay too, because this gives uncluttered access to the interface during development -- allowing debugging and so forth. This applies no matter whether the result is freeware, shareware or payware, or just for private use and not "ware" at all. Consider the payment to register FSUIPC as the developer's "entry fee", fee, to help fund the work carried out on the SDK and also for the developer support you will get. Regards, Pete

Possibly. Did you purchase a user registration key for FSUIPC? You do really need to if you want to undertake software development for it. Regards, Pete