Pete Dowson

I've not quite left yet. :wink: 1235 is just the number of milliseconds since the program started (i.e. 1,235 seconds). Is that all it says? Doesn't it log the server name or IP address? Did you tell it your Server's name or IP address? What does the Server log say? All it sounds like is that WideClient doesn't know where it should link to. The other possibility is that there's a firewall preventing the connection. Regards, Pete

Yes, of course, as I said right at the start, something you installed (presumably IVAP) updated your version of FSUIPC to version 3.xx. If you were using FS2002 with FSUIPC 2.xx before, there would never have been any registration. All that only came about with version 3.00. The last Version 2.xx is now nearly two years old and has not been supported or developed since version 3.00 appeared in July 2003. Regards, Pete

Okay, that is only a little out of date. I would still advise installing 3.47. The PSS-A320 gauge was given an access key in November 2003. Perhaps your version is out of date? Evidently PSS-A320.GAU uses FSUIPC, yes, otherwise FSUIPC would not even be aware of its existence. It should be seeking automatic access by providing its access key -- which was, as I say, given to PSS in November 2003. Please see if there is an update you have missed. Regards, Pete

These won't account for an incorrect number of corrections shown. But they are worse, they are indications of problems which will cause jerky behavior on the affected clients. Until recently, in such a mixed system, I would certainly advise using TCP/IP not IPX/SPX, which gave me problems for a long time when mixing an XP server with Win98SE clients. However, using WinXP SP1 or SP2 I've had no problems. Are you using the original XP or SP1 or SP2? In any case, it sounds as if you have one suspect client. It will take a process of elimination to determine what is actually wrong with it. Regards, Pete

It means exactly what it says. One of the programs you've installed has updated your version of FSUIPC to 3.xx and something you are using is accessing FSUIPC without a proper access key. If the FSUIPC version is not 3.47 then go download the latest from http://www.schiratti.com/dowson. You can find out what version you have in FS by going to the Modules menu and selecting FSUIPC, or simply by right-clicking on the FSUIPC.DLL itself (in the FS modules folder) and selecting Properties-Version. When you get the problem reported, you presumably know which of the add-on aircraft you are loading? Either way, you can look in the FSUIPC.LOG (in the FS Modules folder) to find out which module or gauge is not registered. All the details of the problem will be logged. Regards, Pete

You seem to be applying the conversions needed for the aircraft positon at 0560, 0568 to those from the GPS too! Why are you doing that? It clearly says in the documentation provided that the GPS values are double floating point degrees. You just read then into a normal 64 bit floating point value and don't multiple or divide them by anything. Please, if in doubt, always look things up in the documentation. That is what it is for! Also, if you look carefully in the FSUIPC SDK package you will find a program called FSInterrogate. There's documentation for it too. If you run that, and use it to load the FSUIPC.FSI file I worked so hard on, you will find you can read all these things and see the values obtained. You will see immediately that the GPS values are 64 bit floating point values. Please check both ways. Regards, Pete

If you want to use FSUIPC to program Goflight buttons, you need to purchase a key. Button and Key programming are some of the attractive features available to purchasers. The free installation only allows access by freeware and licensed payware programs. Please take a look at the User guide -- it's a document inside the FSUIPC.ZIP. Regards, Pete

Not sure how FSUIPC fixed whatever was wrong. How do you think it did that? If it was all working, why re-install? When you re-installed, did you delete all your settings (FSUIPC.INI file)? Not sure I can, because I don't know what you did to fix your PSS Airbus problem. BTW did you ever report it to PSS for support? Regards, Pete

Check the WideServer log. Each time a "connected" is shown, the count is increased. Likewise it is decreased on a disconnect. That is most certainly a problem with your Network drivers for IPX/SPX. There's no way WideFS can force such an error. Not for the 6 or so years WideFS has been using IPX/SPX successfully, no. The actual code to drive the network is straight out of Microsoft examples and is unchanged for many years. I doubt if the first is really a problem, but it is impossible to say because there's no information. You need to look in the WideServer Log. Re-install the Network adapter on the Client giving problems. Look for better drivers. Check cables, hubs/switches. Try TCP/IP. Try updates to Windows, especially try Windows XP. Regards Pete

I can't give tutorials here, sorry. I thought I explained well enough in my documentation, so I'm unlikely to be able to improve on it without understand what it is you find confusing. What is the problem? Please ask specific questions and I'll see if I can answer them. Incidentally, I really don't support old versions of FSUIPC. The current supported version, as listed in the Announcements is 3.47. Regards, Pete

