Pete Dowson

There is certainly a priority system in operation in FSUIPC, but only for values which it has to extract from FS by calling procedures or performing calculations. Mostly important values are updates at least once per frame, but some will be less often. The slowest update is one second -- but that only applies to the character version of the time at offset 0C20, which FSUIPC has to update itself. Since that only changes once a second that seemed reasonable. There are some other less important values calculated every 450 mSecs or so. And so on. All this is to ensure top performance whilst still providing optimum support. Actually all the GPS values are mapped directly into the FS memory where they are maintained by FS. FSUIPC does nothing with them. I don't use the FS GPS's but my guess is that this is their actual refresh rate in FS. Maybe this is deliberate, to simulate those many GPS units which seem to have a one second update rate. Regards, Pete

I've no idea, sorry. Possibly it is written using the wrong interface, one from over five years back, which isn't supported with free registration in FSUIPC 3 because it cannot be. I could tell by seeing what the FSUIPC.LOG shows when you have one of these errors. At present I am not even sure it is an FSUIPC access problem as you've not really described it in any detail. As I said in my previous message, but you may have missed it, you can tell if it is an access problem by checking the FSUIPC.LOG file in the Modules folder after such a failure. If you are using an up to date version of FSUIPC you should get an error message coming up from FSUIPC telling you so too. Regards, Pete

All that does is prove that it isn't just some start-up clash. Something is really stopping it getting access to the Network. see my other message. And I am still thinking. Regards, Pete

Nor do I. That's weird. When you "deleted FS9" do you mean you uninstalled it, or just dleeted it? it does store quite a few things elsewhere -- in your "My Documents" folders, especially. Maybe there's some multiplayer mode or flight situation it is loading which is clobbering things. All I can suggest is that you find the FS9.CFG file and remove that, see if it helps. FS will make a new one. Regards, Pete

Yes, it can be a little faster, but it depends. If the three locations are truly contiguous in some memory somewhere in FS, then it will be a little faster. By comparison with the process switch invoked by the Process call itself, this won't be measurable -- but, yes, undeniably it has to be a little faster. However, if the locations really refer to locations in different modules in FS, then there is actually extra code execution needed for FSUIPC to split the request up again. I'm afraid that, in general, there is no way for you to know which way it might be. In FS98 it would all be contiguous (well, at least till 0x1FFF in GLBALS.DLL, then contiguous again but in FSUIPC memory for the rest). In FS2000 quite a lot is still continuous, but it gradually gets less and less so. The time to change process will vary by more than the few microseconds taken by the extra data processing, assuming there would be any, so I don't think you could measure it at all. Even using the more direct module access from inside FS, you are dependent on other things going on. Incidentally, it most certainly used to be much more efficient to coalesce adjacent variables for requests through WideFS -- even if sometimes this meant including some data you didn't really need. This was because the whole block was sent, verbatim, over the Network. However, that was long ago changed. Now WideClient automatically does the coalescing for you, and then compresses the data before transmission. So, all in all, don't worry about it. What you lose on the swings you gain on the roundabouts! :wink: Regards, Pete

Ah, not necessarily. This bit of the WideFS documentation applies: So, worth a try? Configure a RestartHotKey and see if that gets it going. BTW it does sound like there may be some interaction with another add-on which is launching with FS. Check for other additional (non-Microsoft) modules which have been added into the Modules folder, other than WideServer.dll and FSUIPC.dll of course. Try without each extra one, one at a time. Regards, Pete

I'm sorry, but I really have no idea at all. I've not seen the "listen" ever fail before, and it doesn't help that Windows has not returned a useful error number to give the reason. The two seem incompatible. All I could do in such circumstances it try different things in the hope that it would work. First of all, maybe, download WideFS again in case of file corruption. Then, assuming no change, uninstalling and re-installing the Network on the Server PC. Possibly there's some other program or service running which is stopping WideServer offering its service? I don't know much anout firewalls and so on, but that's also an area to investigate. Katy Pluta, who visits the FS2004 Forum sometimes, is good on Networks, so it might be worthwhile asking there. Sorry, I can't be of further help at present. I've not seen this error before, and everything else looks okay from your files. WideFs doesn't know or care what method you use to connect things, that will be all hidden beneath the layers of Windows software which it has to go through. If Bluetooth is supported as a Network connection method using either TCP/IP or IPX/SPX protocols, then it should work, same as Direct Connection does via serial or parallel port, or WiFi. Regards, Pete

Again, this is really a question for folks who know and support PM. You would get more definitive answers there I am sure. All the dedicated functions in FSUIPC relate to the bits provided for the purpose they describe in the FSUIPC Offsets documentation on the PM website. That's all I can do. Please go look at it yourself if you are skeptical. The problems in those modes probably arise from when PM's ND was changed over from a rather limited 4 mode display capability to a full 8-mode one. Perhaps Enrico forgot to re-define the use of those bits correctly. He certainly didn't add new bits. If this is indeed the case, then for proper control of all 8 new modes offered you probably need to resort to the PM GC Controls (By param) function, selecting the parameters accordingly. There is a list of parameters in the FSUIPC Advanced Guide, but, as recommended there, for the most complete and up to date list always refer to the PM's documentation. Regards, Pete

