Pete Dowson

Download the FSUIPC SDK from http://www.schiratti.com/dowson. All the information you need is there. I don't think you'd want to use AI data -- accelerations are what you should be replicating as it is only these with are felt. You'll need to convert 6 axis changes (accelerations are available in all six degrees of freedom (longitudinal, lateral, vertical, pitch, roll, yaw) into something meaningful in your two axes. That's another matter. Certainly you can do it with EPIC hardware, but there are certainly others. Enquiries in one of the cockpit building forums may elicit other suggestions. Regards, Pete

Hmmm. Very strange then. I don't know how any USB device can intterfere with another, non-USB device. I am emailing you my latest interim version of FSUIPC, still under development, as 3.224. Please try this just in case it is related to the over-speed operation of "repeat", which I have now fixed. Let me know. [LATER] I just thoughtthe GF MCP also has its own DLL in the FS Modules folder, doesn't it? Can you try the FSUIPC programming method with that DLL removed? Maybe there is some conflict. Regards, Pete

Glad you resolved it. Not sure what happens when using keys to fly -- FSUIPC doesn't get a look in with those at all! Regards, Pete

Please state what you mean by "FSUIPC (latest version)". I always need actual version numbers. The "latest version" just means the latest one that the user has seen and downloaded -- in some cases this has proven to be many weeks old! Can you also explain what a GoFlight FMC actually is, please? As far as I'm aware there is no such beast, and FSUIPC will not recognise buttons on it in any case. The GoFlight devices FSUIPC currently recognises are: GF-45, GF-P8, GF-T8, GF-LGT, GF-166, GF-MCP, GF-RP48, GF-46 and GF-TQ6. FSUIPC accesses these devices through the Go-Flight module GFDEV.DLL, which handles the USB connections as far as I know. If your keyboard is USB connected too, then possibly you have a corrupted version of that DLL? When you program your GF devices with GF's software do you have similar problems? (They don't use GFdev.dll). The only other thing I can think of is that you are trying to program a rotary knob on a GF device to produce keystrokes, and your have enabled the "Repeat whilst held" option in FSUIPC. Do NOT do this with rotaries -- half of the time, when you turn a rotary, it will be left with the "button" it is emulating looking "pressed" -- FSUIPC will then generate a continuous stream of results, and this may flood the keyboard input buffer. The same would apply to latching switches (toggles) -- you never want to program the "repeat" action on any switches which can stay "pressed" or the equivalent. In version 3.22 of FSUIPC this repeat option is actually too fast -- I am working on a revision now which will regulate the repeat rate to a default of 20 per second, but adjustable in the INI file. However, even then you would not use "repeat whilst pressed" on anything but normal press buttons or spring-centred toggles. I'll add some notes to the documentation about this too. Regards, Pete

How strange. There's not enough significant difference between 3.202 and 3.22 to have any affect on this -- in fact there are no changes at all in anything that early. FSUIPC doesn't even start to do anything important until FS is fully loaded and ready to fly, and even then the changes are pretty much all related to facilities which only activate when used. One of the things it does do straight off, however, is read the INI file. I'm wondering if there is something in that which is causing a problem. To determine this, could you move the FSUIPC.INI file out of the FS modules folder, keep it someplace safe for now, then try 3.22 again -- it means it will revert to default settings, but that shouldn't be a problem temporarily. If this works, please Zip you original INI file and send it to me at petedowson@btconnect.com so I can check it out here. If it doesn't work, then I can only think there is some other third party Gauge or DLL (or external program?) which is connecting to FSUIPC and for some reason doesn't like something it is seeing in 3.22. Are you loading FS with the default aircraft set to a third party one which may have FSUIPC-using gauges? Are there any other third party DLLs installed apart from FSUIPC? Do you have any external programs waiting to use FSUIPC as soon as it is loaded? Regards, Pete

I wish you'd just call me 'Pete', much less formal. :D This must be with FS2002 and version 2.xx of FSUIPC? Because since version 3 those facilities, still improving, are only available to registered users. You are on the 'good' side of 60 still? I'm coming up for 61 soon. :( Thank you very much! Please also be sure to download the latest version, 3.22, from http://www.schiratti.com/dowson. And check the site once a month or so -- or review the Release notices at the top of this Forum now and then. I always post details of each version's changes there as well as in the History document inside the Zip. Regards, Pete

Yes, but to do this you'll need to edit the FSUIPC.INI file. First program it for one 'S' when pressed, and another when released. Then close FS and open FSUIPC.INI for editing (Notepad will do). Look for the [buttons] section and find the two lines encoding your requests -- you may need to refer to the Advanced User's guide for FSUIPC to interpret the list if you've got a load. Just make two more copies of the press line, add them to the end (renumbering the sequence numbers on the left of the '=' to follow the sequence), and you're done. You won't be able to edit these in FSUIPC's options after this -- the dialogue isn't suited to any complex assignments. An alternative, if you'd like a smaller chase view superimposed on your normal view, is to assign a button to the "Chase view toggle" FS control. Regards, Pete

You have up and down winds? I'm pretty sure FS doesn't simulate vertical air movements at all at present -- the updrafts provided for gliders are fiddled a different way. If you are using FS's own weather downloads then FSUIPC has absolutely nothing to do with it. I've no way of getting between the weather inputs and the simulation, excepting in the case of the visibility. You can also clear all weather in FS, but it means several actions in several pages. Why would anyone think it as being down to FSUIPC in any case if they are not using it to allow external programs provide the weather? That's a bit annoying as well as baffling. As far as Microsoft are concerned, they fix things in each successive release. Hopefully this will be fixed in FS2006, but you need to report it via the normal MS channels in any case. They don't tend to bring out any interim patches unless things are really bad (like the program can't be used because it crashes or something). The wind shift problems I know about in FS2004 are the same for any aircraft, because they are not related to aircraft at all in the first place. Just because your more sensitively set aircraft crash and burn whilst others recover doesn't make it an aircraft phenomenon. I can reproduce 180 degree windshifts using downloaded FS weather with no FSUIPC installed and with default aircraft. They are especially likely in parts of the world where there are a lot of close weather stations, like Chicago for example. This subject has been under almost continuous discussion since FS2004 came out -- you'd possible learn a lot about it by searching or browsing. Experiments by top weather program authors seem to point to problems with FS2004 wrongly interpolating wind direction changes when there are anti-clockwise changes as you ascend. Whether this explains all the problems or not I don't know, but it has certainly been shown that keeping all changes clockwise helps. I believe that the very latest versions of programs like Active Sky and FS Meteo may have cracked it, or at least very nearly so. But please don't take my word for it, go do a little more research and see what folks are saying. Regards, Pete

Done. I really hate it when messages disappear into the aether, never to be seen again! Quite a few folks write to me, I reply within hours, then days later I get an annoyed message asking why I'm not speaking to them! And it isn't even consistent! One would think that if the mail service hasn't the decency to deliver that it would at least report back! :twisted: :twisted: :cry: Pete

I already sent the details and some questions, about 19 hours ago. It has not bounced. I used the "email" button on your entries here, which appears correct from what you say above. I was actually expecting a reply by now. Regards, Pete

Okay, I've tried all sorts of things and can't get it to fail here. You said originally "After one flight, FSUIPC thinks that ATAVS is not registered", but I've tried one flight (I cheated to save time -- more in a moment), and i can't see how to get ATAVS to do another without closing it and reloading it. Even then there's no failure. This is going to get a bit techincal and very sepcific to your program, so I'm sending an email. Maybe we can exchange files by email too. It's probably better than this public download stuff. See email ... Regards, Pete

As explained in the documentation, your registration is valid for all versions 3.xx. Also explained in the documentation is the installation procedure, which consists merely of copying the DLL into the Modules folder. Regards, Pete

I have no idea how to program FSBUS -- i would have thought that they would supply such information. The index to all the offsets you can access in FSUIPC is provided in the Programmer's Guide, part of the FSUIPC SDK available from http://www.schiratti.com/dowson. Regards, Pete

The log doesn't show any call form the program to provide the Key. I didn't realise that. How are you providing the Key, please? Is it in the Version Information? Maybe you need to send me the program -- I was relying on the Log to show the key being written. I'm afraid there's nothing there either! Regards, Pete

BUT do you know if these values are FS's own hydraulic pressures, or just ones invented and managed by the panel? You should be able to find out by using the Monitor in FSUIPC. Go to the Logging page and look at the right-hand side. Monitor 08D8 for Engine 1, 0970 for Engine 2. Set the type to U32. I think these values show something like 4 times the psi value. Is it only the keyboard controls that are affected? FSUIPC doesn't see or know about keyboard controls, it cannot do anything with those in any case. FSUIPC operates on joystick controls. And of course this does not explain why it cannot do whatever it is doing when FSUIPC is preventing the "extreme" values it is actually sending, of -16383 and +16383, from getting though. Maybe it uses these to signal things between two parts of itself somehow. No, nor I. Probably only the 767PIC authors can explain the strange way they achieve this result. One thing you could try. Remove both the 767PIC DLL (whatever it is called -- sorry, I don't remember) and FSUIPC.DLL from the Modules folder, then copy them back in a different order. i.e. First try the FSUIPC copied in first, then the PIC one, and, in a separate test (remove them again first), the reverse order. This will make them load in a different order, and maybe (but not necessarily) subclass the main FS window in a different order. Possibly, if the PIC DLL catches the joystick controls first it will work the way you want it to. Regards, Pete

Well, I don't think it can possibly be the same as a neutral setting (zero value), as the FSUIPC spike elimination only cuts out those values which are at the extremes. It sounds like they have implemented some very strange ways of doing things. I've just checked to see EXACTLY what FSUIPC does on "spike elimination". For each of the three main flight controls, if the relevant option is set, it merely discards them if the parameter value is: 0x3fff (16383) or 0xffffc001 (-16383). No other values are discarded and no other action is taken when these options are enabled. These are the precise single values sent by the 767PIC which causes the spiking. I really cannot see how this can possibly interfere with any attempts to set the zero, neutral, value for these controls. I think you have something rather more complicated going on there. You'll need to ask the 767PIC folks about that. Regards, Pete

Well, I don't think it can possibly be the same as a neutral setting (zero value), as the FSUIPC spike elimination only cuts out those values which are at the extremes. It sounds like they have implemented some very strange ways of doing things. Obviously it would be a lot better if they didn't spike the controls in the first place, but they didn't fix that even though they must have had reports and did make at least two update releases. I don't have 767PIC installed any more and cannot really delve into this to find out what they are doing. Sorry. All I can suggest is that, since you are going into the menu to set the hydraulics failure, at the same time you switch FSUIPC spike elimination off too. Regards, Pete

Are these switches part of the 767PIC implementation, or part of FS proper? FSUIPC cannot detect a panels own private switch settings I'm afraid. [Later] There don't appear to be any hydraultic pump switches in FS. The nearest I can get is the hydraulic pressure. Does the FS hydraulic pressure drop to some low value when the pumps are off? What value would be the threshold? Pete

This log is no help whatsoever I'm afraid. As I thought I said, I need the log with IPC read and write logging enabled. All this log tells me is what you've told me, not why. Sorry. I do note, however, that in the log you have shown there is no error for over 33 minutes after ATAVS was loaded and opened the link to FSUIPC. Does this program really not try to access and data via FSUIPC for that long? Regards, Pete

Not that I know of. All the spike suppression feature does is look for FS controls arriving which try to set the control to one of its extreme values (full up/down/left/right). For some reason in some states the 767PIC panel coding does this continuously. FSUIPC simply discards them. There is no real simulation of hydraulics in FS itself, as such, so it sounds like the 767PIC is simulating the failure by simply sending these same extreme controls. Obviously FSUIPC cannot differentiate the reason for those controls arriving. The simulation of the hydraulics being off is presumably all contained within the 767PIC coding -- or is it? If you know of a way for FSUIPC to detect the condition then maybe I can check for it. Regards, Pete

erthere are two "areas", as follows: 1. Choose a category 2. Choose a flight Now, if you deleted all the flights in the location where AutoSave saves the flights (also where FS saves all user-saved flights), then the Area "2" would be blank when the Category selected is "My Saved flights". But there still should be loads of other categories to choose from! for example, to select the original defalut, select the category "Other" (near the bottom of the list), then "Default flight". If you really don't have any "Categories" listed, then it sounds like a whole part of the main FS installation has been lost or deleted! If that is the case I'd really recommend a complete re-install. You won't know what else is corrupted or destroyed otherwise. Er .. that makes no sense. I really don't know what you mean by "from the FS9.cfg ??", but if you open a text file with Notepad, then obviously Notepad knows where it read it from, so when you save it, it knows where it goes. If this isn't the case it sounds like there is something fundamentally wrong with your actual PC system somewhere, but I couldn't possibly imagine where that could be. It makes no sense at all, sorry -- it seems completely unrelated to anything connected with FS. Regards, Pete

I'm not sure why you would necessarily expect that. Certainly there is nothing in FSUIPC explicitly for the GF MCP. I've never even seen one, and there are no facilities in FSUIPC for managing any displays. All FSUIPC offers is the facility to program "joystick buttons". It has done this for many years -- this was extended to EPIC connected buttons, and more recently to GF connected buttons, even those on a separate networked PC (via WideFS). By "buttons" here I mean any hardware which can be detected through some standard method as being "on" or "off" or possible changing between the two (as in the case on rotaries). The FSUIPC facilities allow you to program these "buttons" to execute FS controls, additional FSUIPC controls, Project Magenta controls, or even manipulations of FSUIPC offsets. More relevantly, you can also program them to produce Key presses, as if you are pressing keys on the PC's keyboard (whilst FS has the focus). As well as not even having a GF MCP, I also do not use the PMDG panel. At present I understand that the only way to control anything in the PMDG panel is to program keystrokes to do so. This is where FSUIPC's facilities may well come in useful, assuming that GoFlight themselves do not actually provide any facilities to map keystrokes onto their own switches. I thought that, in at least some cases, they did, but perhaps not in the case of the MCP? I do not know. Buyers of what? Goflight equipment or PMDG panels? Please do not purchase a registration for FSUIPC just to program GoFlight buttons to produce keypresses. Ask GoFlight to support PMDG or allow keypress programming, You'll get far better results, I am sure. After all, much of the MCP is wasted, isn't it, if the displays aren't valid? Regards, Pete

There should be no need to ever delete them. AutoSave itself overwrites them cyclically. By default it only keeps the last 10 flights, though you can change that in the INI file. It sounds like you deleted a lot more than the autosaved flights! Probably you had your FS set up to load into the "previous flight", which is not an AutoSaved flight, but one FS generates. If you generated that, and have never saved any other flights yourself, then the user flights section may be empty. I doubt that you have no flights at all to select from, however. If the Flights dialogue there are many sections other than the user-saved ones. Choose one of those on loading. Please don't bother deleting Autosaved flights in future, unless you are saving hundreds. You should only ever get as many as 10 unless you've changed the INI file. Regards, Pete

No, no offset you can access. But you could program the button (in FSUIPC's button page) to set one of the "virtual button" flags in offsets 3340 -- which you can read yourself. Or, for a more extensive implementation you could obtain some private offsets for yourself and set bits or values in those. The FSUIPC controls which write to FSUIPC offsets are availble for any Key or Button assignments. Look for "Offset ..." controls. There are 12 of them, for setting values, setting bits, clearing bits and toggling bits on 1-byte, 2-byte and 4-byte locations. Regards, Pete

You don't mention the FS version. FS2004 does not provide all of those. It only provides the audio switches I map in the FSUIPC interface to offset 3122. Whether you switch sound to speaker or head phone is surely a wiring job in your cockpit -- FS doesn't implement separate phone and speaker output, it just uses one channel, and I'm afraid I know of no way to separate the sounds. The FS controls that are available are: COM_RECEIVE_ALL_SET COM_RECEIVE_ALL_TOGGLE COM1_TRANSMIT_SELECT COM2_TRANSMIT_SELECT MARKER_SOUND_TOGGLE and of course all the IDENT switches (the Ident codes are the only sounds ever placed on the navigational radios by FS): RADIO_ADF2_IDENT_DISABLE 66557 RADIO_ADF2_IDENT_ENABLE 66558 RADIO_ADF2_IDENT_SET 66560 RADIO_ADF2_IDENT_TOGGLE 66559 RADIO_ADF_IDENT_DISABLE 65836 RADIO_ADF_IDENT_ENABLE 65841 RADIO_ADF_IDENT_SET 65851 RADIO_ADF_IDENT_TOGGLE 65846 RADIO_DME1_IDENT_DISABLE 65834 RADIO_DME1_IDENT_ENABLE 65839 RADIO_DME1_IDENT_SET 65849 RADIO_DME1_IDENT_TOGGLE 65844 RADIO_DME2_IDENT_DISABLE 65835 RADIO_DME2_IDENT_ENABLE 65840 RADIO_DME2_IDENT_SET 65850 RADIO_DME2_IDENT_TOGGLE 65845 RADIO_VOR1_IDENT_DISABLE 65832 RADIO_VOR1_IDENT_ENABLE 65837 RADIO_VOR1_IDENT_SET 65847 RADIO_VOR1_IDENT_TOGGLE 65842 RADIO_VOR2_IDENT_DISABLE 65833 RADIO_VOR2_IDENT_ENABLE 65838 RADIO_VOR2_IDENT_SET 65848 RADIO_VOR2_IDENT_TOGGLE 65843 If you are programming keys or buttons/switches, all these are accessible via the FSUIPC drop-down lists. Pete