Pete Dowson

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

That's not good -- a new key won't solve anything. I need some more details. First, make sure please that they are using the latest version of FSUIPC. I really can't help with older versions. The current version is 3.22. You will notice from reading the "history" document, or browsing all the information on revisions in each successive release in the Announcement at the top of this forum, that there have been many changes and improvements in the whole area of registration, especially for gauges and modules. If, using the latest version of FSUIPC, there are still any problems I need to see the FSUIPC Log for this, with IPC read and write logging enabled. Regards, Pete

Okay. Glad you got it resolved. But the IPC read/write logging should have helped you in any version, that's been there for years. It was how I developed FSUIPC for FS2000 in the first place -- running FSUIPC on FS98 to compare results. They aren't my files, but I'll just have a look to see if I can understand what you mean. (Why is C# so unlike C? :( ). [LATER]: Your quote from the original: int idx; for ( idx = (Token + 4) ; i < (Token + dwSize + 3); i++) { IPC[idx] = param[idx]; //xfer byte array to IPC managed FifO buffer } seems in error, for sure, as "idx" and "i" are mixed up in the 'for' statement. But the currently released version (a file called "fsuipc.cs" in the inner Zip "UIPC_SDK_CSHARP Revision 1.11") has these lines: for ( idx = (Token + 4) ; idx < (Token + dwSize + 3); idx++) { IPC[idx] = param[idx - Token - 4]; //xfer byte array to IPC managed FifO buffer } This looks to have almost the same effect as your replacement, EXCEPT that it seems to copy one byte less (to "Token+dwSize+3" instead of +4). Your code is certainly clearer though, and I don't understand why a new loop variable (idx) was introduced when there's a perfectly good "i" already available. I'll take the liberty of inserting your code in place of the one there, ready for a revision 1.12. Thanks. Why is C# so horribly long-winded and complicated compared to straight C? Is this all to do with it being "managed"? Why would anyone want it? Regards, Pete

Folks who don't have problems don't tend to write, so mostly, when you visit places like this, of course, you read mainly about problems. Always make sure you have the latest version of FSUIPC -- current is 3.22. There are no known outstanding problems at all with Key programming in this version. Well, the term "mapping" in this context isn't mine. I always refer to it as key programming. And this has its own page in the FSUIPC options, called "Keys". There is a whole section in the FSUIPC User Guide about this page, and yet more (advanced) information in the Advanced User's Guide. However, you are not wanting Key programming or even key mapping, as you are using a hardware module with buttons and knobs, aren't you? The Keys part of FSUIPC is for programming keys on your keyboard. You want the Buttons section, to let you program your buttons, switches and knobs. Again, this has its own options page, and sections in both User Guide and Advanced User guide. I suggest that, before you start anything, you at least peruse the User Guide. Perhaps you should have done that before paying for a Registration, in case you decide it isn't for you after all? :wink: Regards, Pete

No, not particularly a misnomer. It's just that you made no mention of such things in the original query. It sounded more like you wanted to mimic flying ("a slew type function"). Rather than mess with LLAPBH, which will not mimic forces but just jump the aircraft in the same way as slewing does, albeit very finely if you like, I would suggest you experiment with the actual accelerations directly. I know some of these are used successfully, for example, in implementing aircraft carrier catapulting and hooking. Regards, Pete

You write the data to FSUIPC and it pretends it came from FS and puts it into the TCAS tables for others to read, just as if it was real AI data. That's it. Nothing very clever. I only provided this facility because I didn't know of a way to get data for multiplayer aircraft internally from FS. Those folks who know how to program Multiplayer can, of course, also get the very data TCAS gauges and the like need --- hence this facility. Actually, since MS recently produced the traffic data part of the panels SDK I could probably rewrite this to get the MP data internally now, although this does assume that users download the SDK and install the extra MS DLL module this requires. So, I think I'd rather stick with it as it stands. I really cannot see this ever being the way to "create" AI aircraft in FS even if anyone knew how. There's just not enough information, no reference to aircraft files for the graphics or performance, and so on. Furthermore, AI aircraft are supposed to be "artificially intelligent" in that they fly themselves, completely unlike MP aircraft which are images generated inside FS which move according to the MP position and other data. The two concepts are rather different. Sorry, I couldn't find this in the docs, could you give me a tip where to look? Offset 2900 in the table of offsets. To find things in the document, with no index, try using the search facility in your word processor. Searching for "traffic" would have found it, eventually, for instance. Please read my comments above. It was precisely because I could find no way to access MP data from inside FS that I added the facility you first asked about! Regards, Pete

Sorry, I think this is a question for the Squawkbox folks, The connection for multiplayer used by Squawkbox is nothing to do with FSUIPC. No changes to FSUIPC would make any difference here, sorry. Regards, Pete

No, and it depends, respectively. First, please make sure you are using FSUIPC 3.22. Second, please turn on IPC read and write logging, then try again. Either show the log snippet here, or Zip the Log file up and send it to me at petedowson@btconnect.com. There's not enough information here or me to help further, yet. Sorry. "Soon"?? This is the first question I've received from you about this, and when I get some information I will see what it is you have wrong. I do my best to respond quickly, but please forgive a few hours delay now and then. There are other aspects to life I have to see to on occasion! :wink: Regards, Pete

Position and orientation, yes -- but why is the subject "dynamic forces"? For position and orientation the mnemonic is "LLAPBH" -- Latitude, Longitude, Altitude, Pitch, Bank, Heading. These are all grouped together in FSUIPC offsets 0560 - 0583, in exactly that order. In FS2002 and before the Sim must be in Slew, Pause, or Zero Sim Rate modes for the latter three (PBH) to take effect when you write to them, but in FS2004 all six are effective. Bear in mind that between you writing to these, the simulation engine will be continuing and changing them, probably using the same velocities and accelerations as before. I'm not sure how you intend to deal with this (except by setting Sim Rate to zero, or using Slew), but you may also want to investigate the dynamics too -- offsets like 3060 and following and 3178 and following. You can try writing to these too, but I don't know how effective that will be. Regards, Pete