Pete Dowson

They are different controls altogether, and the same ones you get on the Keyboard. What for? I can sort of understand why you might want to disable axis inputs, in case you are getting jitter or interference, but surely you don't need to touch the buttons? Same would apply to the keyboard ...? Regards Pete

Here's 2.606! Pete GPSout2606.zip

Ah, a complete circle, eh? What is the serial port speed set? That's really the limitation -- if the defalut speed of 4800 is set then that's only 480 bytes per second which would only allow 48 bytes in each burst with a 100 m/sec delay. What would happen is that a big backlog of data would occur in the PC's serial port driver buffers, until they overflowed and you got some errors., then it might start all over again. meanwhile there's be an increasing delay noticable in the results on the device as it got further and further behind. I'll put the Q and C fields back as they were ... Pete

I thought it was the reverse. It most certainly doesn't use RAW values for axes. But for POVs it must do, surely. I'm sorry, but I really don't understand what is going on. Not since FS98/2000 days when I used EPIC. That's where that text comes from. Sorry. I think in those days there was no "POV_MOVE_EVENT" entry. But also, in those days, FS was using the standard joystick API in windows, and values went through more or less unmolested. Since they changed to DirectInput in FS2002 I'm afraid I lost interest somewhat and I don't really know what happens -- except that DirectInput seems to mess with values. I still use the original Joy API in FSUIPC, and have the facility to read axes in RAW form in the Axes assignments section. But currently there's no POV support there. I suppose that is something I could add -- reading RAW POV values like an axis. It is possible, but not just at present as it isn't a trivial job (lots of table changes to accommodate another axis type after XYZRUV), and I don't have the time to spare at present. If you still haven't solved it by November, say, get back to me and I'll see what I can do. For now I'm afraid it's a case of continued experimentation and debugging to find out what is going on. Sorry. Regards Pete

The FSUIPC steering tiller merely operates the rudder. FS itself currently does not provide a true steering axis at all. The only difference, having a second axis, is that it can be calibrated to be more effective (for turning), whereas for normal rudder operations in the air you wouldn't want such sensitivity. When just operating in increments / decrements it is identical to the rudder, so use the rudder keypresses. Regards, Pete

Still talking about FSUIPC I assume? Sorry, but if you want to use FSUIPC version 3.xxx (and 3.70 is current) then either your "carrier ops" program needs an application access key -- which it is most unlikely to have if it dates back over three years to FS2002 times), or you will have to purchase FSUIPC and register it as a user. I would have thought that the program would have come with, and installed, a Version 2 of FSUIPC, which was relevant to the FS2002 era, and needed no keys whatsoever. That is why I suggested in my other reply that you have an installation problem. Regards, Pete

The "latest version" of "carrier ops"? Sorry, that is nothing to do with me, I have never even seen it. If you really mean FSUIPC (and if so you should say), then they certainly should not have done that, but merely pointed you to http://www.schiratti.com/dowson where you can download it. Just because you installed FS2002 and crarrier ops on a new computer certainly doesn't mean you need a new version of FSUIPC -- you'd be better off using the one you were using on your old computer. If the carrier ops package was never ported to FS2004 then it may not have an access key for FSUIPC versions 3.xxx, which means you would have to purchase a user key. Ah, so you ARE talking about FSUIPC? You have not actually mentioned what it is you are talking about anywhere in your message at all, do you realise that? It would help if you did, you know! Where did you read that a Key would be sent to you? Have you been to SimMarket and purchased one? I've no idea -- probably because you didn't install it correctly. If you were using an unregistered version of FSUIPC, or version 2.xxx on your old computer, then the same would work on the new. It is not PC dependent. It all sounds like a botched install to me! Regards, Pete

I've really no idea how FS POV assignments work at all. Sorry. Does FSUIPC logging show what's happening at all? For a normal Hat there's usually an "off" event which usually does something like restore the forward view. Could your device be sending something like that -- a -1 or 0 when you release it? If so, that could certainly do what you observe. Does it actually change the heading before you release it and it goes to 360? Oh, one other thing. I think there can be two different hat resolutions, one which goes 0 to 360 and another which uses units which go to to 36000 (i.e. in 1/100ths). I'm writing from memory here so it may not be quite like that, but I do recall something like that. Possibly, if your device is configured (in the HID driver?) to give the wrong one the values would be out of range in any case? Regards, Pete

