Pete Dowson

I attach FSUIPC 3.559. Please try this. I could not reproduce your problem any way I tried, including the circumstances you listed. All I have tried now is forcing a message through to WideServer using a separate thread running continuously in FSUIPC but only sending the message when the value in 3365 is non-zero. I really can't think of anything else to try. Please let me know. Regards, Pete FSUIPC3559.zip

You can Zip them all together and attach them to an email to petedowson@btconnect.com, please. Regards, Pete

Okay, more things to try now -- not that it'll fix anything, but hopefully the Logs will show why it is wrong on those PCs on which it doesn't work. Please install the versions of WideServer and WideClient attached (both "6.598a"). Edit the INI files for both, changing the Log= parameter in the User section to "Log=Mailslot". Run it in each of the circumstances you already tried, carefully saving both Server and Client logs each time and labelling them (renaming them) appropriately. The logs should tell us what is going on, IF it is detectable by the programs. If the mailslots are merely being blocked or discarded somewhere deeper down then I'm afraid I don't know any way to find out why. Thanks, Pete WideFS6598a.zip

No, that's clear now -- though previously I had assumed you only meant menu movements not entry into dialogues, because here I cannot, on any PC (I have 12 on my Network) reproduce the case where it is not non-zero when in any of the dialogues -- though maybe I didn't test all of them. I will certainly re-test the ones you mention. I was getting zero in 3365 when pressing ALT and moving around in the menus, without selecting anything. But the change I made to FSUIPC did fix it 100% here, so your results are indeed a puzzle. But of course I am using the latest interim release of WideFS (WideServer 6.596 and WideClient 6.598, available above). Perhaps you could just re-test with those, in case there's some quirk or timing difference, and let me know, before I start trying to find other ways of fixing something which isn't broken here? Regards, Pete

Erthe change I made only operates on menus, not on dialogues. In all my testing the other bit in 3365 is always set when I'm in a dialogue. Before I try to do anything else (not that I can think of anything else at present) can you please clarify EXACTLY now what you mean by "menu" in this context. Evidently you meant something different to what I thought originally. :-( Hmmm. Odd. That most certainly doesn't happen here -- if goes non-zero directly. What Windows system are you using? Maybe there are differences in the messages it sends when ALT is pressed. I'm not sure I can help any further, but I'll have one further look if you can be very explicit. Since it now works 100% here on all my Winodws XP SP2 systems I will have difficulty figuring a solution. It would be guesswork I think. Regards, Pete

I am sorry, but I really have no ideas about this. Later today I will add some optional debug messages to the code and send versions to you to try. If we look at the logs it may tell us what my Mailslot windows API calls are returning which prevents it working in each circumstance. Don't go crazy yeteven if we never get it working, you can still configure WideFS without it, it is just one feature less. Later then ... Pete

That's quite an astounding difference, much more than I could have reasonably expected. I am very pleased it all works so well for you. I've not actually done any numerical comparisons like you, only watching everything subjectively. Thanks! Pete

Okay. That does seem to confirm that the system assumes UDP blocks are "dispensable", that if there's a clash the UDP block is lost and not re-sent. With TCP and SPX, if there's a timing clash anywhere I think the block is re-sent. The sender "cares" about the block getting there, but not with UDP. That is a good solution then, Do you notice if things are smoother, or about the same as with TCP or SPX? I think my PM gauges look smoother (so the block timing is better, less latency from the replies confirming receipt presumably), but it is very subjective. As with FS's own "smoothness", the frame rates are no measure for this -- WideServer regulates the frame rates to match FS in any case. The only time they will appear to exceed the FS rates is when the data from one frame needs to be split into more than one block to keep within protocol and buffer limits. Regards, Pete

Yes, please. Regards, Pete

Thanks for posting this! I am sure such information will be useful to others. Regards, Peter

You are using Borland? I'm afraid I can't help with that, I only ever used MS for FS development. Didn't you find a Borland ZIP with stuff you can use in the SDK? A kind previous Borland programmer submitted some helpful material -- check the UIPC_SDK_BCB5 zip file. Pete

All my code, including examples, are actually C, not C++. Maybe you need to tell your linker that? I'm really as confused as the next person by the plethora of rather arcane settings you need to check in Microsoft language systems, especially linkers. Sorry. Perhaps you need to take the source code of the Library (also supplied) and use that? Strange that you've not sussed any of the function prototypes out. There are many Windows functions which, like the FSUIPC_ ones, return a success/fail indication as the result, but store the data returned in the locatin you point to. After all, the data could be anything from a single byte to an area of offsets many kilobytes long -- it isn't suitable for returning as any "typed" function result. If you look carefully at the prototypes for the Read and Write functions you will see that you have to supply not only the offset (start) value, but also the length in bytes (which could be large), and, most important, a pointer to the data to be Written or to the area where you want the Read to deposit the data. That might be a byte, a word, a DWORD, a double, an array, or a structure, or even an array of structures (as for the TCAS data, for example). Please study it a bit more, and revise what you learned in school about pointers, arrays and structures. Look again at the example and see how the data it displays is read. Regards, Pete

