Pete Dowson

I never got IPX/SPX to work well on my systems with WinXP, so I am biassed in favour of TCP/IP for XP, yes. If I had ever managed to make IPX/SPX work I might be of different opinion. Maybe others can say. All that looks perfect EXCEPT the maximum send depth of 92, which seems rather excessive. However, that may have occurred if you had PFD running whilst still loading flights or aircraft of something in FS. In that case I can't really see why you'd notice any pausing. You didn't say WHERE you saw these 10 second pauses in any case? In the PFD? Could they be graphics problems in its OpenGL driver interface? The WideServer log would at least show performance. What are the reported figures at the end there? What frame rates are you getting in FS? What have you set the FS Frame Rate Limiter to? What processors are being used? Are the pauses coincidental with something going on in FS? Regards, Pete

It only needs registering once per PC (and operating system, if you multi-boot), and it can then be used from any account -- but it has to be registered by the Administrator. It is the same sort of thing as FS installation. You can only install FS2004 as Administrator, but you can allow any user to use it thereafter. Many programs are like that. It is because of access restrictions imposed by Windows on non-administrators. Regards, Pete

The pedals and yoke are connected directly, not via a throttle quadrant or anything similar? The USB connection, does that show as a COM port in the Windows hardware manager? Please refer to the List of Supported Versions near the top of this Forum. The current version of FSUIPC is 3.125. You should not be using 3.11. The first message indicates you are not using a current version of PFC.DLL either. It isn't even a recent one, and is certainly not compatible with any Version 3.xx FSUIPC. Current is 1.72 but I am releasing 1.80 this weekend. The second message is merely a reminder to you to tell the PFC driver which COM port you have your equipment connected to. It only occurs until you have done so, inside FS. PLEASE refer to the PFC DLL documentation, supplied in the same Zip. However, if you are not using any PFC digital controller, such as the Throttle quadrant System, the Cirrus console, or the Jetliner Console, then your PFC equipment probably just looks like a normal Windows game device, in which case you should not be installing PFC.DLL in the first place. Please clarify that with your supplier. Regards, Pete

Sorry, I don't know what you mean there. What's ITRA? All the PM controls you may need are available in FSUIPC for assigning to Key press or Joystick Button. You do not need to use SendKey for PM as FSUIPC suports PM directly. If you explain in more detail what you try, what you set in FSUIPC's Keys/Button pages, even show me the resulting FSUIPC.INI file, I may be able to help, but for most technical things to do with Project Magenta you will in general be better off posting in the PM NewsGroup. (I also appear there! :lol: ) Regards, Pete

