Pete Dowson

You really cannot be ending the process then. Regards, Pete

Is this with WinXP? You can certainly delete the whole process with WinXP without re-booting. Ctrl-Alt-Del brings up the task manager. Select the processes tab, scroll down and find the FS9.exe entry, highlight it then press the "End Process" button at the bottom. Win98 is a different matter. After any crash of any program in Win98 you should re-boot in any case. Regards, Pete

The read/write calls do nothing except add the request to a list. They are nothing to do with the interface to FSUIPC at all really, just a convenient library function to save you having to generate the appropriate structures. The only time FSUIPC is involved is when you do a Process call. that sends the data off and gets the response. Read/Writes therefore take no time at all. You should be accumulating all the reads and writes you want to do on each cycle and passing them all in one Process. The only exceptions to this are when you need the results of one read before doing another, as in the case of protocols involving timestamps. Pete

No. Using the FSUIPC_Open2() method (which you must, from a Gauge) simply sets up the data control areas used to accumulate the data and responses you request. The connection to FSUIPC is via registered messages. However, a Gauge of course is only loaded and running in FS when the panel it is defined in is loaded, so during the course of an FS session the gauge may 'connect' and 'disconnect' several times as you load different aircraft with different panels. No, not at all. It does sound like your gauge has some sort of problem. Better to use FSUIPC's logging. Enable the IPC read and write logging and see what is going on between your gauge and FSUIPC. ZIP it up and send it to me if you like, with a commentary about what you did. petedowson@btconnect.com. Also, use FSInterrogate to try writing and reading the fuel values, to check that you do see what is happening okay. Regards, Pete

Sounds like something is hanging in FS, presumably part of the Squawkbox add-in modules. Rather than reboot the PC you should find it easier to use CTRL_ALT_DEL and close the FS9.EXE process. Closing the FS9.exe process would be better. This proves that there's no change in FSUIPC which will have done this. You need to report this to the SB developers. The fact that it appeared to start doing this when installing the latest FSUIPC must be a complete coincidence, because replacing the DLL does completely change versions of FSUIPC -- there is nothing hidden anywhere at all, and FSUIPC makes no changes to any files or registry entries used by FS, none at all. Okay. Regards, Pete

Thanks. It does look interesting, but it isn't something I want to get into at present. I seem to have too much on as it is, and I'd like to actually get some time to fly before the work for the next version of FS has to be started! :wink: And, sorry but I don't tend to use procedural interfaces except where I have no choice, as they tend to be too inefficient for WideServer servicing of clients -- it has to maintain a list of data being read by each client and scan it frequently enough looking for changes to keep those clients going at roughly FS frame rates. If I had to make gauge type calls for each then it would never get done in the time available. BTW, another way to find stuff like fuel would be to trace through from the "OKaying" of changes in the fuel dialogue to see what happens to it -- i.e. how it gets written. It may be quicker to do it this way for specific items like that. I needed almost everything in the engine and fuel departments, so I had no choice but ot do it the hard way. Best regards, Pete

The only way to discover this sort of thing is to hack into FS. You need a good debugger -- Soft Ice is good but a tad expensive, and a disassembler -- I use IDA. Start with the SIM1.DLL, that is where most things are done. It gets very complicated and very messy. The data is not in fixed global areas, but in private data owned by classes. The classes all seem to be derived from each other, meaning that there a pointers to pointers to pointers et cetera to follow through. And these are not static. Each time you load a flight or aircraft the class instances involved are destroyed (along with those data areas of course) and rebuilt. Worse, in FS2004 for the first time there are lots of separate ones for different subsystems and each of those only exists when it needs to -- Helos for instance have a completely different set to gliders. This is really about all I can tell you. 90% of the code in FSUIPC is concerned with this sort of stuff, and developing it takes many months of solid 100 hour weeks for every new FS release. I'm sorry if the results seem inefficient to you, but the FSUIPC code itself is relatively sleek, especially compared with the contortions that the use of C++ seem to be inducing in the innards of FS itself. Ah, it all used to be so easy in FS4! That's kind, but isn't that available through the GPS_export DLL provided by Microsoft? I don't really want to duplicate stuff. Thanks anyway. Regards, Pete

This is without those changes I suggested to PFC.INI? Maybe there was some resource conflict with the port the modem was connected to. Regards, Pete

