Pete Dowson

Yes, that would be best. After all, it will be he who defines what he will write there. Of course he will need an access key unless this will only be done on systems owned by folks who have paid for a full user FSUIPC registration. He should also use the Module User's interface (the one using FSUIPC_Open2 not FSUIPC_Open). All the details he needs are in the FSUIPC SDK. If he wants to stay independent of FSUIPC for the majority of users he will need to make two versions or have some method of installing which can tell him the choice. Regards, Pete

Well, as I said, most completely separate A/Ps are completely separate. Not just the altitude, but most everything else too. However, in this specific case I thought that most implementations would climb if you change the altitude before the glideslope is captured. I always set up the GA after both GS and LOC are captured -- I thought such changes requested before that were to be obeyed in any case? If you suddenly realised that you were going below MDA before intercept (i.e. the 3000 was an error) would you disengage everything to climb? But it doesn't matter. I can allocate the space when confirmed. Regards, Pete

56xx is allocated to Project Magenta. If there's not enough information available in the PM website then you will have to ask PM support. However, I think that particular area is for use with pmSystems, which isn't even released yet. No doubt the documentation will be included with the software when it is released. Regards. Pete

Yes, I think this is why many implementations don't set the altitude hold until the climb or descent is to begin. Are you only wanting 2 bytes then? A 16-bit word for the altitude? Should I allow also for the 90 indicators you might be providing? I would be inclined just to allocate you 16 bytes and let you use them as you wish. Okay? Regards, Pete

POV hats either have 4 or 8 positions. If the POV is genuinely supported as a POV in Windows (see Game Controllers), then those 4 or 8 positions will be seen and encoded separately by FSUIPC. Like FS2000 used to do, FSUIPC encodes the 8 positions with button numbers ranging from 32 to 39. If the POV only has 4 positions you will get alternate numbers. It is only since FS changed to using Direct Input that it has restricted the assignment of POVs to a single function. Regards, Pete

Sorry, I don't know the PSS A320. Not many of the panel makers provide controls for use of their panel, they either only support mouse clicks or, possibly, keyboard short-cuts. You need to refer to the PSS documentation. FSUIPC can allow you to program FS and Project Magenta controls on buttons, or keystrokes. It does not do mouse clicks. But there is a program by Luciano Napolitano which can convert keystrokes to mouseclicks, so that's a possible solution. I think it is called Key2Mouse. Regards, Pete

Yes, but if you are Mr. McPhail I am at a complete loss to understand what the problem was in the first place. Your registration was only two weeks ago and the name and email address used seemed to be your own, so what was the real problem? Well, after the operations I am now long-sighted in my right eye, and need reading glasses for close work -- different ones for PC work to normal reading. The advantage of being short-sighted was that all you had to do to see things clearly was bring them closer. I could remove minute splinters by viewing my finger at 1 or 2 inches distance, for example. This takes some getting used to -- I always need now to have glasses with me, even if I don't have to wear them all the time. I cannot get prescription glasses till the sight settles down -- it looks like the right eye will be different from the left, so straight ready-made reading glasses won't do the job. I shall go for varifocals again I think. At present I've had to get cheap reading glasses from the local chemist shop, looking for identical frames but different strengths, and then swap lenses about so I have ones about 1.5 dioptre stronger for my right eye. The good part is that for outdoor activities, or watching TV, things like that, I don't need to wear glasses. And I really do like that! :) My main sight defect is the Retinitis Pigmentosa, which, in my case, is killing off all the rods (or is it the cones, I always mix them up) in the retina. Basically I've got no peripheral or night vision. My right eye has extreme tunnel vision effects, my left is catching up. No operation can (yet) fix this, unfortunately. Worse, at least two of my three children (now 39, 38 and 36) have the same condition, starting already. Ah, I don't remember ever not having short sight. There must have been a time before I got my first pair of glasses, but I don't remember it! :wink: Regards, Pete

I cannot really help much. There is no offcial documentation. The main thing to realise is that Gauges are also DLL's, and also load and interface in the same way as DLLs. The only real difference is that Gauges are loaded by Panels (by reference in the Panel.CFG files), and unloaded when they are, whilst DLLs in the Modules folder are loaded initially and stay loaded. I found this out by hacking into existing (FS) DLLs to see how they worked. You need a good disassembler (I recommend IDA) and a reasonable knowledge of Intel assembly code. A good debugger (I use Soft-Ice) is also very handy. So, you first step is to learn to write a Gauge in C or C++ (the MS SDKs should help there), and when you have that sussed, see how to make it run as a DLL in the Modules folder. There's another thread here somewhere which did contain a link to a sort of "module builder" kit, but, sorry, I can't find it offhand. It is still here though, I've not deleted anything. Regards, Pete

Sounds like an application of multiplayer, or possibly Luciano Napolitano's WidevieW. The latter in particular is designed to make any number of clients folow the motions of the server exactly. Joystick signals? I'm not sure what you are reading and writing, but the joystick values are just inputs to a very complex simulation. Any slight different in the initial timing, the setup, and then even milliseconds difference is feeding the signals, will gradually magnify in significance -- the errors will grow and grow until there is no resemblence whatsoever. This is chaos theory, also known as the butterfly effect. Don't forget that you cannot even achieve a "few milliseconds" delay -- the FSUIPC client programs will be forcing process changes which can take something in the order of 2-10 milliseconds in any case. The network delay will normally be 10-30 mSecs at best (I am assuming you use a Network, how else do you run two copies of FS?). Regards, Pete

