Pete Dowson

Milliseconds since FSUIPC started -- in fact since the System and FS times loagged at the start. Regards, Pete

But Cowl Flap 1 is not assignable in the FS assignments dialogue. Whatever control you tell FSUIPC to use has to be one which FS is reading already -- FSUIPC is not a joystick driver, it does NOT read the axes at all. All it is doing is intercepting the controls which FS is using and changing them to do what you want. Probably the axis you originally had assigned to that lever was already assigned in FS. All you need to do is find the numeric corresponding to THAT control, then tell FSUIPC what it is in the "CowlFlaps1Control=n" line. I know. That is precisely WHY these facilities were added to FSUIPC. It is a "fiddle". You assign any otherwise unused axis control in FS then tell FSUIPC what it is so it can detect them. Assign any otherwise usused axis (the one it normally gets assigned would be fine). Then tell FSUIPC which it is. Regards, Pete

To start with do not use ANY string of numbers or letters. Use the Buttons page in FSUIPC exactly as I told you earlier. When you've followed my suggestions there, check the method for doing conditions THEN ask questions on bits you don't understand. You seem to have ignored the help I've tried to give so far altogether! Pete

This is nothing whatsoever to do with WideFS. All WideFS does is offer an FSUIPC interface on a client PC. I thought Aerosoft stopped developing the 747MCP firmware and driver long before the LDS767 came out? The support in the version I have is for Wilco's 767PIC -- is the LDS 767 the same? Anyway, you'll never get that working through WideFS or FSUIPC because the 767PIC (and prersumably also the LDS767) support by Aerosoft was via a special DLL Wilco provided which runs on the FS PC and bypasses FSUIPC altogether. I really cannot do anything with that at all, irrespecive of any strained relationships. Regards, Pete

This simply amounts to an attempt at toggling the value of 7B91 when the button is pressedbut the second the defeat the first. I cannot understand why you want to make it so complicated in the first place. Just use the toggle facilities. Delete both lines. Go into FSUIPC's Buttons page, and program the button as as Offset Byte Togglebits with offset x7B91 and parameter 1. "Toggle" means simply swapping between two values. You don't need to test them first then change them. And for such simple things as this you don't need conditions nor INI file editing. Regards Pete

Not FSUIPC? Doesn't WidevieW use FSUIPC these days? That's exactly what WidevieW is for, yes. A WideFS server could also be run in that PC, and you could have two copies of ActiveSky, one sending to one server and the other sending to the other. Each would need to be on a different PC unless you used the facility in WideClient for different Class Names -- but then you'd need to get the AS folks to allow the class name to be specified, or even to run one copy to send to both the standard FSUIPC classname and the additional one or two WideClient ones simultaneously. Or you can run an ActiveSky in each PC running FS, no WideFS involved, just AS talking to FS via FSUIPC, locally. Whether this would keep them synchronised better or worse than WidevieW I couldn't say. No, that's wrong. It just needs the FSUIPC interface, whether locally in the FS PC or remotely through WideClient. It is WideClient, not WideServer, to which it interfaces on a remote PC. Well, of course, ActiveSky could be changed to do all sorts of things, if the authors so desired. But so could WidevieW which already includes the networking software. You just need to be able to persuade the authors of the justice of your cause, or bribe them with lots of loot, perhaps? :wink: Why not more often? Having WidevieW only update every minute doesn't sound very good. Regards, Pete

All of it? Surely you can ask specific questions of specific bits? Most of it uses small non-technical words after all! Is English the difficulty? Anyway, I explained above how to do most of the work, all you need to do now is work out how to convert the lines to have conditions on them. Please try that. Regards, Pete

Sorry, it is hot and humid here and my body is also still on Madrid time, so it felt even later. You were just lucky to get my last response before I retired. Pete

I think it is the other way around -- it would be better to have your FSUIPC key changed to match your new email address and WideFS key. Send all the details to me at petedowson@btconnect.com -- both email addresses and keys. I'll deal with it via email. Regards, Pete

