Pete Dowson

The logs will be different then -- the timeout of 10 seconds set by the RestartTime parameter is the only one which could eplain the 10-12 second cycle shown in the original logs you sent. Either you've entered the parameter wrong -- e.g. added it to the end of the file instead of putting it in the [Config] section -- or adding it has changed what is happening and you have another problem which is not shown in the original logs. Therefore, please double check, then send me both Logs and both INI files. Regards, Pete

This may well be because there is no such parameter in Wideclient.ini! It will be ignored completely. Only the Server has the power to restart all clients. Please read my messages a little more slowly! :wink: I said: I have a revised version of WideFS ready to release, with this fixed and a few other small improvements, but I really do need you to try this interim fix first, please. :? Regards, Pete

Whatever control you have got assigned to "Shift+[" can be sent to FS via the FSUIPC interface using the facility to send any control to FS via offsets 3110-3117. All you need to do is identify the control and thus its number. In my FS9.CFG this line defines it: PANEL_TOGGLE=219,9 As you can decode from the list in the FSUIPC Advanced User's guide, 219 is the key code for the '[' key, and '9' indicates Shift. In the FS2004 Controls document (from http://www.schiratti.com/dowson) you will find that the numerical value of "PANEL_TOGGLE" is shown, thus: PANEL_TOGGLE 65748 so all you need to do is write decimal 65748 to the 32-bit offset 3110, and your Uncle is called Robert! Try it with FSInterrogate. Note that you can't be sure this turns it off rather than on -- it is a toggle. However, There are these controls listed: PANEL_ID_CLOSE 66508 PANEL_ID_OPEN 66507 I have no idea whether these work, but they might be worth a try. I assume the ID is the number assigned to the panel part in the Panel.CFG file. You probably need to provide that as parameter. There are also the set of 9 PANEL_X controls, but those are toggles too (they are the ones normally assigned to Shift+19). Regards, Pete

No problem, glad you sorted it out. Regards, Pete

Er is this addressed to me?I am not aligned to, or a member of, any group, although I have from time to time been in the Beta testing group of some things -- never any aircraft though. Sorry. (I don't even use any FS panels whatsoever). It may well be, then, that PSS panels are only mouse driven. If they've made no provision for either keystrokes nor joystick buttons then I'm afraid there's nothing FSUIPC can do for it. Maybe. It depends how Key2Mouse gets its keypresses -- buttons programmed in FSUIPC can send keypresses to FS. This is done with a Windows facility called "SendInput". Whether that is susceptible to being intercepted by the likes of Key2Mouse I'm afraid I don't know. Instead of using FSUIPC you may need to find a utility which can program buttons for keypresses in the general sense, not specific to FS. Regards, Pete

"z" operates the FS autopilot. Some add-on aircraft have their own more sophisticated autopilots. Aircraft like the PMDG series have facilities to allocate keystrokes to these functions. Sorry, I don't remember what aircraft you are using, but maybe this is the problem. Certainly, simply progamming a button to press 'z' should work easily with default aircraft. Regards, Pete

Odd for him to say that -- if WideFS was having problems it would affect everything, not just selectively VNAV and LNAV operation. It has no idea what data is being transferred. When using PM there will be data flying about all over -- why does he think it would be selective? That is a bit of a problem isn't itbacktracking is a useful way of working things out. ZIP them together and use the "email" button at the bottom of my messages. Regards, Pete

Until it connects to the Server it isn't doing anything, so it isn't exactly "ok", just idle. There really are no parameters which you should change for any of that. When you say "blocks", is this WideClient only with no applications running? If so, all it will be doing is sending one short message every 2 seconds or so to maintain contact with FS. If you only get problems when loading an application program, then it will be related to something that is doing. Please do NOT mess about with parameters in WideClient or WideServer INI files unless advised. They have been carefully optimised for best results on most systems. The "RestartTime I mention above is an interim fix for the constant restarts which afflict one or two folks. If your application is trying to send/receive data constantly and causing the machine to appear locked, then you can set a larger TimeOut parameter, as this holds off the application (slows it down) on each request, but in general it isn't recommended, and I don't know of any programs for which it is needed. If you are running PM's PFD.EXE then try the UseTimer facility in its INI. Otherwise the major suspect is probably going to be the OpenGL drivers. Hmm, with which WideServer? Not enough information I'm afraid. I always need to see both client and server logs and INI files. I could also do with knowing what applications you are attempting to run. Regards, Pete Torsten

Hi Jan, I think I may have found a possible cause of the problems you've been having. Could you please try adding this line to your WideServer.INI (in the [Config] section): RestartTime=0 If this helps, can you then try RestartTime=30 I think it is the new default I set for this -- 10 seconds. This is shorter than the 20 seconds fixed timeout I use to declare a client dead, and I think under certain timing circumstances the two kinda get synchronized and WideServer kills the Clients wrongly. If this is what is happening, both the above two settings should fix it. Let me know, please, and I will then be able to fix the code. Regards, Pete

I don't think so -- it looks like the Elite DLL is expecting to be able to get onto FSUIPC first thing on loading, and if it can't it immediately gives up. It may be that by shuffling things or a faster disketc you can get around it, but it's only going to get worse, not better. If you are including the FSUIPC.INI here, then I think that is all that matters, and its removal is just speeding up FSUIPC's initialisation so it is more likely to be ready in time for the Elite DLL's one shot. Regards, Pete

I've only just noticed this one, which was slipped in whilst I was replying to any earlier one: That was a problem which existed for one release (3.128) when I tried to protect FS from crashing by preventing access to FSUIPC by programs and modules until FS is actually "ready to fly", so that I know I can access stuff which is actually loaded and ready. If you review the thread you reference you will see that I changed the way I did it in 3.129, and this then fixed things to work as they did in 3.125. I have not changed it back again since then, I assure you. FSUIPC does have to read and write its INI file and open the log before it starts to offer its services. Maybe the growing number of parameters it has to deal with takes this towards a time that is critical for modules which don't appear to allow any leeway or perform any retries. Maybe it is so close, timing-wise, that simply defragmenting your disk or putting files in a different order is enough to clinch it. I don't know. But this is not any area in which I can really make any adjustments, I'm afraid. I have to deal with all the initialisation before I can start interacting with other programs, and as extra features are added to FSUIPC this will naturally take longer. We are only talking milliseconds, at most, here. I really think the answer has to be in the hands of the DLL programmers. Rather than expecting immediate access on their "module_init" entries from FS, they should use a SetTimer-TimerProc instigated routine to retry access, perhaps 10 times over a 5 second period. That should be safe enough even for those who have reset the FSUIPC InitDelay parameter to its erstwhile default of 3000 (3 seconds). Regards, Pete

Sorry, what do you mean "proper"? What was the last log, then? Anyway, if the last one was NOT from a failed Elite initialisation, you might think that pretty well nullifies all I said about it, wouldn't you? But no! Looking at this one I think I can stand by what I said back there. Going through it, although it seems to show something reasonable: 42234 READ0 3304, 4 bytes: 00 00 20 32 42234 READ0 3308, 4 bytes: 07 00 DE FA 42234 WRITE0 (failed, read-only!) 330A, 2 bytes: 00 00 That is a standard FSUIPC Open sequence. The version number of FSUIPC is read (3220 0000 for 3.22), as also is the version of FS (7=FS2004 in FSUIPC). The "FADE" part indicates that the Advanced Weather Interface is initialised. The write to 330A should normally show the version number of the FSUIPC SDK library, but it is of no consequence as I never updated it. It should fail "read-only" because this forces it to be logged as I intended at the time. 42234 WRITE0 8001, 28 bytes: 43 4A 4D 34 4B 42 4E 4E 31 52 4C 51 50 4D 44 47 42234 4F 70 74 69 6F 6E 73 2E 44 4C 4C 00 BUT: this is the Access Key being written by PMDGOptions.DLL! In other words the only access to FSUIPC being made here is that by PMDGOptions.DLL (part of the PMDG aircraft install I believe, and responsible for the PMDG menu additions). There is still no access being made by Elite's DLL! Over to Elite I think. Regards, Pete

Please review my last answer above --- when the error occurs the Elite DLL hasn't even accessed FSUIPC for any offsets. So what is it checking, and when? The fact that it sometimes does work implies a timing problem -- maybe, for instance, if FSUIPC is loaded early in the chain of module loads and the Elite DLL is loaded late it would work. But why? What is it that the DLL is doing which makes it so precarious? Regards, Pete

I suspect then that the Elite module is attempting to get a response from FSUIPC before it is even ready. The Log shows no attempts whatsoever at reading or writing to any offsets, and explains why FSUIPC doesn't even see the module. The link doesn't seem to work, but it's of no consequence, because this problem is not one from FSUIPC. It looks like the Elite DLL implements some basic check for FSUIPC and then gives up. I don't know any other module which works like that without even reading some offsets. Maybe it is checking the Version Info of the module file itself, in which case it could simply be an error in the numeric version checking it performs. If it is an initialisation timing problem, then what surprises me is that it ever worked in FS2002, because there the InitDelay parameter defaulted to 3000 (for 3 seconds), so FSUIPC never 'opened its doors' for three seconds then. Now the responding Window hook is established very early on (this is the "InitDelay: 0 seconds" logged). Maybe you can try inserting an "InitDelay=3000" parameter into the FSUIPC INI file (in the General section), but if it works I'll be surprised. Since the Elite DLL isn't even accessing FSUIPC there's no more I can do for you. Sorry. The fact that it 'sometimes' works for you does indicate some sort of timing problem -- maybe their DLL is attempting to contact FSUIPC during the Modules initial loading, which would probably make it dependent upon the ordering of modules in the Modules folder. The only solution really is to ask Elite support to look at what they are doing, in those initial moments, and change it for a more consistent approach. I can't tell how they are checking for FSUIPC since there's no contact, so it is up to them. Regards, Pete

Oh, sorry. My memory isn't good enough. One thing I missed in your last message was this: Which INI file is this? By "they" you mean the Elite driver..(s)? If you can consistently get things to work by following a specific path then there should be a big clue there. FSUIPC logs the attachment by external programs. Is the Elite driver a DLL? You are starting a Flight off many times there, but there's no other information of use I'm afraid. Can you get rid of every other FSUIPC user (PFC, ActiveSky, anything else) except the Elite driver, then enable FSUIPC IPC read and write logging -- do this before starting FS by editing the FSUIPC.INI file. Just add LogReads=Yes and LogWrites=Yes to the General section. I need the Elite driver to be the only FSUIPC user so that I know that all the log entries for data reads and writes are from it. Having other things running is just going to muddle it too much as well as making the log too big. Tell me exactly what happens, and how many seconds into the FS load it is when you get that Elite error message box, then close things down. Regards, Pete

If it is checking the version number and doesn't like version 3 then there is no solution --- I thought Elite had corrected this? Are you sure you are using the correct Elite driver? Is this with a registered copy of FSUIPC? If not, have you considered buying a user registration for FSUIPC? No. If you show me the FSUIPC Log file I may be able to tell you what is happening, or at least advise about adding more logging to show more. But I have no information to go on as it is. What do Elite support say? Isn't it really their job to support their products? Regards, Pete

Ah, yes. You would have to reload the aircraft after entering the registration. But of course it should have been okay next time to ran FS -- you don't have to enter this every time. Regards, Pete

FSUI.DLL is a major part of FS, it is the User Interface. You cannot have two copies with the same name in the same folder, so possibly you have a RENAMED copy of FSUIPC in the Modules folder. Check properties (right-click, properties-version) to get the real names. The other possibility, which has occurred once before, is that you have an FSUIPC.DLL in the main FS folder too -- it seems that, these days, FS loads add-on DLLs from that folder too! (Ugh!) All recent versions of FSUIPC detect the condition of two copies and one of them should close down in any case, though this may then lead to FS itself closing. However, you say: so I don't think this is FSUIPC, as FS would certainly not last for 45 minutes otherwise. You may need to check your other add-ons. Regards, Pete

Sorry, not that I can advise, but I am no expert. I just read and follow hints elsewhere. You might find the FS2004 Forum useful. BTW my previous PC with the Parhelia was a Pentium 2.4, and the frame rates were correspondingly slower -- worse than yours I recall -- so I am afraid that processor power is a prime need. Regards Pete

If your FS9 is on the same PC as your FS2002, just copy over the FSUIPC.key file (from Modules folder to Modules folder). If it's on a different PC you will need to re-enter the details, but they are all in the KEY file. Be sure to keep a safe copy of the KEY file, of course. If you've already destroyed your FS2002 installation then you have to get the key from whoever supplied it to you. In the case of SimMarket I think you can get it by simply going to http://www.simmarket.com and opening your account. Please take better care of things you pay for in future! :wink: Regards, Pete

That's very odd. I'm sure this facility has been used successfully by many folks. Sorry, I can't make any sense out of that statement, Can you re-phrase? Sorry, is this relevant? I certainly think you must have a programming error somewhere, though in that case it is a bit odd that you got it working with FS2002. I assume you are, in fact, writing to the 560-580 offsets? I have just checked all those using FSInterrogate -- you can try this yourself. With FSInterrogate I can write individually to FS (yes, in pause mode) values for Latitude, Longitude, Altitude, Pitch, Bank and Heading, and each one sticks and the results are cumulative. Please check your coding. You may find the FSUIPC IPC Write logging useful so you can actually see what your program is writing. Also make sure you have no add-ons interfering. Maybe things like Active Camera do something with this too. I tested here with a plain FS2004 installation. Regards, Pete

This is not an area I've experimented with, but I think in FS2000 and FS2002 you had to set paused, slew or zero sim-rate modes in order to change some of those things. But in FS2004 you shouldn't need to use any of those. Have you tried it without setting pause, or setting slew mode instead, for example? It may be the fact that you've paused it which is stopping the new values being accepted. The main difference in FS2004 is that the locations from which that data is readable (offsets 0560-0583 incl) are only read-outs. New values written there are ignored by FS2004, so FSUIPC has to intercept them and issue the appropriate commands to FS to effect the changes. Regards, Pete

Hmmm. Good news! But the Log didn't seem to match the KEY file, excpt right at the end when it said "ModuleOK". What did you do, please? I like to see solutions here as well as problems as it helps others. Thanks, Pete

I don't know. I had another report with this recently. Are there no error messages, just disconnections every 11-12 seconds or so? If so, it is similar. I don't know why this has started happening recently, with no changes at the Network level to either WideClient or WideServer. The only recent change was to Wideclient, to add the button polling. Can you see if it is better with that switched off (put ButtonScanInterval=0 into the Wideclient.ini file [config] section)? Because of the other report, I already have this in my list to start looking at soon, but I am up to my (failing) eyes in other things for a couple of weeks. I would need to try to reproduce it here, or failing that, to get some diagnostics. There's a little "email" button at the end of each of my messages. You can use that (but please don't make a habit of it! :wink: ). If you are sending logs and things, please Zip them up. I need both Server and Client ends -- please Close FS and the clients down first, as then I also get frame rates and performance summaries at the end. For additional diagnostics you could try changing the Logging. Put "Log=Debug" into the [user] section of the WideServer.ini (replacing any other Log= there already), and "Log=DebugAll" into the [user] section of the WideClient.ini (replacing any other Log= there already). This will make the logs very large, so please keep the session short -- long enough only to prove the problem still occurs -- and replace the original Log= lines after (probably "Log=Errors+"). I will then get to this when I can. Apologies now for any delay. Regards, Pete

For FS2004 the only way you can be certain of the wind affecting the aircraft is by waiting for FSUIPC version 3.30 and using a new facility there to directly control the wind at the aircraft (only). This isn't an aspect of the Weather as controlled by WEATHER.DLL, but an override in the actual simulation engine, and so isn't readable in the normal weather structures. For all versions of FS you can read the "Ambient Wind" value at the aircraft, however -- this is listed in one of the offsets and has been maintained by FSUIPC through all FS versions. At least with that you can monitor the wind and find out if your pilots are 'cheating'. However, until FSUIPC 3.30 you don't have precise control over that -- you would just have to "disqualify" him or do something nasty to his aircraft! :twisted: Regards, Pete