Pete Dowson

Odd that you make no mention of having installed he MixW pair of virtual serial ports on the laptop? There's absolutely no way that the same COM port can be used by two programs simultaneously -- only one program can get a single serial port at a time. There has to be two ports, one for WideClient to send the data on and the other for your map program to read the data from. Normally these would have to be real ports with a cable linking the two, but the MixW program I provided does this by "pretend" ports ("virtual" ports) and links them by software. Please read the GPSout and WideClient documentation through again. It really looks as if you've skipped some important points. Regards, Pete

FSUIPC doesn't have any such message. WideServer does. Where's the log? What's a "Blitz3D basic"? Sorry, no. I really have no idea what program you are using nor what "point it at the right port" means? Doing what? This is getting thoroughly confusing. If you run WideServer in FS, just run Wideclient on the client PCs. You then run FSUIPC applications on the clients. Let WideFS deal with the Network stuff. What are you trying to do with it? What "linking business"? We seem to be talking different languages here. If you want to use WideFS please check the documentation. It is all explained there how to use it correctly. There is a library for FSUIPC, of course, it is part of the FSUIPC SDK. If you want to interface to FSUIPC you need the FSUIPC SDK. There are sections in the SDK for several languages, including Basic. Have you looked? Please just download the SDK and check the documentation. It sounds like you are starting from completely the wrong end of things. Ignore WideFS, write to interface to FSUIPC. WideFS is just a way of interfacing to FSUIPC across a Network. Regards, Pete

If the "dock" option is grayed then all that means is there is no cockpit panel part for it to dock to. The INI relates to the Locking, not Docking. There was no need to "RAR" the file and upload it for downloading. it is only a few lines long, look: [AdvDisplay] Window=1290,382,324,188,1,1 Enabled=Yes PositionLocked=Yes HideWindow=No AutoHide=No AlsoATIS=Yes MultiLineOnly=No Scroll=Normal There's nothing wrong with that, so I think you are seeing another symptom of how FS2004 misbehaves in full screen mode on multiple monitors. Pete

Well, FSUIPC doesn't care about the Internet, and FS9 will only "trigger" a restart if it detects a serious error -- and even then you should first get the error report with the "restart FS" option. Okay. But it might be worthwhile trying the No-CD crack for the FS9.EXE file in any case. I have grave suspicions over interactions between what it does to protect MS's copyrights and what Internet and Anti-Virus related routines do to protect your system. In general most game programs advise disabling virus checking whilst using them. Regards, Pete

No, not when "Locked", only when "Docked". I must admit I don't know about Virtual Cockpits. They didn't exist when AdvDisp was designed. What you say does happen, at least on the main monitor, when the window is Docked to a panel part. The Lock facility is not related to panel parts at all. The window should simply stay locked in position. It is never hidden of its own accord when locked. If it disappears it sounds like the way FS is handling the display is causing the Z-order to become messed up. The details for "Locking" are saved in the AdvDisp INI file, those for Docking are panel-dependent and saved in the aircraft's Panel.CFG file in the [AdvDisp] section. You can check that to see what it is docked to. It seems there may be some second monitor arrangements in full screen mode which cause some problems. I wonder if this is all related to the problems I've seen with FS2004 on two monitors in any case. On my nVidia two-monitor set up, having FS2004 in full screen mode makes it almost impossible to have a panel set up which is remembered from one aircraft load to the next, let alone across reloads of FS. I think others have complained about this FS bug as well. It used to all work fine in FS2002 and FS2000. I hope this sort of thing will be resolved in FSX. Meanwhile, possibly swapping the use of the two monitors over might help? If the main one is to the right, the coordinates for the left probably go negative which may just be one cause of problems. If you are using Lock instead of Dock perhaps you could show me the AdvDisplay.ini file so we can see the saved position? For Dock you'd need to find the section in the Panel.cfg file. Regards, Pete

Does it interface only to FSUIPC? If so then it should have no problem at all through WideFS. I don't understand what you mean here. Certainly nothing of mine requires any application to link a DLL. You need to explain what you mean. Any application written to interface to FSUIPC on the same PC as FS should certainly have no difficulty connecting via WideFS, as the interface is identical. That's the whole point. There is no application DLL necessarily involved in any of that. That does not make sense. FSUIPC has no Network code in it whatsoever. And "sending stuff via TCP" is not ever going to get WideFS interested. It has its own complex protocol in the interaction between Server and Client. This is independent of the Network protocol, which can be TCP/IP or SPX/IPX. Regards Pete

I'm sorry, you need to direct your inquiries to the sellers. I only do development and technical support. As far as I know you pay in whatever the units say on screen -- it is your credit card company that converts it, you won't know the final amount till you get your bill. At least with all my purchases on the 'Net this is what always happens. Regards, Pete

I'm sorry, but if there is no version info there there is no way it was gain free access to FSUIPC. The whole license checking process revolves around automatically reading that data when the program connects. The only answer for such programs is to purchase a user registration key for FSUIPC. Most users find this quite worthwhile in any case, for access to the facilities it provides. Regards, Pete

