Pete Dowson

No, TrafficLook is just a standard FSUIPC-interfacing program and works fine on a WideFS client - in fact that's how I use it most of the time. I think in some older versions you needed to wait till FS is running before starting it, but version 1.55 should start okay either way. Regards, Pete

It wasn't MY assignment! Please read the thread a little more carefully. I asked Peter for HIS assignments, so I could understand exactly what he has done, so that when I document it I will know it works! This is because I have no way to test it here! Just copying someone else's assignments to your INI files won't necessarily work. Your hardware may be different .. as I see it is! So, you assigned all the Hat buttons as if they were on joystick 1 and expected them to work from joystick 0? If you KNOW what you are doing, try editing the assignments you copied to make them address #0 instead of #1 as they do now. You can see the 1's, can't you? Otherwise, why not simply do as I suggested. Delete those you added and go and do the assignments properly, via the FSUIPC Buttons tab. you know, the one in the FSUIPC Options when you load and run FS and press ALT M F. I did explain this. Please, what is the problem now? Regards Pete

Do you mean Pete or Peter? ;-) I assume you made sure there were no duplicate numbers on the left? You copied them literally, no changes? Is your CH yoke joystick #1? The reason I put the names in my copy was so that you could do all those assignments in FSUIPC's buttons tab -- then you'd be sure. Check in your INI file, are the other CH buttons all joystick 1 (1,)? Or look in FSUIPC. When you press a button, what does it show? If FS is doing something then one of those button numbers is being seen as "ON" initially -- if you are looking straight up, then it sounds like 1,32 is on all the time. Without knowing what you have connected I wouldn't know what that was. If you don't know how to edit and interpret the INI file, I wouldn't mess about with it if I were you. Program the buttons in FSUIPC's Tab. All you need to know from the list above is the "R..." is for Press and with the button Repeating, whilst the "U ..." is for Release ("Up). So you do two assignments for each of the hat positions which look like buttons 32-39. Pete

Okay, I'll annotate those, so: 41=R1,32,C65734,0 ; PAN_UP 42=U1,32,C66415,0 ; PAN_RESET_COCKPIT 45=R1,33,C65856,0 ; PAN_RIGHT_UP 46=U1,33,C66415,0 ; PAN_RESET_COCKPIT 43=R1,34,C65672,0 ; PAN_RIGHT 44=U1,34,C66415,0 ; PAN_RESET_COCKPIT 47=R1,35,C65857,0 ; PAN_RIGHT_DOWN 48=U1,35,C66415,0 ; PAN_RESET_COCKPIT 49=R1,36,C65735,0 ; PAN_DOWN 50=U1,36,C66415,0 ; PAN_RESET_COCKPIT 51=R1,37,C65855,0 ; PAN_LEFT_DOWN 52=U1,37,C66415,0 ; PAN_RESET_COCKPIT 53=R1,38,C65671,0 ; PAN_LEFT 54=U1,38,C66415,0 ; PAN_RESET_COCKPIT 55=R1,39,C65854,0 ; PAN_LEFT_UP 56=U1,39,C66415,0 ; PAN_RESET_COCKPIT Interesting that you found "PAN RESET COCKPIT" was the one to use. I see there's a "PAN_RESET" too (65875) which, from its numbering appears to be more associated with the other controls you've used. Did you try both? Any difference? Thanks Peter. It looks complete -- 8 buttons down and up -- can't be any more ;-) Best regards Pete

Please check the Interim Versions announcement above and download the latest FSUIPC (3.709) from there. It is a bug with saving some types of aircraft-specific changes, fixed in 3.707 as you will see. Regards Pete

Ah, yes, by assigning to each of the 8 buttons a POV_VIEW with the appropriate direction parameter! I had forgotten that! Thank you ever so much! The thread is http://forums.simflight.com/viewtopic.pht=#338853. Peter, I may add this example to my documentation. I don't suppose you could extract the appropriate lines from your FSUIPC.INI file for me, could you? I don't really have a proper hat device to do my own and test it to be sure, so a known working example would be great. Thanks! Regards, Pete

In transition? The traffic should only be relaoded when you are on the ground. weather at a destination should have been set enough in advance for the traffic to be okay. You need to check those options badly. Do you have any documentation for ASV6? No idea what would do that -- except of course the very same sudden wind change ("shear" its called) which is presumably also why the traffic is being reloaded. You should be able to switch off the latter, but the former probably means you have no wind smoothing enabled. Al this sounds like a badly configured ASV6 setup. I use ASV6 all the time, and even on its default settings it is not doing any of that sort of stuff. Have you been changing things I notice you did mention VatSim? Are you using two weather sources -- ASV6 and Squawkbox or something? I'm not sure they'l get along, you need to switch the weather off in one of them. Pete