Hmmm, well, yes -- "guaranteed ordering of frames" isn't the same as "guaranteed no missing frames". That's more about data arriving out of order because of the queuing inside WideServer and Windows. In fact, the other part, where it says "retries are also reduced by better scheduling and not even retrying for Server transmissions of data changes, just leaving them to be seen again next time round." could actually induce more missed blocks if there were problems of blocking network connections in the first place. The part "excessive logging of missed sequence numbers is avoided in cases where the server knows that the frame couldn’t be sent, by backtracking on the frame numbering system" is related to spurious extra logging of the same single missing block error because of subsequent errors in block numbering. Quite honestly, whilst things will have improved -- I always strive to improve my software all the time -- I cannot honestly tell you that the problems you are getting would be any different with today's versions. That may be, but it really doesn't seem so likely to me. If you could only say what you changed since having a working 5.40 WideFS network -- I simply cannot believe you've had the same problems with WideFS ever since the release date of that old version (February 2003). All I can say is that if you had problems with today's versions AND if they turned out to be caused by software rather than hardware, then at least I'd be in with a chance of diagnosing them and maybe fixing them, for instance by turning on some more logging. There is no point in turning on extra logging in version 5.40 because I cannot match what it logs to the software, because it is too old. Sorry, is this relevant? I'm not really sure about all that stuff -- I did some things like right-clicking on folders and selecting "share" or something and giving access permissions. I haven't really touched any of that for ages -- it isn't needed for WideFS, only for PM, and I think there's a program available from the PM site with which you can check it all. If I were you I'd run that and check the results. I have the CDU in its own PC (1.2GHz). I used to have the MCP running there too, when my main FS PC was a 2.4GHz one. When I upgraded the FS PC to a P4 3.2GHz with hyperthreading I found everthing was a little smoother by running the MCP on the FS PC. I think it helps keep the main WideFS network traffic down when the MCP is controlling the flight. You check your frame rates first by setting the limiter to "unlimited". Do a typical flight and observe the fps, then set the limiter to something lower than the average (not just lower than the max) -- the idea is that it should be set so that FS is hitting that limit almost all of the time, so (a) remaining less jerky and (b) always allowing some time for other activities, like WideServer. Remember, I am using FS2004. I assume you are using FS2002 -- otherwise you couldn't be using such old modules of mine. When I was using a 2.4 GHz I had to turn AI traffic down as well as much of the graphics, and the limiter was down to around 15 fps I think. With the 3.2GHz PC and FS2004 I have the limiter set to 20 or 25 fps, and most things up full. For FS2002 I expect 18 fps is fine on a 2.4 GHz PC. But I cannot remember what FS2002 was like on my 2.4 now, sorry. The specifications sound fine. But are they all working? I don't understand the sentence "I come now with the problem because I bought my computers after and after!!". "After" what and "after" what? Whenever I've had any sort of Network problem, and I've had several over the last 6 or 7 years of WideFS, I've eliminated it by trial and error. In that time I've had two bad network Cards (it is a good job they are so cheap!), one bad (cheap, ug) cable, and one bad hub. Each of those problems have accounted for a separate problem and each took several days of re-configuring, unplugging, reinstalling, and so on to find and rectify. If you have spares it is easy. If not it's a matter of swapping things between machines. My last big problem was trying to make things work after my main FS PC was changed from Win98SE to WinXP. I had no end of problems with IPX/SPX, and it was because of that I concentrated on making the TCP/IP side better and better. I am now 100% TCP/IP and no other protocol is installed. I runwith two PCs on Win98SE, two on WinXP Home and two on WinXP Pro. I've also got a Win2000 Pro installed on one of them for tests only. I hope this helps. I would of course still advise you to upgrade both FSUIPC and WideFS. If you have the latest versions you may well find your problems are resolved, but I cannot promise this. All I can say is that it would then be easier for both PM support and me to help you. As it is it is not really possible. Regards, Pete

Check the cloud settings in Options-Settings-Display-Weather. Set 3D clouds to 100% If this slows your sim too much, reduce the top two sliders. Also look for the Chris Willis fast cloud set. It sounds like your system isn't coping too well with the default clouds. The wind smoothing options will work, but only if you enable them. It will have nothing whatsoever to do with stutters, which are almost always 100% to do with graphics. Regards, Pete

Okay. You can do that, it just needs a little more thought. You can certainly tell whether the plane is on the ground or in the air, whether it is pushing back, starting up, and so on. With a little history (i.e. checking what is happening) you can tell if you are taking off, climbing, cruising, descending, and probably even landing (gear down and descending are clues). I should think you could derive as much as "bState" gives you for AI aircraft, and probably more. Thanks! Regards, Pete