Seems that there are some faulty AFCAD files about! Thanks for the feedback! Regards, Pete

If there's no error message in the log saying that something is attempting access when it isn't accredited, then the problem you have is nothing whatsoever to do with the access key for the gauge. It seems that you have been going down the wrong road. Something else is wrong with the way your panel is configured, which is nothing to do with FSUIPC. Sorry, I can only suggest that you contact the panel author for support. Regards, Pete

It's been reported before, and I contacted PMDG about it. It seems to be only since the 800/900 update -- this effectively updates the 600/700 too. I didn't have these aircraft at that time, and PMDG could not reproduce the problem with their current build. They then sent me the latest, and I cannot reproduce it either, so I am fairly sure that whatever it was it is fixed in the latest update -- I assume this is the Service Update 1 which was released at the end of July. Regards, Pete

I'm very sorry, but I am completely stumped. I've not even seen that error report before, let alone had a problem which only applied to an unadorned FS2004 installation. There is then really nothing to stop it. Can you explain the problem (especially the error message) to Katy over in the FS2004 forum? Maybe she has some ideas. Possibly there are some properties in the Network adaptor settings or in the TCP/IP protocol settings which, because of some difference in FS2004 compared to FS2002, prevent WideServer listening on any sockets? Something like the number of sockets being set too low, and FS2004 grabbing them all, perhaps? Did you check through all the possible problems outlined in the WideFS documentation (don't ignore them just because they are mainly applicable to IPX/SPX, try them all). Regards, Pete

Ah, right. For some reason the faster button scanning in versions 3.22 and 3.30 does seem to clash with something in Windows Me and 98. It's perfectly okay in Win XP. Very strange. I think it is something to do with the rather weaker USB support in the earlier Windows versions. This is the first time I've seen it reported when loading weather, though -- usually it has either simply stopped FS loading at all, or it has hung when entering the button programming options in FSUIPC. Really, for an unregistered copy, there's no need for me to scan buttons, since you cannot program them in FSUIPC in any case. However, the scanning involves a separate thread and I find the system is stabler and more efficient if all the threads I need are created on start up and killed on closing FS. Anyway, I will fix this in the next version so that that parameter is assumed if you are using WinMe, Win98, or even Win2000 (which I believe may also have weaker USB support). Sorry for the hassle, and thanks for confirming the fix. Regards, Pete

Does the Wideclient.LOG file show anything? Have you made sure the Win98 PC has permission to access the server? Just because it lists all the others as present in the Network doesn't mean it has permission. To be honest, the complicated permission system in WinXP took me ages to sort out, and I only succeeded by trial and error. I also have 4 WinXP PCs and just one left running Win98. When I run into Network problems I usually ask Katy Pluta for help. She seems to be an expert on most things Network-wise. Contact her on the FS2004 forum here, or, probably more appropriately, in the PM Newsgroup. Regards, Pete

I'd need to be able to reproduce this to know what is going on. There have been no other similar reports. Have you set any FSUIPC options? Try deleting your FSUIPC.INI file so that everything returns to default first. Also, please try adding this to the FSUIPC.INI file (before running FS): [buttons] PollInterval=60 If you are using Win98 or WinMe or earlier this could be the answer -- in the next version of FSUIPC I am doing this automatically on these operating systems. It may also be dependent upon other things -- aircraft panels (does it do it with all aircraft, or only some? Does it happen with any default aircraft?). The main likelihood is that with FSUIPC enabled some aspects of the weather are generating more load on the graphics and the graphics driver is failing, so another option is to try different video drivers. The most usual reason for solid hangs needing a hardware reset are drivers -- graphics or sound. In fact it is really impossible for an application level program like FSUIPC, which doesn't actually touch any drivers, to hang the system solid like that. Regards, Pete

Sorry, I don't know that term. And I'm not sure how you "negotiate" with SimMarket. They don't have any non-automated email services -- all the services you need will be tied to your account. All you need for your account is your name and email address, the same ones you used when you bought your goods. I am still not understanding your difficulty. Is it that you invent new and unrelated "user names" on the spur of the moment and therefore have no idea what you used when? This seems so unlikely! Surely you used one or other of a small selection of ways of writing your own name? If you want me to try to find a closest match with my contacts in SimMarket I can have a go, but I need your real name and email address, and an approximate date of purchase of the key. I'm afraid if you can't even supply those details then there is no way forward. What is that supposed to mean? Since then I have had operations on both eyes, so maybe now I wouldn't be wearing the glasses. Are you just trying to be nasty for some reason, despite my earnest attempts to help? [LATER] I found your email address from your details here. Now, are you Mr. McPhail? If not it is odd because you seem to have the same email address. If so, then as far as I can determine you first registered FSUIPC exactly 2 weeks ago using that name. (How can you have forgetten so quickly?) If you are Mr. McPhail go to http://www.simmarket.com, open your account there with your name and your email address, and retrieve your key, exactly as I said in the first place. Regards, Pete

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