Pete Dowson

The problem is obvious from the log sections shown above. It seems that the ASV.EXE program is actually attempting to read offset 0020 before it has supplied its accredited Key! This is not an FSUIPC error. I suspect ASV has several threads and, for some reason, on your system one is getting ahead of the other. More synchronisation is needed between the threads if that is the case. You could easily verify this by enabling IPC read and write Logging (in the Logging page) before starting ASV, but beware the log will get quite large. Also the extra logging may change the timing and "lose" the problem. Please relay these details to HiFi Simulation so that they can rectify it. Meanwhile, if you register the application manually (on the first page in FSUIPC options), with the name ASV and Key CV8X CNJE RB7Y you should be good to go. (But it isn't the right solution). Regards, Pete

Well you have the "forward, left, right, back" view controls which are as fast as the graphics would allow, then the more gradual up/down incremental ones. But, yes, if you need to views at some pre-calculated angles before engaging them (or as soon as), I can see the difficulty. Sorry, but I have no answer to this. I really don't know where such values are stored. This is something I would endeavour to look for in future versions of FS, but I am afraid that I really don't have the sort of time needed to hack further into a two-year old version. Sorry. The author of ActiveCamera probably knows how to do these things. Maybe he would give you an interface to control things through his code? Regards, Pete

Ah, yes. When stopping Windows services you need to be pretty careful. I only ever did it one at a time, eventually settling on a set of disabled ones after weeks. Thanks for letting us know. Pete

Sorry, but I've never heard of it. Have you asked the authors? I'm really 100% tied up with doing things for FS without doing 'plug-ins' for other programs, certainly until February at least. Looking at their website, they say: ... though there's no sign of the SDK yet. When it is released, with that together with the FSUIPC SDK you should be good to go? Regards, Pete

I'm not sure. I will have to search the "material" in the SDK for youthe only "material" to search, BTW, is the one document, the programmer's guide. You just need to load it up and use word search for likely terms. First, though, let's be sure there isn't a simple control you can use. Is this the view of the outside world from the cockpit? If so don't the normal adjustment controls (e.g. those by default assigned to Shift+Enter and Shift+Backspace) do the job? If not those, what about the 'eyepoint' controls? If you can be more explicit so I can understand, maybe there's a much easier answer than you think? First try looking through the FS2004 controls list (included with the FSUIPC Zip). Any control can be sent through FSUIPC's interface at offset 3110 if you want to do it by program. Searching the Programmers guide, as promised, all I can see which is specifically to do with views is the byte at offset 3126, but that's really only for the main quadrant views, at best. The other view things are to do with tower position. Regards, Pete

What have you changed? The only information which is of any use is: 28859 Server = RALFY 28859Okay, IP Address = 192.168.2.100 29922 Error on client pre-Connection Select() [Error=10061] Connection refused This is from the Client. The Server never sees anything. It seems that you have something blocking the access. Possibly a firewall? Have you installed some protection recently, or changed some settings? The only other thing which is a little odd is that IP address. It is unusual to have a Subnet of 192.168.2.0 -- that third number is usually 0 or 1. Can you check that both PCs are on the same Subnet? i.e. that those three numbers are the same in both. Regards, Pete

It does, for weather injected into FS from external programs via FSUIPC's weather interface. Surely it would be wrong to mess with FS's weather if the option to do so is disabled? I don't understand your logic. Where do you set them if not in the FS weather menu? Sorry, you've lost me somewhere? It applies to ALL weather supplied by external programs because I can influence the values as they are being set. Very little of FSUIPC's weather functions can be applied to FS2004's own local weather because not enough is known of the grid structures used. It took many many hours of difficult hacking through complex code even to do what has been done. I nearly gave up. But that fiddles the visibility at the aircraft in a totally different way. It isn't really doing any weather manipulation. I can only apply an upper limit. Regards Pete

That only applies to weather set via FSUIPC's weather interface. No. Sorry. That sounds like an option you want to request of your favourite weather program. Regards, Pete

Well, that is something you really need to negotiate with the sellers, SimMarket. I don't actually sell it directly at all. If yours is a commercial enterprise (it looks like it wants to be) then I doubt if there would be much of a deal going. If it is intended to be non-profit making that maybe SimMarket will come to some arrangement for some publicity on your system. Best discuss it with them. Regards, Pete

Pin 9 on the 9-pin D shaped plug/socket is the "Ring Indicator". You don't need that. In fact GPSout only needs two wires -- the TXD data out from the FS PC (pin 3) connected to RXD data in to the receiving PC (pin 2), and a common earth or return line -- pin 5 to pin 5. Maybe the serial port on the receiving PC is configured not to accept input unless some of the control lines are valid too. The usual way to do that is by connecting DCD, DTR and DSR together at the receiving end (pins 1, 4 and 6) and also RTS and CTS at the same end (pins 7 and 8). A serial printer cable would do that (though serial-connecting printers are now very rare if they exist at all). The FS PC end needs no such fiddles as GPSout configures the COM port to do without all that stuff. Regards, Pete

Hmm. Then either the USB serial adapter isn't working, or the so-called "null modem" cable you have isn't right. See if you can verify it some other way. Regards, Pete

Ah, I misunderstood, then -- you are using a REAL COM port on the FS PC, so that doesn't need an adapter? Then you have a serial port adaptor on the other computer? If PortMon is showing activity on COM2 then it would appear to be working, at least from the internal view. So where and why were you trying that USB-type name if USB isn't being used on the main PC? When you installed the USB serial port driver on othe other PC, did it assign that COM5 name? I'm confused now as to how you have these thnigs hooked up. Regards, Pete

Only if COM2 is indeed the port to which the cable is connected, and it is indeed the correct cable, and you have the right port the other end. As it is a USB port I don't see how it could be, unless it has a Serial Port adapter on it and you are using a driver for it which makes it look like COM2. How did you arrive at COM2 in any case? How would you know if the latter should be WCEUSBSH001 or something else? Maybe there are several USB ports and they all have different names? I'm sorry, I really know nothing at all about USB. I gave up trying to link to my iPAQ long ago. I hope someone else will be able to help you. Regards, Pete

The very last page in the Joysticks section of the FSUIPC options provides calibration facilities for up to 4 reversers. However, I'm sorry, but I have not included facilities to map two reversers to 4 engines. No one has actually asked before, and it isn't a trivial job. I'm not sure when I'll get a chance to implement such an option, but perhaps you should remind me in February next year (I am on holiday in January). To use those axes, because FS doesn't support separate reversers, you would have to assign your spare levers to some unused axes in FS (Joystick assignments), then look up the numeric equivalent of those axes (in the FS2004 controls list provided in the FSUIPC ZIP file), and edit Reverser assignment parameters in FSUIPC's INI file. Check the documentation, the parameters are listed there. You might find it easier (and maybe more flexible) to assign just one of your spare levers, only, as the reverser -- assign it in FS to the Engine Mixture. Then go to page 7 of FSUIPC's joysticks options and calibrate it. That will drive all the engine reversers. You could then use the other lever for a speedbrake/spoiler lever. I think this is the best arrangement. You really never need asymmetric reverse thrust in any case, so one lever for all engines is fine. Just calibrate the throttles, in FSUIPC, so that both the Centre and Reverse values (in the boxes underneath) are the same. i.e. Pull the throttles right back, to where idle should be, and click the Set buttons for both Reverse and Idle. Allow them forward a little for the other Idle value, so you always have a good stable idle. Make the Max value still the Max (full forward). Doing this will stop any reverse thrust being applied -- the minimum "OUT" value will be 0. Regards, Pete

Well, IPX/SPX was most definitely favourite on an all Win98 setup. But it became problematic with mixed Win98/Me/NT/2k/XP setups, so that's when I added TCP/IP support. As a programmer I prefer IPX/SPX just because it is so much simpler at the lower levels -- there is far less red tape. The actual data part of the transmissions is a much higher proportion -- there's too much red tape and multiple levels in TCP/IP, which are needed for Internet linkage all over the world but are a huge overkill on a small Network in your computer room upstairs! ;-) Of course when I first did WideFS, back in FS95 days, local networks tended to be those coax-connected affairs running at 10 mbps. The faster hardware was pricey back then. Now 1000 mbps connections with support on the motherboards are commonplace, and you can take 100 mbps for granted. Also Microsoft have put much more effort into making TCP/IP operate efficiently and smoothly, and it isn't so bad since WinXP SP1. Really unless you are really pushing a lot of stuff around I think you'd find it difficult to find any preformance differences between IPX/SPX and TCP/IP -- provided the PCs involved aren't overloaded. I still think IPX/SPX is cheaper in terms of processing, especially in the Server. Well if you are okay at installing IPX/SPX, and have either an all WinXP or all Win98 setup, then go for that. You can easily compare them then, as the only change would be in one little parameter in the client INI file -- WideServer supports both automatically (if both are installed). On my test systems I have a mix of Clients, some TCP/IP and some IPX/SPX, and there's no problems. I am all WinXP these days. If you use the latest version of WideFS (6.50 or the interim updates available above) then you don't even need to configure anything other than the IPX/SPX choice if all your machines are running XP. Version 6.51 will be released next week I hope. Not any big differences, just a consolidation of the small things. Regards, Pete