I assume you are using FSUIPC 3.30 or later? If not, upgrade first. If so, this is best directed to the PM support folks. All FSUIPC does is set or clear or toggle the bits in the FSUIPC offsets used by PM, in accordance with the documentation on the FSUIPC offsets used by PM that you can see in the PM website. That part (the changing of bits) most certainly works. Different builds of different PM components do different things. Many of the functions did not work unless the MCP was running, but I think that was changed in some builds. The PM builds change faster than I can keep up though, which is why it is best for you to ask those that know these things, or at least post on the PM newsgroup. You should also be more explicit about which commands you are trying and what PM components you are using. Regards, Pete

Several? There's only one FSUIPC.ZIP surely? There are brief descriptions there too. Didn't you look at those? There's also a list of supported versions in the announcements at the top of this forum. Please scan those! If you don't know what it is for, you certainly don't need it and probably don't want it. If you are really curious, please just read the documentation. I don't see any point in printing it all here. Otherwise why not just forget about it? Regards, Pete

1. You don't need it. 2. Of course CH don't support it. It isn't their program, it is nothing to do with them. It is nothing to do with CH in general, in fact. 3. Whether you want it or not is entirely up to you. If you download it you can browse through the documentation and see if it strikes you as useful. That costs nothing. Then throw it away if you don't find it of interest or don't understand it. 4. You find it on http://www.schiratti.com/dowson. 5. You must always use the latest version, no others are supported. Please see some of the announcements above for details and to keep up to date. Regards, Pete

No, because I don't have a database of registrations. All the registrations are dealt with by the supplier, for instance SimMarket. Your notification from them of the Key will contain the user name and email address which you told them you wanted it registered under. Are you saying you've lost your received emails too? For a lost access key you can obtain it again from SimMarket by going to http://www.simmarket.com and opening your account there. But to open your account there you need the user name under which you established that account. If you are in the habit of using lots of different names in different places and can't remember which one is which you are in a bit of a sticky situation, as it is only by such details that you can be identified. Regards, Pete

Possibly. I'm not sure how DxDiag gets involved, but I think that the reason you get a crash and I don't is simply that there are different things in the memory which FSUIPC is assuming will contain the Engine 2/3/4 stuff. If something critical gets overwritten, you get to know sooner or later. If not, you don't. The problem in FSUIPC at present is that I only check whether the pointer I derive points to valid accessible memory, which it does. Before I prevent writing to these things altogether, I'll look to see how easy it is for me to derive separate pointers for each engine so I can nullify those which don't apply. Regards, Pete

It provides all of that and more. You can get not only pitch roll and yaw, but, much more to the point I think, the velocities and accelerations in all 6 degrees of freedom (X Y Z P B H), both relative to the aircraft body itself and to the world at large. Just download the FSUIPC SDK from http://www.schiratti.com/dowson and peruse the programmer's guide -- particularly the tabulated details of the data available. But you will need to do some programming! Regards, Pete

If it is indeed an FSUIPC access problem, and this doesn't prove it by any means, just enter the gauge name, in full, and the Key into the correct places in the dialogue you get when you press the "register an application" button. The gauge is an "application" in this sense. You can tell if it is an access problem by checking the FSUIPC.LOG file in the Modules folder after such a failure. If you are using an up to date version of FSUIPC you should get an error message coming up from FSUIPC telling you so too. Most maintained applications, gauges and DLLs for FS which have access keys do this stuff automatically. It is a shame not all programmers bother to make the small changes necessary for this to happen, but at least then they should really provide some instructions. :( Regards, Pete

Hmmm. Not sure where DxDiag comes into it -- how does that start to run? I thought that was a user utility to check for problems in DirectX. I've tried all sorts of tests here to make this crash occur, and I cannot. However, really you should be using the well defined and well established throttle controls in the lower areas. Most all of those upper areas are non-writeable or unpredictable if written. In fact now you've told me there is a problem with those I will be blocking writes to them, making them read-only, so please change your program. You may have noted that those were only recently "promoted" from the 2nd, unsupported table in the Programmer's Guide, to the first table, but I should really have marked most of those "read only". Many of them will certainly crash FS. The problem I have is time to test every location in every version of FS with every aircraft type. BTW the fact that you are getting FS crashing rather than a mere error being trapped by FSUIPC does indicate that in fact it isn't a memory access problem, it is just that whatever you are writing to is actually part of something else and causes the crash later. Thanks for the details! Regards, Pete

It wasn't me who sent it. That's all handled by whoever you bought it from, probably SimMarket. If you didn't re-install Windows then all you had to do was save the FSUIPC KEY file, as it says in the documentation. However, be that as it may, now you need to re-register and you must use exactly the same details -- same name, same email, same Key as before, exactly as notified to you. It sounds like you are making a mistake with the entry of one or more of these parts. Regards, Pete