I'd really prefer it if you tried a little and asked specific questions about things you didn't understand. That way, at least, I can gradually improve the documentation in those areas folks don't understand. Having things done for you it only a one off measure and doesn't improve things. One hint to get you going. Program all the buttons for one shift state in FSUIPC's Buttons page in FS -- that's easy enough after all. Then edit the FSUIPC file and insert a ";" character after the "=" in each of the [buttons] lines so produced. This makes them comments but preserves and reserves the numbers. Now reload FS (or if you didn't close it go back to the Buttons page and click "reload" at top left), and program all the other states you want on the same buttons. Press the button you want to use for a shft too, but don't program it, just note the Joy/Btn numbers (top centre). Now close FS and edit the INI file again. Remove those ";" characters you inserted. You now have every button (except the shift one) programmed twice. All you now need to do if make one set conditional on the shift button being pressed, and the other on the shift button being unpressed. See if you can figure out how to edit them to do this -- come back with specific questions, then I'll not only be able to help but I may be able to figure out why my documents are so bad. :wink: Okay? Regards, Pete

The MCP you are using is not relevant -- PM uses FS's barometer setting. The way to set "STD" is simply to program a button for "Kohlsman Set" as described in the FSUIPC User guide -- it is one of the examples, thus: Anyway, following through with your actual question simply as an example: Is it? "ASTO"? Not sure what that means. Is that an Airbus term? Stop right there. First, please explain why you are delving into the Advanced users guide and trying to do all this manually by editing FSUIPC.INI? Why not use the facilities provided to make this a lot easier? Please, please, check the simple FSUIPC User Guide first. It tells you about a page in FSUIPC's options, selected by one of the Tabs in the on-line options, called "Buttons". Just load up FS, go to the FSUIPC options, select the Buttons tab, press your button, select Controls, drop down the list of controls and find the "Offset Dword Togglebits" control. Why this? Well, you refer to PM's offset 5414 as 4 bytes in length. One byte = 8 bits. 1 word = 2 bytes = 16 bits, and 1 double word or DWORD is 4 bytes = 32 bits. "Toggle" rather than Set or Clear because, if you check PM's offset 5414 again you will see it says to toggle the bit. Near the end, Right? So, select that control, and put "x5414" as the offset (in the space marked "offset"). The "x" is there for "heXadecimal, otherwise numbers look like decimals. Now the only thing left is the parameter. That's more tricky. "Bit 19" needs to be set, the others zero. To take the simplest approach, this means 19 zero bits (we count from zero in this world) then one 1 bit, from the bottom (least significant) part of the number. i.e: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 Now, notice I've split these into groups of 4. This is not just to make them easier to count but also because it makes it easier to convert to hexadecimal. Hexadecimal is base 16 -- 16 is 2 x 2 x 2 x 2, and numbers from 0 to 15 occupy 4 bits in binary. Reading the above "reversed binary" number forward instead we get: 1000 0000 0000 0000 0000 converting this to Hexadecimal we get: 1000 = 8 (1 x 2 x 2 x 2, + 0 for the other three bits) 0000 = 0 (easy?) 0000 = 0 0000 = 0 0000 = 0 so, the parameter needed, in hex, is x80000. That's it. Please, next time you have a question on PM (which this really is, as it is PMs offset documentation which needs the explanation), please post it to the PM newsgroup/website. I'll help there as well, but there is a wealth of PM expertise in all these things there and you'll be better off. Regards, Pete

But if the values are different every time, my feedback system never gets a chance to actually do what it is trying to do -- that is adjust things to achieve a steady given pitch or roll angle. Surely, what you are doing is acting on the feedback instead of allowing my code to. At 20 times per second you should surely be operaing the ailerons and elevators directly to achieve your ever changing roll and pitch requirements. It isn't really anything to do with what it can "handle". It is altering the elevator and aileron settings to achieve a specific target. It is using a history of past values taken at intevals, like your 55 mSecs, to see how fast the changes in pitch and roll are occurring and modifying the next elevator or aileron position according to complex formulae which attempt to predict where the values will be next time. It's a sort of "weighted extrapolation", like the trend arrows on a glass cockpit PFD. If the value it is trying to achieve is different every time, then the whole idea is up the creek. The history and adjustments it is making are more or less worthless because they were all based on a target which is now different. What is it doing if it does this? It then isn't doing any feedback checking nor prediction nor anything at all except operating the ailerons and elevators. You say "up/down/left/right" and it does it? Think about it. Currently it is trying to work out what it needs to do to the aileron and elevator to achieve a specific KNOWN result. It doesn't KNOW what result you are going to want on the next interval, so what is it going to try to do? What I think you must mean is "Would there be a way that instead of the feedback facility being given a target pitch/roll that it would accept a constant streaming elevator and aileron settings instead and let my external flight director perform all the calculations to acheive the target pitch/roll?" And of course the answer to that is, "no, but you can stream your aileron and elevator values yourself". Why pass them through something else which is doing nothing but copy your values to a different offset? See offsets 0BB2, 0BB6 and 0BC0 -- these are the places the FSUIPC feedback loop is updating for you. The only advantage the FSUIPC feedback loops provide is that they are close inside FSUIPC and can synchronise with FS's own updates. They are not doing anything that other programs could not also do, they are simply better placed for precision and smoothness. Some third party autopilots implemented in advanced cockpits do their own, in similar ways, where they think they can do it better, or usually more flexibly, than the built-in FS A/P. But of course they too are better placed, being in gauges inside FS. Project Magenta's autopilot, almost always run via WideFS, does a good job for an external program, but it currently uses a mixture of parts of FS's A/P and its own controls. It is capable of good autolands on any ILS equipped runways -- but the PM A/P does need configuring for each aircraft, of course, as any A/P would. Regards, Pete

What key presses? Have you configured these? It is best to change things from the default assignments, as they do tend to clash with default FS assignments. However, they should still work nonetheless. Was FS running and ready BEFORE you started RC? If not you will have to run RC again, as it only sends the Hot Key settings once, when it is first started. You ARE using the keyboard on the FS PC, aren't you? RC uses FSUIPC hot keys, which operate on the FS PC. Whether you use WideFS or not has little to do with it. Is there an RC forum where you can ask these things of folks also using it? I can certainly vouch for it all working perfectly on my Network, but I am Beta testing RC4 these days. Regards, Pete

I think it does do something in FS2004, as I do seem to recall times when I've had problems with icing -- in fact this is why I added the maximum icing level option in FSUIPC, because I thought a setting over 3 certainly is asking for some trouble if you don't switch on anti-icing. (I've ALWAYS remembered to switch on pitot heat so it couldn't have been that causing problems). Try setting some cloud layers with maximum icing and flying through them with pitot heat on but anti-icing off, and let me know what happens! Maybe others will chip in here. Regards, Pete

Erwhat are you updating and why? The pitch/bank control works by itself. You set the taget pitch or bank and FSUIPC operates the elevator and ailerons to achieve and then maintain that pitch or bank. For a turn you'd just set the bank for the turn, eg 25 degrees, then monitor the heading and simply reset the target bank to 0 in good time to achieve that heading. Similarly for airspeed control and climbs/descents by pitch. You only need to re-affirm the control you are exerting every so many seconds, as indicated in this text from the documentation: I really cannot imagine what you are trying to do changing values every tenth of a second? How to you expect the feedback control in FSUIPC to ever achieve a moving target with any success? There is evidently something very basic one of us is not understanding here. Regards, Pete

PLease switch off the "CAPS" lock -- it is harder to read all capitals. :wink: To register an application which doesn't bother to register itself (most do), run FS, find the Modules menu, and click on FSUIPC. On the display you get you will see a button, bottom right, "Register an application program". Click that. Enter the complete Gauge name (including the .gau part) and the Key is the spaces provided. Pete

I wouldn't have thought so, but that area is a black art to me as well. Sorry. Regards, Pete

Some misunderstand seems to have happened here over the word "shift". You want to use one key to change the way other keys work, right? NOT to actually generate the keyboard "shift" code without another key. This sort of facility is provided in FSUIPC under the name "conditions". Any Buttons line in FSUIPC.INI can be made conditional on any other button, or on flags set/cleared by other buttons. This does have to be done by editing the INI file, however. Please have a look in the Advanced User's guide, where there are some examples. If you have any specific questions, get back to me. One thing to check first, however. Some button implementations in yokes are wired so that only one button can be seen at a time. Certainly all of the older (game port connected) CH yokes and joysticks used to be like that. They were limited to 14 buttons, max, but only one at a time. This restriction may be removed in the USB gear -- but check first by using Game Controllers. Press combinations of buttons in "test" mode and ensure they are all seen. If not, you can still do it, but your "shift" button will have to be used like a toggle -- press it to toggle an FSUIPC button flag. Then you effectively have the other buttons on one of teo modes depending on whether the shift button was pressed an even or odd number of times. The problem with this is, of ocurse, that you have to remember the mode you last set. Regards, Pete

If you are running on the same PC as FS the "cycle time", that of making a request to FSUIPC and getting the results back will rarely be more than even a millisecond or so -- and most of that time is process-switching. Running at 55 mSecs intervals should be no problem, though you may want to try to make the interval correspond to the FS frame rate. 55 mSecs equates to 18-19 fps, so you'd set FS's frame rate limiter. If you wanted a faster smoother rate you'd decrease the interval and increase the limit. If your processor is a Pentium with hyperthreading then your program's performance should be perfect, but this may be affected by the video card as both you and FS will be using it. On any lesser PC your stutters may be caused by FS's takeover of the processor. Again, the frame rate limiter in FS should help. Regards, Pete

It cannot make any difference, because all you do it turn on the facility with a target pitch or roll angle. After that, everything is internal to FSUIPC and FS -- there's nothing on the Network having anything to do with it. Or are you trying to change the target value all the time? That's not the correct way to use it -- if you are doing so, why? Regards, Pete

If you only use one throttle, you simple assign it to THE throttle in FS, then FS itself uses it to control all 4 engines. FSUIPC doesn't have anything to do with it. You can select engines in FS using the E control (E + 1 2 3 4 for the engine(s) to be controlled). Regards, Pete

No reason that I know. Are you using a registered FSUIPC? If not you won't be able to access FSUIPC correctly in any case without an access key. Enable FSUIPC IPC read/write logging, run your program, show me the Log. Regards, Pete

Dealing with this in private email. Pete

13? Data error? That's a result when the data in the memory-mapped file passed to FSUIPC contains un-interpretable data. sounds like something is wrong with the way the data are is created. Switch on IPC read/writer logging just to checkHowever, if the memory-mapped file atom number is wrong then FSUIPC won't even be able to identify the program to log it. No, not at all. There are many programs with FSUIPC access split into DLLs. For external programs threads and DLLs make no difference whatsoever to the interface -- only the Process matters. I think you'll need to use a debugger to see what you are doing wrong. Sorry, I cannot debug your code from here. Regards, Pete

No, key codes. There's a list of them in the FSUIPC advanced users documentation. Regards Pete