Aha. Similar to their (eventual) solution for the 767PIC, then. I by-passed that because it would have meant packaging the DLL with my programs, and I don't want to get into any of that. In the 767PIC the DLL only sent messages to the FS-installed parts to get the data. In this new case, is the DLL a standard part of the aircraft install, or do applications using it have to supply it or get the user to obtain the SDK also? Well, there would be problems testing without the aircraft in any case. If you have code that does the job already I can plug it in and let you test it? :lol: But I don't want to supply their DLL. Seems that some must have more jitter than is tolerated, then, as I thought that was the problem originally reported. Getting your input values matching what their code wants would be a problem. I don't think that's going to be solvable even with an SDK, except maybe by disconnecting throttles altogether, which removes the possibility of auto-disconnect again. Yes, of course. I do the same. But Project Magenta doesn't seem to mind. :wink: Regards, Pete

Sounds like the hub wasn't powered? Powered hubs have their own connection to your electricity supply. So-called self-powered hubs rely on power from the PC and are only suitable for very simple devices. They must be milliwatts (mW) -- 400 Watts is more power than your whole PC will be taking! Anyway, I'm glad you solved the problem. Regards, Pete

Ouch. I seem to recall that this was a problem with the earlier Wilco 767PIC. Isn't that why we can't use the "suppress possible interference from Game Port throttle assignments" option on these aircraft? In that case, instead of using the FSUIPC throttle disconnection option, you might try disconnecting the PFC throttles only. If you check the PFC DLL User Guide, you'll find a section entitled Application program axis handling You'll see that you can disconnect selected PFC axes by setting bits in FSUIPC offset 3BC8. You can either set and clear these bits direct from a program, or do it by programming a button in FSUIPC and using the Offset Word controls to set, clear or toggle bits. Let me know if you can't figure this out and I'll go through it in more detail. You'd need to be clear which PFC axes you have throttle inputs on. If you can give me information on how to detect A/T engaged state in the LDS 767 I can look into doing this automatically in the PFC driver, but it will now have to await my return from holiday, first week in April. Maybe you still need to retain the action of A/T disconnection on significant throttle movement? Isn't that what they are really trying to emulate? It seems that they really have a bit of a bug in allowing minor fluttering to disengage the speed modes. I could do that. Let me know please. Regards, Pete

I can do it, no problem, but I am simply too busy today and this weekend, and go on holiday in the wee hours Tuesday. I've made a note to do something when I return, first week of April. If you don't hear anything here, remind me then. Regards, Pete

It will simply be because when the user calibrates his throttle axes in FSUIPC, the latter applies this to the THROTTLEn_SET controls. It is most unlikely that his actual idle detente will correspond to an input of zero, so there's a change going on which is upsetting things. The axes controls actually processed by FSUIPC, and their ranges, are actually listed quite clearly in the FSUIPC User Guide. I can make an INI parameter option in FSUIPC for it to ignore inputs from THROTTLEn_SET commands and only process the newer AXIS_THROTTLE controls. In fact had I known what was going on just over a week ago I could have included this in version 3.47. As it is I am on holiday after this weekend, and will not be able to do anything until April. Thanks, Pete

The latest is 3.47. I assume your "4.0" is a misprint? Or are you looking at something else? Maybe that's a clue? Unless the IVAO install puts a renamed FSUIPC into the Modules folder (i.e. one not actually called FSUIPC.DLL), or places it, incorrectly, into the main FS folder, I really don't think that is a possibility. Please cross-check EXACTLY what you are doing when you think you are installing FSUIPC version "4.0", which doesn't exist. That is the main suspicious part now. I really doubt very much that the IVAO install will be doing anything wrong. Regards, Pete

I don't understand. Is the package for VB.Net already in the FSUIPC SDK no good then? I know there was a problem with it way back, but I am reasonably sure that the current revision 2.004 has been used successfully. No one has reported a problem since it was updated last July. Regards, Pete

There are no default aircraft for FS with FLCH or LNAV modes built in. If you are using a specific add-on aircraft with FS you will need to find out how to interface to its MCP. For instance, the PMDG 737NG series allow you to assign keyboard shortcuts to most things, and it is these keypresses which you would program in the FSUIPC buttons page. Project Magenta is supported as a special case because (a) if it the only fully adaptable cockpit system which uses FSUIPC offsets throughout for all controls and (b) which openly publishes these offsets and how to use them. Please check the PM offsets list on http://www.projectmagenta.com/resources/docs.html and you will see what I mean. There is nothing else I know of comparable to this in its flexibility of application nor openness of its interface. Hence the assistance in manipulating its offsets by added FSUIPC controls. You can do similar things with any offsets, but there won't be special FSUIPC controls for them -- you would use the generic Offset controls provided by FSUIPC for such purposes. However, it is no use you setting and changing FSUIPC offsets which don't actually connect to anything which does something useful. What are you trying to communicate to by doing this? Are you implementing MCP gauges in FS and trying to connect to them from your hardware through FSUIPC? If so, why not just make your gauges deal with the buttons and switches directly? Regards, Pete

