Pete Dowson

Because the interface FSUIPC and WideFS presents to applications was invented for and designed for FS98. Even FS's main Window is called "FS98MAIN". Wideclient replaces FS98MAIN for applications to see, thinking they are connecting to the FS98 interface. What am I using? Well one or all of these, not necessarily all at the same time, but mostly so: ASV6 FSRealTime Radar Contact V4 pmSounds pmSystems AISmooth ShowText Project Magenta MCP Project Magenta PFD/ND Captain Project Magenta PFD/ND F.O. Project Magenta EICAS Project Magenta CDU Project Magenta RCDU Flight Keeper TrafficBoard Regards Petes

That's not right. FSUIPC will process the 3110 write BEFORE it processes the 3114 write. You must either write them in the same FSUIPC_Write (i.e. make a structure of 2 x DWORDs and send 8 bytes) or do the FSUIPC_Write for 3114 before the FSUIPC_Read for 3110. That's weird. I will have to try it here when I get time. If it is an FS bug I'm afraid I cannot really do anything for you -- all FSUIPC does here is send your control and parameter to FS. you could actually do exactly the same by posting a WM_COMMAND message to FS's Window with the command as wParam and the parameter as lParam. However, please revise your code to fix the order first, just in case it is that which is messing things up. Well, as I say, FSUIPC is transparent here. Try fixing the order first, before crying. Regards, Pete

Zip up the FSUPIC.INI file and send it to me at petedowson@btconnect.com. I can check that easily. There are some powerful axis assignments you can make, you certainly don't want to assign things willy-nilly! ;-) If the graphics "problem" was actually only a continual change of view then the most likely thing is that you've assigned a jittering axis to one of the view controls. If that's the case you should be able to find it simply by reviewing all the assignments, one by one, in FSUIPC. i.e. go through the process looking at each axis in turn. If you send me the INI file I can check here too, to see what's been assigned. Either way, "reinstalling" FSUIPC isn't realy necessary as the only data file controlling what FSUIPC does is the INI file. You can either simply delete that before loading FS again, or, if you have set lots of options up the way you like them, edit it in Notepad, find the [Axes] section and delete just that one section (or more if you've made them aircraft-specific -- each of those will be [Axes.]). But please don't delete it until you've sent the file to me. Please let me know either way, and also, if you do encounter folks discussing problems with FSUIPC elsewhere, please see if you can encourage them to come here. Regards, Pete

I seem to have read this before in another thread? Please don't post the same things twice, it just makes a lot of extra work. Trying? This is probably the commonest action FSUIPC is used for, and it has been used in this way now since FS2000 days with no problems. Why did it need "trying"? You most definitely had something else entirely going on there then -- there is absolutely no way FSUIPC touches any of that. There's no difference whatsoever unless you want to use FSUIPC's axis assignments. And no one's asked questions here, until now, so why are they "responding" elsewhere? The Beta versions are provided here for a reason, so I can get testing and feedback. It is no use having that going elsewhere! :-) If you are confused by Axis assignment in FSUIPC, why on Earth use it? Use the assignment in FS. Of course you can assign an axis to the mixture in FS OR in FSUIPC, not both. Either way it would be picked up by the default setting for reverser in FSUIPC's Calibrations. An easier way without going via "mixture" is to use the "direct to FSUIPC calibration" option to assign it directly to the Reverser! Surely, isn't it obvious that FSUIPC's Axis Assignment is an alternative to FS's axis assignment, with more facilities. That's what it says. Why any confusion? It is ANOTHER FACILITY! That is all. Would it be clearer if it were in a different program called "AXISASSIGNMENT"? If so, why, exactly? I am vey very puzzled over this reaction. My general advice is: if you don't understand it you probably don't need it at all, so don't use it. It was added in answer to requests, and I'm sure those who requested it will use it well. Sorry, I've no idea. There's no such thing as "X rotation" in the standard Windows joystick API. It must be a name given to or by DirectInput. However, if the same axis changes the numbers, then, yes, it IS the same axis, by definition! That's how I would find out if I needed to know. The axis calibration facility scans the axes and shows the one with the biggest change at that time. It does this initially and the scan can be repeated by clicking the Rescan button. Please read the documentation about this. It explains at length, with pictures, how to use that tab. If an axis is shown as soon as you select the tab it usually means that axis is changing. If you aren't touching it this would usually indicate some jitter. You might need to use the Ignore button to see the one you want to program next, or check on another. No, it writes the INI with ALL the changes you have made on any or all Tabs, only when you press Ok to exit. At any time before you press Ok you can Cancel, or press Escape, and NONE of the changes you made, at all, during this entire entry to FSUIPC options, will be effected, all of the previous values will be retained. No, never. Only after user Registration, when you are prompted to restart. Why should one be needed at any other time? That would be horrendous! I really cannot imagine what you are doing, but the fact that other things got screwed up is certainly an indication that something else is wrong with your FS installation. I would advise reinstalling FS itself. POVs are not read and cannot be detected by FSUIPC's axis programming. They are only read by the Buutons tab and converted to 8 buttons according to direction. Not just yoke, all and any joystick devices. But you don't have to disable them, I only said you could IF you wanted to do everything through FSUIPC. It might be more efficient, and certainly more flexible that way (what with the aircraft-specific capabilities). But you don't have to. You certainly can mix them. Just take care not to have any specific axes or buttons programmed in two places at the same time. Regards Pete