I don't know FSBuild at all. Does it use the FSUIPC interface for its dealings with FS? If it is only a flight planner then I wouldn't have thought it would link to FS at all, merely placing its generated PLN files into the appropriate folder for FS to pick up via the standard FS options. The FSBuild manual? You don't have to have any parameters in WideClient.INI at all if you just want to run a program. Have you tried just starting FSBuild as you normally would? All the Run parameters do for you is start programs to save you doing it. Get FSBuild running manually first, worry about automating things if you want to later. I have no idea what that would be. Nothing of mine makes any such files. It sounds like you need to ask FSBuild support for help. What FS related files? Now you are confusing me. Exactly what ARE you trying to do? Is FSBuild written to interface to FS via FSUIPC? If so it should run via WideFS as well, but it may need access to folders on the FS PC too, which would have to be done by file-sharing, not by WideFS. I really do think you need to ask FSBuild support for help in the first instance. That's correct. If it shows "connected" it is working. You can forget it and see about running your FS applications. WideClient will look like FS running FSUIPC to them. Normally you'd minimise the WideClient window, or even hide it. You'd only want to see the window if you were using the recently added ButtonScreen facility, or if you were using an FS application which liked to attach itself to FS's Window -- the WideClient Window "pretends" to be FS for just that purpose. There aren't many programs which do that -- EFIS98 (for FS98) is the only one I can remember. Regards, Pete

