Pete Dowson

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

With WideClient 6.596 you either need to run it with Broadcasts operating correctly (i.e. on XP systems for Server and Client -- maybe Win2K though this is not yet clear), and the "AdvertiseService=1" parameter correctly defaulted in the Server INI files, and not have any Server details in the Client INI, OR you must specify not only the ServerName, IPAddress or Node but also the required Protocol. If Server details are specified in the Client INI files, the broadcasts from the Server are ignored in any case. If Broadcasts aren't being used then there is no use for the "ProtocolPreferred" parameter in the Server INI, because by the time the Client can get this information it must already have sorted out a protocol. I attach version 6.597 of WideClient (only -- the Server is not affected) which is similar, but operates correctly in that if you omit the Protocol parameter and specify the Server name, address or node details, the protocol is chosen automatically -- with SPX preferred if a Node is specified and TCP preferred otherwise. In either case, Broadcasts from the Server are ignored because you are specifying the Server explicitly, locally. The ideal situation, reflected in the default INI settings, is for all PCs in the system to support the Mailshot broadcasts (i.e. be using WinXP), and for the only protocol specification to be the ProtocolPreferred one in the Server's INI. There would be no need for any Server details or Protocol in the Client INI. This setup would allow you to test any of the three protocols across all clients by only changing the preference in the Server INI. I hope this is clear. I am trying to make things very simple, but it is quite difficult when there are so many possible exceptions! ;-) Regards, Pete WideClient6597.zip

Okay, I found a problem in WideClient . I can only reproduce your Log if I stop my server broadcasting (by setting AdvertiseService=No in the server INI file). For some reason it is now ignoring the ServerName and ServerIPaddr parameters UNLESS the Protocol is specified explicitly, and since is deletes "UseTCPIP=Yes" without replacing it, this presents a problem for those not using Broadcasts. Anyway, the main indication in your case seems to be that the Broadcasting isn't working, so I still need to know what your Server is running and to see the INIs. Meanwhile I'll fix the reading of the Server name or IP address details and re-issue WideClient only. Thanks, Pete

Seems like the broadcasting isn't working anyway. If you specify the Protocol in the clients the ProtocolPreferred parameter is totally redundant. It only affects what is transmitted in the broadcasts in any case, and you don't seem to be getting those. However, without all that the Clients should default to TCP, and if that doesn't work they should then try SPX and UDP, in that order. They do here. I still need more information please, including INI files and Server log. The Server initialises all of the protocols it can in any case, setting a protocol there is redundant -- you never did it before, remember? I need to see the Log please! Regards, Pete

Hi Thomas, You shouldn't need to set the protocol explicitly on the XP clients. That merely makes the "ProtocolPreferred" setting in the Server redundant, and the clients then have no choice. I don't know about the Win2K ones -- does my Broadcast system work for those? i.e. do they connect okay without being told the ServerName or ServerIPaddr? Regards, Pete

Are you running winXP on all of them? If not then you'll need to provide the Server name to those which are not running XP, or all if the FS PC isn't running XP. The log seems to indicate that those clients aren't receiving the Broadcast. Only XP can provide that facility. This isn't a change from the previous version of WideFS. You didn't delete your previous INI files did you? Ah. Not sure about Win2K. What's the Server running? It won't see them unless they see the Broadcast, which they don't. The Clients have to send an "I'm here" message to the Server, but they can't when they don't know who the Server is. I really don't think there's anything I have changed in this part of the mechanism which could result in these symptoms. I'd like to see the Server Log in any case, and maybe the INI files. Does the Win2K one normally work with the ServerName missing? Regards, Pete

One think I recall, when someone else had a similar problem, was this: add TableFog=0 into the [DISPLAY.Device *] section of the FS9.CFG file. This, I presume, fixes a problem some drivers have with the way FS displays fog. I think this snippen originally came from a post on one of the AVSI< forums, back in January. On the other hand I think the person who tried it got it to work only once, then it reverted. What did fix it in the end was a re-install of FS -- apparently he had something corrupted. Personally, before taking such a step, I would try deleting the default-loaded FLT + WX files (or even all your WX files) and possibly also the FS9.CFG file. This is because I think the most likely scenario is a corrupted WX file, maybe from a bad download. Corrupted WX files have long been known to cause odd problems, and these could well change with or without some other add-on present, whether FSUIPC or something else. This is because the presense of the add-ons changes the memory configuration and the timing of events, so different things happen as a result of the one original problem. I hope this is of some help. Regards, Pete