Whether a value is positive or negative is all in the interpretation, not the value. In 16-bits, for example, a value 65535 looks identical to a value of -1, depending whether you treat it as signed or unsigned. In hexadecimal they both look like FFFF. If this is in a 16-bit (2-byte) word, then send 63536. It is the same. Calculate it as 65536 + (the negative value). In EPIC you would need to do 65535 - (your positive value, eg 2000) then add 1. The 1 difference is needed because 65536 cannot be accommodated in 16 bits. Regards Pete

You are correct much of the time in most of Western Europe, and even sea locations like the Canaries in many weather conditions, but I've flown all over the world and sharp horizons are also quite common, especially in the dry season or in central continental places where air moisture and pollution doesn't give that fuzzy indistinct edge. All I am saying is that it depends -- sharply delineated horizons, especially those featuring mountains -- are, in my opinion, just as realistic as fuzzy ones, and more so as you ascend (because you are looking through less moisture and pollution as you climb out of it). At very high altitudes the loss of horizon distinction in some directions (replced by a sort of glow) is more to do with sun glare and reflection/refraction effects than either pollution or moisture. A friend and occasional co-pilot of mine, also an ASv6 user, was lamenting recently because no matter what he did he couldn't get a sharp horizon, which he also thought he should see from altitude, at least much of the time. We fixed it (it was to do with visibility settings of course). I have had other questions on this too -- it was just odd to me, after those, to see someone asking the reverse! ;-) Regards, Pete

I need some information about the file. Send me an email (petedowson@btconnect.com) containing: 1. The EXE name 2. The "Product Name" 3. The "Company" Both the latter are from the Version Info -- right-click on the EXE in Explorer and select Properties-Version. If those fields aren't present it may not be possible to enable free access for it. Pete

That sounds like not so much a "lock up" as either a pause, or a zero sim-rate setting. Either that or it is the graphics section which is locked up, but I thought that would effectively freeze all FS access as I don't think it is all separately threaded -- FS2004 is *not* written to take advantage of multiple processors, which would be the case if such major portions were threads. That "goofy" file is to do with the anti-debugging and copy protection in FS2004. I shouldn't really advocate this, but I think you should try getting hold of the No-CD crack of FS9.EXE and see if that fixes your problem. I wouldn't be surprised if the anti-piracy checking is falling foul of something else in your system, like anti-virus checking or something. I have to use the No CD crack for versions of FS because there's no decent way of developing and debugging my programs with that anti-everything stuff running. Make sure you get the correct version -- there's one for FS9.0 and a different one for FS9.1. Regards Pete

There's something weird going on with your video driver then. I cannot make it disappear here. I use nVidia cards -- what video card are you using, and what drivers? It is most odd. AdvDisplay has been in use on many systems now for many years, with very few changes ever needed. This is not just with RC, though it has been the mainstay of RC's menu system since RC version 2 I think. Certainly all the way through Version 3. You shouldn't need to go to the Modules menu in any case. If you need to switch it on and off there's a Hot Key option for it in FSUIPC's HotKeys tab -- you can assign a keystroke then either use the keyboard, or program a Button to send that Keystroke. Regards, Pete

Switching views will temporarily lose the display in DOCKED mode, because the panel part is closed too, but the LOCKED mode merely re-displays over any part. I've never found a case where it doesn't work. I don't understand how it doesn't in your case. Whay mode are your two displays configured in? for FS you really need them as a single wide screen. You can't use ShowText over parts of FS. As I said, try that if your other monitor is not using any part of FS. In full screen mode, the FS windows will always prevail. That's what "full screen" means -- FS takes over the entire video system. Regards, Pete

Lightning, like clouds themselves, are placed randomly in the graphics and effects routines of FS. There's no way I know of getting precise data for either, other than the general weather settings for each nearby weather station. To see if there are any storms nearby you would need to read the cloud data for each nearby weather station, checking the cloud type for CB ("storm"). You'd need to search the FS weather station lists to determine valid nearby weather stations -- check the Weather folder in FS. FSUIPC does allow you to read weather at any weather station given its ICAO id, or, in fact, weather near any point given a latitude and longitude -- but the weather describes that for the locale, so a storm cloud listed may simply be within several miles of the station or point. Regards, Pete

Not the surface limits in FSUIPC. Use the graduated visibility option and set the upper altitude limit. If you want a foggy horizon (odd, most folks don't, at least not all the time!) just set the upper altitude limit to 20 miles or less (2000 units). Don't set the FS view distance to the minimum -- that will operate like a cut-off, and simply stop drawing at a certain distance. Maybe that's the effect you are seeing? You want that as high as possible without degrading your frame rate too much. Same with the cloud view distance. Regards, Pete

Yes. It really does sound as if FS is not relinquishing control of the processor very often. Not surprising with only an Athlon 2100+, I found such a machine struggled with FS2002 even, let alone FS2004 (I had one similar years ago, for FS2000). No, not at all. It is really looking like a horsepower issue. I really think you either need a much faster PC or a separate Networked PC to run RC (or any other separate programs) on. Regards Pete

That's an odd complaint -- most folks complain that it isn't often as sharp as it ought to be when at altitude! This is the first time anyone has complained the other way! ;-) This really isn't a lot to do with ASV6, it is merely a combination of things -- the visibility, which is usually much greater at altitude than on the ground, and the viewing distances you've set in FS's sliders. For the former there are visibility options in FSUIPC for limiting it and have it varying according to altitude, up to whatever altitude you like, then limited to a higher value. Look there -- but you'd need a user-registration to use FSUIPC options like that. Regards, Pete