This sounds like a facility in ASV6 to force FS to reload the traffic when the wind is changed, so that they use the correct runways. I am not *sure* about this, though -- you'll need to check your ASV6 options and/or documentation. I don't think it should do this whilst you are flying, but it may do whilst setting new weather whilst you are on the ground. The only other thing which causes traffic to be reloaded is a change of more than a couple of minutes or so in the time. In fact some programs actually change the time in order to force this to happen. You can also do it manually (as I do after new weather has been set) by assigning a button or key to FSUIPC's "traffic toggle" control. Nothing in FSUIPC -- take a look at ASV6. If you don't let it force a traffic reload you may have difficulties taking off against AI traffic taking off or landing in the wrong direction realtive to the wind. Pete

FSUIPC sees the hat switch as 4 or 8 separate buttons (depending on the device) -- so you can program them in the Buttons tab. If you want to use it in virtual cockpit mode exactly as it defaults in FS, however, you'll need to enable it in FS. FSUIPC doesn't support such a "POV" (point of view) control in the way FS does. Pete

The pedals won't affect the PARKING brake. If you mean your toe brakes were full on, then that is certainly more likely. Most pedals have the brake axes reversed. You'll need to reverse them in FSUIPC. Have a look at the Calibration screen in the options -- you'll see the checkbox to check. Regards Pete

Unfortunately neither log is of any use because of this. The client log shows PFD loading and everything running perfectly well -- for just 15 secoonds before you close it down. I hardly think 15 seconds is enough for PFD to get going properly. Even so an average frame rate of 25 is good, very good, and the PFD program made an average of 65 requests per second. The Server log is totally irrelevant to the above, of course. It simply shows an FS session runninmg for 18 minutes, with the Client (ORD12) apparently restarting at irregular intervals. Since there's no matching client log there's no way of knowing why. It looks like you did it manually in some cases. The first connection lasts for about 1 minute into the session for about 5 minutes with no problems, reconnecting only 8 seconds later. It lasted another 4 minutes then disconnected and reconnected a good 1.5 minutes later, this time for only 40 seconds. And so on. Whilst connected the performance was good, 24 frames per second, but of course it wasn't connected much. There's no other information I can extract. The client log would show more. Pete

Yes, I did link it to this thread. :-) Best Pete

Hi Chris, I received this reply over in the PM webgroup: Looks like I should simply warn folks off Windows Server in my WideFS documentation? What are you using on the FS PC, by the way? Regards Pete

Ahnaturally I'd assumed that WinXP SP2 came with such already installed. After all I think it does have some sort of speech stuff in it. In any case I only wanted to see what it did. I have no use for it at present (I use a fully switched cockpit setup), though possibly I could use in with a headset for selecting Radar Contact actions (i.e. replying to RC by voice instead of buttons). I'll probably investigate that at a later date. I did try the commercial "Voice Buddy" program for a while, but it was too inconsistent and got me into deep trouble with ATC several times! ;-) Regards, Pete

Even stranger then that the author would ask me for an Access Key for "SpeechBuddy" this June! I'm thinking now that maybe the one he has a Key for is actually a LATER version -- i.e. #3 -- but that he's not "Open Sourcing" it, possibly preparing for a shareware or payware release? There was no version number associated with the details he sent me. In case this is what is happening, I cannot supply a Key for version 2 until I hear from him that this will be okay. He may want to encourage folks to move on. I have written to him on the address he used in June and hope to get a reply some time ... Regards Pete

Hi again, Okay, I have researched this and seen what it might be able to do (though on my system it gives OLE errors). Then I remembered -- the author did request and receive a Freeware FSUIPC Key back in June 2006. But it was for a "SpeechBuddy" not a "Speechbuddy2" -- so the key he received then, and actually built into the program, would not be applicable to the renamed one. I believe some of the other details (in the Version Info) have also changed. I'm not sure what his intentions are with SpeechBuddy2 as he didn't request a new key, so I have written to him too. It is easy enough for me to make one, but I think it should be built into the program, as the previous one was. Incidentally, were you using Speechbuddy before Speechbuddy2? Regards Pete

What's "prm"? Midnight where? Are you talking about Zulu time or local time? The only day I know in FS is the Zulu day. It is well known. There are lots of time zone issues in FS. this is why FS Real Time is so popular -- I use it, and it works well. The downloadable Zip includes updated BGLs (scenery files) too, which correct some of the zoning errors. Er, what a cheek! Why don't you just remove FSUIPC and find out for yourself? Or read the documentation, which describes everything asbout FSUIPC -- the ONLY time-related option (which would need to be user enabled) is a seconds-level synchronisation, that is all. FSUIPC is not an application program, and in any case why should it deliberately mess up time zones and differences for you? I rather resent your implications! Well, a suggestion: go and get FSRealTime and pay the author some money for it, for a good job! I think you'll find it on Avsim. Pete

Er .. autorudder just means you can "steer" with the ailerons -- it's for folks with no rudder pedals. It provides auto-coordination of aileron and rudder in the air, and operates both steering and ailerons on the ground. It makes your rudder pedals rather redundant, if you have any. There's no way that will switch a rudder control to a spoiler though! ;-0 Pete

