Pete Dowson

There's no such variable nor offset in my software. There is an assignable control provided which simply toggles or sets some bits in PM's offset space. The rest is then up to PM. Please refer to the PM offsets documentation on the PM website. You can verify the correct bits or values are changing via the MCDU offset monitor, or FSUIPC's own monitor (set in the Logging options). Please report PM problems to PM support -- I really cannot deal with other folks' software here. An that's especially true for the AB offsets which I've never even used -- I don't have any of the AB software. Regards, Pete

Hi Chris. The logs you attached were of no use. Well, the 6.47 one was okay, but the 6.70 one is not comparable because you only had "Log=Yes" for that. Here's what i said: "Perhaps I could compare the Logs -- but use Log=DebugAll, not "Yes" as you did before -- that only shows the exchanges between client applications and WideClient, which were fine. Do exactly the same test with 6.47 and then with 6.70, Zipping up each log separately and labelling them appropriately." I was going to spend some time on this today, but I need something to start with, please. Don't attach them here, send to petedowson@btconnect.com. Regards Pete

Why would that be of interest? Using WideFS is not at all dependent upon having an FSUIPC key. If the time was being spent in my code, in Wideclient, then it would be a doddle for me to find. It would even be reasonably easy to find if it were reproducible on any of my 10 PCs. But is isn't either of these things and in fact is a very very rare occurrence. The only place in the processing it can be sepnding any time is in Windows -- probably in the Network drivers themselves. Something is locking up at such a low level that the normal Windows message processing is very slow. Again, also unfortunately, there's been very little change in the way WideFs uses the Network software in Windows -- the main differences being the addition of UDP and the broadcasting by wideServer so that clients can find servers automatically. Are you using WinXP on both machines? If so could you please just try without an INI file at either end? Just let everything default. I'll look at the Logs later, but probably tomorrow now. Regards, Pete

Hmmthere's a couple of years of development between the two, so that's really not a lot of help in itself. Perhaps I could compare the Logs -- but use Log=DebugAll, not "Yes" as you did before -- that only shows the exchanges between client applications and WideClient, which were fine. Do exactly the same test with 6.47 and then with 6.70, Zipping up each log separately and labelling them appropriately. Maybe if I can find some intervening release versions we can zero in a bit more -- I can see 6.65 (June 2006), but for anything earlier I'd have to delve into archives. Version 6.50 was the last major change before that, and that was August 2005! If you ignore this 100% business (it may or may not be relevant, i don't know), does it work? just saying "100%" isn't helpful. Here 6.70 is working flawlessly on many systems, using a mix of TCP, UDP and IPX. It's easily the fastest version, very smooth for gauges like those in Project Magenta. But evidently there's something it does to achieve this which isn't compatible with, what a handful maybe of systems. Why, I've really no idea at present. Regards, Pete

There you have it then. It couldn't be much clearer, could it? It is telling you what is wrong. EFIS98 was designed for FS98, and it did even work in FS2000, but it looks like the author has deliberately stopped it in FS2002 by checking the FS version. Version 3.10?!!! The current version is 3.70. I cannot support 3.10 in any case. Please update if you want more help. In any case there is nothing wrong with either the connection to FSUIPC or FSUIPC. Here: You need a change in EFIS98 to bring it up to date for FS2002 (which is itself already 5 years old -- EFIS98 is about 8 years old now). The author never developed it further. He did work on a much more sophisticated system based on B777 autopilot and FMS operations, but that never got issued. I think you may need to seek alternatives, or go back to FS2000. Regards Pete

No it isn't. In jorge's case the connection is working perfectly, but something on the client Pc is preventing correct multi-tasking so that ASV6 isn't getting past the initialisation. All of Jorge's WideFS logs show the wideFS side working perfectly. In your case this is not occurring. You have a non-working connection. completely the opposite. It looks like it isn't working because it is continually restarting! WHY have you changed the AutoRestart value from its default? Maybe i should delete that parameter as, especially when you first connect, there's so much being done 9programs loading, initial data exchanging, etc) that it is quite possible for the frame rate to be less than 5 for 5 seconds. But why have you changed it? In all cases if you have a problem, try reverting parameters to defaults. All the stuff has been "tuned" over many years and should really be left alone except under instruction for special cases. It doesn't want to use IPX. you are reasding it wrong. The server always sets up services for TCP. SPX and UDP. It will retry all three each time it initialises. Pete