Ah, sorry --- with starting a new thread I cannot easily link up to your previous posts. You will understand that I answer almost all questions here and I also respond to emails and participate in several Newsgroups. And I try to get on with program development too! This is why I prefer the Forum method, but it doesn't work if the threads are continually broken and started afresh. I think you were having some network problems but were using WideFS 5.40 and IPX/SPX, and I said that version 5.40 was rather old and I couldn't support it. Correct? Whether the latest version, 6.23, will resolve the problems or not I do not know and I cannot guarantee it, so I still cannot tell you to pay for this and expect results. Your problem could be elsewhere. Additionally, if you change from 5.40 to 6.23 you will also have to change from version 2 of FSUIPC to Version 3, and if you are currently using any of the FSUIPC User facilities you will lose access to those too, unless you also purchase FSUIPC. Unfortunately, for some reason I don't understand, you did not keep your WideFS up to date -- 5.40 was superceded by 5.50 well over a year ago. How long have you been using WideFS 5.40 and had problems which you are so late in asking about? Or, if these problems are new, what have you changed to bring them about? If you are a beginner in this, how is it you have version 5.40, which as I say is so old now? Your statements do seem a little conflicting. Katy and Enrico are away at present, otherwise she would no doubt help. I think Jonathan is saying the same as I am, that we cannot undertake to support such old versions. All that means is that we have no way to determine what is wrong when you are using old versions. However the software side turns out, if this is a new problem you must consider what has been changed, as the answer will lie there somewhere. The sort of errors you mention do usually arise because of bad network hardware (cards, cables, hubs or switches), or, less often, driver or settings problems. Without upgrading your software you could pursue an investigation of trial and error. Change this, test that,, change something else, test it, and so on. Only change one thing at a time or you learn nothing. Regards, Pete

No. The plane you are flying is the subject of most of the rest of the data available from FSUIPC. And if it were to be added tothe TCAS tables it would have to be specifically eliminated by TCAS applications because you don't show your own plane in that way. As I say, most of the rest of the data in the FSUIPC interface is concerned with the aircraft you are flying. but there is no "bstate". That relates to the stage in the AI simulation of traffic. The aircraft you are flying is not subject to artificial intelligence, but your own, real intelligence. You don't have to go through stages, and you know when you are taxiing, taking off, and so on. Don't you? :o Regards, Pete

Why not use SimMarket? Sorry, but I really don't know Enrico's exact movements. You could try writing to him at the support@schiratti.com address. Other PM folks will also see that. Better than which version? There's been no substantial changes in WideFS for years. The refining of its performance using TCP/IP mostly occurred between version 5.40 and 6.1, but the main change from 5.50 to version 6 is compatibility with FS2004 and dependence upon Version 3 of FSUIPC instead of Version 2. I am not sure what you are looking for, but I wouldn't want to entice you into spending money unnecessarily and on false pretences. Regards, Pete

Sorry, I'm not sure I understand. FS9 is not really involved in "seeing" anything that my PFC.DLL driver does -- PFC.DLL works directly with FSUIPC to drive FS without any assignments, calibrations, etc, in FS at all. If you connect your control axes through the PFC system you need really to disconnect the same ones in FS. In fact, unless you have some other joystick connections to FS you should disable joysticks in FS altogether. Don't forget to enable the control axes in the PFC.DLL dialogue. If you've been using a normally connected joystick they are probably disabled in PFC.DLL to avoid interference. There are individual checkboxes to enable them. Regards, Pete

Thank you Frank! Regards, Pete

The FSUIPC options dialogue also blocks FS paint messages, as you can see when it is dragged! If you want unregistered FSUIPC access take care to at least Open the FS interface in the main FS thread. If you don't it will not be able to identify your module when you call (wrong stack) and will fail the access check. I don't know why it minimisesthat's sounds strange. When your module is initialised and de-initialised by the two mandatory calls you get from FS, you ARE in that thread! You can use that to start threads, as you are apparently doing, or create (invisible) windows to receive messages, but of course you can also SetTimer to get later and regular entry to a TIMERPROC, and on one of those, if you need to, you can subclass the main FS window which is of course the Foreground one with Class "FS98MAIN". Regards, Pete

According to Doyle Nickless, if you download his driver software and install it according to instructions, it now includes the GFDev.DLL in the same path as the GFConfig.EXE program you use to program GF devices with GoFlight software. Look there. If it isn't there, or not installed correctly, FSUIPC can't read GoFlight buttons. Regards, Pete