Well, not having it in the CFG file doesn't help if FS generates it internally on each load in any case. The CFG file only represents what it was using at the time you closed it down. Trying? This is probably the commonest action FSUIPC is used for, and it has been used in this way now since FS2000 days with no problems. Why did it need "trying"? You most definitely had something else entirely going on there then -- there is absolutely no way FSUIPC touches any of that. There's no difference whatsoever unless you want to use FSUIPC's axis assignments. And no one's asked questions here, until now, so why are they "responding" elsewhere? The Beta versions are provided here for a reason, so I can get testing and feedback. It is no use having that going elsewhere! :-( If you are confused by Axis assignment in FSUIPC, why on Earth use it? Use the assignment in FS. Of course you can assign an axis to the mixture in FS OR in FSUIPC, not both. Either way it would be picked up by the default setting for reverser in FSUIPC's Calibrations. An easier way without going via "mixture" is to use the "direct to FSUIPC calibration" option to assign it directly to the Reverser! Surely, isn't it obvious that FSUIPC's Axis Assignment is an alternative to FS's axis assignment, with more facilities. That's what it says. Why any confusion? It is ANOTHER FACILITY! That is all. Would it be clearer if it were in a different program called "AXISASSIGNMENT"? If so, why, exactly? I am vey very puzzled over this reaction. My general advice is: if you don't understand it you probably don't need it at all, so don't use it. It was added in answer to requests, and I'm sure those who requested it will use it well. Sorry, I've no idea. There's no such thing as "X rotation" in the standard Windows joystick API. It must be a name given to or by DirectInput. However, if the same axis changes the numbers, then, yes, it IS the same axis, by definition! That's how I would find out if I needed to know. The axis calibration facility scans the axes and shows the one with the biggest change at that time. It does this initially and the scan can be repeated by clicking the Rescan button. Please read the documentation about this. It explains at length, with pictures, how to use that tab. If an axis is shown as soon as you select the tab it usually means that axis is changing. If you aren't touching it this would usually indicate some jitter. You might need to use the Ignore button to see the one you want to program next, or check on another. No, it writes the INI with ALL the changes you have made on any or all Tabs, only when you press Ok to exit. At any time before you press Ok you can Cancel, or press Escape, and NONE of the changes you made, at all, during this entire entry to FSUIPC options, will be effected, all of the previous values will be retained. No, never. Only after user Registration, when you are prompted to restart. Why should one be needed at any other time? That would be horrendous! I really cannot imagine what you are doing, but the fact that other things got screwed up is certainly an indication that something else is wrong with your FS installation. I would advise reinstalling FS itself. POVs are not read and cannot be detected by FSUIPC's axis programming. They are only read by the Buutons tab and converted to 8 buttons according to direction. Not just yoke, all and any joystick devices. But you don't have to disable them, I only said you could IF you wanted to do everything through FSUIPC. It might be more efficient, and certainly more flexible that way (what with the aircraft-specific capabilities). But you don't have to. You certainly can mix them. Just take care not to have any specific axes or buttons programmed in two places at the same time. Regards Pete

I don't really know what those controls do -- is that the Virtual Cockpit panning normally associated with a point-of-view hat on a joystick device? If not I would have thought it was the latter you wanted. Not sure what you mean by "exchanging axis", but for all AXIS (and _SET) controls you need to make sure the paramter is written first (to 3114), or at least at the same time in an 8-byte FSUIPC_Write. FSUIPC actually triggers the control itself when it sees you write to 3110. A "tilt" will presumably tilt left or right based on your current viewing axis. Is that correct? Are you expecting it to retain the aircraft's axis instead? If these are viewing controls, which I assume they are, aren't they naturally all relating to the viewer's axis? How are you doing that? I wouldn't think that of the three available AXIS PAN controls one would be siginifcantly different from any other, unless you've just found a bug in FS? I am at a loss to understand the problem in the first place, sorry. Is it some interaction between the three axes that concerns you, or something which looks buggy just with the Tilt one? Regards, Pete

The time is from the start of one message to the start of the next. At these low speeds the message itself can eat into that time enough to make it look faster. Additionally, the time will vary a little -- the FS PC is busy doing other things. The timing is based on a Windows timing system which will fluctuate a little, then, added to that, the serial port driver system is buffering. I cannot control the exact timing synchronously because that could adversely affect FS performance (inducing stutters). If your device fails when messages are too close, increase the time a little to ensure more space. Okay, good. Regards Pete

I've had an exchange with the SB3 author, and he points out that the bug you refer to as already listed is not relevant to this problem. He also says that as far as he is aware the feature is implemented as I understood it, and was tested. However, he or I will try to test it again within the next few days. Nether of us are in a position to do so yet. It may help if you provide all the details to the support team and get it listed as a potential bug. Yes, there are facilities in FSUIPC for sending keystrokes to FS, or rather to the PC in which FSUIPC is running in, which normally amounts to the same thing -- as the program with current focus is the one normally receiving keystrokes. Other programs only manage to by "capturing" them as hot keys. Yes, FSUIPC has never transmitted keystrokes to clients. WideFS simply does not support such a feature, mainly because it is impossible in the keystroke mechanism to direct such events. You forget that there are many systems with multiple PCs in the Network. Instead, FSUIPC and WideFS support a MUCH more powerful and flexible system called "KeySend" which sends an event, called KeySend, with an event number (1-255). You can program FSUIPC to send any of 255 events, either in the Keys or Buttons section. These events go to all Clients. Then, in the WideClient in which you want the event to actually do something, you tell it the event number (1-255) and what you want it to do. this is normally a keystroke, which can then be delivered either to the PC, as in FSUIPC's case, or directly to a specific program's window. This is all described in the WideFS documentation. Did you look? Yes, you can do that in the way I just mentioned. What syntax? From what you say you''ve not even actually looked up the KeySend stuff as I suggested yet. How can you know that your "weak mind" is so weak as not to be able to understand any of it? I don't mind asking specific questions, but you please make an effort, if you want to achieve anything. Regards, Pete

Oh dear. What a shame. I'll write to Joel about it -- seems odd, it isn't a difficult thing, he already did something very similar for the normal PTT to match the original Roger Wilco methods. You can't do that. FSUIPC offers no facilities to send keystrokes directly over a Network, only to FS! As documented in the WideFS document, you must program your button to do a KeySend control in FSUIPC, then match the KeySend numbers against the keystrokes you need to do in WideClient.INI. Please refer to the WideFS documentation. It isn't so easy because different programs need different ways of getting Keystrokes into them. I wouldn't know what works for SB3, you'll have to experiment. WideFS offers several ways. This is why I added the VERY EASY automatic PTT and PVT controls which involve no messing in INI files at all. It would be FAR better to get the PVT facility working as it was intended. if no one has reported this to the SB3 folks then it won't get fixed! Regards, Pete

In FSUIPC/WideFS the implementation of the PVT transmit on/off is IDENTICAL to the implementation of the original PTT except for the same of the specific registered message used. I merely support the message which the author of Squawkbox said he was implementing. I am not a Squawkbox user, I don't have it and wouldn't know what to do with it if I did. So I presume the facility has been implemented correctly in SB and tested by now. But no one has ever let me know one way or the other. Sorry. Your first stop syhould be with SB support to check this. Regards, Pete

Just read the details for offset 02A0. Pete

It was only added in a recent SB3 update. Sounds like you have an older version. To implement it via FSUIPC / WideFS it is exactly as for the PTT one. You do need the recent versions of FSUIPC and WideFS though, of course. If you are using the correct version of SB3 then I'm afraid you need to refer to their support. Pete

Sorry, I don't think Level D use FSUIPC offsets for their switches and values. They do provide a software development kit though, so maybe someone's implemented something. Are you sure GoFlight don't support it? Pete

Sorry, you do really need Simkit support. I've absolutely no idea how they operate their gauges. I thought you calibrated them using software they provide. Also, are you sure it is intended to work with the PMDG aircraft? Test it with the default aircraft first. Maybe it has to be calibrated differently for each aircraft. Regards, Pete

Well, I wouldn't normally, but I had a look and it was pretty easy, as PFC already placed the raw axis inputs into FSUIPC's memory (offsets 3BA8 ff, as documented in the PFC DLL doc). All I had to do was make FSUIPC's axis scan include those locations as "extra joysticks" (16 for flight controls, 17 for quadrant, 18 for trims and tiller), and make sure PFC.DLL continued to scan the axes when FSUIPC needed them in its dialogues. Regards Pete

First, why delete the previous version? The update merely involves copying the later FSUIPC.DLL fileinto your FS Modules folder. Nothing else, that is all you needed to do. It would have helped if you had said what the reasons displayed were, but I think "Access Denied" can only occur for one of several fairly basic reasons: 1) The folder is protected -- you've restricted it in the access permissions. If this were the case you would not have been able to delete FSUIPC.DLL in the first place. 2) The file you are replacing is protected. Again, this cannot be so if you have deleted it, as it isn't there to be protected! 3) The file you are replacing is actually being used! This could only be the case if (a) you haven't already deleted it after all, and (b) FS is actually still running -- you can't change parts of a program which is running. I can't think of anything else which could give you "access denied". The most likely conclusion therefore is that: 1. You have not actually deleted FSUIPC.DLL from the FS Modules folder after all, which is jolly good because you don't need to. 2. EITHER the FSUIPC.DLL already there is read-only, or FS is actually still running. To check and change the former, right-click on it in Windows Explorer and select "Properties", then look down near the bottom of the window which appears. Uncheck the "Read-only" check box. To check if FS is still running, use Ctrl_Alt_Del to bring up the Windows Task Manager, select Processes, and look through the list. FS2004 will show as FS9.EXE. If it is still there, but with nothing showing for it on the desktop, then it didn't close down properly -- forcefully end it here using the button bottom right. Regards, Pete