Jorge, I received the "DebugAll" log, and this shows ASV6 connecting, but then simply looping on the initial operations -- the part in the FSUIPC_Open call it makes when it is establishing the connection. It is reading the validity check (okay0, and the version numbers of FSUIPC and of FS okay. But it simply loops on this, retrying every 2-3 seconds. I really don't know what it is doing -- I assume it is timing out, which means it is not getting the response back in sufficient time. The actual time spent in Wideclient in that period (3 seconds), to actually process the request, is only 1-10 mSecs in most cases. Something is stopping ASV6 getting the process sufficiently, so it isn't processing the messages. This, combined with your 100% utilisation observation seems to indicate a PC system which is simply not coping. Whether this is due to other processes or just a slow processor i am afraid I don't know. Did you tell me what system you use (processor, memory, windows version and so on)? What is your typical FS frame rate? Do you have the FS frame rate limiter set? The WideFS link is flawless and the exchanges are perfect. The problem lies in the client PC somewhere -- something is preventing correct multi-tasking. Regards, Pete

This shows a healthy connection to FS, and the fact that there have been 2 transmissions back to the FS PC every second ON AVERAGE (max of 17), means that ASV6 or something is actively sending and receiving data. It looks like you did not have Log=Yes for this test, so apart from the good performance nothing else is useful in this log. Please enable the data logging. If you don't mind making a huge file, use "Log=Debugall" -- but for me to look at that you'll need to ZIP it up and send it to petedowson@btconnect.com. How do you know they aren't relevant? Did you try killing them? I couldn't possibly hazard any guess without such a trial-and-error process! something in your system is evidently interfering with WideFS, you need to find out what. Pete

ErI didn't ask that question. I asked if you used FSexpand (which is nothing to do with WideFS). It may also be relevant to know what else you have running on that PC -- not to do with FS, just other programs, background services, etc, running. Maybe there's some antivirus or firewall checker which is clobbering it. These sorts of problems are so rare, and so far each of the few there have been are different. In the end it all comes down to a process of elimination. In the end it may be necessary to go into the windows process list and kill each background process in turn until either the problem goes away or the system crashes. In the latter case, note that one, re-boot, and continue but leave that one running! This has found some culprits before. I think one was a Kensington mouse driver. Why I've no idea, but apparently it wasn't doing anything useful so it was easily dispensed with. Sorry, but it's no use, as you can probably see. ASV6 never ran. In the previous log at least WideClient sees ASV6 connect: "38636 New Client Application: "ASv6" (Id=3252)". That didn't happen this time. If ASV6 never connects then there's nothing to log. It needs sorting at the ASV6 side. I need to know why ASV6 doesn't see the FS window class Wideclient presents. How did you make it connect the previous time? Or is it that after setting "Log=Yes" you forgot to run ASV6? BTW why are you specifying a ServerIPAddr? Surely the ServerName would be better? Or leave both off altogether if you are running winXP both ends. Pete

There is certainly something wrong with one of your keys. Please Zip up and send me the FSUIPC.KEY file from the FS Modules folder and I will check them both for you. Please also attach the receipts from SimMarket. Send to petedowson@btconnect.com. Please remember to Zip the KEY file as it won't get through otherwise. Regards, Pete

Hi Thomas, I confirmed the problem and fixed it in version 3.709, now available above, in the Interim Versions announcement. Thanks! Regards, Pete

Okay. So now we must find out why it thinks it is "disconnected". It is a shame it is not more informative. In the WideClient.INI file (which I assume you have not edited?) change the Log= line to read just "Log=Yes". This should show us what it is reading, if anything, which makes it think it is disconnected. However, this part of your original report worries me: The last report of this type was from someone using FSexpand as well -- it appeared that FSexpand somehow stops Wideclient running correctly. Perhaps you'd like to peruse that thread too? http://forums.simflight.com/viewtopic.php?t=55723 That got to analysing huge logs, which showed that whilst Wideclient's Network threads were quite happily exchanging messages, and, in fact, the client application was too, there was no time left over for any windows message processing, which made Wideclient looked hung, and the client program inoperative. I currently don't know of anything else like that. But maybe checking the other things you have running may show a conflict somewhere? You say you've changed nothing, but obviously something has changed. Regards Pete

Eryou ran it for 30 seconds? When did you start ActiveSky? I think that alone takes more time than that to start, doesn't it? What did ActiveSky say? Where's the WideServer Log? What version of FSUIPC? Pete

What programs are you running on WideClient? what version of wideclient, WideServer, FSUIPC? Any Log files at all? What protocol are you using? And what did you change 'a few days ago'? Pete

What does the Wideclient Log say? When the programs "don't connect" what do they say? Maybe the WideServer Log would show something of interest too? What versions of wideServer, WideClient, FSUIPC? Pete

Did you buy the WideFS key with your new Email address and not ask SimMarket to match it to your FSUIPC key? If so then one or the other Keys will have to be changed. SimMarket could do that for you, or otherwise you will need to send me the receipts (notifications) for both of them (to petedowson@btconnect.com) and tell me which address you want to use. Regards, Pete

I don't knowI will check it here. But it will be tomorrow, now. Sorry. Regards Pete

If you have a file image, then you have a file called FSUIPC.KEY in your FS modules folder. That is a Text file with your registration details -- just cut and paste from there into the FSUIPC registration dialogue. If you don't have that file you'll have to follow the recommendations in the announcement/sticky above, as i said. Regards, Pete

No, no way I know. Even using a count is no use as you have no control over the timing of each increment, other than maybe the button scan interval. But to increment a count needs some button action, something held pressed. In the cockpits I deal with such needs are accommodated by programs like pmSystems, where you can program this stuff easily. If you can't find a way and still want this in FSX, let me know in a few months time when I should be ready to start adding new facilities again. At present, I am just too busy trying to implement the ones I already need to! Regards, Pete

Are you trying to say that you lost your registration key? You didn't make a copy of the FSUIPC.KEY file or keep a backup as advised? You just deleted everything? I don't keep any such information. in fact I don't have anything to do with the Registrations. Please review the announcements above. One of them tells you what to do. As for FSUIPC itself, it is where it always has been for the last seven or more years, http://www.schiratti.com/dowson. Regards Pete

Thanks. I'll check it here. I'm gradually working through the offsets but it's a long job. I was hoping for lots of feedback, but there's been very little -- that's either a good thing (most are okay) or bad (no one's looking!). Regards, Pete

