Pete Dowson

Phew! I had to dig out my EPICINFO document just to understand what you were talking about. I'm sorry, but I haven't used EPIC for several years. Hmmm. That doesn't necessarily follow I'm afraid. I seem to recall I never knew how to identify them exactly except by trial and error. I did once actually edit the Registry, giving each of the EPIC joysticks a different name, so I could tell. That worked for a while, but it is very messy and dangerous to do. I did ask Ralph Robinson (R&R) if he couldn't install them all with different names, but I don't think he ever got around to it. Well, this shows something changing, slightly, in the axes. Not enough to notice I suppose. Random jitter perhaps? According to my Microsoft jostick API refernces it means "joystick unplugged". Most likely thing is that you've got the wrong joystick number. Try using the JoyView program (from Thrustmaster) -- if you can find it still. If not, I may have it buried somewhere in my archives. It has always proven very useful when trying to sort EPIC axes and things out. You can monitor what's being changed in the PM MCP using FSUIPC's Monitor facilities. The offsets you need to monitor are listed in the PM offsets document (on the PM documentation site). They are all 16 bit words (U16 or S16) at offset 5406 onwards. Regards, Pete

The landing gear control in FS is only a switch (on/off in other words), you don't really get to control it's position, only tell it to go up or down. Whilst it is possible to program buttons to send axis controls with particular values, the reverse (to make axis inputs with particular values send button controls) isn't possible with FS nor with anything of mine, I'm afraid. Having said that, there is a "GEAR_SET" control in FS. At least it is listed (see my List of FS2004 Controls in the FSUIPC ZIP). Whether it actually does anything in FS2004 or not I don't know, but the big problem is getting it assigned. Even if you edit the FS9.CFG file and add the details for it there, it looks like FS2004 deletes any axis assignment other than the declared AXIS_.... ones. [LATER] I've tried setting different GEAR_SET values by programming buttons to send it (in FSUIPC) with different values. The only one which seems to do anything is a parameter of 0, which raises the gear. None of the non-zero values I tried did anything, not even 16383 which I would have expected to operate it. So I'm sorry, it looks like you'll need to use a toggle switch or button instead. Regards, Pete

