Pete Dowson

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

It's just a misprint in the document. I'll fix it next time. All that group are for ADF2, as looks prertty obvious. The ADF1 switch is at 3107. Did you not search? Chester is only about 30 miles or so, less than an hour. My wife goes there shopping sometimes! :wink: Regards Pete

As I said, it actually Dowson, but please call me Pete. There are only the possibilities I listed above. Did you check each one? Regards, Pete

Ah, I see. It is actually the same as what it was supposed to do, ever since it was first implemented. The bug wasn't actually intended ( :roll:), and, oddly, wasn't even reported to me for the life of FS2000 and FS2002 put together! I actually fixed it within a few days of it being reported! I assume folks just assumed it was supposed to be like that. :? For most of that time the only proportional brakes I had were linked to my GA28R cockpit device and driven, correctly, by the Aerosoft driver that came with it. When I eventually got some PFC pedals with proportional brakes I was driving them via my PFC.DLL driver, again which worked okay. So my only source of information about behaviour with, for example, the CH USB pedals, was (and still is) by reports, though once receiving one I could reproduce this by assigning other axes, on an ordinary joystick, to brakes. That's how I tested the fix. Regards, Pete

It's "Dowson" actually, but call me Pete. There are three possible ways this can occur: 1. There are indeed duplicate versions, possibly with different names. Renaming FSUIPC to something else will not necessarily stop it being loaded by FS. If it still looks like a DLL it will load and run. 2. There's a copy of FSUIPC, by its own or another name, in the main FS folder. Not so long ago it was found that FS will sometimes actually try to load modules there as well in the Modules folder. 3. There is still an FS session running, without a Window. That happens when you thought you closed FS down and it appeared to, but something (usually one add-on -- an earlier version of Active Camera, for instance, did this) actually refuses to close, so Windows cannot remove the process. Check for this by using Ctrl-Alt-Del and looking at the list of Processes. There's really nothing else at all which I know of which can give the symptoms you mention. It has to be one of those three I think. Regards, Pete

Sorry, but with so little information to go on I really have no idea. I have heard of cases where assorted other processes installed and running in Windows (especially XP) can create strange effects in FS + Add-ons, but your original description didn't sound like one I'd heard of before. It only sounded like a Key problem. Regards, Pete

Assuming your pedals are analogue axes not just on/off switches, then what you describe was certainly a long-standing bug -- it was fixed in 3.201 as descibed in this paragraph of the History document: Regards, Pete

Ah, no. I never knew thatprobably because I've never really used those new axis controls. Does seem a little odd -- but, then, the button actions operate like my implementation. Of course, they would, really, because that's what I copied way back in FS2000, imitating the effect C00 and C01 had on FS98 (those were the Global offsets changed by F11/F12). I don't think the FS2002/FS2004 AXIS controls for brakes have the slower pressure release. Regards, Pete

All those values are listed with offsets in the Programmer's Guide. Have you checked? Which are you having difficulties with? Please, for such questions, just first check the Programmer's documentation in the SDK. Also, try using FSInterrogate which will display all these things for you. Regards, Pete