Pete Dowson

Sorry, but I'm afraid you will need to explain quite a lot more if you want a sensible reply. Pete

One byte is 8 bits. 4 bytes is 32 bits, the size of an ordinary integer in Intel 32-bit processors. Read it into one of those in whatever language you are using. There's no conversion necessary -- read it into a 32-bit numeric variable and use it. Please check out FSInterrogate where you can see all this happening for real. Pete

Well, in FS, Windows, and C/C++ terms, it IS a string already -- a sequence (array if you like) of bytes each containing a printable ASCII character value, ending with a zero byte. As far a VB is concerned, I'm sorry, but I've no idea. VB seems to have trouble with strings, numbers, almost everything. I'll have to leave it to someone else, hopefully, to look at your code and comment. Regards, Pete

I'm sorry, but I know absolutely nothing about Multiplayer. If that limit is specified in the MS SDK for it then I expect it must be true. Maybe there's someone here who will know, but you may find more in the way of MP expertise on the Squawkbox or other on-line flyers' forums. No, the AI aircraft and their routes are defined by a BGL (scenery-type) file. There are primitive facilities in FSUIPC for influencing them a little, but nothing like you want. Multiplayer is the only way. Regards, Pete

I have received the Log you made with FSUIPC 3.488. This clearly shows that FSUIPC is only setting reverse for Engines 1 and 2, not for Engines 3 and 4. This can only happen if the FS value stating the number of Engines says "2", not "4". The number of Engines is given in offset 0AEC. Why it should possibly say '2' for the default 747 I have no idea, but this is the entire reason for the problems you are having. I have never seen a case where FS declares the number of engines incorrectly -- it should make a lot of things go wrong! Just to verify this, please go to the Logging page in FSUIPC options (ALT M F) and, looking on the right-hand side, change the first monitor offset to 0AEC, type U16, and check the "AdvDisplay" option below. Okay out to FS and load up different aircraft, including the 747. Check that the displayed value for the number of Engines is correct each time. From the log you sent it certainly wasn't correct for the 747. Please let me know before we take any further steps. If it is showing '2' for the 747, check all your other aircraft. I can make the number of Engines appear to be 2 for the 747 if I edit the Aircraft.CFG file and remove two of them. i.e. in this section: [GeneralEngineData] engine_type = 1 //0=Piston, 1=Jet, 2=None, 3=Helo-Turbine, 4=Rocket, 5=Turboprop Engine.0 = -107.5, -69.5, -6.9 //(feet) longitudinal, lateral, vertical distance from reference datum Engine.1 = -76.0, -38.9, -10.4 //(feet) longitudinal, lateral, vertical distance from reference datum Engine.2 = -76.0, 38.9, -10.4 //(feet) longitudinal, lateral, vertical distance from reference datum Engine.3 = -107.5, 69.5, -6.9 //(feet) longitudinal, lateral, vertical distance from reference datum fuel_flow_scalar = 1.0 //Scalar for fuel flow efficiency min_throttle_limit = -0.25; //Minimum percent throttle. Generally negative for turbine reverser if I delete the lines "Engine.2" and "Engine.3" then I have only two engines controllable and offset 0AEC reads 2. However, this couldn't apply in your case because you wouldn't get any movement of the other two throttles then. So it is a real mystery. I think you have either got something installed which is interfering, or something in FS is corrupted. I really don't know how to get any further with this at all. If 0AEC is reading incorrectly, I can only suggest you reinstall FS. The best thing to do, assuming you have enough disk space, is to rename your current FS folder (from Flight Simulator 9 to, say, "Old FS9") then install a complete new copy. That way you can check the new one as a "virgin installation", just with FSUIPC.DLL, .INI and .KEY copied over, and know for sure that the other installation is corrupted. THEN and only then process to install or copy over other things you've added -- you shouldn't actually need to reinstall things as the registry won't be messed up, But take care what you copy so you can tell what the last thing was in case it gets messed up again in the process. A program that can compare folder contents and list the differences would be useful here, too, so you can see what's been changed. I use Directory Toolkit for that, but there are others I think. Re-installation or parallel installation is certainly the way I would go under these circumstances -- unless that is you can identify things you've changed. Regards, Pete

