Pete Dowson

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

The last two only apply to Project Magenta users (which form quite a big part of PFC users) -- one is for the Project Magenta MCP and the other for the CDU/FMS. You can suppress that check screen by a checkbox on the first Option screen. It will only then appear again if the COM port isn't set or isn't available (e.g. it is used by something else, or its driver has failed). You have everything I can possibly offer now, in the previous messages. You still haven't even bothered to check the font size as I asked a long time ago, and there are other suggestions listed in order in my previous messages. Please go and follow those. The final thing, if nothing else works, is Windows and FS re-installation. But try the lesser things first! There's really nothing else I can suggest after those, but why you aren't even bothering to do the simple checks I suggest I cannot understand. It seems as if you completely ignore most of what I write. I am not going to keep repeating it all. Please go back and read them and do them. Regards, Pete

Groan! :-( Each time I send you something it is for you to try! I shouldn't have to send you something and then have you wait until I tell you six times to use it! What's the point of that? We will get nowhere. Please install it. See my other messages. This is going to take months longer unless you actually do something now and then. Pete

It's you that we are trying to help. I cannot make the problem happen and have never seen it except in the three reports I referred you to (over the last two years), and now your own. Unfortunately, if you refer to the other three reports, all I did was suggest COMCTL32.DLL and the sufferers never came back. So I assumed they'd all fixed it. But none actually told us how! In your case, all those versions of COMCTL32.DLL I also have here, and I've tried them all and have not produced the problem. So unless one of them has actually been changed or corrupted without the version number being affected, we've got no further. However, there are still some questions: First, you never told me if you checked your desktop font size and made sure it was set to "normal". Did you do that and forget to tell me? Second, I've been told that Windows "themes" can affect this sort of thing. Can you check, and revert to default Windows settings, no themes, if possible? Third, there are some third party programs, like "Window Blinds", that can mess around with Windows settings, though I've never heard of this being a symptom. See what add-ons you have which may mess with things. Fourth, I am emailing you a COMCTL32.DLL, zipped,. This should be IDENTICAL to one you already have, but it is worth trying as nearly the last resort. If you have already installed the PFC 1.94 I attached earlier, just copy the emailed COMCTL32.DLL into the main FS folder (not the Modules folder) -- that PFC.DLL will pick it up there. Fifth, see if you can roll back to a Windows restore point before this thing started happening. This is by Start-Programs-Accessories-System Tools-System Restore. If you have no suitable restore point saved (unlikely I hope), or even that doesn't do the job, and you've checked all the other things I've just mentioned to no avail, then I can only suggest two steps: re-install Windows, then FS. If I can find any other suggestions in the mean time I will get back to you. Something is corrupt somewhere -- if it isn't in these modules, then it is in Windows settings somehow and re-installation is the only way out that I know of if all else has failed. I know it seems drastic, but you'd be surprised at how many folks religiously re-install every few months as a good way of keeping their system clean and efficient. Regards, Pete

As fast as you can switch processes (because that's what happens every time you call FSUIPC_Process), as long as you don't slow down FS so much you lose the point of such interaction. Each FSUIPC_Process call itself normally takes much less than a millisecond in FSUIPC/FS itself. The rest of the time spent in the FSUIPC_Process call is message queuing, process switching (twice -- to FS and back again) -- plus of course any timeslice that FS uses whilst it has that control you gave it. If you are running on a multi-processor system, or even a Pentium 4 with "hyperthreading", the timeslice bit probably doesn't apply, so you should see a much faster return. HOWEVER, the data you are reading isn't really going to be changing every millisecond, unless you are managing to get FS to run at fantastic frame rates. You should be aiming at matching the frame rate -- and to do that, you could do with FS's frame rate being steady. To get FS to keep a steady frame rate, use its Frame Rate Limiter (Options-Settings-Display-Hardware). Set it to something a bit below the average you normally get. Then time your FSUIPC access cycles to match. e.g. Frame Rate = 20 fps, cycle time = 50 mSecs. Regards Pete

Read the version numbers of all of them please. Pete

surely you cannot be unclear! You already did a search and found several instances of COMCTL32.DLL. All you need to do is run the search again, and this time right-click in the filenames and read the Version data. The search results include the folder details, but it doesn't matter in any case. The search results are in an Explorer window. You don't need to go anywhere else. Just right-click on each one and read the version details, please! Pete

I said: Well, it was difficult to try them all. In Windows 98 very few system programs used COMCTL32, and so after an initial boot, before running anything clever, it was easy enough to change such a DLL in the System folder. In WinXP it seems almost everything uses it, so it is not possible to change it in Windows. It becomes a complex re-booting exercise which I've not figured out yet. So, in order to test the versions of COMCTL32.DLL I have here I have altered PFC.DLL so that it first looks for this library in the FS folder itself. If it finds one there it uses that -- otherwise it allows Windows to decide which to use (normally this will be the one in the System32 folder). I attach this later version of PFC.DLL (1.94) -- you will see there are quite a few changes in it which haven't been formally released yet. Just copy it into your FS Modules folder. Then you can try each of the COMCTL32.DLLs you can find, simply by copying them into your FS folder (the main one, NOT the Modules folder) one at a time, loading FS each time and looking at the PFC menu. But first, let me see the version numbers of each COMCTL32 you have, please. Regards, Pete PFCDLL1940.zip

Okay. Got them. The INI file contains the COM port already, as expected. See: [Connection] Debug=512 Port=COM1 Are you saying it ISN'T COM1? If it isn't, change it in the file. The picture is EXACTLY what I expected if the COMCTL32.DLL is incorrect. Now that is very strange considering that the version you are using is the same as mine. I assume you are using Windows XP SP2? If not, what, please? Did you check the font size as I suggested? I am puzzled that the problem appears to be as if it is using the wrong COMCTL32.DLL. I am wondering if it is picking up one from elsewhere. Did your list account for all possible copies throughout your system? Could there possibly be one in the FS folder? On my most recently installed system, using WinXP SP2, FS2004 9.1 update, and Flight 1 Ultimate traffic installed, I can only find 4 copies of COMCTL32.DLL. The one which I think is being used, in the System32 folder, is the same as the one you have there. But I also notice two others with the same date but different sizes in the "WinSxS" folders -- I suspect the dates are misleading, therefore. Can you check the VERSION number of the one in the System32 folder, please. Right click on it, select Properties, Version. Mine says: "5.82.2900.2180". I also have one with a much later date (11 Mar 2005) which is bigger (904 KB) and has version number: "6.0.2800.1643". The ones in my WinSxS folders (deep down in subfolders) are: "6.9.2600.0" (size 900 KB), and "6.0.2900.2180" (size 1026 KB). These version numbers are rather confusing. i would have thought version 6.xxxx would be later than version 5.xxxx but the fact that the lastand biggest file has the same last 8 digits is disconcerting. I am going to try each of these in turn to see if I can reproduce the symptoms. Meanwhile, could you check your version numbers please? Later ... Regards, Pete