Simple? :roll: I just read through it three times and I'm still not really sure what the question is, I'm afraid. "On MCP"? do you mean you are going to program an MCP? I don't understand any of that. Sorry. What offset, what program is run, what function (in the program?), and what has programming a function in VB.NET to write an offset got to do with FSUIPC's button programming facilities? I'm really lost now. PM wrote what codes where, please? The only thing that makes anything show as programmed in the FSUIPC Buttons page is you programming a button in the buttons page, or, if you like, editing the FSUIPC.INI file's [buttons] section as described in the Advanced Users documentation. Programming a button or keypress is nothing whatsoever to do with writing a program in VB or C or C++ or Delphi. Perhaps the term "programming" is what is confusing you? The buttons and keys facilities in FSUIPC are just assignments, like assigning FS controls to keys or buttons in FS's own Options-Controls-Assignments, only more so. Ah, this is a different question. And the answer is simple: no. How can it? Those lists are (a) all FS controls as listed by Microsoft in their CONTROLS.DLL, plus (b) all the extra controls added by FSUIPC, as listed in the Advanced User's document, and described in the User Guide. In other words, they are all pre-defined in one place or another, and all documented and listed. You can certainly use the added FSUIPC controls for reading and writing Offsets to access any FSUIPC offset. The offset controls are some of the special controls added by FSUIPC, and they are listed. Regards Pete

I really have no idea. I don't use WidevieW myself so I don't even know this gauge. It would only be possible is any one or more of these three things were true: 1. The gauge uses an FS control to operate its switch, perhaps one not otherwise used much or at all. Then you could assign it to a key or button in FSUIPC. 2. The gauge accepts keystrokes to operate, in which case you can either use that keystroke or program it on a button. 3. The gauge uses FSUIPC offsets to operate. If none of those are true, and it can only be operated by mouse, then the only way would be via the same author's Key2mouse program. Regards, Pete

AutoSave doesn't need to know any of them. It simply calls the routine in FS which saves them. I've not even looked at the SDK really. Sorry. Is all the payload data per flight, then, not per aircraft? In that case "reload user aircraft" controls won't be any use to you, you will have to load a flight. If there are sepcific keywords you don't understand and need to I expect you may get a response with the specific questions, but I really doubt that there's anyone with a handle on the whole thing. Note that, like all my INI files, all of the FS CFG files are "private profiles", accessed through the Windows private profile API. You don't need to get into full file I/O operations. Just read and write the keys you want, as you would in the Registry, for instance. This is also a much safer way of dealing with such files because Windows handles multiple accesses et cetera for you. Regards, Pete

Only when the plane is re-loaded, either via Flight loading, or aircraft selection, though I suspect that a cached copy might be used if you reload the same aircraft. There is a "reload user aircaft" control (66512) which may do the job. I don't know if that forces a file access or not. Regards, Pete

Yes, but I think that has to be done in the aircraft file, as Jose says. We did have hopes of changing payloads on-the-fly via the offsets we found, but, whilst you can change them, and things appear to be affected, in fact the changed weight doesn't influence flight characteristics or balance, so it isn't 'real'. I think the solution in the end was editing a file. Regards, Pete

I am not surprised. 3BFC is a computed value from FS telling you the current ZFW. It isn't really likely to be an input of any kind. To change the weight I think you have to change the payload. Before FS2004 I think the only way to change the "effective" payload was to add more fuel, but now there are payload points -- different numbers and positions for different aircraft, as defined in the AIRCRAFT.CFG file. FSInterrogate would only say it wasn't possible to write there if I entered such a thing into the FSI file I provide, and in general I only do that when either (1) the offset is actually read-only in any case, so you'd get an error trying to write it, or (2) I'd actually proven that there's no effect or a bad effect by writing to it. In this case neither applies, just in 90% of other cases. I'm afraid I really am not able to test every single variable I provide access to. In most cases I don't have the foggiest idea what they do in any case. I don't prohibit writing to places where there is a direct mapping into an FS variable because for all I know someone may find out it does something useful. This happened, for instance, with some of the accelerations, which are used for aircraft carrier catapaults and tailhook brakes. Sorry, I think that in order to change the payloads, you have to change the payloads. Regards, Pete

If there's a duplicate it will not have that name. If it did have the same name it would be replaced when you added the new one! I'm sorry I cannot see your system from here, but the check carried out by FSUIPC for a duplicate is essential. If it were to carry on regardless of that check FS would not work correctly in any case, but it would take a very long time to work out why. This used to happen before I added the check, and is the reason for it. It has been present in all versions of FSUIPC for about three years and has never been wrong yet. If you cannot open FS9 without FSUIPC installed, then you need to look elsewhere. That is your first priority, to get FS working. Do not install FSUIPC or any other add-ons until you can load and run FS9 successfully. Regards Pete