Yes, exactly. You can send ANY of the FS controls (and any of the FSUIPC added controls except the offset-writing ones, which of course aren't needed) by writing the control number, and parameter if needed, at offset 3110. Please look it up. For the numbers of the FS controls check the List of FS controls provided with FSUIPC, and also available separately at the http://www.schiratti.com/dowson site. For the numbers of FSUIPC-added controls see the Advanced User's document in the FSUIPC package. Regards, Pete

The normal ALT + Prt Scr should save a bitmap on the clipboard for you. You then just have to paste it into a graphics program like Microsoft's Paint ands save it as a file. I use a program called "FSScreen" (it says it is from http://fly.to/matthias-holzer but you probably need to find it on Avsim or Flightsim.com) which saves the files for you automatically, so you can take several successive pics. Regards, Pete

It doesn't need activating. Did you follow the installation instructions in the FSUIPC documentation? They are very short, here they are in full: Copy the FSUIPC.DLL file into your flight simulator Modules folder. Why? Where did you read to do that? The only file you need for FSUIPC is FSUIPC.DLL, as that has always been needed in the FS Modules folder. Please please please look at the documentation supplied. Regards, Pete

Network the PCs and use WideFS. Check the excellent Project Magenta documentation which explains it all, with pictures too. Questions on Project Magenta are best sent to the PM support group, http://news.promagenta.com:8080/login. Regards, Pete

Okay, I checked and doubled checked everything here, and there's no way anything in FSUIPC can be doing this. Something is interfering. Please make sure you are using the default 747, and check that you have no other DLLs in the Modules folder than FSUIPC and the standard FS ones (all those will have the same date). To help get to the bottom of it I've added an additional logging option in FSUIPC 3.488 (attached). This shows the individual reversing axis controls sent internally by FSUIPC when you operate the reverser. To get the extra information, please do the following: 1. Put the attached FSUIPC.DLL in the FS Modules folder. 2. Make a safe copy of your FSUIPC.INI. Then edit the one in the Modules folder as follows: In the [General] section add: Debug=Please LogExtras=16 LogAxes=Yes (the last one might be there already) Then add a complete new section at the end (cut and paste this one): [Monitor] Display=3 Monitor0=0,088C,2,0 Monitor1=0,0924,2,0 Monitor2=0,09BC,2,0 Monitor3=0,0A54,2,0 Now run FS, with the default 747. Shift+4 to show the throttle quadrant. Operate the thottle once from idle to full thrust and back, then operate the reversing lever, from idle to full reverse and back. You will see the 4 engine values on screen whilst you are doing this (those four locations 088C to 0A54 are the actual FS throttle settings). Note what you see at each stage. Close FS. ZIP up the Log and send it to me at petedowson@btconnect.com. Restore the saved FSUIPC.INI file. This is about as far as I can go in trying to identify what is going on. The log will show all the controls being sent to FS to operate the throttles, and it will also show the actual throttle values at regular intervals (as you saw on screen). Regards, Pete FSUIPC3488.zip

Yes, this is a function of the way FS handles the "spoiler arm" setting. Do NOT try to test spoilers on the ground -- as you move the lever it passes through the "Arm" detente. FS detects this AND the fact that you are on the ground and immediately deploys the ground spoiler setting (100%). This is wrong, but there it is. Only test/calibrate spoilers in the air. This is without FSUIPC, or are you saying you re-installed it? And how come this is the exact reverse of what you reported before, i.e. that (your words) "3+4 don't move as far back as they should, and when reverse thrust is cancelled, 1+2 throttles turn idle, and 3+4 open fully."? This is becoming even more confusing because you report different phenomenon each time. Anyway, looking at the other data you provide: First, the calibration of both throttle and reverser seems rather odd compared to that for the other axis you have set: Throttle=-16193,16192 PropPitch=-7040,7040 Reverser=-16193,16192 These are such precise numbers and so coincidentally exactly the same, it looks as if you've not allowed any movement at either end of the lever slot for slight variations in readings. It is really essential to allow a little slack. Also, the fact that two of your levers give almost maximum readings and one gives less than half the range indicates that you've not set maximum sensitivity in FS for them all. Please check the FS settings and make sure all the levers are set with the sensitivity slider set as far to the right as it will go, and the null zone slider as far to the left. Then recalibrate anything you use in FSUIPC with a little slack at either extreme -- this will ensure that you can get to full idle and full thrust on each. The axis logging merely shows things working as they should, so I'm afraid that isn't of any help here. I'm looking at ways of getting more information. What you have going on there appears to be unique. The way FSUIPC treats engines 3 and 4 is absolutely identical in every respect to Engines 1 and 2. Please confirm which aircraft you were using in your tests -- I hope it was the default 747? Later. Pete

You only have to register it if you want to use any of the user facilities. Please look at the documentation, it tells you what you would get by purchasing it. Then make up your own mind. The full facilities of FSUIPC are certainly not free. You are mixing up access by programs and the user facilities you have to pay for. Programs (not users) may or may not get free access -- freeware does, payware programs are usually licensed so their access is included in the price you paid for them. RCV3 is licensed and has a built-in access key. You don't need to do anything. If it isn't working it will be because you've not got the updated version which works. [quotw]How do I register this latest version of FSUIPC? Go to the SimMarket page and pay for a key. If you don't want or need the user facilities, don't register it. Please read all about it first and decide then. You will also find lots of helpful information in the announcements and "stickies" at the top of this forum. Regards, Pete

There's only one current and supported version, and that is 3.48 at the moment. PFC will just recommend the latest one whenever they get around to updating their website. More important for PFC equipment with FS is the version number of the PFC.DLL. Excellent product. I've been using it ever since it first appeared. Er, sorry, I cannot picture that. what "should be the back ground" in what menu? What's a "menu mode"? Dot? Do you mean mouse pointer? I don't understand, sorry. Why do you have dots? Er, really? That needs challenging then. There are issues with folks using illegal pirated keys to register FSUIPC, but certainly there are absolutely no issues with any products with correct registration. Furthermore, you were just referring to PFC menus, which are from PFC.DLL and are absolutely nothing to do with FSUIPC. You haven't asked me before. Why do you say such wild things? Please calm down. First of all there is no possible reason the Flight1 stuff should do this that I can think of. They are also wrong in asserting the there are problems using a registered version of FSUIPC. PFC are wrong in recommending an out-of-date unsupported version of FSUIPC -- you should be using version 3.48 which has been current now for over two months. I cannot picture what your problem looks like, but it may be a result of something changing the common controls DLL for Windows (COMCTL32.DLL). There have been cases where installation of a program also replaces this essential Windows module, and occasionally the one installed does not match the rest of Windows. I didn't think just installing an FS add-on would do it -- it is usually a result of something like a video driver update. One of the resulting symptoms is that the dialogues pages (produced by one part of Windows) becomes too big for the containing dialogue Window (produced by another part). Check the FSUIPC options (ALT M F, select FSUIPC). Does that look the same? If so, then this is almost definitely the cause. If not, then in order that I can understand, perhaps you could take a picture (ALT Prt Scr) so I can see what you see. But first, you also need to tell me the version number of the PFC.DLL you are using -- after all that is what you are complaining about -- and also, please, update to the current supported FSUIPC 3.48. Perhaps you should have checked the documentation of PFC.DLL and seen that the Support is here, in the first place? You have not asked here before. Why do you wear yourself out in the wrong places? No no no! They are almost always quite a long way out of date. They are usually far too busy to keep up with the changes. Please ALWAYS go to http://www.schiratti.com/dowson for all my software -- it is always the latest there. Also, always refer to the Announcements and Stickies at the top of this Forum from time to time. This site is here to help, and it where you should have come. If it is the COMCTL32.DLL responsible, and so far that is the most likely from what you say, then you will need to find it and identify its version number and date for me. For that (and this applies to any module), find it using Windows Explorer (Search), then right-click on it and choose Properties-Version. Note that it will probably be classified as a "hidden system file", so first you may need to go to Explorer's Folder Options and elect to see those. Another way to check Windows files is to use System File Checker. But first please tell me what version of Windows you are using. Regards, Pete

HmmmI've not seen that happening. Are the parameters similar in both Client INI files? Ah, yes. I've had that happening on some PCs. It seems that because FS takes a lttle time to close (and wideServer deliberately slows it to make sure the messages get to the Clients), sometimes the Client will reconnect too fast. Try the attached "improved" WideClient in both cases, see if it helps. Regards Pete WideClient6473.zip WideClient6473.zip

I could start a "sticky" library of working parameter sets. Just the [buttons] section of the FSUIPC.INI, and the GFDisplay.INI, with hopefully a short Text file explaining them. I could put a summary in the text of the "Sticky" and the files could be downloadable attachments. Will you be the first to submit an example? :wink: Best regards, Pete

No. Hexadecimal means "base 16". It is "decimal" which is base 10, so runs 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, then 0 again. For base 16 there are sixteen digits: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F. As defined in the FSUIPC Advanced user's guide, and even mentioned in my last message above, that B is for "Byte" (8 bits). There's also W for "Word" (16 bits or 2 bytes) and D for Dword (32 bits or 4 bytes). See this part og yjr ASdvanced User's document: Regards, Pete

Did you enter the whole name ("F16.gau")? This gauge has been a problem on and off for a long time. It works perfectly with the key on most systems, as it does here, but something about the way it is written is strange and it causes problems on a few folks' systems. Search on "F16" in this Forum and you will see what I mean. In one case I think it was some interaction with another application altogether. I do provide tools and instructions for application authors to build in the Keys I allocate, so that their programs or gauges will actually register themselves automatically and give no hassle to the users. Unfortunately one or two authors, even though still actively programming, haven't come around to taking this easy step. You wil see from the list of supported versions earlier in this Forum, version 3.44 is not supported. It is several versions out of date -- 3.48 has been current for over two months. You should update your FSUIPC before reporting problems and asking for assistance, please. If it still doesn't work, and you've entered the details correctly, there are three alternatives: 1. Try to find out what it is in your system which is causing the problem, and fixing that. As I say, it works on most systems. Possibly a search though this Forum will show something which relates to your system. 2. Find an alternative TCAS gauge which isn't so troublesome. The Lee Hetherington ones are pretty good (ILH_TCAS for instance). 3. Purchase a registration for FSUIPC. This effectively bypasses all application registration checks as well as giving you a load more facilities. Regards, Pete

I found that the Aerosoft MCP747 driver does have some impact on FS performance too, you are correct. It certainly isn't a big hit, though. And it is a lot better on a Pentium 4 with hyperthreading. I actually found the TRC (SimKits) driver to give more impact. However, just to correct one possible misunderstanding, I think you'll find that FS uses 100% CPU according to Windows performance measurements no matter what. It seems to have routines which "soak up" idle time. It doesn't mean it is actually using it all to any purpose, and it should therefore relinquish any spare if other processes demanded it. You may also find a better balance if you impose a frame rate limit (in the Settings-Options-Hardware-Display dialogue). On a Pentium 4 with "hyperthreading", FS shows 50% rather than 100%, but only because it doesn't take advantage of multi-threading. Regards, Pete

What is "C66B0"? The "B" in "B66C0" means "Byte". What do you mean by "C"? As it declares explicitly in the GFdisplay documentation "Offsets 66C0-66FF are available for anything you wish". Just choose another which you are not already using. For example, 66C1 (the next Byte) if you are not using that. The examples supplied in GFdisplay.ZIP only use 66C0 to 66C5, so even if you were using all of the stuff in there you still have 66C6 to 66FF (58 bytes altogether) to play with! Regards, Pete

Everything you need is in the FSUIPC SDK, from http://www.schiratti.com/dowson. An "offset" is simply a reference to a value. It is actually a hexadecimal number, and used to be the "offset" in FS's global memory to where the value was kept. However, that was back in FS95 and FS98 days. These days just think of the "offset" as being the identification of a value -- there are tables in the SDK defining them. Regards, Pete

I think you have the "levels" upside down to the way I view them -- the lowest down you can get is hardware, so a keyboard sending keystrokes is real low. FSUIPC can't get that low, and it doesn't get down to driver level. But it uses "SendInput" for the precise reason that this recently-added Windows API is supposed to reproduce the results just as if the keypresses had originated reasonably low down, so "fooling" most programs. The other way is to use the recorded playback facilities, but they are very awkward and need the program to have focus -- SendInput is specifically addressable. If "key2mouse" manages to avoid seeing them it will be because it is using a much lower level access, effectively interrogating the keyboard itself, not processing windows messages, which is unlikely. Regards, Pete

It is only for KEYUP and KEYDOWN. It doesn't actually do a "SendMessage", because that isn't effective in simulating keystrokes (they need to be processed in Windows to generate WM_CHAR and other messages and indications where appropriate). They actually generate calls to the Windows "SendInput" API -- this is why it says you need Win98 or later, as that API didn't exist beforehand. Why send them via FSUIPC? As long as you are running on the same PC just send them directly to FS. Regards, Pete

Are these only available signed? I seem to remember that VB has a lot of difficulty dealing with unsigned values. What is an 8-bit value, or isn't that supported? I would have thought it would be needed for arrays of bytes representing actual computer addressable memory. Are characters always the 16-bit Unicode or Wide character values, or is this a compiler option? I notice a lot of folks "extracting" characters from strings in order to make Windows-API and FS-compatible strings, or vice versa. I assume this is the Intel 64-bit floating point format, same as "double" in C/C++, and "Single" is the 32-bit equivalent (known as "float" in C/C++). Aha! This is why folks use them to "fake" a 64-bit integer, multiplying by 10000 because of the assumed 4 decimal places! I always wondered what that was about. Thanks, Pete

There's something strange there already. You assign it to the spoiler in FS assignments, and it doesn''t work even with FS (nothing to do with FSUIPC)? I think, until you resolve your spoiler axis problem you shouldn't use FSUIPC on any axis at all. You need to resolve that first. The part about "not moving back as far" is weird because all 4 throttles are treated identically. The other part sounds almost as if you have Throttles 3 and 4 reversed somehow, though using only a single throttle axis it shouldn't be possible. Anyway, check all the FS settings, make sure none of the throttles are set reversed, and also go through every page in FSUIPC's joysticks options, make sure none have "REV" checked. Can you show me the complete jostick section from your FSUIPC.INI file please? Well, there's been no changes in this area for a long time, and as I say it is pretty basic when you only have one throttle axis -- all 4 throttles are commoned up, all have exactly the same values submitted to them. You could switch on Axis logging in the FSUIPC Logging page and do a short test as you described, just to illustrate the problem for me. Keep it short -- the log will get very large otherwise. Regards, Pete

I'm afraid some Gauge in what you've added to the Aircraft in that update is accessing FSUIPC incorrectly -- i.e. it is badly programmed. Even if it is freeware there is no way I could make an Access key for it, because it is not using a valid interface. The correct way for gauges to access FSUIPC was defined back in FS2000 days, years ago, and pretty much all such access implemented since then has been correct, so either this must be a very old piece of programming you've just installed, or it is simply badly written more recently. Unfortunately, because it uses the wrong access method it is impossible for me to identify it precisly. There are two choices here: 1. You find out which Gauge it is by a process of trial and error -- i.e. examine the PANEL.CFG file, then remove each gauge in turn till the culprit is found. Then leave it out, or 2. Purchase a user key for FSUIPC, which will allow all accesses, even bad ones. The last is slightly risky -- one of the reasons the access method being used is "bad" is that it can cause problems when two or more such internal modules (Gauges or DLLs) try to access FSUIPC in the same way. Because of the way the memory-mapping is done they could corrupt each others data. Regards, Pete