The main slew axes are disconnected by bits in offset 310B. All six should most certainly work -- they are all programmed in exactly the same way. I've just checked, in fact. the FS axes they deal with are those named AXIS_SLEW_AHEAD_SET AXIS_SLEW_SIDEWAYS_SET AXIS_SLEW_HEADING_SET AXIS_SLEW_ALT_SET AXIS_SLEW_BANK_SET AXIS_SLEW_PITCH_SET in that order. There's zero difference between how each of these are dealt with because it is the same code -- a bit match against the control codes for the above (65867 to 86872) less 65867. i.e. numbers 0-5 used to shift a bit mask for the bit on 310B. >> As a test, I set all eight bits and found that only the first three had the expected effect. << Log IPC writes, Monitor 310B to the log, and log axis events, then check the log to see what is happening. Pete

I know little about Elite hardware, except that I'm pretty sure it is non-standard. It won't be seen as a joystick type device by FS or FSUIPC if it isn't by Windows. In that case it is a bit like the serial port PFC devices, for which I do a module. However, I do provide good calibration facilities in the case of PFC. No, and no, sorry. Elite are solely responsible for supporting their own devices. I believe they use FSUIPC as well, but they've never once got in touch with me. Regards, Pete

Try 2.605, attached. Pete GPSout2605.zip

I think so. In FS -> from "user defined" to clear In FSUIPC -> turn off weather Hmmm .In my experience the FS weather always spontaneously changes to "user defined" when any external program tries to do anything with it. In fact it was one of the (unexpected) problems with some of the global weather filter options in FSUIPC. Regards, Pete

What problem? You've not mentioned one. Anyway, the answer is, no, FSUIPC does not use the internet. Pete

Right -- I suspect that the bits changed by the other PM ND control you used was programmed for the older mode and that's why it doesn't work with the new one. I don't think Enrico properly maintains the use of the toggle bits method those FSUIPC PM commands use, preferring things to go via the general parameter-driven interface. I think this comes about because of the complications with assorted modes and first/second officer differentiation. Regards, Pete

Right. In fact 2000 os probably long enough to cause some programs to time out the FSUIPC connection and report an error! But it does indicate that the cause of the problem is not some initial zero the program wasn't expecting. Really, I doubt if I'll be able to get anywhere -- the author needs to be involved. I can help him, of course. That is actually very strange and points to something other than WideFs entirely. It sounds like it is more to do with the installation of the software. I'm surprised it uses the registry so much. I try to avoid that as it makes things far too install dependent. No, not at all, sorry. No, thnkyou anyway. I am really far to busy. ;-) Regards, Pete

FS weather should always be "user defined" if it is being set by an external program. In fact just the act of setting it externally makes it user defined. Sorry, I don't understand what you have changed. Pete

I have no idea why it would want any in the first place! One other user of P8R wrote me that he tried to reinstall XP, WideFs and the P8R softs and that the problem was solved. The "Log=Yes" wasn't for fixing anything, only to see what the program was asking for just before it crashed! Really the author of the program should be investigating and fixing this. He seems to be shirking his duties! Pete

Well, yes, that should easily be possible but ... ... this really indicates that you have something wrong with your parameters in the WideClient INI file. No way pressing "C" should bring up the Windows taskbar. You are somehow causing a different keypress, or having it addressed to the wrong program, one minimised to the task bar. If you want me to check that you'll need to tell me what programs are running on that PC and show me your INI file. Regards, Pete

Sorry, no, I do not. It sounds like his program is assuming that all data it reads is going to be valid straightaway, but with WideFS it can be many milliseconds for some values to initialise. Before that they will read as zero. Now zero is NOT an invalid floating point value, but I guess he may be assuming that he has a non-zero value and is doing something naughty with it, like dividing it into something. I would have thought that this would give an overflow errors, and maybe it does -- but his message "invalid floating point error" may be a catch-all. (I wonder what a valid floating point error would be! ). There is a parameter in WideClient which you could conceivalby use to make the program wait longer for any fresh data it needs. This is defaulted to 500 msecs (half a second) which should be easily adequate, but perhaps it all depends upon how fast the connection is and how much other data he is requesting simultaneously. Please see the first Question and Answer in the WideFS document. Registry? Don't understand that. Or is he rferring to a list of data items he reads, in which case he might be asking you to find out which one it is by a process of elimination. You can use the extensive Logging facilities in WideClient to see what the last data his ND read was before it crashed. Use Log=Yes, as described in the documentation. Keep the session short with only the crashing program running. I can help you decode the log afterwards. Regards, Pete