This is confusing. Did you write to Project Magenta support with the same questions? This looks identical, so I'll repeat my replies for the benefit of other readers -- though you will actually find your answers in one or other of the threads already here. One quite recent one, in fact. No, it is caused by some bad gauge programming somewhere. Microsoft have been very specific about this. I consider it a weakness in the design of part of FS, but they say that if folks designed their gauges correctly it wouldn't happen. Therefore it won't be "fixed". The acceleration from units of 1 to units of 10, or whatever, is triggered by a second control following the first within so many milliseconds. I'm not sure of the actual interval off-hand, but it relates to normal keyboard repeat rates and so on, so is around 30-40 mSecs. Really, I think the acceleration should ONLY occur if the second control, arriving so close, is the SAME control as the earlier one. But for "efficiency" (if you like) MS don't bother to check. They just assume that if two controls arrive so close together they MUST be the same. After all, if they are being generated by user action, there's no way he could change so fast, right? The culprit gauges seem to be those which, for some reason best known to their authors, send controls to FS continuously at ridiculous rates, many every second. The first panel in which I met this was the 767PIC on FS2002, which is when I added the "acceleration fix" into FSUIPC. For some daft reason that panel was sending controls like AP off 20 or 30 times a second! No wonder some of these panels slow FS down so much! So much waste! Unfortunately it seems that, with the development now of XML gauges, my fix (which merely fiddles FS's acceleration timer if it sees a control which is different from the previous one) doesn't work with all gauges. The XML gauge "events" bypass the method I use to detect them. Ah, not FSUIPC 3.61 as in the email! :wink: Please note that the current version is 3.44. I really cannot support old versions, especially as old as that! Anyway, FSUIPC isn't relevant. Take it out and you'll get the same results. Why? Just stop writing gauges which continually send controls to FS. There should be no need. At least test values before sending controls to see if they would actually do anything useful. Things like setting the A/P off 20 times a second are daft if the A/P is off already. Et cetera. Regards, Pete

It doesn't mean to say it would have worked properly. It would have depended what was also being loaded before it. The whole business of logging and reporting on accreditation was tidied up to avoid some of the confusion the earlier laxity induced. The gauge may simply be a renaming of one of the other freeware TCAS gauges. If it is then renaming it back to its original name might help. Check the freeware key list above. You could try right-clicking on it in Explorer and checking Properties-Version. Regards, Pete

Are there URLs for further info? I don't recall those. Let me know so I can either delete them or update them. In order to transfer data between two processes, there are a limited number of choices. Don't forget that separate processes run in separate virtual machines, with their own virtual memories. They cannot see each other directly. The choices include the obvious one -- writing a file to disk for the other to read -- and also "pipes", which is a sort of serial link managed by Windows, and DDE (Direct Data Exchange) which was favourite in Windows 3.1 days but I think is rather inefficient (though with the right stuff installed does have the advantage of working over Networks, nowadays, I believe). The method used by FSUIPC is actually one also used by debugging API facilities to read and write process memory. It is memory-mapped files. All that happens is that the client program creates a memory-mapped file, with a unique name generated from its process ID and a few other things that FSUIPC can check. Since it cannot actually TELL FSUIPC this name (it cannot place the string in shared memory until the memory is shared --- classic chicken and egg dilemma), it registers the string with Windows as an Atom name. Atoms are guaranteed unique in the system. Windows provides an ID number for the Atom, which the Client can pass over to FSUIPC in a Message. This allows FSUIPC to obtain the memory-mapped filename, by asking Windows for the string corresponding to the atom number. Thus, it can "open" the memory mapped file, and read and process the data, placing the results back into the same area for the client to read when the Message call returns. There. Simple, eh? :wink: Most folks don't need to know all this, BTW. Just use the stuff provided. :) Regards Pete

I bet it didn't start FliteStar either, eh? To make shortcuts I just use the mouse, drag the EXE to the desktop bu press the ALT key before releasing. I think that works with all versions of Windows. Regards, Pete

They should be written to your FSUIPC.INI file. That's where everything is saved. What version of FSUIPC and what version of PFC.DLL? Check that you haven't protected FSUIPC.INI as read only. Check that it isn't corrupted -- show me the Buttons section if you like. If you haven't much invested in FSUIPC settings already you could simply try deleting the INI file so it makes a new one in any case, or at least test things by moving it out of the Modules folder for safe keeping. But, if you are not using FSUIPC 3.44, please make sure you update it first. Regards, Pete

It won't become apparent on its own. The offsets you would need to get the 737NG MCP values to the GF MCP display are not published by PMDG, though they have been hacked. Since I have an agreement with PMDG regarding its use of FSUIPC it would be unethical of me to help you further on that without PMDG's permission (which I've tried to obtain several times in vain). You will have to search for the information yourself I'm afraid. Sorry. But didn't I read, somewhere, that GoFlight themselves had at last come to some arrangement with PMDG and will be supporting it with their own drivers? Check the GoFlight website. Maybe I was dreaming? Regards, Pete

I've never heard of that gauge, and there is certainly no record here of anyone ever asking for a key for it. Is it part of a Freeware panel, or is it a Freeware gauge you got on its own and added to a panel yourself? Regards, Pete

Did you edit the FStarRC.ini file, to set your choice of paths and so on? I'm wondering if that may have anything to do with it. The other thing to check is that you are running FStarRC.exe FROM the FliteStar folder, the one which contains the FliteStar program itself. If you have made a short cut to FStarRC make sure that the Properties show the same folder as the working folder. Does FStarRC, when run, load and run FliteStar for you? If it does, then, since that is in the same folder as the RWS file, it should find that too. Finally, you could set "Log=Yes" in the INI file, run it, then show me both the FStarRC.INI and FStarRC.log files. FStarRC has been going now for years -- I first did it in the time of FS98 and FliteStar version 6 or 7. This is the first time any one has had such a problem. Regards, Pete

Actually version 3.44 was released the week before Christmas, so it isn't one month old yet. There is a facility included in FSUIPC to keep the aircraft flying normaly, but maintain its geographical position (latitude/longitude). It is documented in the History document (see item 2 for 3.44, either in the History document in your FSUIPC ZIP, or in the "recent changes" Announcement at the top of this forum). It is a facility specifically requested for use in professional pilot training simulations, where, for instance, various attitudes and aircraft parameters can be experimetnated with in an approach position, or whatever. This facility is not activated at all by FSUIPC itself, but by one or other of the methods indicated there. If the description of this "position freeze" facility matches what you are seeing, then it sounds like something you are running is writing to the control byte for this facility: the section would be relevant. You could check this by enabling IPC write logging in FSUIPC (Logging options tab) and searching the resulting Log for "3541", or possible something which includes the offset 3541 in a larger write. The log should also help identify the culprit. If you do this and want help with analysing the log, ZIP it up and send it to me at petedowson@btconnect.com. Regards, Pete

Great! Glad it was so easy, in the end! Regards, Pete

Yes, you certainly are! You say you are "familiar with entering the key". How is that? Have you registered FSUIPC as a User? If so there should be no need at all to enter any keys for any specific programs! Your payment for FSUIPC covers them all. If you are merely exaggerating, and have not entered a key before, please notice that there are, in fact, THREE buttons for key entry, on that first page in FSUIPC options. You need the one labelled "Register an application program". After all, isn't it the application you are trying to register, not yourself as a User? Please take a longer look next time, and see the facilities that are available. Perhaps English is not your native language? If so, I can understand there may be some confusion, but surely someone could help you read the earlier parts of the FSUIPC User documentation? Please see the section entitled "Program Registration" -- there is even a picture showing the entry window. Let me know if you still have difficulties, and, please, tell me why you were trying to register it wrongly in the first place. I need to understand how people can get things wrong so I can improve the documentation in future releases. Thanks. Regards, Pete

Only if the values to be displayed are accessible in FSUIPC offsets. Certainly Project Magenta is well catered for (and will feature in the examples provided), but few others, if any actually use FSUIPC offsets or, when they do, publish the details as PM does. The general problem is that each separate implementation of a non-FS autopilot or other subsystem does things in its own way, using its own values and storage. There is no general access for FSUIPC to take advantage of, UNLESS they use the common space in FSUIPC offsets. My GFdisplay program will allow anything stored in FSUIPC offsets to be displayed, after conversions have been applied if needed. But the data has to be there in the first place. Of all the well known complex aircraft panels available, the only one I know that definitely uses FSUIPC offsets is PMDG, but they don't publish details. I think there are some hacked offsets values for PMDG MCP data around, so maybe someone could make them work, but there's no way I can support this officially. It is up to the panel makers to publish their methods and how to access the values you need. Regards, Pete

Okay, let's stop there a moment. According to my records that is certainly the correct access key for flight tracker, provided it has the following properties: Program name "FlightTracker.exe" Product Name (in Version Info) "FS Flight Tracker" Company (in Version Info) "K. D. Lovell" So, assuming those things are true, it would have worked if you entered the details correctly. So, please explain what you entered and where, exactly. Then I can see where you went wrong and help you get it right. Right? Regards, Pete

Sorry, I'm afraid I don't understand your shorthand at all. What does "clic cwr screen fsuipc!" mean, exactly? And what "appears"? If you can explain in a few, possibly longer, words, maybe I can help. Regards, Pete

Sorry, I've no idea. Try the FS2004 Forum, there's usually someone there who's seen each sort of crash you can get. Regards, Pete

No, FSUIPC offers no such options. It's a real pain in FS2004 to get anything to stay on top of FS -- it was easy enough in FS2002 and before, but MS changed to some different DirectX techniques in FS2004. Even if you get it on top in Windowed mode, doing so in Full Screen mode is still a big problem -- you get flashing. For FSUIPC's own dialogue I intercept FS98MAIN's Paint messages and validate the paint area to prevent flashing. This is okay providing you don't want your stuff displayed in normal flight or slew modes. Otherwise, sorry, it's a matter of trial and error to find something that works. Maybe others have an idea. You may have to delve into DirectX methods (ugh). Regards, Pete

Okay, good. Maybe FDC thinks it's a single engined aircraft or something? Anyway, glad you got it sorted. Well, I wouldn't worry about the latter, but generally the first thing to do when you have an aircraft problem is fly the nearest equivalent default aircraft to copmare it. If the default is okay then your suspicion should fall onto something in the add-on aircraft installation, maybe a gauge, a setting, or a CFG file parameter. If the default suffers in the same way, then you start looking at possible other add-on influences, as, in this case, FDC. Regards, Pete

Can you say what has been changed to achieve this, or have you never used FStarRC before? The runways database is binary. It contains a sorted table of all runways in all airports, but, alas, it is still based on FS2002. I have on my list to rewrite my scanning program for FS2004, but, though I think I now have the new AFD formats, it is not a trivial job and I haven't yet had time to do it. I know it works well with version 9.xxx because there have been folks using this for a while now. I only just updated my FliteMap before Christmas, and am now running 9.04 (Build 7523). FStarRC works fine with it, still. Regards, Pete

There's no support at all for displays and indicators in FSUIPC, sorry. BUT I have completed a separate program, which complements FSUIPC's facilities for GF modules, and allows full control of all the displays and indicators. This is "GFDisplay". I finished it and tested it all well before Christmas, but I have not had time to do any documentation for it yet -- and it needs it, I'm afraid. I'll complete a set of examples (involving both FSUIPC button programming and GFdisplay parameters), and do the documentation, then I'll put an announcement up here asking for Beta testers. But it won't be for a couple of weeks at least -- probably end January (I hope). Regards, Pete

No, not without detailed information -- that would probably be in the Client log files. Something is blocking. The symptom of increasing numbers of connections is described in the WideFS documentation. There are also a couple of threads here which include suggestions which have worked. But things have moved on a bit -- you may want to check the announcement at the top of this Forum, which also includes a test version for folks with problems to try. I'm also still working on improvments so keep an eye out. :wink: Regards, Pete

I don't think there's any other way you'll get pre-made detentes to match FS's. You'll have to do it the other way. Build the thing then make the detentes where you get the stablest results for each position. Calibrate your axis in FS or FSUIPC. FSUIPC is a little more precise and has a jitter filter, but you want best calibration in FS first. But the notch positions will be FS's choice, not yours. Regards, Pete

I'm sorry, but I don't really know how you use that particular aircraft's FMC. If it accepts keystrokes directly, then FSUIPC can be used to convert button presses to keystrokes, though the gauge may need to be put into the mode where it accepts these. Some gauges only operate with mouse clicks, at least for button pressing (the selection keys either side of an FMC, for instance, as well as some of the function ones below). If this is the case with your chosen aircraft then I think you will need to look at Luciano Napolitano's Key2Mouse program. Regards, Pete

I have managed to implement a multiple position calibration system for the PFC throttle quadrant axes, in my PFC.DLL, but it can only work with a fixed number of known detentes, of course. I don't plan to do the same in FSUIPC. I assume you are selecting the specific aircraft you are going to fly, before making this flap system with its fixed detentes? I think the best way is to implement it with a numberof trimpots, one for each detente interval, each large enough to be able to cope with the normal range (i.e. 50k or 100k max). Then instead of a main potentiometer for the lever axis use a multiposition switch or some electrical contact system, so that the current passes through a different trim pot depending on the postion selected. Then, by adjusting the trimpots one by one from one end or the other, you should be able to calibrate it, after a number of cycles through, to suit the values needed by FS. You could use fixed resistors instead of trim pots, but you will then need to use a potentiometer initially, to find the resistance values needed to select each of FS's detentes, and an ohmeter to measure same. This would also be a good way, possibly mixed with some trimpots for fine tuning. Just ideas. Regards, Pete