Okay, I've downloaded some files to look at, but I'm not sure when I'll get time to sort through them to work out what the program does, nor why it needs to use FSUIPC. Unfortunately the web site isn't very explanatory. I read it and I still have no idea what it really does, nor why it needs to do any more than convert speech to keypresses or similar. Can you summarise? Regards, Pete

Possibly. I don't actually know of it. Could you provide a reference so that I may see it please? Are you sure it uses FSUIPC? I'm not sure why a speech-to-keypress, or even speech-to-FScontrol (whichever it may be) would need to use FSUIPC in the first place? I would need Version information for it in order to make the key. I can take a look if you supply some details, otherwise I'd need you to find them out for me. I see you are asking the author about FSX as well. Can you tell me what is FS-specific about this program? As noted above I am having difficulty imagining what it could do that needs FSUIPC or is FS-version specific. Regards, Pete

Sorry, I've no idea how you managed to do thatFSUIPC has facilities for swapping axis uses according to aircraft name, but nothing checking "on ground" or not. I'm pretty sure PMDG don't support any such facility either, so I'm afraid I just don't know how you did it. Regards, Pete

You give insufficiient information I'm afraid. Are you using an offset, or a control, or what, to control the flaps. And how? What does WideFS have to do with it? FS will never change the flap setting on its own, though it is conceivable that an add-on panel may do so -- so test with default aircraft only. Have you tried using the Logging in FSUIPC to see if you can trap whatever it is which is doing it? You can log both axis and button type controls, and you can Monitor offsets. Not knowing anything about how you are trying to control the flaps, I'm afraid I cannot advise further. Regards, Pete

Yes. "Float64" means "floating point 64 bit". It's the unit name used by FS in the same FS SDK that the Names and the Token IDs come from. That'll all be revised -- the whole of that second table will be deleted, most of the values moved into the main part. This is thanks to support for those being made "official" by Microsoft in FSX. Since you are using the SDK (which isn't from "my site" BTW, but from Enrico Schiratti's "Dowson" page), you should also have found in there the program called "FSInterrogate" which not only shows you all these values, live, but also enables you to view them all in all supported formats, including "float64". Additionally, you may like to look at the Logging options tab in FSUIPC options. On the right-hand side there's a facilitiy to monitor any offset, and again one of the units you can choose is "FLT64". These facilities are documented in the Advanced User's guide for FSUIPC. When you are investigating values you can get from FS it is useful to know about these things. But "size" is a relative term. For example, just 1 64 bit floating point number is actually 8 times longer than 1 8 bit integer ("byte"). For all I knew your line for "SIOC" may have been using bytes, words, double words or 654-bit values -- all are valid units. If it needs size in bytes, then you need to know that the size is determined by the type of value: FLOAT64 is a 64-bit floating point value. 64 bits is 8 x 8 bits, so 8 bytes. There's NOTHING else in "this". It's a 64-bit floating point number!! There's only the 64 bits of that number in it! Your question makes no sense, sorry. I'm afraid the FSUIPC SDK is aimed squarely at programmers. That's what "software development kit" means -- a kit for programmers doing software development. From what you say it seems to me that this "SIOC" stuff must also be aimed at folks with some technical experience? Or is their documentation just not up to scratch? Please take a look at the tools I do provide. Play with FSInterrogate for starters, look at the various values it reads. I'm sure you'll learn a lot. It isn't just that list -- browse through the values in the main list. There are plenty of "double" floating point values there too. and some of the values in the "FS2000" list are BOOL (32-bit), BOOL16 (16 bit), SINT16 (16 bit), etc. The list is simply one derived originally from the Gauges SDK for FS2000, to which some offsets have been mapped. As I said, I'm integrating most of those into the main list. But this won't change what sorts of numbers they are. Regards, Pete

Supported, now, actually. I thought they were among those I moved to the first table? If not they will be in the next update. There's quite a lot of "unsupported" data which is being provided by FSX via SimConnect, so I can safely assume it will be okay for the foreseeable future. ;-) Yes, the double floating point value at 2834 is what you need. I don't know what that is supposed to mean, but if you are trying to read it as a 1 byte integer you will get it wrong. It is an 8-byte (64-bit to be precise, floating point number, a "double" in C/C++ terms). It is listed of course -- 2866 is part of the 8-byte (64-bit) value at 2860, the "hot battery bus voltage". You are not reading the list correctly at all I'm afraid. You are simply taking a small part of a large number. Again, I've no idea what your size of 1 means, but 2866 isn't an offset of anything at it stands, but part way through. All those variables labelled "FLOAT64" are 64-bit floating point numbers, at the offsets given. I'm afraid I cannot predict what you will get if you take small bits of 64-bit numbers! Regards, Pete

Sorry, there are no sound facilities in FSUIPC. I think you need to ask the PSS support folks what can be done. I don't really understand much of that, but it does really sound more like the panel you are using is simply designed to prevent external controls being used. Have you asked their support about these things? I really cannot see how I can provide more than the generic facilities I have done -- Iam really not in the business of doing specific drivers for specific products. Maybe PSS ought to look at supporting folks with hardware? Regards, Pete