Pete Dowson

All FSUIPC does with these PM commands is toggle the bits in the offsets provided by PM for these controls. I think what happens then depends upon the version of PM modules and whether you have the PM MCP running. Up until recent builds the PM MCP used to handle all the ND bits in the offsets -- I think this changed recently, but to ascertain which builds are which you'll need to ask PM support. There are alternative PM controls you could try too (it seems almost everything in PM can be done in at least two ways!). If you look in the FSUIPC Advanced User's guide you'll find that the ND range INC and DEC commands are also supported (48 and 49) in the PM GC Controls offset. You can program any of those with buttons in FSUIPC -- find the GC Controls (by param) control and place the command number in the parameter field. Please make sure you are using the current FSUIPC in any case (3.30), and note that the new PFC driver (1.90) works better with 3.30. If you wish to verify that the buttons are operating the right bits in PM offsets, you can get the PM offsets documentation from the PM site, and monitor the locations themselves in FSUIPC using the monitor (see Logging page). Regards, Pete

Well, it isn't a "Registry" code, its an access key. Entering this is part of registration. Please check the documentation supplied in the ZIP, which tells you precisely this in its early pages, or read the thread on this subject in the announcements in this Forum. Regards, Pete

Ouch! Yes, you are correct, it is broken. That will teach me not to try to do so much when I can't even see properly! Looks like I broke it after the last Beta. Sorry. I'll try to fix it now and send you a version to test. Regards, Pete

Wideclient is part of WideFS. If you install an updated WideFS this means installing both the Client and Server parts. If you only install part of it you (a) won't get any of the improvements or fixed included in that part, and )b) risk incompatibility between the two. So, yes, always install all parts when updating. If the flap switch is recognised by FSUIPC when you operate it, yes. Just assign it in the FSUIPC buttons page. I don't have a GF TQ unit to check it on I'm afraid. some units but that was a while ago. He must have forgotten). Regards, Pete

Sorry, I don't know what AS2004 does now. If you look at the FSUIPC options and the smoothing is checked, then it is enabled. AS2004 can do that for you if it is programmed to do so. It cannot set the parameters though -- just adjust them to your liking if they are too slow or too fast. Pete

It isn't so much FSUIPC being a different product, but SimMarket have their own system. Maybe you've never purchased from SimMarket before. It'll just be the way their system works. I doubt that they will want to rewrite their software but you can always suggest it to them. Regards, Pete

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