Pete Dowson

No problem. I expect the SB problems will gradually be ironed out. It is still in Beta isn't it? Or hasn't it got to Beta stage yet? Regards, Pete

Unless they are specifically checking for your registration, this actually is not possible. Are you sure that they don't mean "unregistered"? Otherwise it simply doesn't make any sense. When you register FSUIPC it doesn't then do any access checks on any program! This will not be anything to do with FSUIPC access keys, then. It seems you are getting confused between their licensing scheme for their software and the FSUIPC access system. Once you register FSUIPC as a user, no access keys from programs are even looked at. They become completely irrelevant. If it's some registration scheme in their program to make their program work, then they won't "fix" it because it probably isn't broken. It sounds to me that you have keys for their prgram but their documentation doesn't clearly tell you where to put them. They certainly won't be FSUIPC Keys at all. Contact me privately at petedowson@btconnect.com with all the details if you want further advice or confirmation on this Regards, Pete

But they are different for different products. The receipt system is probably an automated generic system. With some things you order you would expect a box in the post several days later, with others there may be something later from the author. I think the fact that the DELIVERY method is spelled out clearly on the order page is sufficient, but if you feel otherwise by all means submit a complaint to SimMarket. They've been trading in this way for many products for a long time now and I would have thought they would have already heard from folks if it was a problem. Are they? I buy quite a lot of stuff on the Internet and rarely have I had instant returns of keys or anything. Some places only tell you that the author is notified and he should get back within 2 days or so. Regards, Pete

Sorry, I don't follow. If you have registered FSUIPC as a personal copy then there shouldn't be a button to register an apppication. It isn't needed then. If that button is showing then you haven't registered FSUIPC as a user yet. Sorry, I do not understand what you are saying. If you have an unregistered FSUIPC and a freeware program and a Key to go with it, then please just follow the instructions and register it through the application registration button. If you have user-registered FSUIPC you need no other keys for any application. No, sorry. What for? Regards, Pete

I think you'll find that it does explain on the site that the registration will be emailed to you within 24 hours. All you get automatically is a receipt. Humans have to process the order and dispatch the keys. You cannot expect them to be able to always respond immediately! Here's what it says very clearly and explicitly in the order page on SimMarket, right near the top: Surely that is clear. :roll: Regards, Pete

Hmmm. Not sure why that should be. I don't think they use anything FSUIPC is involved in. I have had UT installed since it first came out and haven't noticed a problem with PalmSpotter, other than the time is usually wrong. Mnd you, that was with the original release, I've not used it for a while. Thank you! Regards, Pete

Well, the Betas of 3.30 have been through a lot of testing on many systems over the past few weeks. I really cannot see any way that a change in the module could cause a crash in a completely unrelated part of FS. I'm sure it must be a conspiracy of coincidences. It is a matter of finding out what. It doesn't really necessarily follow. You'd have to get the same result with no FSUIPC applications -- it is of course possible that some incorrect behaviour from an application went unnoticed with ealrier versions, but as the offsets are gradually being used and allocated it is making an original problem show up. What FSUIPC applications are you runnig? Try without them, then add them one at a time. If you are not running anything that uses FSUIPC, then FSUIPC isn't really doing anything. If you are a registered user you could try removing your FSUIPC.KEY file, temporarily, and see if that changes anything. For then FSUIPC would truly be doing nothing without applications. If this does change it you could re-instate the KEY file and try changing one FSUIPC option at a time. But really I don't think it could be any of them. Well, if you have the time and patience some sort of process of elimination I've just mentioned would be useful. Thanks, Pete

Hmmm. I get a spate of reports like this every single time I release a new version. I will be amazed on the first time I don't! :? Honestly, there's absolutely no changes in 3.30 which would have anything to do with this, all the new facilities and options are passive until used. Your problem is evidently just a result of a change in memory layouts -- either because of the ordering of modules in the FS Modules folder, or because of differences in memory usage between the versions. I have found the FS2004 GPS window to be precarious in a number of add-on situations, and I think there is some bug in FS which is quite difficult to pin down. There are a number of things you could try. First, move all your add-in modules out of the FS Modules folder (to any safe folder), then move them back one at a time, testing each time. When/if you get the error again, do the same but move them back in a different order. Et cetera. The other thing to be wary of is having a default flight loading with a complex panel. Try loading FS with one of the default panels initially then, when things are settled, load the complex one. Regards, Pete

Yes, but that isn't the question. Have you been using WideFS 5.40 since February 2003, when it was released? When did you start getting problems? Why didn't you keep WideFS up to date -- it is after all quite likely that 5.41 was better, and 5.50 was better still? Now, 17 months later, it is too late for such free upgrades. Isn't this as before? As I said before, it does look like a problem limited to that PC. So do some eliminations. Try the MCP and CDU separately -- they are both quite heavy users of the network. Maybe you have the "NetDir" on a different PC? I think the NetDir is very often accessed by both modules, but I'm not sure. And, to check the hardware, try swapping bits around. I'm sure I've suggested all this before. Not necessarily, but, honestly, 5.40 was NOT optimised for TCP/IP and was, in fact, a transition version between a good IPX/SPX version (5.30) and a good TCP/IP version (5.50). I really cannot advise you on 5.40, It is too old and I do not remember!! (Haven't I already said this too?). Honestly, I am still completely confused as to how you are a NEW user but with 5.40. How can this be??? Really? I thought that was always optional. It depends on what sort of things you are running on the same PC. PLEASE READ THE WIDEFS.DOC. It does describe the use of these parameters. Oh dear. I am very sorry, but I cannot advise you any more. I have made suggestions that you try to determine what is wrong, by a process of elimination, especially whether it is hardware or not. I also advised you to update both FSUIPC and WideFS, but I am not going to tell you to spend money and expect solutions as a result, simply because I cannot possibly know what the problem is! I cannot guarantee anything, how do you expect me to? We are going in circles here. Please try to isolate the problem. If you want to buy new versions, please do so, but I cannot help with your hardware nor with PM, and I can only help advise you on results with current versions of my programs. I do keep saying all this, but I assume you do not understand my replies? Regards, Pete

Glad you sorted it so quickly! Pete

Try version 1.90, now available, without those parameters. Regards, Pete

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