Pete Dowson

Well, I'm really glad you solved it, but I'm afraid i still don't understand. To me the above two parts of your explanation are contradictory. I just can't imagine where the modules folder comes into it at all. But it doesn't matter, now you have it working. I only hope i don't meet else anyone using the same protection system as yours! ;-0 Regards Pete

There are no folder sharing permissions needed for WidefS (other than to be able to write its own logs, which it obviously can do), so I really don't understand what you are talking about. Folder permissions only really come into play in FSX on Vista and Windows 7 installations, if FSX has been installed into its default of Program Files. This is because "Program Files" is protected as a whole -- but (a) this only affects Vista-aware programs, as Vista makes provision via Aliasses for older programs, and (b) the FSUIPC4 installer makes the Modules folder read/write accessible to all. There's nothing at all that I am aware of that involves any folder permissions for WideFS. All of its exchanges are on Ethernet, there is nothing at all via folders! If you are able and have time, could you explain, please, what it is you think you have found out? Regards Pete

4.32? Phew, that's very old and long unsupported. You'll need to download the 4.52 package and run the installer. If you then want to use the update available in the Updates announcement above, you can download that and simply copy the DLL over to the FSX Modules folder. Regards Pete

That's the prime suspect them. It is probably blocking access to the server by WideClient. Since the whole set of 3 possibilities was concerned with how the Log file had yesterday's date and time on it, it is obvious surely that it was the log file I was referring to? What else? :-( Only one named WideClient.log and WideServer.log -- those are the current or most recent. The previous one is saved with a numerical character included in its filename. This is done so that folks with a problem or a need to close the Client to change a parameter can do so, and get it back up straight-away, without losing any information from the previous effort. Yes, see above. The Server is never seeing hide nor hair of any Client attempts, I'm afraid. The Client is definitely being blocked at the Client end, or at the Server end, or both. Regards Pete

Ah, sorry. The documentation needs updating. My own Certificate, the one my name, expires this month. I tried to get it renewed earlier this year, but it seems now that none of the accredited agencies will issue certificates, even renewals, to individuals, only to Registered Companies. I am not going to all that trouble just for a certificate, so my publishers, simFlight (the owners of these Forums and of SimMarket) kindly stepped in and purchased the certificate for me. So it is now in simFlight's name. It is good. I shall update the documentation in the next release. Thank you for pointing it out (I did update it in the FSUIPC4 user guide!). Regards Pete

In that case one of the following MUST apply: * Your Server has the wrong date/time set, OR * You've not got WideServer installed, so it isn't running, OR * You've got hold of the wrong file! There are no other possibilities! No. But is the IP address returned by Windows correct? On the test you did yesterday (or at least the date and time shown), WideServer never saw anything: Since you either didn't run WideServer today, or got the wrong log file, i couldn't comment on this mornig's test. What I don't understand, and you still haven't gotten around to explaining, is that, as "a long time user of FSUIPC and Wide Client", where you said you never had a problem, how is it that you now suddenly have no connection whatsoever between the Server and Client? What have you changed? That might be a clue, don't you think? Regards Pete

Could be, but it's only by one hour. I've never had anyone report the problem before where it was only a time zone difference -- it's always been something like a reset PC with the wrong date (year) entirely. If the time zone element was significant you'd think I'd have had a lot of problems with American buyers, up to 8 hours behind, but no, not one that I can recall. Anyway, glad you are sorted. Change your date back now! ;-) Regards Pete

The most likely reason is that your system date, the one on your PC, is actually earlier than the date of the registration, making the latter look invalid. Set the computer's date to one at least the same as, or later than the registration date (i.e the date on the Key receipt). The log is useless, as it it incomplete. You need to close down FS first so the complete data is available. I am adding the PC date to the "system time" log entry in the next update. The problem will then become more obvious by inspection. Regards Pete

Whilst I am not sure at all why you've posted this question here (WidevieW us by Luciano Napolitano who has his own website, and probably a Support Forum), I know for certain that you can use the Matrox Triplehead to Go add-on adapters with WidevieW. I know this because a well known 747 Captain (Captain Mel Ott, now sadly passed away before his time) had three PCs, all with TripleHead adapters, each PC linked by WidevieW, for a splendid 9-screen surround view stretching nearly the full 180 degrees around his seating position. He used Project Magenta instrumentation on other, lesser, PCs, with their own screens positioned appropriately. However, I have never seen or heard of a single video card with provides triple outputs other than the sadly now defunct Matrox Parhelia. The TripleHeadToGo adapters seem to have taken over, but at least they can be used with many of the latest and greatest video cards, especially those from nVidia. Regards Pete

Assuming you tried to run WideClient on the client PC during this WideServer session, the WideServer log shows nothing ever got through. this suggests your network is simply not set up to allow such communication. Perhaps you have an active firewall preventing it? No. "Run1" would run it as soon as WideClient started. When I say "RunReady" I actually do mean "RunReady". Please refer to the WideFS documentation which clearly shows these methods load starting (and stopping) application programs! Regards Pete

Okay. Thanks for letting me know! Pete

Apparently FSCommander shouldn't be started until WideFS connects. Best to start it from Wideclient.INI using the "RunReady" facilities. The problem is you aren't getting a connection. Have you EVER had a connection? I understood from your last message that you were a "long-time user". All this time and no connection? Your WideClient log only shows something wrong on the Server -- assuming, that is, you've not messed around with any timing parameters in the WideClient.INI file. You forget to show the Server log, so I can't say any more. Tell me, please, HAVE you actually used WideFS before? If so, if it connected, what have you changed? Regards Pete

If Wideclient is "waiting for a connection", there's no point in trying to "connect" any other application, unless it is a tolerant type which sits and waits for FSUIPC to be accessible, retying now and then. The title bar message "wait for a connection" does NOT mean "waiting for an application", but waiting for a connection to WideServer, in the FS PC. Hmm. I wonder what the point of the message number is, then? Is that meaningless? Surely the author knows what the message means in terms of what it is finding wrong? Anyway, if FS isn't yet running, or it is but FSUIPC + WideServer are not yet servicing Clients (and they won't be until you are "ready to fly"), then no client program will connect. Maybe that's all the message means? All the information about what WideFS is doing is put into the Log files -- WideClient.log on the client, WideServer.log on the Server. You say you're a "long time user of FSUIPC and Wide Client", so surely you recognise by now whether WideFS is connecting? (It will actually say "connected", to help! ;-) ). If you cannot get WideFS connected, please check those log files. Show me, if you like. Also think what you have changed since you had it working ("for a long time"?). Incidentally, a monor matter, but I assume you mean FSUIPC 3.916, not 3.169? Regards Pete

What, exactly, are you running on that PC which you think is FSUIPC? FSUIPC is a DLL, a module, which only runs inside FS. If you have no FS installed on that PC there is nowhere for you to put it! For FSX you must mean FSUIPC4. The FSUIPC4 Installer can be run on a non-FS PC, but it will complain about the missing FS and tell you so. If you want to run FSUIPC applications on a separate PC from FS, you first need to Network the computers, so that they can talk to each other, then you need to purchase WideFS, register it in FSUIPC4, and run WideClient on the non-FS PCs. Please do read about WideFS. You can download the ZIP and read the documentation before purchase. [LATER] I just had a quick look at the FSXpand website, and the first thing I see is this: FsXPand 4.2 creates your own cockpit for you, by connecting 1 or more PC's to one FS PC over a network (my emphasis) which implies that it does its own networking. So presumably you don't need WideFS, only FSUIPC installed in FS. It looks to me as if you need to read the documentation for that package a little more carefully, or ask their support for assistance? Regards Pete

Yes. You'll either need two serial ports and a null modem cable, so that you can feed out of one and back in on the other, or a virtual serial port program such as the free ones from MixW or Eterlogic. Those program can create a pair of serial ports linked together, all in software, fooling Windows into thinking they are real ports. Please first check that FliteStar can be used as a moving map, that it will accept NMEA input from a GPS. When I bought my copy it was called "FliteMap" -- more expensive than the package called FliteStar which certainly did not have any moving map facilities in those days. This was over 10 years ago so things might have changed -- but do check first! Regards Pete

No. I do not produce any "drivers" for any Saitek equipment! Surely the device came with appropriate drivers by Saitek? You'll need to ask them. I'm sure they have support arrangements. If you mean FSUIPC, you will find very full instructions for assigning any Windows-recognised buttons and switches to FS functions in the User Guide which is included in the ZIP. But to access these you do need to purchase a Key to unlock the user facilities. Again, full details are provided in the User Guide. Regards Pete

Thanks for the information. I suppose I've never installed any scenery that used it. Odd, because in FS2004 days I think I installed just about everything! That might only turn off some of its actions. It may not stop the problem. The DLL will still be loaded, so it depends what it is doing which somehow interferes with things. Regards Pete

Unlikely. Each new version of FSUIPC fixes bugs and adds new facilities. And you get no support with older versions. If you have a problem then it needs clearing up, not sweeping under the carpet! Have you even bothered to try the interim update (3.916) in the Updates announcement? You never know, maybe whatever the problem is it has already been reported and fixed? Although as far as I am aware the only thing FSUIPC is used for by that aircraft is the TCAS, which hasn't been changed for years. Regards Pete

The problem is with the add-on, which was designed and sold BEFORE version 9.1 of FS2004 was available, and therefore came with a version of FSUIPC which hasn't ever heard of 9.1. That is what this means if you read it properly: In other words, that version of FSUIPC doesn't know FS2004 version 9.1 and only works with 9.0. No magic wand needed. All you ever needed to do was read some of the Announcements here, and particularly the one which tells you which versions of my software are supported. You are using one which is about 6 years old and which hasn't been supported for most of that time. Please just go to http://www.schiratti.com/dowson and get the current version of FSUIPC3. Regards Pete

I very much doubt it, as I think they didn't change to the digital control system I support till later. Additionally the stuff for Jeppesen may have had a specific protocol for Jeppesen, just as their stuff for Elite did. However, to be sure you really need to direct your inquiry to PFC themselves. www.flypfc.com. Regards Pete

Sorry, I'm not with this. "L" operates Lights doesn't it? At least it does in my FS9 -- all of them, in fact! Can you explain what you mean when you say "using "L" on my keyboard, I can open in FS9 the map and using "Enter" I come back to the cockpit.". Which map is this and how come it operates with "L"? Pete

Really? How strange! I never thought there was any way to tell whether FS was in window or full screen modes. FSUIPC is only detecting flight loading by receiving the "FlightLoaded" event from SimConnect. If SimConnect is sending one of these events when the screen mode changes there must be a bug in SimConnect -- though I find it amazing that anything in Simconnect is anywhere near awarre of such video-side changes. I'll just go and try this now ... ... No, sorry. It certainly doesn't happen here. The count stayed resolutely at 1 even after changing to full screen and back to Windowed. It only increased when I loaded a flight. This is with SP2/Acceleration SimConnect and FSUIPC4 version 4.523 (as in the "Updates" announcement above). Check the logs. Whenever 3F02 is updated, simultaneously the FLT details are logged, like this: 332828 \\LEFT\FSPLANS\Baron at EGCC.FLT 334110 Aircraft="Beech Baron 58 Paint1" The FLT pathname is provided in the data accompanying the "FlightLoaded" system event. Regards Pete

The logs show none of that. These must be the wrong files -- though there are only ever two logs -- "WideClient.log" is the current one, and the other is the one before. The complete time shown in the first is only 50 minutes, and that includes a 12 minute gap whilst the Server (WideServer) was closed, having specifically signalled a shutdown to the Client. 25 seconds after is reconnected it was closed again. The actual end of the log, showing WideClient closing, wasn't included, so I don't know how much longer you continued this cycle -- if your client's system clock is correct the log goes up to 22:26 on the 29th. The older, saved log, is for a short session immediately before that one, from 21:27, only lasting 91 seconds. It never connected due to this error: meaning the Client PC had no idea how to find the IP address of "valued-735da7ac". You must have done something to correct that before re-running WideClient at 21:35. The fact that you have to re-boot the PC does really indicate something serious wrong with the Networking set up on that computer. I'd check it out more thoroughly if i were you. Maybe a re-install is called for. Incidentally, coincidence, I've just read a message on the FSX Forum at AVSIM from a happy iMac user with WideFS running really well on it with lots of apps. "Right now, I'm typing this in Firefox on the Mac. Thunderbird is also open. XP is running with ASA, WideFS, FS Commander, FS Flightkeeper and Dreamweaver MX all open. On the FS PC I'm currently in the CS757 with FS Passengers, flying across China". See http://forums1.avsim.net/index.php?showtopic=255641 , scroll down to the message from Dean_EGTC! So it isn't the Mac per se. Something's wrong. Sorry I can't tell anything from these logs as they don't seem to tie in. Whether full matching logs would help much I can't say -- but please, only the current logs -- ones actually called WideServer.log and WideClient.log, and only after both FS and the Client programs are closed down. Else we don't get the full picture. If files are really too big -- and they certainly shouldn't be unless there's a lot going wrong (!) - ZIP them and send them as attachments to me at petedowson@btconnect.com. If you post them here use the "Code" button to envelope them, else they make the message too long and incoherent. Regards Pete

For FSX there are separate offsets for Airlines, GA and Ships and Ferries -- see offsets 0250 to 0252 in the FSUIPC4 Offsets status document. Otherwise, for both FS9 and FSX just use the facility at offsets 3110-3117 (inclusive) to send FSUIPC a control to obey. Such controls can include any FS control and any added FSUIPC control (except those dealing with Offsets, of course, where there's no need). Regards Pete

If you mean there's one with a numerical suffix as well as a simply named one, then, no, it is't a problem. The numbered one is the previous one. The logging system is designed to allow folks to restart after a problem and THEN still retrieve the details of the problem which caused them to restart. I think there's no problem attaching if you ZIP them, but embodying complete text files in a message is okay provided you bracket them using the "Code" button. that provides them with both a scroll bar for browsing and a "select all" facility so they can be grabbed and saved. The first log shows no disconnection until you closed FS, or at least transmitted the close down signal, after 2307 seconds (38 minutes): It then continually tried to reconnect, to a server which appears to have been closed (as the "closing down" indication confirmed, in fact): until , 701 seconds (nearly 12 minutes!) later, it reconnects: Only to be told, just 25 seconds later, that the server is shutting down again: Your WideServer log, the one corresponding time-wise with the WideClient log I've just analysed, shows you only ran it for 428 secons (7 minutes)! Sorry, all these logs show is WideClient being told that the server is closing, and the Server log confirming it. You need to keep FS running if you want WideClient to stay connected to it. Regards Pete