I've not heard of LabVIEW (now "VIs"), but FSUIPC.DLL is not a library which you can call from application programs. It is very specifically an FS module, effectively becoming part of FS once installed. If does not export any FSUIPC_ functions, as these are not usable by FS. There is a C library (a .LIB file) which I provide in the SDK. That can be linked into application programs and it does contain the FSUIPC_Open, Read and Write routines which you would need to call. However, if LabVIEW needs to call routines in DLLs then you would have to make the normally statically-bound library into a DLL first. The source is actually provided in the SDK as well, so this is entirely possible. Regards, Pete

Okaytry PFC 1.994 and FSUIPC 3.537, both now available above. Be aware that if you assign PFC axes in FSUIPC you need to disable those same ones in the PFC options (uncheck the enabling checkbox for each). The FSUIPC assignments do not override thse in PFC, unlike the Button assignments. Regards, Pete

What is "not right"? If by "this" you mean FSUIPC not liking it that your identity (as far as my program registration is concerned) has changed, why is that "not right"? FSUIPC performs the registration for both itself and WideFS (WideFS is only an extension of FSUIPC, after all). Its only way of identifying you precisely is by your entered name and email address. I prefer this to the method many payware systems use, based on your computer system, because that needs updating if you change your computer, or even enhance it significantly, and also restricts your use of the products to one PC. In my view, if you paid for my software, you can use it whereber you like. Would you really rather a more restrictive system? Well, I fail to see what is so strange, and in any case no one ever said an e-mail change was not possible. Both Simmarket and myself have done this directly, on request, for the relatively few times it has arisen. It doesn't happen that often that it's a problem. And as for information about this need, it does actually say this in the FSUIPC document, in the section early on about entering registrations: Maybe you missed this? That's fine, it is what I would advise you to do, though I would only need to replace one of the Keys -- your choice. Note that, since I am not SimMarket and have no records of your registrations, I normally ask for you to include the original notifications from SimMarket so that I can process them properly. In this case, if you've already sent details without I'll see if I can check them here anyway. Regards, Pete

