Pete Dowson

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

They don't relate at all. It seems you have ordered and received the USB version of the standard game port pedals. The PFC DLL driver I made interfaces only to the PFC controls systems. the rudder pedals for those plug into the back of the throttle quadrant or other PFC control system. Well, I expect they have to. The game port is dying out. And because of the (Microsoft promoted) gradual demise of the serial port, even some of the controllers have USB connections instead of or as well as serial, now. (The PFC MCP is one such). Unlike the converted Game Port devices (like you have with your new pedals), the controllers use USB as a serial port emulated connection. The FTDI driver which is needed in the PC makes the USB device look like it is on a serial port -- when you check the Windows device manager you'd see the additional COMn port resulting. LOL! It has never been "necessary" -- there was a PFC driver before I did that. It's just that I didn't like it and, with the encouragement of hardware from PFC, wrote my own, which was warmly received by PFC. The PFC.DLL only interfaces to the controllers inside sophisticated PFC devices - i.e. those with 'computers' actually inside. It deals with the PFC protocols these devices utilise. The current examples include the Throttle Control System, the Cirrus II (each of those with optional Avionics stack and RIC), the Professional version of the prop console, the Jetliner console, the MCP (with the optional EFIS and Six-pack modules), and the 737NG cockpit. [Apologies to PFC if I've not use all the right names here]. I expect you could have specified that you wanted to plug your pedals into the controller you already have (it has a socket round the back, hasn't it), and then it would be handled by PFC.DLL. As it is you have a generic USB pedal set which may, or may not, be more flexible for use in the future. Good flying in any case! Regards, Pete

It's a lot of work and may be best left till I have a chance to work on that separate joystick axis allocation system I have wanted to do for a long time. However, it isn't too dissimilar to what is already done for Buttons and Keys (they have aircraft specific sections) so it may be worth a look before then. Something very like what you are suggesting is actually implemented for the PFC throttle quadrants in my PFC driver. In that case it was pretty much essential, since you can actually change the levers to suit each aircraft. Anyway, all I can say at present is that such things are on my list. There's just no way I can give a date, or even a firm promise come to that. Regards Pete

LOL! If I'm not careful I get that way with 737NGs and Project Magenta. I'm getting so deeply involved in the subsystems I forget there are other aircraft which are rather different! :wink: Regards, Pete

I don't understand why you'd need two -- after all it is only FSUIPC you are pausing, not your own threads/program, surely? The problem is likely that, since both threads are in the same program, the memory-mapped filename generated in the SDK code you are using will be the same -- it uses a Process ID to make it unique, but both threads are in the same process. If the identifying string is the same in both cases, the memory-mapped file being used to transfer data back and forth is the same in both cases. Each time you use an FSUIPC_Read or FSUIPC_Write call you are altering data in the SAME memory area but incrementing different pointers. If you really do need two separate links to FSUIPC in one process you most certainly will need to delve into the interface code you are adopting from the SDK and add the thread ID or some other differentiating value to the string generated to make the name. Do NOT change any of it up to and including the Process ID or FSUIPC will nto be able to identify you. However, I do think you are making things too complicated. It will be far more efficient to concentrate all your FSUIPC access in one thread, with one link, and channel all your requests and settings through that. Not with FSUIPC, which is completely unaware of threads in processes outside of FS. You are using interface code in the SDK which generates unique strings as memory-mapped filenames and which uses the Process ID to do this. Opening more than one in the same Process uses the same memory-mapped file. You need to use semaphores to coordinate access and maintain common pointers to use that file correctly. Check the source code you are using in the SDK. You will see what I mean. Regards, Pete

Microsoft's term "FLOAT 64" just means "double" in C, or whatever your 64-bit floating point numbers are called in other languages. "FAKE 64" surely isn't VB's name for a standard 64-bit flloating point number? That sounds very very unlikely. I am pretty sure VB supports standard Intel format floating point, otherwise many programs written in VB would be almost impossible. Please check your VB reference book(s). These are standard Intel formats: FLOAT64 = floating point 64 bit ("double" in C/C++) FLOAT32 = floating point 32-bit ("float" in C/C++) I suspect your "FAKE 64" is some sort of 64-bit fixed point integer, similar to "long long" or "_int64" in C/C++. You would use those for the 64-bit values for Latitude, Longitude and Altitude at offsets 0560, 0568 and 0570. BTW, I see this in your code snippet: / (10001750# * 65536# * 65536#) Why would you try to convert a fuel flow in pounds per hour as if it were a Latitude value in FS units? For it is only such latitudes which are converted in this way. Where are you getting this formula from? Please do two things when working out access to an FSUIPC offset: 1. Check the programmer's guide in the SDK. Look up the varaible in the table. For instance, for offset 0918 it most clearly states that it is a "floating point double" as well as "(FLOAT64)". I would have thought that the words "floating point double" at least could be translated into whatever VB calls them. You will also note then that there is absolutely no conversion from FS Latitude units mentioned for the Fuel Flow in PPH. 2. Use FSInterrogate, Please. This is capable of showing EXACTLY what is being read in several different formats, including floating point double. A version currently being developed will also add FLOAT32 and INT64 (your "FAKE 64" I suspect). Regards Pete

Is that different from Visual Basic? There's a section of the SDK which includes VB. Isn't that any use? I cannot help otherwise, I don't use it, but someone else may chip in here. FSLook operates like a gauge, it isn't an example at all. Use FSInterrogate. That is where you need to go to learn how the FSUIPC interface and the FS values behave. Start with the FSUIPC SDK. All the information you need, if you are a programmer, is in there. If you don't yet program then it may not be a good place to start learning I'm afraid. can you help me? UIPC_SDK VB.NET Shell Rev 2 produced 48 errors in conversion. I am lost! Perhaps your VB Express is more related to VB than to VB.NET? Did you check that? I really know nothing about these many new languages, all apparently incompatible with each other, that Microsoft keeps churning out. Why don't they at least attempt to keep some sort of compatibility? Maybe there's some Help from Microsoft for those changing from one version of Basic to the next, somewhere? Sorry, I am no use for this stuff at all. Regards, Pete

That's not true. I've always used it on another computer, via WideFS. It is connected that way here at this very moment. But then I've only ever used iy with Project Magenta or standard FS autopilots, not with either of the 767's. The difference is, of course, the interface direct to the 767 DLL. It doesn't use FSUIPC offsets therefore WideFS cannot help. Regards, Pete

First of all, please update to the current version (3.48 ). I cannot support such old versions as 3.411. Then if you get the same, or any other problem, ZIP up the log together with your FSUIPC.KEY file and sent it to me at petedowson@btconnect.com. I will check it here. The only reason so far there's ever been any problems with registered installations but not unregistered is that the access key is incorrect in some way. I'd need to check. Provided you obtained it legitimately it should be fine. Regards, Pete