No. it is nothing to do with when you connect. You are corrupting memory by incorrect declarations. Are you thinking that this reserved 1024 bytes for your FSUIPC connection? It does not. This defines a single byte (yes, just 8 bitss of data), then tries to initialise it to 1024 (which is impossible, as the maximum in one byte is 255. Doesn't the compiler complain about this?) To reserve 1024 bytes of memory you need to do this: BYTE FsuipcMem[1024]; Please refer to some C programming books! :? This is wrong in two ways. If FSuipcMem is an array, as it is when you define it correctly, then you either need to provide its address just as "FsuipcMem", OR give the address of the first byte in it, like this "&FsuipcMem[0]". Second, the FSUIPC_Process call processes your reads and writes, but you have done no reads and writes here, so it is a waste of time. It shouldn't do any harm, but it might. You must NOT use that library in a Gauge. The correct library is the "moduleuser.lib" which is included in the Module User part of the SDK. Regards, Pete

There's really no point. Your INI files should allow everything to default, except just set UseTCPIP=No in both, and in the Clients you may need to provide the Server Node details, as documented for mixed systems or NT/2K/XP servers. I cannot make that happen for you as your Server node address will be unique to you. If it is working at all it means the INI files are correct. Whilst there are lots of parameters you can tinker with, it is not a good idea to do this without any other information about this symptom, "some long pauses". It took me 6 months of tinkering and adjusting to get what are, for most instances, the 'ideal' settings. If you want to keep tinkering for another 6 months and get better settings, be my guest, but I would not recommend it. It is not hapy work I assure you! If there are these massive pauses, there'll be a reason. What do the WideSever and WideClient Logs show? WHERE are these pauses? In FS, in some Application? Which Application? Are you sure it isn't the application which has the problems? And, of course, are you using the very latest versions of both WideServer and WideClient, and FSUIPC for that matter? Please do not show me any logs of older versions. And please, if you do show logs, please close FS down and show complete logs -- there are summaries of performance added at the end which are useful. Finally, why are you using IPX/SPX? Is your system all Windows 98SE? It certainly should be okay if so, but since version 5 WideFS has been optimised more for TCP/IP. Mixed Windows systems, and Windows XP, are probably better with the TCP/IP protocol -- not faster, certainly, but smoother and easier to sort out. Regards, Pete

The effect of running Radar Contact is the same whether it is via WideFS or locally. It uses FSUIPC's hot key facilities. The whole purpose of wideFs is to extend FSUIPC's interface to client PCs. Yes, but it doesn't work for Exit selection, nor pushback. I tried it. Regards, Pete

The hot key provisions in FSUIPC work fine. many programs use them including Radar Contact and Flight Deck Companion. You evidently have some errors in yuor program. I can only repeat what I said before, which you seem not to have noticed: I cannot tell what you are doing wrong without more information. Can't you see what is happening by logging the IPC Read/Write data? That's what it is for, to help debug application programs. See the "Logging" page in the FSUIPC options. If you do the logging and still can't see what you've got wrong, ZIP the log and attach it here and I'll take a look. Regards, Pete

Follow the link in the FSUIPC documentation. It takes you to the SimMarket page where you can register. The key arrives within 24 hours by email. If it doesn't, something has gone wrong and you need to contact Customer Services (see http://www.simmarket.com). Oh, right. The accreditation of Alert is in process -- maybe it was released too early? anyway, I'm sure you'll find it beneficial in the long run to have a full copy of FSUIPC. Thank you for your support! Regards, Pete

Yes, it definitely works with FS2000, FS2002 and FS2004. It can be used in FS98 but there's generally not much it does in that, and it does operate a little in CFS1 and CFS2 (but not CFS3). It works fine with FS2002, I use it here quite often still. The message you are getting is because you have not registered FSUIPC, so you need to enter the freeware program registration key for Squawkbox. Please check the FSUIPC User Guide, part of the documentation included in the FSUIPC Zip file. You will find access keys for some popular freeware programs, including Squawkbox, in the 'sticky' thread about Freeware Keys near the top of this forum. Regards, Pete

Ah, so it was something in FSMeteo? I must have missed the version with that problem. thanks for letting use know! Regards, Pete

I'll add it in the next Release. You've already got the ability to see if there are any WideClients connected, if you want to exclude those (or at least flag a 'warning' in your results). I suppose the same could go for add-in modules and gauges -- you can list those that are running and look for suspects. :) Pete