Version 3.44 is not supported. Please first update to the current supported version, which is 3.50, and then remember to do so again for 3.51 which should be released next week. I cannot and will not support old versions! This indicates that there is something seriously wrong with your registration. Where did you buy it? If it is not legitimate you will have problems. If you believe you have purchased registration legitimately then Zip up the FSUIPC.KEY file (from the FS Modules folder) and send it to me at petedowson@btconnect.com, along with details of your purchase such as the receipt from SimMarket. Pete

Please update your two-year old (!!!) version of FSUIPC first. Then ask again. Regards, Pete

Where any of the PMDG indications are actually the FS indications, yes, you can make them work. But where PMDG have their own, separate, indications and displays, then, no, since we don't know where they are or how to read them they cannot be displayed externally. GFdisplay interfaces to FSUIPC, and FSUIPC is able to read just about everything (but not quite) in FS. But it cannot read proprietary values which are contained only in third party code, as is the case with most of the PMDG stuff. Until and unless PMDG release information on how to interface hardware to their panels then I don't se that anything can be done. And they've expressed no desire to do so, quite the reverse, except for specific drivers they may bring out for specific hardware (as, for example, is the case for the Engravity CDU I think). You need to hammer on PMDGs and GoFlight's doors to get them to agree. I'm afraid there's nothing I can do. I've tried my best to persuade PMDG to no avail. Regards, Pete

Okay. The log named "WideClientWithServerName.Log" shows: or, on the other hand, the other Log (just named "WideClient.Log") shows: So both methods work in the sense that the Server PC is identified correctly. So you can leave both the Server Name and IPAddr parameters out. However, please look at the IP address: 192.168.1.101 In your previous set of files you were actively setting the IP address as 192.168.0.101 If the so-called "subnet mask" is set to its usual default, 255.255.255.0, then the difference between that 1 and that 0 could be absolutely crucial! I think that BOTH PCs MUST BE ON THE SAME "SUBNET". In fact all PCs you want to work with each other should be on the same subnet. Check the IP address of the Client PC -- if that is not 192.168.1.??? (??? is anything), then you either need to change it, or change the Subnet Mask so that the 0 and 1 difference does not matter (e.g. change it to 0). I don't know how you managed to get the Network into this sort of mess. Are you setting IP addresses explicitly, or letting them be assigned by a Router or something? Maybe you are assigning one explicitly and the other automatically? You need to be consistent. This is really all in the realms of Networks which I know little about, by the way. It is nothing to do with programming. I had to figure out how to get my Networks configured by reading Windows Help and using trial and error. I know it isn't easy and I'm sorry if I'm not good at explaining things I know little about. But let me know if you cannot find where all this stuff is set or examined. I can help you there. Pete

