Pete Dowson

If that were so you'd get shifted m (i.e. M) all the time, not the unshifted m. Also keys from the normal keyboard will be shifted too -- all thse keyboard messages go via the same queue in Windows. Do you have the Microsoft spyxx program? If so you can use it to monitor keyboard messages in the main FS window ("FS98MAIN") and see exactly what is happening. But it is not likely to be anything to do with the virtual buttons or WideFS operation -- the programming of keystrokes in FSUIPC is exactly the same no matter what the trigger. What is this "m" or "M" being used for? How are you actually detecting the difference? Regards, Pete

Yes, though apparently it is more so for those of us with Retinitis Pigmentosa, which has been progressively getting worse for the last 10 years. It was that which stopped me flying for real. The eye on which they removed the cataracts first is actually the one with the worst R.P. induced tunnel vision, so it gives me better long sight but very very narrow! :? Ah wellthe date for the other eye has just been confirmed as July 14th (Bastille Day :) ), so not long before I'm hopefully running normally again. Regards, Pete

Well the control acceleration only occurs when there's something (program, Gauge or DLL) continually sending controls to FS, a t a rate fast enough to fool the rather simplistic code inside FS which assumes that, if a control arrives within so many milliseconds of a previous one then it must be the same one again, so it needs to speed it up. Mostly this is caused by some add-on panels which have gauges or modules (DLLs) which send these controls. If it's a DLL it may not matter which aircraft you fly. The fix in FSUIPC is relatively simple. It intercepts ALL controls and if it sees one which is different from the previous one it overwrites the FS timeout which is used to accelerate it. If the control is the same as the last, FSUIPC leaves it be. Regards, Pete

Er, no. Chucking stuff generated by my own logic out to a COM port involves Writes. There are no Reads at all in GPSout. However, that's not the point -- there are no NMEA parsing instructions in GPSout. There are no writes to FSUIPC. None of the code in GPSout is applicable except possibly the opening and closing of the COM port (as a file). You'll find COM port I/O easy enough. It's handled in Windows just like a file. You open it, read it, close it. There are extra bits for setting port properties and so on but they're easy to look up! I don't remember this stuff, I look it up as I go along in any case! Regards, Pete

I take it that you are programming the button normally, in FSUIPC's Joystick page? Of course, there is absolutely no difference in that whether the button is local to FS or via WideFS, or whether it's a "virtual" button or a real one. So the question is, are you losing Shift events on your FS PC when using something local too? All FSUIPC does is use the Windows SendInput API to send the programmed sequence to FS. What triggers it to do this is completely irrelevant. The SendInput API generates the standard WM_KEYDOWN/KEYUP sequences. You can, of course, also send those yourself, from your program, using the facilities in offsets 3200-320B inclusive. What are you trying to do, BTW? Keyboard simulation is not the ideal and most precise way to control things normally. Regards, Pete

No, sorry. Personally, I don't see the point of using FS as a moving map when there are much better and more accurate map programs which run faster and smoother. However, others have already mentioned this (see several threads here on the subject), so I expect there are some developments along those lines in progress somewhere. It's an application that any programmer can provide, but it isn't really of much interest to me -- I provide the tools, like FSUIPC, which make it possible. GPSout was written many years ago (FS95 time, way before FSUIPC and WideFS) for my own amusement specifically to provide a moving map for FS. Ah, I see. I expect that reading the output from a GPS and using it to inject positional data into FS would be a relatively trivial program for you to knock up then. You could make it very specific to the particular GPS you will be using, so cutting down the work needed for a full NMEA parser quite significantly. Regards, Pete

What exactly is the PrecisionFC CDU? Is this the separate PFC hardware CDU built with its own PC inside (I have one of those) and running PM's CDU, or something entirely different? Errrors logged in the Server Log and/or the Client Log, or what? I cannot see them from here, perhaps you'd like to show me an extract? It does sound like you may have too much running on the one Client. What processor is it? If it is the PM CDU you are running, on the same PC, then it doesn't indicate an OpenGL problem particularly because I don't think the CDU uses OpenGL. But this sort of thing needs checking with the PM folks. If you are running all of the PM components on one slow processor I would thing another (cheap) PC would be a better bet. As I said, I don't think the CDU needs a particularly good video card. Are you perhaps running with 2 or more separate monitors on the one PC. If so, then it may be the loss of hardware acceleration for OpenGL which is doing it. In that case, possibly later drivers or a new video card may help. But I am the wrong person to help here -- you need some of the PM expertise you will find in the PM Newsgroup. Regards, Pete

Yes, it does actually explain the number of connections business, as follows (5th para under "Running WideFS"): However, if you get this often then you are having some problems. First, please make sure you are using the latest version -- 6.23. If you still get this symptom, check the Log files (WideServer.LOG and WideClient.LOG) -- show bits to me if you want some diagnosis. Regards, Pete

Well, there's no harm in asking. Sorry if the answer wasn't the one you wanted. Regards, Pete