What logging are you enabling in PFC's Test page? It is not a good idea to turn on any of that except on request for my own diagnosis. Please turn it all off. There's no particular error there of any note. However, the "synchronize switches" refresh is normally done shortly after FS is ready to fly, yet the timestamp on these lines shows it occurring 1923 seconds into FS! I don't understand that. Is it perhaps because you started with a deleted PFC.INI and only entered the Serial port name late? Anyway, I have had one other case where the restarts were causing a problem in WinXP. I seem to have fixed that in my latest version (1.90) which is almost ready -- just documentation to do as usual! :wink: For the time being try switching off the restarts -- both the Sync Init as above and those which may occur on any long delays in seeing PFC data. The parameters you need both go into the [Connection] section of PFC.INI and are: SyncInit=No AutoRestartTime=0 Whilst you're there, change any Debug vlaue to Debug=0 to stop the excess logging. When you get version 1.90, maybe later this week, try removing these parameters, then let me know. Regards, Pete

Hmmm. How very strange. I really don't understand how either FSUIPC or any add-on using it can achieve such a result. If such a thing happened to me I would suspect one of three things: 1. Something in FS or its data is corrupt. 2. There's a video problem, drivers or, less likely, hardware. 3. There's a hardware memory problem For the first, a complete FS re-install is probably the only way to be sure. And this does mean complete -- including removal of data files as in the C: drive's FS files area and saved flights and plans (and especially weather files). I've seen one user have problems of crashing in WEATHER.DLL which turned out to be a corrupt weather station file, generated by FS on installation and possibly updated on occasion by the FS weather downloads. For the other two I suppose a process of elimination is in order. Different video drivers, swapping memory chips around. The different memory patterns obtained in each case combined with one of the possibilities I mentioned could account for this. Another way to experiment with memory patterns is to change the order in which modules load. To do this you move them out of the FS Modules folder, then back in in a specific order. Module loading orders used to be particularly critical as I remember in several FS releases, most noticeable FS98 which had an error in FE.DLL which was memory-pattern dependent. Well, unless AS2004 is writing to unexplored parts of FS, which seems unlikely because 1. It wouldn't just be happening on your system then, and 2. It is getting increasingly difficult for any program to write to any unpredictable unknown parts of FS simply because more and more of the offsets in the FSUIPC interface are becoming specificaly allocated and routed to known things. The only advantage I can see of posting to the AS forum is to see if you can find anyone else to disprove reason 1. Sorry I can't be more helpful at present. It's an area of FS so unrelated to anything touched by anything I know or do that it is difficult to understand how it can happen. Regards, Pete

You are welcome. Thanks for the appreciation! Regards, Pete

None. How can there be? There's no way to predict how someone will rig up the hardware connections to his PC. You'd have to write the driver for it, dealing with the I/O on the COM, Parallel, USB, firewire or PCI/ISA board you rig up to connect the hardware through, and interface to FS through FSUIPC. That's what FSUIPC is for, an interface into and out of FS. Yes, actually, there is such an interface -- the Windows joystick interface. The generic interface you need to present is one of a Joystick. With a USB one you can have 6 analogue (axis) inputs, a POV hat, and 32 buttons for each defined 'device', with up to 16 devices. The Direct Input spec supports much more than this, but FSUIPC uses the simpler Windows joystick API which is limited. Of course with a joystick interface you could program many things directly in FS's Options-Controls-Assignments in any case. This is for input/control only. For displays I don't know of any standard. Maybe there is one defined in DirectX someplace, but display support isn't provided in FSUIPC in any case. I do also support input from GoFlight's equipment, using the GFDev driver, and of course EPIC via my EPICINFO DLL (that's for both input and output). The EPIC support I provide pre-dates FSUIPC by several years. Perhaps you wil find something closer to what you are looking for with FS-Communicator? I'm not sure what types of hardware it supports, though. There's also FS-Bus which involves hardware I think. Sorry, but I am very familiar with these alternatives. Regards, Pete

No, no. Thank you! :D It isn't quite the way I wanted it, but, whatever works. :wink: Regards, Pete

Right. Thanks. Pete

You don't purchase a specific version. The registration covers any version 3.xx. 3.201 is very old now and not supported. The current version is 3.30. Download the current PFC DLL please. there will be a new one soon, version 1.90. You forgot to mention any version number, but the current supported version of WideFS is 6.23 and registration is not optional. You cannot run version 5.xx with FSUIPC 3.xx. Regards, Pete