Pete Dowson

Well that shows nothing wrong, though I can't tell if everything is okay because the Log is unfinished. You really need to close FS down before showeing me the log so i can see the end of it too. So, when you say "I cannot get FS2000 to run with FSUIPC 3.9 in Modules directory", what exactly do you mean, because it evidently is running (subject to seeing that the log ending is also okay)! Regards Pete

FS2000? Phew! That's 10 years old! I've actually got no way of debugging in FS98 or FS2000 these days. The earliest I can go back to now is FS2002, and that not for long. Is there an FSUIPC.LOG file produced in the Modules folder? If so, show it to me. If not, then it sounds as if you haven't actually put FSUIPC.DLL into the Modules folder. What version of Windows are you using? 3.1? 95? 98? Me? Regards Pete

Sorry, I don't understand what good that would do anyone. Better to keep to context. Really the ONLY output which has application relevance here is the XML file. Any comment in the log should surely be kept in its place. And, BTW, who would deliberately use these unknown surfaces or "grass 2" etc in any case, when there are perfectly good ones already correctly labelled / documented? Sorry, I've no idea what on Earth I could say, other than it is an Unkonwn surface with code 254, which is what it says!? Sorry, no. If I start on that route I'd eventually need to include the whole BGL specification for airport data in there. It isn't relevant to any applications of MakeRunways.exe I am aware of. This is starting to go too far. MakeRunways is a little freeware program which has grown like topsy. I don't mind doing the odd improvement where it helps, but I'm not going long ways down obscure pathways. However, thanks for your input. I may add some more translations for the XML output, next time I have other reasons to change the program. Okay? Let's leave it there, please. Regards Pete

Only if you don't check both. They both get written to the same file. Yes. You cannot have the two programs registered to different people on the same installation, and your unique identity is by both your name and address/email (names alone are seldom unique). The need to have them the same is documented in the FSUIPC user guide. The quickest way is probably to raise a problem ticket on SimMarket, explain that you had not realised they had to have the same email, and ask for the FSUIPC registration to be updated to your new email so that you can use both. Regards Pete

Oh dear. I hope it mends quickly for you! Ah, so AFCAD allows you to set these, using these "unknown" or "grass" names. I see. I might, just for the XML output, use the Grass and Concrete names for these otherwise unknowns, and perhaps add something to the TXT log. But not immediately -- I've just released version 4.35 which was needed to correct the XML when airport or city names with non-UTF-8 (ASCII) characters are included. Thanks for the info, Regards Pete

Hmm. Well, I may anyway. Regards Pete

The REX thing. Yes, it was reported on theirs and other Forums within hours of the REX 2 update being available. They issued a fix for it a few days ago, but it won't restore your EXE.XML. Glad to see you've managed it anyway. Mostly the complaints were related to UT2 which also needs and entry in the EXE.XML file or else you get no Traffic! Ah, that's not really sensitivity as such, simply ensuring there's a dead zone so that normal rudder use doesn't also trigger braking. Regards Pete

No updates, not even the Installer, touch your Settings file, which remains intact. To update from 4.50 to 4.525 you should first update to 4.52 using the full installer at http://www.schiratti.com/dowson . This is to make sure the documentation and other files provided for each major release are updated. Then download 4.525 from the Updates announcement and simply copy the FSUIPC4.DLL into the FSX modules folder. If Windows queries this, just agree to overwrite the older file with the new one. Regards Pete

I still can't find where For axis assignment, where it explains the selection for aircraft-specific or profile-specific. See this (I've highlighted the bits you must have skipped over): I'm sure I can find a similar statement for calibrations, but 'nuff said, right? ;-) Regards Pete

Actually there's no such thing as a sensitivity setting in FSUIPC, unless you are referring to the response "slopes"? I can't see how a completely separate device would have any interaction with another. Does this "Pro Panel Switch" have its own driver, something installed for it? Sorry, I really know nothing about it. How do you assign things to those switches? Well, more information is needed. I've no idea what this Pro Panel switch is nor how it is connected nor how it has its functions assigned. You appear to have said FSUIPC isn't involved in any of that. FSUIPC most certainly won't start acting on devices you've not asked it to. Perhaps you are asking only after some coincidence of events? Regards Pete

Sorry, I'm a bit confused. How did you define those unknown surfaces when making this fictitious airport? In other words, to get these: "UNKNOWN 3",// 3 ("UNKNOWN"), looks like "GRASS" "UNKNOWN 5",// 5 ("GRASS 2"), looks like "GRASS" "UNKNOWN 6",// 6 ("GRASS 3"), looks like "GRASS" "UNKNOWN 10",// 10 ("UNKNOWN"), looks like "CONCRETE" "UNKNOWN 11",// 11 ("UNKNOWN"), looks like "CONCRETE" what do you set in AFCAD2? And when you say "looks like" do you mean the actual appearance on screen, or are you copying that comment from AFCAD2? I don't mind replacing the UNKNOWNS with better names if they are true, but I need to understand better first. Regards Pete