I have been briefly glancing at the original Avsim thread which provoked this one, and I came across this: Evidently this gentleman hasn't read much about FSUIPC recently, but in case this viewpoint is a common one I should try to dispel it here. I'm not a registered member of Avsim (or I am but have forgotten my user name and password), and anyway I think it would be a mistake for me to discuss my work there rather than here. So... The "memory mapping" used in the FSUIPC interface is an illusion. The interface is designed to look like memory mapping purely for compatibility with older programs. It follows and includes the original FS6IPC interface by Adam Szofran. But hardly any of those "offsets" are actually offsets into a memory area. The reason this illusion has been maintained should be obvious. When I made FSUIPC first of all. for FS2000, I did it so that all the programs written for FS98 could be run without changes. I just ADDED new stuff, maintaining the old stuff -- in many cases the illusion started there. Even between FS98 and FS2000 the was little compatibility in terms of either the memory positions or the values there in. Along came FS2002 and the same happens again, only more so. Then FS2004. (Oh, also CFS1 and CFS2 in between those). In each case the previous illusion needs to be maintained so that existing programs can be run unchanged, and more elements added to the illusion to support new features. The state today is that pretty much ALL of the so-called "memory map" is entirely illusory. It is the software inside FSUIPC which creates that 'map'. When programs read from a 'location' FSUIPC has to act upon that and obtain the appropriate value. It does this by a variety of methods: sometimes direct access into some C++ class private data inside one of the 'black boxes' of FS DLLs, but more often by using procedural interfaces inside FS to obtain them as products. Often, for compatibility, values need calculating or converting. FSUIPC does that before returning the results. Similarly, when values are written, FSUIPC is triggered into an action to get that value known to whatever needs to know it inside FS. This, again, may be by direct access, but that is very rare these days. Many IPC writes translate into procedure calls, or even a string of them, into parts of FS to get the action accomplished. The fact that in the end it looks simply like a "memory map" does imply that there isn't much to FSUIPC. Maybe that is why several others have tried to replace it, then found it isn't actually that easy. I should probably take the misunderstanding quoted at the start of this message as a compliment, that FSUIPC has succeeded to make such a complex convoluted interface look so simple on the surface. ;-) Enough from me for now. Good flying! Pete