No. Don't fiddle with any WideFS parameters, they've all been optimised over a long time. I only still have the parameters for testing purposes. Are there two or more possible routes betweenn any of your machines? Is it daisy-chained, like a firewire link, or a star network with a hub or switch? If its a hub I'd strongly recommend changing to a switch. Have you looked at any of the WideFS logs to see if there are errors reported? UDP is not guaranteed nor checked. It's super for distributing data which is changing all the time, such as keeping gauges running (eg on Project Magenta's PFD or ND), as if some frames are missing now and then it doesn't matter so much because the next will be along soon. Even so, having said that, I have it working fine on my 8 PC Network but *only* after changing from a firewire daisy chain (400 mbps) to a standard 100 mbps switched star network. If it is too much pain using UDP and finding what the problem is, stick to TCP or even try SPX. Both of those are fully checked and "guaranteed". It is for these reasons I always avoided moving to UDP, even though FS multiplayer does use it. I only added it when I found out how easy it was to implement, so thought it worth a try! ;-) Regards, Pete

It is actually beginning to sound more to do with FSMetar's weather update methods. Your PC certainly sounds okay. Can you find a Forum where other FSMetar users gather? Maybe you can compare notes. I'm afraid I just don't know the program. Sorry. Regards, Pete

Not sure. Have you tried reading the FSUIPC manual and followng the suggestions there, especially calibration? Does you TQ6 work in FS in any case? If you have no response in FS, then there's really no point in asking FSUIPC to do anything. Please start from basics. After that, if you'd like to formulate some more specific questions, i.e. ones that can actually be answered, I'd be glad to help. But I think you need to do a little more first, please. Pete

Can you please post this on the PM support webboard. It is something which I am sure can be better answered there. All the FSUIPC "PM control" facilities are doing are toggling bits in PM-owned offsets. What happens then is totally in PM's hands. As for KeySends, that really isn't a route I'd take with any PM modules -- they are far better controlled through their offsets, and that is, in fact, how they communicate with each other in the first place. However, you say: What, here, do you mean by "lower toolbar"? I'm really not sure why you can't produce a 'C' keypress aimed at PM, but if you show me the settings I may be able to help. However, I do think it's the poorer method, by far. The most likely difficulty you have with PM ND modes is due to developments in PM -- there have been a lot of changes and unfortunately I think some of the bits originally allocated for functions no longer operate in the same way. I have not been able to keep up with all the changes that occur in PM. You may find that you need to send a value to the general "PM GC Controls" offset instead. There's an FSUIPC control for that too. If you look in the FSUIPC Advanced User's guide you will see a list of parameter values, including Boeing "classic" mode 'MAP CTR' (your 'rose') and the new ND mode 'CTR pushbutton'. I think which works will depend on how you've configured your ND in the PFD .INI file (or via the options on screen) as PM does support so many different ways of doing things now. Possibly, the only reason you've had any problems is because you'vce abandoned the 'classic' mode settings and gone to the 'new' modes. Sorry I can't help much more. I tend to get equally confused as PM changes and i cannot see what does what. But folks will have sussed it out, and they will be on the PM support web site/newsgroup, which is where I think you should be? Okay? Regards, Pete

Hmm -- stutters with no clouds? In that case I should think the problem is one of your PC. Are you running FSMetar on the same PC as FS? I assume it is getting weather from the Internet? What sort of Internet connection are you using? When I used to have a slow internet connection and a slower PC I used to dowload the whole weather (using FSMeteo) before I started flying, and then let it use that with no updating off the internet. These days I run ActiveSky on a separate PC via WideFS. Maybe it is just that your PC cannot cope? What is it? Regards, Pete

No, I never managed to find any way to hook that. I would have liked to extract the text itself to help automate responses. No, see above -- you are wanting to do what I wanted to do, but I couldn't find my way through the mass of C++ OOP class structures and Direc3D links. Yes, but they were before I added the new Window facility. All RC's menus come through offset 3380 -- programs like AdvDisplay (in FS) and ShowText (on any WideFS client) pick them up from there. You can do the same. It's just text. Regards, Pete