Offset 2900 is used to send FS controls to individual AI aircraft, or to delete them, individually. Nothing to do with display options. There aren't offsets for everything. But you can operate any FS or added FSUIPC control by writing the appropriate control number to offset 3110 (with a parameter at 3114 if needed, written first or at the same time -- i.e. same FSUIPC_Write). Control numbers for FS controls are listed in the List of FSxxxx Controls document, whilst for FSUIPC added controls are in the Advanced User guide. Regards Pete

You are expecting something which won't happen. Joystick assignments and calibrations for a Profile apply INSTEAD of any general settings. The documentation does say this. To understand why, think about it: Buttons and Keypresses can be a mixture of generic and specific -- with specific ones taking over when duplicated. But buttons and keypreses only happen when you press them. Contrast that with axes. If you have general axes and specific ones, how do you stop the generic ones you don't want for this particular aircraft interfering? Axes are always active, unlike buttons and keypresses. Furthermore, how does FSUIPC decide which is the same "intended" axis action in order to deal with overlaps? There are lots of ways of applying some of the actions -- routing direct to FSUIPC, routing via FS, assigning single generic throttles or up to 4 separate throttles, etc etc. No, it's not possible. Far more versatile and clear if each profile for axes and calibration took over the complete job. BTW you have these labelled wrong: [Axes] 1=2X,256,D,7,0,0,0 ; RUDDER no -- LEFT BRAKE 2=2Y,256,D,8,0,0,0 ; LEFT BRAKE no -- RIGHT BRAKE 3=2Z,256,D,3,0,0,0 ; RIGHT BRAKE no -- RUDDER Regards Pete

Sounds like the software you are using is not correctly clearing the condition it is setting in FSUIPC for the controls to be disconnected when in A/P modes. This facility has to be renewed every few seconds (less than 10), and when it is not renewed, FSUIPC automatically re-connects the controls. The maximum time for this, after the lack of renewal from the application is a timeout -- set to 15 seconds. It sounds like the software is not actively clearing the option, which it should most certainly do immediately, not rely on a timeout. I think there was a bug in the timeout option back then. Please check with Sim-Avionics about this. They need to actively disable the control disconnection (mention offset 310A to them). Regards Pete

It may be that there's no provision by the Aeroworx to operate them by key-stroke. Have you checked the documentation? If you can assign keystrokes for those actions you can certainly program joystick buttons to send those keystrokes for you, in FSUIPC. There's a very remote possibility that they used otherwise unused FS controls for those actions. To see if this is the case you can enable "Event logging" in FSUIPC's Logging Tab, then operate the controls by mouse, then look at the FSUIPC.LOG file (in the FS Modules folder) to see if it detected any events being used. If this is happening you can assign those same events to your buttons. The only other possibility with FSUIPC alone is to see if they programmed their cockpit in a way which is amenable to FSUIPC's "mouse macro" facilities. Have you tried this yet? Please refer to the section on this in the FSUIPC user guide. If none of these things apply, then the only other thing you could do, aside from complaining to Aeroworx about their lack of provisions in this area, is to buy Luciano Napolitano's "Key2Mouse" utility, which converts key presses to mouse moves and presses. Then you assign the joystick button to the keypress assigned to the mouse operation ... Regards Pete

Well, the WideServer part is a separate module on FS9, but built into FSUIPC4 for FSX. I don't really think that makes much difference though, whether there are separate parts inside FS or only one. Anyway, I think it is easier, as you've concluded, to do your own relaying of data to Linux clients -- especially if, as it sounds, it is only for instrumentation (outgoing data), not so much for controls.. Regards Pete

It's only been commercial a small part of its lifetime, and I'm not fussy -- if you wish to hack into its protocols and try to build a Linux client, feel free. It is just that I cannot provide you a specification of the protocols and so on it uses -- it has grown and changed over the years and to provide a specification would mean a lot of work poring through the code to work it out. It's a bit, er, organic, if you see what I mean. The sockets used are definable in the INI. Default 8002 listening at the Server, 9002 broadcasting server details (though that part isn't essential). It is written in C rather than C++ (never got into the OOP lark, I'm a bottom-up procedural programmer by a 45 year habit started off by engineering test programming). The networking library it uses is WinSock (WinSock32 to be exact). Can you tell me, then, what FSUIPC applications you have ready on Linux? I don't understand the point of a Linux WideClient if there are no applications? Regards Pete

Download the FSUIPC SDK from http://www.schiratti.com/dowson . All of the applications which interface to FSUIPC use the information in that SDK. In order to run a Linux application for FSUIPC/WideFS you'd need to write it using the information in the SDK. You are starting off from scratch -- no FSUIPC utilities run on Linux, and there's no WideClient for Unix. What would be the point of the latter until there are the former? There's no point! And, quite honestly, it would be quicker and easier for someone to write both ends (server and client) of a link to Linux in any case. There's no way I'm going to unravel a >10 year old program like WideClient in order to re-ravel it for an operating system I have no idea about. Regards Pete

Is this an add-on plane, not default? For FS98, FS2000, FS2002, FS2004 or FSX? Or even mayb CFS1 or CFS2? If there are no FS controls to operate it, and it is an add-on aircraft, then has the programmer provided any way to control these things? Some little extra information might help me help you! ;-) Regards Pete