They are not separate programs, but modules inside FS just like FSUIPC. I can certainly do that. But I cannot count programs using WideFS and running in a separate PC. WideFS won't be counted as a program as it isn't, it's an extension to FSUIPC as I said. And what if your "cheat" is running his helpful applications on client PCs? For install, all my instrumentation is running on PCs other than the FS PC. I don't even use an FS panel at all. It really isn't a problem, and I can add it in the next release (certainly this side of Christmas) but I really don't see how it would help a lot. Maybe you should refuse to let him use WideFS too? You'd be able to detect it in any case through FSUIPC offsets, you don't need to list all the modules in FS -- bit 2^1 at offset 333C indicates whether any clients are connected. You don't have to force him to uninstall WideFS, just assume he's cheating if there are clients connected. What about add-ins like Gauges and DLLs (GoFlight is but one -- there's my own EPICINFO and several others designed to get data already). These can of course interface to FSUIPC, and some do, but they can equally and more usually get their data direct from FS? Regards, Pete

Is this with FS2004? If so, then for the first time you can change the position without first switching to slew mode. Or, for FS2000-FS2004 you could try using Pause mode instead of Slew. You can certainly change some of the acceleration values and have some effect. I believe programs simulating catapult launches use this. But I'm afraid I don't know which ones would be effective, now how effective they'd be. You'll need to experiment. I don't think you can change the airspeed directly. Regards, Pete

I cannot tell what you are doing wrong without more information. Can't you see what is happening by logging the IPC Read/Write data? That's what it is for, to help debug application programs. See the "Logging" page in the FSUIPC options. If you do the logging and still can't see what you've got wrong, ZIP the log and attach it here and I'll take a look. Sorry, I don't understand. What's a "hold filename"? Anyway, offset 3D00 contains the title of the current user aircraft, not the flight. The current flight is at 3F04, as documented in the Programmer's guide. Regards, Pete

So I assume there's some delay after using the Toggle Exit control before anything happens -- otherwise how does it know you are not going to select 1 or 2 or 3 or something afterwards? Or does the control always toggle Exit 0 anyway, then any other doors you list with the numeric keys afterwards? I've always assigned "Ctrl+Shift+number keys" to the Radar Contact functions as the numeric keys are used for several things in FS. Pushback and turn, for one -- don't you do pushbacks? Go to FSUIPC's Keys or Buttons page (depending on whether you want a keystroke or a joystick button for this), assign your key or button to the Toggle Aircraft Exit control, and also set the parameter (it's the field labelled "parameter") to, say, 1 2 or 3 for door 1, 2, or 3. The FSUIPC User Guide explains how to assign keys and buttons. Regards, Pete

This is a whole new side of FS I've never heard of! I've never used any exits in my cockpit, except the one to the kitchen to make a brew! :) As a consequence I really have little idea of what you are talking about. I take it that there are now doors in some aircraft that can be opened and closed, and that this is done by a sequence of keys rather than a single control? I've just scanned through the list of FS controls, and I see "Toggle Aircraft Exit". I assume this is the one? Are you saying that you follow this with a keypress, 1, 2, 3 et cetera to select which door it is, a bit like engine selection after E? Have you tried setting the parameter for that control to the door number, instead of leaving it default to 0? I'm not saying that will work, but the parameters have been known to be used in some such circumstances, so it is worth a try. Otherwise, if the sequences are supposed to work, but don't, do you think this might be a symptom on some panels which send loads of controls all the time -- the same problem that causes some A/P and other values to be accelerated all the time? If one of those controls intervened between the two parts of your sequence, it would certainly mess it up (same as using any other control between the Shift+P for Pushback and the 1 or 2 for selecting direction messes the latter up). To check this, tell me which aircraft in the defaults in FS have multiple doors and I can test it here. If none of them do, how would I add multiple doors to one of the defaults without importing a whole cockpit? Regards, Pete

But what if it is your program, restarted for some reason? Each fresh process ID looks like a fresh program. Also, I only keep memories of so many then they look fresh again. And as I said, there are other ways of getting the speed -- FS's own GPS for one, Goflight displays another, programs using the other IPC type interfaces, etc etc. WideFs doesn't look like a program to FSUIPC, it is an extension to itself. But if WideFS is running there will be Clients, and any client can read information and FSUIPC has no knowledge at all about Wideclient applications. Do you really think there's any point? If I implemented something like that it would only ever increment, never decrement -- I don't know when a program has finished accessing FSUIPC. How would you interpret it? Pete

The original FSLook works, on the FS PC only, via a special, very inefficient and otherwise unsupported "fiddle" in FSUIPC. I did this only to help Gauge programmers, in the early days. FSLook2 is merely using the normal FS offsets, those from the 2nd table in the Programmers' Guide. Anyone can do that. In that sense it is a variation on FSInterrogate. No, because it is far more efficient to do it via the offset mapping method, and this provides far more opportunities to get desired data. Furthermore the offset method works with WideFs. There's no way any token reading is ever going to be efficient on a Network the way that WideFS is. I don't think any of FDSConnections actual code is from FSUIPC. You presumably mean the code to interface to it? That is a published interface. It isn't the most efficient way to do it, but it is used because it was used by so many programs on FS95 and FS98, with FSUIPC's predecessors. There's nothing wrong with other programs supporting the same interface. I hope that the competition is so good by the time FS2006 comes out that I can retire from all this and get on with something else, so ...good luck to them! :) Regards, Pete