That's what I thought you meant, and as I said, it is not possible -- unless PM was simply frozen, or running in demo mode. But this is a question for PM, not me, in any case. Good idea. you should be able to get a new key easily enough. Regards, Pete

You are addressing this to the wrong person. If you want your stick fixed for free I suggest you contact the makers. If you want it calibrated better then try Windows, whose "Games Controller" is supposed to do such things. Every user of FSUIPC wants something different from it. If I made each desirable part free, what would be left? It isn't a realistic nor sensible request I'm afraid. You can of course download the SDK and write your own program to control the throttle, or you can try some of the other offerings for axis programming, like FS-Communicator. Regards, Pete

Hope you mean in terms of fatigue and work, not that something happened? Best wishes (to your wife too) No, only the problems of using the two eyes together whilst they are totally different. The 'new' eye has gone off a little and seems to want to be out of focus like the old one now -- the surgeon said it's my brain trying to make sense of it all! When I get the other eye operated on so they match better I'll be okay (he says). I am hoping this will be done on the 14th July now (that's the best date I could get from the Hospital). My wife got back from her hip operation yesterday, and is walking around using a couple of sticks. This is only 6 days after her hip operation! Amazing! Best Regards, Pete

Hmmm .. good luck! You will need the FSUIPC SDK (from http://www.schiratti.com/dowson), but working out how to move the platform in response to the simulators accelerations (all of which are available for FS2002 and FS2004) is something which I would have no idea about -- it obviously isn't just a matter of applying the numbers. You need to make the platform move in ways that make the occupant(s) feel as they would in the real thing, without actually moving the platform as the real thing moves. Not sureI know that Ralph Robinson (R & R electronics, makers of the EPIC) has been involved with some folks in the U.S. building and programming one, using EPIC for the PC interface of course. Maybe a web search will find other contacts. Ah, you are quite far advanced then. So the EPIC reference isn't correct for you. I'd take a look though the data available to you from FS and plan how to make use of it first. Learn to program a bit, even VB should be okay -- not sure how clever it has to be if you already have the interface to the hardware sussed. Regards, Pete

FSUIPC 3.30 will help. It has been imminent for a while and still is. I had hopes for a Release this weekend but it looks like being early to middle next week now, but I'll get to it as soon as I can. My eyes have been proving more troublesome than I anticipated. Regards, Pete

Hi JD. I sent Peter 3.253 to try and he has confirmed that the problem has been solved. Thanks for the offer though! Best Regards, Pete

I don't think that is at all possible. I think you mean that the PM software is frozen, hanging? What does PM support say to that? You had no errors on this Client for over 20 minutes, but then a short-lived problem where it had a difficulty sending something to the server. This may have been because you had FS loading a file or something. There's nothing significantly wrong though. The only other error: 1900603 LAN data received: PREQ ulSize=276, ulTime=22330, uSum=22431, fUsed=0 20 00 00 FE 04 00 AC 0C 00 00 74 02 00 FE 02 00 1900603 --> Sumcheck error! 1900603 Size Act=287 Exp=287, Sum Act=22737, Exp=22431 1900843 GetRecv() missed block? Sequence 22330 jumped to 24012 1934571 Reception maximum achieved: 39 frames/sec, 4930 bytes/sec Looks as if the client PC was frozen (hardware or driver problem) for a while -- quite a while judging by the gap in the block numbers (22330 to 22431 -- 100 blocks missing!!!) Again, with WideServer: 1925547 Retried 137 times: sends blocked for over 5 secs! (0 of 349 sent), Error=10035 (skt=3716) 1930563 Retried 135 times: sends blocked for over 5 secs! (0 of 361 sent), Error=10035 (skt=3716) 1930766 Send ok but needed 5 attempts! (360 of 360 sent) (skt=3716) 1956578 Retried 137 times: sends blocked for over 5 secs! (0 of 381 sent), Error=10035 (skt=3716) 1961594 Retried 136 times: sends blocked for over 5 secs! (0 of 395 sent), Error=10035 (skt=3716) 1962813 Send ok but needed 32 attempts! (395 of 395 sent) (skt=3716) 1974641 Send ok but needed 134 attempts! (369 of 369 sent) (skt=3716) 1987422 Send ok but needed 109 attempts! (380 of 380 sent) (skt=3716) 1998781 Send ok but needed 115 attempts! (302 of 302 sent) (skt=3716) Those errors look real bad, but before that there was absolutely nothing wrong for over 32 minutes. So it doesn't lok like there's anything wrong with the Network, at least with the WideFS linking. Errors like Sends from the Server being blocked, or needing many retries, are usually caused by hangs or problems in the Client, but as seen in the Client Log these aren't occurring in Wideclient. The prime suspect in my opinion will be the video drivers, the OpenGL parts used by PM. If they hang or cause problems it will affect everything else on the same PC, whereas is there were problems inside the PM code itself the network should still run okay. If it isn't the video side, then some intermittent problem on the Network Card (unlikely) or a virus. I think you need help from the PM folks. WideFs is doing okay here, honest. It looks most likely to be video drivers, but as I said there are other areas. Check with them for some advice. Regards, Pete

Better not rush though, as your Log shows that FSUIPC is actually crashing on your FS2000 installation. It traps its own crashes and logs them, as that way not only do I avoid crashing FS but I'm able to get more information, which FS and WinXP in particular are otherwise very reluctant to give me! I'm sending you my latest Beta to try, just in case it is now fixed. There have been a *lot* of changes since 3.22. If that fails too I shall have to get FS2000 up and running again, to see for myself. Regards, Pete

Thanks, but my eyesight won't be fixed till the other eye is operated on. I see the surgeon tomorrow and hope for an early date. Meanwhile using one eye at a time is tiring. Please ZIP it and send it to petedowson@btconnect.com. Did you check the Technical option I mentioned, and try it switched on or off (whichever it isn't?), or is your copy not user-registered? Regards, Pete

I just mostly use the defaults without any problems, though I think you probably should check that The Network device property "Link Speed/Duplex Mode" or similar is set to 100 Full rather than Auto modes (I think Auto slows it down a touch). Receive buffer maximum of 64k if that's there. For TCP/IP it is best if you assign fixed IP addresses to each PC rather than have them being looed up and assigned each time. And if you've then got nothing else using IPX/SPX, uninstall that protocol on every PC. (If you use WidevieW you won't be able to, however). For more authoritative network advice I'd ask Katy Pluta over in the FS2004 forum. She has helped me a few times! :) Regards, Pete

Check the FSUIPC options in the "Technical" page. This is the relevant part of the FSUIPC User Guide: I'm not sure what's happening with the sign reversal -- the FSUIPC fix was originally designed for FS2000 because it can get the sign wrong by itself. With FS2000 not being used very widely any more, and of course many many developments for FS2002 then FS2004, maybe some error has been allowed to creep in. I can investigate this, but can you please see if you can get it down to basics. No Radar Contact or AdvDisplay needed. Just try setting a higher altitude with A/P Alt Hold on, and see what V/S is set, and similarly a lower one. If you can reproduce it easily that way, fine, just tell me. If not then we need to examine the details of your previous experience more. Like are these specific altitudes (what to what), and is Radar Contact's co-pilot doing anything or are you in sole command? Sight of the FSUIPC Log would be useful too -- especially if you enable "Extras" logging first. Thanks. Regards, Pete

Sorry, I've absolutely no idea what the panel is doing. You really do need to ask the folks who did itt, or at least someone who knows a little about panels. I don't even use any. The first thing I would do is try a complete re-installation of the panel. After that you probably need to check the list of Gauges accessed according to the PANEL.CFG file against the gauges you have installed. It is possible that one is missing, misnamed, or misplaced. Regards, Pete

The log showed the gauge registered. You don't need to keep doing that. The business about restarting the program, for an aircraft gauge, would simply mean reloading the aircraft. If you want to you can close FS and restart FS, but surely you must have done that at some stage in the course of this thread in any case. Once the gauge is correctly listed in the FSUIPC.KEY file you can forget about registration. That's over and done with. Your panel problem is not at all related to FSUIPC access registration. Regards, Pete

"Final" answer? sorry, I really have to be prepared to answer most if not all questions. :wink: In terms of actually typing the name and key into FS, of ocurse you can only enter one at a time. But then you can "Ok" out of that and re-enter the same dialogue to register another, and so on, all day if you like. All that dialogue does is do a little bit of processing on the data and save it to the FSUIPC.KEY file. Nothing more, nothing less. It is the list in the [Programs] section of the FSUIPC.KEY file to which FSUIPC refers when a program, gauge or DLL requests access and does not provide a Key directly through the FSUIPC interface or via its Version Information details. (You see there are several (easier) ways for programmers to make the access automatic, and many do. But sadly many also do not). For programs with only alphanumerics in their names, you could actually simply edit the FSUIPC.KEY file and add the keys there. Accented characters and non-alphanumeics have to be eliminated -- excepting the "." in ".gau" and ".dll" for those two types. EXE files omit the whole ".exe" part. No, that's wrong. There is absolutely no limit whatsoever to how many are listed. All FSUIPC does is look to see if the program has a correct KEY in the [Programs] section of the FSUIPC.KEY file. It doesn't matter how many are there, but you can't have two programs with the same name. Regards, Pete

That's all fine. Sorry, I think there must be something corrupted in the FS installation someplace, most likely to do with the scenery stuff. As to why it seems okay without FSUIPC but not with, that is most likely a difference in the memory layout with the extra module installed. One last thing you can try -- set the InitDelay parameter to, say, 3000 or even more, to make FSUIPC refrain from infiltrating FS's main window for that number of milliseconds (3000 = 3 seconds). This is a long shot, but since, as I said, FSUIPC isn't even doing much other than gathering information at that time, there's not much else that can be changed. If that fails I can only suggest a re-installation of FS. Regards, Pete

Yeah, that's all fine. As I thought, the panel problem isn't related to any FSUIPC access problem. Sorry, I think you need to recheck the installation of the panel and its gauges. Regards, Pete