I guess this one is for me! ;-) The vast majority is from SimConnect. Other stuff is obtained by direct hooks into parts of FS, and a very few bits are via the gauges interface into PANELS.DLL. Before SimConnect it was nearly all by hooks into parts of FS. The idea of SimConnect was to provide all the required data, and write access, "officially", and the FS team intended to fulfill all the needs I listed and to extend this over time, with quarterly updates to SimConnectUnfortunately the bean counters took over and stopped all that, so we were then left to wait for FSXI for the fulfillment of many of the promises. Now of course it is all at an end. Regards Pete

Sorry, I've no idea about anything in VB, let alone VB.Net. However, the connection has to be Opened first. If it opens successfully then the connection is established, if it doesn't you have to wait a while then try again. If you mean you want to detect if FS is closed or crashed, so becomes unresponsive, then read offset 337E at intervals and use a timeout for it to change. But remember to allow time then for delays in menus or loading scenery, flights, aircraft etc., when FSUIPC cannot update it. Regards Pete

Hmm. Strange. It shouldn't do. Incidentally, the documentation (the section in the Advanced User's guide about all this) does explicitly include the .KEY file: Not sure how you got away with it under XP -- there's no difference as far as any code in FSUIPC is concerned! Regards Pete

I do a similar thing, though not in separate partitions, just folders, like "C:\FS9orig" and "C:\FS9". Provided the DLL.XML only contains the relative path to FSUIPC4.DLL, yes, that would be fine. By "relative" I mean relative to the FSX main path. And is the ONLY change the move to Win7? No FSUIPC4 update at the same time? Did you rename the FSUIPC4.KEY file to take into account the difference in the FSX.EXE name? I think it would have to be FSUIPC4.workFSX.KEY There is one other possible problem I can see, which results from the merger at FSUIPC 4.50 time, of FSUIPC4 and ESPIPC. It think I check on the presence of the FSX.EXE or ESP.EXE in order to determine which version FSUIPC4 is running in. If the wrong answer results, some things may not work. I don't think this can affect registration though. Can you check the FSUIPC4.workFSX.LOG file, see what it says? ... [LATER] Well I don't think the latter would be a problem with FSX.EXE renaming, but it would with ESP.EXE, where FSUIPC4 would decide it must be running on FSX not ESP. Regards Pete

There's a log produced by the Install program which will help me help you -- that is what it is for. Please find your FSX folder, look for the Modules folder and find the Install log file. Show it to me. (It will be a copy of the one shown to you on screen during Installation). It sounds like either some other program you installed has protected the DLL.XML file, which prevents other FSX modules from installing, or, possibly more likely, has corrupted that file. If you can find it, show it to me too -- it is in the same folder as your FSX.CFG file (provided you've actually run FSX before -- if not, do so, THEN try to re-install FSUIPC4). To find the DLL.XML file, use Explorer: go to Users - your log on name - AppData - Microsoft - FSX. The file is a text file. Open it with Notepad, then copy and paste it into a message here. If you can find it you can also try renaming it (say DLL old.XML) then re-run the FSUIPC4 installer -- it will make a new one to get itself loaded. Regards Pete

Not at all randomly. The display shows the first input which indicates a change. If one you aren't moving is being seen, it is because it is suffering some "jitter". Many potentiometer-based joystick axes give slightly different readings each time they are measured (temperature, pressure, dirt, humidity etc). Normally one "parked" at either extreme should be "quiet". This is the reason the Axis Assignments tab is equipped with an "Ignore" button, so you can tell it to ignore interfering jittery axes (on this visit only). You obviously have jitters in more than one place. Maybe a wobbly power supply? Or you are allowing USB power saving? And try parking all unused axes. Not strange at all -- jitters are quite common especially with cheaper or older joysticks, less so with modern digital ones -- providing the power supply is smooth. After all FSUIPC4 can do no more than respond to axis changes. That is all it is doing. I can apply filters to axes AFTER assignment, but if applied beforehand the filtering might eliminate the changes which it needs to detect. Regards Pete