Nice one Frank! :lol:

Not really. As far as FSUIPC is concerned each access is a unique event. It can, for the purposes of accreditation checking, investigate each and every access, but it only does this by the process ID after the first access otherwise it would slow things down too much. Between accesses nothing is known about any program. The communication is all from the application to FSUIPC. So most of the time FS is running there are effectively no FSUIPC users (else only FSUIPC would be running and FS would stop, if you see what I mean). In any case there are several other programs which can and do access data such as airspeed without using FSUIPC. As well as FSConnect there is the GoFlight stuff for instance. Anyway, when you actually fail the ASI, doesn't the airspeed read from FSUIPC also fail? I'm sure, for instance, that when the pitot heat if off and the pitot tube freezes up programs like Project Magenta also show zero airspeed, and PM definitely reads it through FSUIPC. Of course, there's also Ground Speed which effectively by-passes the ASI and can be read in things like PM (thanks really to the INS available in airliners) and of course FS's own GPS gauges, and then there are the cruder estimates of speed available through DME read-outs if you are travelling to or from a VOR/DME. Regards, Pete

I think Squawkbox only uses FSUIPC for certain things, like your aircraft position and the setting of your COM radio. Oh, also setting the weather unless that option is turned off. In that case the FSUIPC connection sounds like it is still working correctly. The details about other aircraft are entirely performed through Multiplayer, FSUIPC isn't involved in that at all. Isn't it "SBRelay" which matches FS2004's Multiplayer to the FS2002 type data expected by Squawkbox? I hope someone who uses SB + SBrelay + FS2004 successfully can jump in and help you here, as it is truly outside my area of involvement and experience. Regards, Pete

Right. So, either it is still as I said, a slight timing difference, or there's something in the way the compiler optimises for P4. However, since the crash doesn't appear to be actually in FSUIPC, the former still sounds the more likely. One timing-related possibility is that some access made by FSUIPC into other parts of FS takes place at a slghtly different time and this has an effect of some thread synchronisation somewhere. I'm still pretty sure it must be video or Direct3D related, but there are so many threads running in FS that tying it down is problematic. Thanks for the answers. I'm none the wiser, really, of course, but I suggest you stay with 3.126 for now, and upgrade to the next version when it is available, and so on, and hope for the best. If we ever do get stuck we'll experiment again like now. Regards, Pete

Yes, that was mostly the circumstances in the old mainframe days. Certainly it was all good training for producing code as free of silly errors as possible. When I was working in the development labs, though, we used to be able to get all-night hands-on sessions. I was involved in developing engineering test programs and operating systems for machines in development, or in the field but under engineering investigation for one reason or another. In other words, the software couldn't trust any of the hardware to work and had to self-check al the way. If you couldn't trust the software either, well :) Regards, Pete

I don't know exactly why. It's just my peculiar capability. Sometimes I wish I could play a musical instrument instead :) I discovered it at the first programming aptitude test I took when looking for a job back in 1963. We had an hour for this paper and I finished it in about 20 minutes and couldn't understand why no one else had. I got 100% (I was informed afterwards). I've always made typo-type mistakes -- this comes from trying to type as fast as I think. I used to stutter for the same reason. Luckily, most typing errors in programs get caught by the compiler --- but not all. Quite a few of the silly mistakes I've made this year have been typos. Otherwise nearly all my mistakes are when modifying existing code to do something extra or different when I've not been near the code for a while. If I misunderstand what I was doing originally then I'm almost bound to mess it up, then spend a while working out why. I think the difference these last few years is just that -- memory. I used to be able to look at a piece of code I'd written years before and remember what it was all about despite my appalling coding style and imbecilic commenting, or more usually the lack of it. Now I think I remember but, evidently quite often, don't. I put it down to erosion of the "little grey cells" by the preponderence of home-made beer (keeps me awake and helps me work all night! I don't use coffee), and the delicious wines we like to have with our meals. Regards, Pete