I'm sorry, but that is really not at all a likely addition for PFC.DLL. I really cannot understand why you'd need it. To me it would seem to be more appropriate to adjust the control effectiveness parameters in the Aircraft.CFG file. The "feel" of your controls should be set to suit the controls, surely? Because the throttle quadrants are exchangable, the levers are different on each. When PFC bring out a console with similarly exchangeable yoke and pedals I would have to extend the driver to support those too. I will make a note of your request, certainly, but it has been the only one in the many years I've provided PFC.DLL. It is far from a simple software change. Actually, thinking about it, it might be better to make PFC.DLL route the axes through to FSUIPC and let you assign them and configure them there (see the Interim release details for FSUIPC 3.536). I already do this for more advanced button programming -- I'd rather all the similar additional user facilities in my products be grouped in one place. I'll look at it that way -- keep an eye on future FSUIPC releases. Pete

I think EpicInfo only knows a few axis controls. Certainly not that one. Aren't they listed in the documentation? I'm afraid you misunderstand still. Is the SDK documentation really so obscure, and my previous messages too? It is the CONTROL NUMBER you have to write to 3110. Look that up in the List of FS controls! You first need to write the value you want for it to 3114. I have told you this before! If that is what it does, yes. Are you sure? I've never tried it. But the offset 3110 is where you send the CONTROL, not the VALUE. The value goes to 3114, first. The problem with trying to do this with EPIC soft axes is that you only have 16 bits. The control numbers for FS controls all need 32 bits, so you will have to write a value to 3114, then the upper part of the control number to 3112 then the lower part to 3110, in that order. It is writing to 3110 which triggers the action. Is LANDING_LIGHTS_SET acceptable to FS9 in its CFG? It usually deletes anything which doesn't figure in its assignments. If it is in its assignments, then why not do it there? What I don't understand is why you are making it so complicated, and seemingly ignoring the advice I give you. If you can now make the EPIC send a button event, why not simply assign the button action to the LANDING LIGHT SET control in FSUIPC, and use the parameter facility there to set a fixed value? You can have different EPIC (virtual) buttons for different fixed values. Alternatively, if you really want to use an axis, like U3, then check out the axis assignment facilities in FSUIPC 3.536 (in the Interim Versions announcement above). You would need to use 'RAW' mode to prevent the automatic Windows calibration changing the value. Please review the assistance I've been trying to provide in this thread. You seem to be missing things, judging by what you have written this time. Regards, Pete

