Pete Dowson

Aha, yes, 8Hz would be jerky. Maybe you could try interpolating intermediate positions if you cannot get something better? Pete

There's really been no change in that area, none at all. But what "X" in 3.6X/6.6X? Where are you configuring the Button? There's no information in what you've provided. If in FSUIPC, you need to check the assignment. That's the main suspect surely? "ActionKeys" hasn't been needed or used for several releases of WideFS, not just the last one. A log of the WideFS actions may be useful -- is your client actually connected? Please check the WideFS logs for both ends. Why bother to specify the ServerIPaddr in the client.INI? I see you are using "ProtocolPreferred" in the Server, so you must be using WinXP all round. You don't need to specify a Server at all. And there's really no point in having ProtocolPreferred in the Server with "Protocol=UDP" in the client -- take the latter out too. Regards Pete

Is the sim restricted to running at the same frame rate? 25 mSecs, if consistently achieved (is it?) would be 40 fps. It maybe better to aim at a lower rate so that both can sync more reliably -- eg, 40 mSecs for a 25 fps limit. It may also be better if run on a PC with dual cores or hyperthreading, where your program and FS are running in separate 'processors'. Finally, there are several modes in which FS can be when doing this. Before FS2004 you actually had to put it into Slew. In FS2004 you can try Slew, Pause, Zero simrate, or normal flight modes. Experimentation may be needed. Regards Pete

I'm sorry, but you'll need to ask Microsoft. In the past the Microsoft FS SDK's were always quite a bit after the main FS Release date -- in the case of FS2004 coming in trickles over a period of many months. However, from what I have read there are high hopes of having SDKs quite early for FSX, possibly at or soon after launch date. We shall see. Regards, Pete

I think for basic things like throttle and trim settings, the standard FS offsets work fine. After all, they are the values the SIM engine inside FS is using at the time, no matter what clever programming there may be in specific add-on aircraft to set them. Really, the main difference with some add-on aricraft in in the autopilot control -- the settings on the MCP. Surely your motorised throttle and so on only has to folow the current Sim settings for those values, not worry about the MCP values? Regards Pete

I keep things parallelled, don't fret. Pete

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