Further to the details in my last message, you should note that, like IPC transfers direct with FSxIPC the blocks defining particular read, write or other operations are themselves blocked together in frames, up to 30kb in size (though limited by parameters in the INI normally). With IPC transfers these blocked requests do not have a header, but simply a zero DWORD terminator. In WideFS transfers yjrtr#s no terminator, but each frame (blocks of requests) has a header which contains the block size, a sumcheck and a sequence number or timestamp. The WideFS logs actually do not log the header in raw bytes but decode it and show the walues at the head of each frame decode. I thought you'd see that immediately if you were monitoring the actual TCP/IP data being transferred, but if not here is the frame header format: struct { ULONG ulSize; ULONG ulTime; WORD uSum; BYTE fUsed; } PREQHDR; Don't ask me what "fUsed" is -- this is a bit historical. I would need to delve deep into code to work that out. The others should be easy enough. The Sumcheck is a byte sumcheck of the data following the header which is of size ulSize. The ulTime values used to be a timestamp but now it is just a sequence counter, at least in the ->client direction (I've not checked the other way). Well, that's about it. You should be able to go a long way with all that. I can try answering specific questions if you get stuck. Regards, Pete

Why dream? You can do that easily already in FS Options-Controls-Assignments. You don't even need FSUIPC for such straight-forward assignments. Not at present, because the Gear is only controlled by switches not axes. But it will be possible in a forthcoming version of FSUIPC. I am implementing axis assignment in FSUIPC, with the possibility of sending controls from axes too, and all optionally aircraft-specific so that you can have different joystick assignments for different aircraft, as you can now with the button and key facilities. Regards, Pete

FSUIPC only has that message on initial loading -- it in't available to it and nor is the check re-run once the initialisation of FS in completed. It is done in the DLL loading routine (DLLmain) which is called by Windows when a DLL is first loaded. Therefore, if it is happening apparently DURING an FS session, FS must have thought it crashed and it is trying to reload. There's an option check mark in the error message it displays which can be turned off to prevent automatic restarts, but it sounds like something is obscuring the whole operation on your screen, or there's some problem with the video drivers. Try running in maximised Windowed mode instead of full screen mode (ALT+ENTER) until it occurs -- maybe you can see better what is going on. The only other possibility I just thought of is that whatever is going wrong is cauing incorrect code to be executed and somehow the remnants of the DLLmain part is being jumped into by whatever is going berserk, but i think this is so unlikely as to be discountable. No, never. Where did you get that impression? Ah .... so maybe if you could get a copy of 4.6 you could at least eliminate 4.7 or nail it that way? Regards Pete

The COM port number will change, so you'd need to tell PFC.DLL that -- editing it in the PFC.INI file is easiest. Nothing else will change. Regards, Pete

It works here but you normally need to use "Lock" not "Dock" -- the Docking facility is used to associate it with a panel part. If there's no part of FS on the second monitor, you might want to try using the ShowText utility, supplied in the AdvDisp package, instead. Just use the Hide Always option in AdvDisplay and set up ShowText as you wih. It has rather more display options than Advdisplay in any case. You could also make it run and close automatically using the FSUIPC facilities to run programs. Regards, Pete

I don't know if this will work, but try using the FSUIPC "offset" facilities to manipulate engine selection, instead of the keypresses E+1234. The engine selection set by E+1234 is a single Byte at offset 0888. In this byte, one bit each is used per engine. Engine 1 is bit 0 (value 1), Engine 2 is bit 1 (value 2), Engine 3 is bit 2 (value 4) and Engine 4 is bit 3 (value 8). So, for example, E+12 sets offset 0888 to "3". If you have two buttons you can use, the program one to select Engine 1 and the other to select Engine 2, but only on "Release". On "press" set NO engines. Do all this using the FSUIPC control "Offset Byte Set". The Offset parameter is x888 and the data parameter is x0 for no engines x1 for Engine 1 x2 for Engine 2 Then, press and keep pressing the selection button whilst reducing the mixture lever to zero, then release the button. That SHOULD prevent the non-zero value being written to the new engine mixture. I cannot test this here at present, so please let me know if it works. Regards, Pete

I'm a bit at a loss to understand what this may have to do with a problem of FSUIPC reporting multiple copies upon trying to load FS, unless you are saying that FS9 appears to "go down" whereas it is fact only disappears from the desk top yet remains in the Windows task list as a running process? I'm not sure why you ask here, but considering that FSNav is one of the top-selling add-ins for FS, so must be in use on many thousands of systems by now, surely the problem is known to the author? Have you reported it? Have you checked that support forum? Regards Pete