WideFS does not split the FS program into little programs you can run elsewhere. WideFS is simply a Network extension of the FSUIPC interface. Anything which interfaces to FS via FSUIPC on the FS PC should run quite happily on a Networked PC running WideClient. Not sure. There are lots of external instruments provided by external software, as I listed for you. Anything that runs OUTSIDE of FS, providing it interfaces TO FS via FSUIPC, should run okay on a WideFS client PC. That's the whole idea -- there are lots of such programs. as well as instrumentation via Project Magenta, vasFMC and so on there are Weather programs like ActiveSky, ATC programs like Radar contact, tracking programs like FlightKeeper, and so on. If you are only running FS on your "main com" all you can do is turn down some of the sliders. Regards Pete

WidevieW only runs in FS. WideServer will run in the same PC with WidevieW, but of course Wideclient is designed only to be run on a PC which isn't running FS, so, no WidevieW either. You cannot run FS's own panels without FS. They are not complete or separate programs, only modules which drive FS graphics. If you want gauges and subsystems running on other PCs you need to look at programs like Project Magenta, FreeFDS, vasFMC (all FSUIPC/WideFS compatible), or maybe FSexpand which I think has its own networking system. Even then, really your throttle control needs to be on the FS PC, where your throttle is. Regards, Pete

No worries about crying out about problems. It could have been a real problem, after all. Thanks for confirming all is well with 3.708, and please don't worry about reporting things in future. I don't give out black marks! ;-) Oh, please make sure you left Lefteris know too, it was he looking to reproduce it. Regards, Pete

Not really looked. In the gauges which display these things they would normally be derived from an assortment of conditions, which of course should be shown on the six-packs and overhead. All the more advanced panels do their own logic here, just as I do for PFC.DLL and pmSystems does for Project Magenta cockpits. [Later] No, I don't see anything relevant in the lists of accessible variables for SimConnect. Best thing to check, when you get FSX, is the XML source for the gauges, assuming any of the default panels actually operate the annunciators. You should be able to see the logic used and variables accessed. To be honest I don't use FS panels (or any panels at all really) so I don't know if there are any default ones which do all this. Regards, Pete