So, even with the correct parameters (which you did not show me), it still does not see the Server? There is no error reported in the logs you sent, merely a timeout at both ends though lack of any connection. Can you show me files relating to your attempts with the correct parameters? Maybe there are then more clues? Yes, the problem in the files you sent were that the parameters were incorrect. You put the IP address in the Server name parameter. I suggested trying both using the ServerName ("DADS"), and even, if you have Windows XP installed in both, leaving both Server parameters out. Neither of these steps require you to be a computer programmer, surely? I don't know where you get that idea from. I did say that all these things are mentioned in the documentation. I assumed you had not bothered to look, otherwise you woyuld have surely realised that the word "ServerName" is not same as "ServerIPaddr"? The WideServer log even explicitly tells you the Server name (DADS) in case you don't know how to find it! Now that you have tried the suggestions I made, without success, perhaps you could show me the results so that we can move on? That is the weirdest response and attitude I have come across in a very long time! Where are you coming from on this? You say you have a problem, and send me files. I study them and make at least two suggestions as to why it may not be working and things you should try, and you react so crazily? If you don't want any more help, that's fine, but I don't understand why you should bring in all this irrelevant stuff about programming and "not being worthy" (?) as an excuse. I help as much as I can with the information I am given and at the same time try to encourage folks to find ways to help themselves. If you are doing the latter now, that's fine. If not, let me know.. Pete

What are you thinking of, putting this parameter in the WideClient INI file: ServerName=192.168.0.101 ? That isn't a name! It's an IP address. Please check the WideFS documentation. Although, somehow (I don't know how), Windows does seem to recognise something with that "name" as something with the same IP address, it is a very odd way to misuse the WideClient parameters. As far as I can see it probably isn't even the correct IP address. Why not use the actual Name to save having to worry about such obscure things? Your ServerName is apparently "DADS" (see the WideServer LOG). It's a whole lot easier. You seem to want to make it difficult? ;-) In any case, if you are using Windows XP on both PCs you don't need to give either the ServerName or ServerIPaddr. Clients will find the Server automatically. It's one of the new facilities since 6.50. Again please see the documentation. Pete

No. Purchasing a registration gives you access to the additional user facilities in FSUIPC. Without user registration FSUIPC is still the FS interface for applications it was always meant to be, like FS5IPC and FS6IPC before it (though greatly extended, of course, to match FS developments since FS98). If you read some of the Announcements above you will learn more, and even more again from the user documentation included in the FSUIPC ZIP file. Regards, Pete

The facilities in FSUIPC for programming buttons and switches have no knowlege or facilities for driving displays or indicators. No, but it may help you sort it out. There aren't any magic solutions until GoFlight and PMDG come up with some agreement to work together. Is the documentation too obscure? It uses the facilities provided in the GoFlight SDK to drive the displays according to parameters you provide. How much more do you need to know? If you want technicalities, first download the GoFlight SDK then ask specific questions, but preferably ask GoFlight support, eh? ;-) It is unlikely -- unless you can hack into PMDG code to find out where they store the information you need, and how to convert it. The do not publish anything useful. All jet aircraft have some way of switching the fuel flow to the engines on and off, for engine starting and cut-off. Obviouisly the PMDG ones do too. Do you assign the switches to whatever keyboard short-cuts PMDG assign for those? Sorry, but I really cannot undertake to support either GoFlight or PMDG products, and especially not both at the same time. You must ask your questions of the appropriate support. If they use the standard default FS methods, then they use the Mixture Full Lean for cutoff and Mixture Full Rich for start. I advise you to first try a default FS aircraft, for which these things are documented by Microsoft. When you can start and stop the default Jets, try the PMDG ones. From what you are saying you seem to be trying to run before you can walk? Regards, Pete

You are using version 3.48 of FSUIPC, which is old and which I cannot support. however, the log shows no attempt at an access by any recognised gauge at all, only some illegal access unidentified. If you want further help please first update to a supported release -- 3.50 or later. Version 3.51 will be released within two weeks and then 3.50 won't be supported. Regards, Pete