Ah ok, good luck! Do please come back and tell us what it turns out to be. Regards, Pete

Basically. FSUIPC_Open at the start, FSUIPC_Close at the end. In between use FSUIPC_Read and FSUIPC_Write calls to specify the data to be exchanged and then an FSUIPC_Process to send the request off to FSUIPC. The interface is enveloped in these 5 simple procedures to make things very simple for even beginners to understand! Please tell me what is so confusing? If you don't want to use the procedures, the source is also provided so that you can see exactly how the interface works in terms of basic Windows API calls. When it comes down to it the only real interface to FSUIPC is a single SendMessageTimeout call. If you are a programmer, surely you can follow these things? If you have specific questions, please formulate them, but it simply makes no sense at all to say "I know how to program but I don't understand even one line of any of this", which is what your statements seem to amount to. This really means you don't know how to program, surely? Please be more specific. I am not going to write programs for you. Regards, Pete

I really don't know how it gets as high as 1.89 Gb. Most folks advise setting a fixed sized paging file at 1.5x your real memory. In my case I don't think I ever see such a high usage. Yesbut it is very odd nonetheless whichever way you look at it. Next time I have FS running with RC on a separate PC (as well as the FS PC, I use at least 8 WideFS client PCs altogether - 6 in the cockpit, for all the displays and instruments, 1 extra for RC, ActiveSky and other additional programs, and one with FliteMap as a moving map. I'll look at the PF after a session. There are other possibilities -- maybe your PF is severely fragmented on your hard disk, which may make recovery difficult and there either take a long time or not actually even occur, thus the stuck value at 4Gb. Also, the hard drive may be filling up. Msake sure there's a good amount of free space. The best thing to do with paging files is to keep them at a fixed size, unfragmented, in the first place. Something like 2Gb should be enough. If you only have one drive that's going to be difficult to accomplish, but if you have two or more (drives or partitions), you could try reconfiguring all the PF to one drive, then defragment the other, and create a fixed sized PF on that instead. Regards Pete

Both speed and altitude are available in the list. Didn't you find them? You are using C++ for the first time, or do you know how to program? If you do, then look at the easy example provided. Just adapt it to your use using the different offsets for the variables you want. By all means ask specific questions, but please not general ones like 2how do I write a program", which this amounts to so far. ;-) Regards, Pete

Hi Thomas, I don't like the look of your logs with block sequence errors. Because UDP is not guaranteed, I suspect when there's a clash somewhere in the Network (hub, switch or router?) it simply loses the blocks, whereas TCP and SPX re-send. For some less critical display, like a map or some instrument readout without consequence, it may not matter much if the odd blocks are lost, but otherwise you might need to consider going back to TCP, or finding out why your Network is rather unreliable (at least for two clients -- AMD-HARDWARE and, really bad, AMD-FMC). Are you using a switch or hub? I think a hub is more likely to suffer from traffic clashes. I use switches all round and have no sequence errors with UDP on 10 clients. Regards Pete

Well, it is then very very strange that mailshots don't appear to work. I don't understand that. Could they be blocked somehow in your settings? :-( Pete

I'm unfamiliar with "PF", is that the swap file you mean? "Paging File"? Hmmmsounds like the Network drivers are using rather a lot. I've not seen such symptoms anywhere else though. Er .. at what stage did it decrease from 4 Gb? I'm confused. It certainly shouldn't be there for long unless something is going wrong. Do the WideServer and WideClient logs show anything? What happens when you run RC on the FS PC, as I assume you did before? Regards, Pete

I'm afraid the Log shows that the aircraft is using either a badly written gauge, or else a very old one, which doesn't use any correct access method -- possibly it is one dating back as far as FS2000. You''ll either need to register FSUIPC as a user (which will get you past that error, but won't guarantee that the bad gauge will work), or by trial and error remove each of the gauges in turn until the culprit is found. This is the indicative part of the log: The reason it looks as if it is FS9 itself trying to use FSUIPC is because the gauge is trying to access FSUIPC as if it were an external program, which of course it is not. Regards, Pete

It most certainly sounds like the Server doesn't support mailslots. you still haven't told me what operating system version you have there. Is it SP1 or 2 or the earlier (bug-filled) version? That's even odder. I'd need to see a client log of that -- it should be less of a problem on a "connectionless" protocol like UDP than either TCP or SPX, as neither end have a dedicated "socket" for that "connection" -- they simply send and hope the other receives. It is even more important that we discover exactly what it is you are using for an operating system on the Server. That definitely means mailslots aren't being supportedvery odd. I need to know versions of Windows on both Server and Clients so i can publish limitations. Regards, Pete

I've just realised the source of some of the confusion, and a weakness in my design. in trying to make it simple and automatic, and altering folks' INI files directly, I have actually mucked things up a little. I am attaching yet another WideClient -- 6.598. In order to clarify the assorted configuration possibilities out I shall tabulate them, thus: Case A: Server not specified in Client INI (In other words, no ServerName, ServerIPAddr or ServerNode parameters). In this case both the WideServer PC and the WideClient PC must support mailslots (i.e. run Win2K or XP), and the "AdvertiseService" parameter in the WideServer INI must not be set to "No" (it defaults to "1", for 1 second intervals). Sub-case A1: Protocol is set in the Client INI: This protocol is the one which will be used by the Client. If it isn't installed you'll get an error. Sub-case A2: Protocol is not set in the Client INI: The protocol tried first is the one specified by the Server in "ProtocolPreferred". If there is none, TCP is assumed. but in either case, the client will try others if the initial one is not installed (in order TCP-SPX-UDP, cyclic). Case B: Server is specified in Client INI (In other words, at least one of ServerName, ServerIPAddr and ServerNode parameters are provided). In this case the Client can work with or without Server mailslots operating to this Client PC. This depends on whether the protocol is set: Sub-case B1: Protocol is set in the Client INI: Broadcasts from the Server are ignored altogether. This protocol is the one which will be used by the Client. If it isn't installed you'll get an error. If the Client cannot find the specified Server you'll get an error. Sub-case A2: Protocol is not set in the Client INI: Broadcasted mailslots from the Server are needed. Only broadcasts from the specified server will be accepted -- this prevents the client from connecting to a different Server when there are more than one. The protocol tried first is the one specified by the Server in "ProtocolPreferred". If there is none, TCP is assumed. but in either case, the client will try others if the initial one is not installed (in order TCP-SPX-UDP, cyclic). This is true no matter which Server identification system is used (name, address or node). Existing users upgrading for version 6.51 or earlier First, a potential problem for early testers: The previous two interim Wideclients (6.596 and 6.597) will have deleted the "UseTCPIP=Yes" parameter and not replaced it. If the Server is identified in the Client's INI file, then broadcast mailslots will now be needed even if they weren't before, and this will cause problems on non-XP/2K setups. Solution: edit the relevant INI files and add "Protocol=TCP" (or whichever you want to try). For users who've not yet tried 6.596 or 6.597, I've made the solution work in WideClient 6.598, as follows: If the Client INI contains UseTCPIP=Yes and also identifies the Server in any of the three ways possible, then the UseTCPIP=Yes parameter is replaced by "Protocol=TCP" automatically. Otherwise, if the Server isn't identified, it is assumed that the mailslots have been used successfully, so the Protocol parameter is omitted altogether. Phew! Any questions? Regards Pete WideClient6598 only.zip

Got them by email. Thanks. No INI files though. The logs looks fine, excepting one little error on one Client: 105402 UDP connectionless mode set up okay! 105422 Error on send() of 215 bytes [Error=10057] Socket is not connected That occurs so soon (20 mSecs) after the "connection" (odd term for a so-called connectionless link, but I don't know what else you'd call it! ) that I think it must just have run foul of some setting-up still happening in the Server. I'm not getting that on any of my 9 or 10 clients here, but I may see if I can deal with it before User release. It looks good on Win2000 Pro so I'll change my documentation to say the broadcasting ("AdvertiseService") facilities work okay on that too. Thanks! I assume Win2000 non-Pro will be okay too. Now, please try it all with the "Protocol=UDP" lines removed from all the WideClient.INI files (as you implied you'd set), so that the "ProtocolPreferred" setting is effective. That will allow you to compare UDP with TCP with SPX with only one parameter change. ;-) Oh, please also update to WideClient 6.597 first, just to be sure we are all using the same things. Thanks again! Regards, Pete

Registrations normally work for all 3.xxx versions, excepting registrations purchased in 2006 need 3.53 or later (a date check error -- I had expected FS2006 in 2005, but Microsoft fooled me! ;-). Without registration FSUIPC is doing nothing unless the programs or aircraft you are using it with are accredited, of course. To test 3.48 with accredited programs or aircraft you will have to delete you FSUIPC.KEY file (or just temporarily move it out of the FS Modules folder). Regards, Pete

You can set Latitude, Longitude, Altitude, Pitch, Bank, Heading. In FS2004 you can set this in flight modes, in previous versions the sim has to be in Slew, Pause or Zero Rate mode. In Flight modes the sim engine will be moving it between your updates of course. The airspeed is a result of the sim engine and is a physical thing. You can't actually change the sim engine results -- or at least not for long (up to one frame). If you don't want the sim engine running then you use slew or pause mode, or even zero sim rate mode. GPS position is a result of using a GPS -- it is the actual world coordinates you change -- i.e. you move the aircraft, not fiddle GPS readings. Regards, Pete