No, no idea, but it is likely related to something FS is doing with invalid values. After all, the only valid values for the last digit of the frequency are 0, 2, 5 and 7. Try testing the last digit and increasing/decreasing by 2 or 3 depending on the current value. Your values are hard to check in decimal. It's the hexadecimal which is important. Your "9093, 9092, 9091, 9090, 9089, 9088 and then back to 9093" are frequencies 123.85, 123.84 (invalid), 123.83 (invalid), 123.82, 123.81 (invalid), 123.80. The next time you decrement you would get the invalid 123.79. Why FS should do more with that than the other invalid values I don't know, but try to give it proper values only and see what happens then. Regards, Pete

Those locations may not be so well checked -- I think they are directly mapped and intended for reading only, but I'll check that. Writing to them has never been tested, I'm surprised that this works at all. The supported Engine variables, compatible from FS98 through FS2000, FS2002, and FS2004, are those at 088C onwards. These are the ones almost universally used by third party programs. If FS crashes, e.g. with access violation, whilst FSUIPC is doing anything, like writing to such locations, it will not crash FS but the crash will be trapped in FSUIPC and logged, then things carry on. The log would show the error, but nothing else. But that's by the way. I've just loaded up the Cessna (as the default, just to be sure) and tried to replicate your crash by writing values to the Engine 2 throttle with no problems at all. In fact the values "stick" and can be read back, which is odd when you think about it. Yes, please, because at present it is not looking like FSUIPC's doing. BTW I assume you are using FSUIPC 3.30? If not please try it with the latest version, I don't care to try to track back to older code. Thanks & Regards, Pete

That shouldn't happen, as FSUIPC checks, not for the number of engines, but for a valid ultimate destination. It wasn't until FS2004 that FS separated all the engine stuff into up to 4 separate structures, and didn't bother to allocate the structures if they weren't needed. In FS2002 and before the setup for all 4 engines was in one bigger structure with other stuff. Same for helo instrumentation and other stuff not always present. Please tell me EXACTLY what you do that crashes FS so I can investigate. As I say, it should be covered. Regards, Pete

FSUIPC has no way of creating traffic. There are only two ways I know of, one is multiplayer and the other is compiling new traffic BGL files. Only multiplayer works "on the fly", but at a cost -- in multiplayer mode you lose FS's AI traffic and ATC. Ah, that's different! Yes, you can do that -- it is documented in a section near the front of the FSUIPC programmer's guide in the FSUIPC SDK. It is the facility used by AIBridge to get MP traffic seen by TCAS displays, but it will work without MP running and will mix with "real" AI traffic. Regards, Pete

Please just download it and read the documentation. Then ask questions if you don't understand. Yes, a normal latching toggle switch. Yes, of course. If the simulator does not actually support separate "ON or OFF" controls for a particular function you would have to program the same "toggle" function for both "press" and "release" and get the switches synchronised before you start. But for many functions, FS does off separate ON and OFF controls as well as Toggle. For instance, Strobes, landing lights and panel lights have On, Off and Toggle. However the other lights (Nav, Taxi, Wind, Logo) only have toggle functions so you'd need to synchronise them with your switches first. Check my lists of FS controls (http://www.schiratti.cxom/dowson) is you are curious. For a more thorough treatment, all the light switches can be accessed through FSUIPC offsets -- a separate bit for each one, set for 'on', clear for 'off'. There are FSUIPC controls which you can program on buttons to set, clear or toggle bits, so you can do anything you like. This is not quite so intuitive, and for FSUIPC offset details you need the Programmers Guide documentation, in the FSUIPC SDK (same website). Regards, Pete

Try setting Summer or Winter as the season in FS, see if it helps or not. If it was one of those when you crashed, try the opposite: i.e. Spring or Fall. But I think the CTD problem was related to transitional trextures so these are more likely. One CTD I came across was fixed by removing some apparently bad AFCAD files. These were Project AI related files I think The filenames were: PAI_AF2_?????_?????.BGL and AF2_????_????_???.BGL The sufferer mentioned that there were 77 of these on his system and after he removed them, no more CTDs. The only way to find bad scenery files really is to eliminate one add-on entry in the Scenery library at a time. Or, quicker, do a "binary chop" on your list -- i.e disable one half, see if you crash, if so, halve that and so on. If not, swap halves. This is quite quick, getting through 256 add on scenery layers in 8 reloads. However, the results will be ambiguous if you have more than one causing problems. Regards, Pete

The Key for what? You enter all Keys by going to the FSUIPC Options (ALT M F), as described in the documentation. For an FSUIPC Key you press the button to register FSUIPC. For a WideFS Key you press the button to register WideFS. For an application Key you press the button to register an application. If any of the buttons are greyed out then this has already been done, or there's no need. For instance, once your Registered FSUIPC as a user you never need to register any applications. Most applications register themselves automatically in any case. It is only dead programs (i.e. those which are not maintained by their authors) which may need manual registration. There, what is so obscure about any of that? Regards, Pete

No, as the documentation says, that is the pathname of the current air file. There is no facility to load an aircraft except by loading a FLT. Sorry. Regards, Pete