Only the throttle quadrant is expected to change according to aircraft type. The main flight controls are not aircraft-specific! But there are no response curves for throttle quadrant axes, only the main flight controls! Regards Pete

Well, actually they are simply quadratic or cubic calcluations. Easier (quicker) to compute and just as effective for the sorts of numbers we deal with here. They are actually pre-computed and tabulated for fast lookup and application. They are simply referred to as "response curves" in the PFC driver, "slopes" in FSUIPC. I would never have recognised them by the name "expo" I'm afraid. ;-) Okay. The response curve number is saved in the INI file. It's part of the first number in lines like: Elevator=341,1,0,16,56,68,116,255 Rudder=357,2,0,28,49,60,97,255 Here I can see Elevator is using curve #5 and Rudder #6. It's in bits 4-7. Regards, Pete

If there's been no software change, then it must be a hardware problem. However, first just re-check the FS assignments first. In particular, in FS's Options-Controls-Sensitivities check that the sensitivity slider is full right and the null zone slider full left. Sometimes I think FS2004 changes those. There's no calibration program within FS9. When you select calibration in FS is takes you out to the standard Windows calibration. If, indeed, that does show things are okay, but it doesn't respond correctly in FS9, then the most likely problem is the FS sensitivity setting as mentioned above. How do you assign a pedal to the yoke? They are two separate devices, right? Have you registered FSUIPC and used it to do things with the joystick? If not then FSUIPC won't be touching it at all. If so, and you have been messing with it and don't know what you've done, just start again -- delete the FSUIPC.INI file from your FS Modules folder so that it starts with no options set and no joysticks calibrated. However, note that, unless you are using the Axis Assignments in the interim version (3.536), FSUIPC does not deal with joystick axes as such, only with FS axis controls. So if the right brake was being handled through FSUIPC, this would not also mean the throttle was too. When you re-assigned the pedal axis and got the same result you actually more or less proved it couldn't be FSUIPC and very likely is not FS either. One last thing to check in FS is that you haven't got multiple assignments for the same axis or control, in the different joysticks list. In FS's Options-Controls-Assignments, select each joystick device in turn, via the drop-down, and check the entire list of axis assignments for each. Regards Pete