Pete Dowson

Please state the VERSION of FSUIPC which "did not work correct". "Latest" is never good enough, it is not specific. If you do not mean 4.942, please update and try again. Is the version of P3D the last hotfix (#4) for 2.5? Do you have the build number? And are you saying that whatever goes wrong doesn't with 4.939k? 4.939k is too old to work correctly the the latest P3D build, 12946. Also please explain what you mean by "the Window after Work". Pete

Since the only purpose in resetting the Server is to make the Client reconnect, wouldn't it be better to make the client do it directly. It wouldn't need to wait for the timeout then. Did you ever try closing and restarting wideClient, or doesn't RC reconnect if you do that? It would be relatively easy to provide a parameter to specify an automatic reconnection timeout in wideClient. Please note, though, that I've spoken to a friend who also uses RC (one Ray Proudfoot, who you may have encountered on the RC Forum, and whose voice you will here in RC sometimes), and he says he has often left everything running overnight on a transatlantic hop and not had the problems you have been having. I'm pretty sure it's some function of the lower levels in the Windows + hardware networking system, and it most certainly shouldn't happen. Pete

Okay. I've had a look, and with the D000 request area, it does wait for up to one second to see if can get both departures and arrivals in one answer, but after the timeout it gives neither if both aren't found. I'll change the timeout action to accept either, as you suggest. This will be in the next release (4.943), but I have some more things to do first. Hopefully it'll be before the weekend.or at the latest, during the weekend. Pete

Ah, so the data, and WideFS is working in that respect. Really? I shall have to revisit my old programs. I don't recall weatherset providing runway data. Certainly it wasn't its purpose, it was only for me to test my weather reading and writing facilities -- WeatherSet (1) for the older "advanced weather interface" (pre-FS2004 compatible, and later), and WeatherSet2 for the "New Weather Interface" which extended from FS2004 to FSX and P3D. I presume, therefore, that you are saying your code has the same bug (?) as WeatherSet2, assuming there is one? I'd have to examine your code more thoroughly to understand this. Are you sure it isn't a matter of timing? At one glance you seem to be only scanning once each 5 seconds. Is that right? Wouldn't an event call based on offsets be more appropriate, or at least a one-second base for scanning like TrafficLook and WeatherSet? Pete

I assume you mean TrafficLook? WeatherSet doesn't read traffic or runways. There's actually no conditions in the code awaiting either event, spedcifically. When the information is available it is provided, no other conditions. There's never any reason for waiting for both conditions to be true. I don't know what is happening in your case, but i'd need more information. For instance, how are you using "Weatherset2" to check? Why not use FSInterrogate or FSUIPC's own logging to check? I'll investigate further with more information to follow, but I cannot at present see anything wrong. Pete

No, FSUIPC provides no facilities for instrument handling via Mouse, only, as Thomas says, for trimming in mouse trim mode and zoom in mouse move mode, bith of which are options on the Miscellaneous tab. I'm note sure, but I think scroll wheel action in aircraft gauges is a function of the individual add-on aircraft, and not all will offer this. Pete

All of FSUIPC, including settings (the FSUIPC4.INI file) are within the FS Modules folder, so just back up the folder and restore from that when needed. Pete

Hey, that's a good idea! I had completely forgotten I'd had such a thought before! Sorry I doubted you! Strange. You'd think it would do they same thing. I'll take a look at making the hotkey version work. Probably the delay just isn't long enough to make the Client timeout and retry properly. It needs to go into "waiting for connection" mode. That might take many seconds actually, so I'll see if there's a more certain way of detecting it. I've not got time for this now till Thursday, but I'll be in touch after then. Pete

Okay, I'll try your INI, see what is going on. But first can you please confirm that these aircraft are, in fact, still installed and accessible? 1=iFly 737-800 (Normal screen) 2=iFly 737-800 (Wide screen) 3=AirEurope 4=Easyjet BTW this profile will apply to ALL Easyjets and AirEurope aircraft, not just 737-800's. You are quite entitled to have separate profiles for every variant if you wish, but considering the 737-600, 700, 800 and 900, all being NGs, are all exactly the same to fly, why on Earth have separate profiles for them all? I have a hardware cockpit based on 737NG and can fly any 737NG without changing anything. The only differences are the numbers in the CDU. Also, your INI is getting very large and so rather inefficient. It is exactly for such cases that the facility for separating the Profiles into separate files was introduced. It may pay you to read up on it -- there's a document in the FSUIPC Documents folder which explains it. Unfortunately I have guests here today and tomorrow, and won't be able to investigate your problem now till Thursday. Sorry. I'll get back to you when I can. Pete

Further to my last message (which still applies, please), I have just been doing some thorough tests on the "New based on ..." facility, and it works in all cases EXCEPT when these things apply: 1. The current UseProfiles setting is "Yes", but it had previously been "Files". 2. The Profile data for the base profile is actually in a separate file, in the Profiles folder In this case FSUIPC currently does not correctly find the profile data and therefore does not create the new profile with that base data. I have fixed it here and it will be fixed in the next release. However, in all other combinations I have not been able to make it fail. The above circumstances are quite unusual, applying only to someone who decided to use the separate profile files facility, and created one or more this way, then changed back to the main INI based profile system again, leaving the earlier profiles still in separate files. I await your data so that I can see what is happening for you as there is no other combination I can think of trying here without more information. Pete

Why not use the FSUIPC settings dialogue? I think the control is toggle exit, with the exit number as parameter. Better to use the controls directly than mess about with keypresses. Pete

Please show me your FSUIPC4.INI file -- just paste it in. There's been no changes in this since the facilities for profile files were added many releases back now. Please also state which Profile(s) you are trying to base the new ones on. Pete

Your reply crossed with an update to my message above. Enjoy reading where you wish, now. ;-) Pete

Well, there is a documentation section here and that gets updated whenever I get round to updating the documentation, which hasn't been done for too long a time now. I will get there but with an update to FSX-SE and another to P3D every other week or so and trying to fit my overseas trips in, I don't know when it'll be. I also like to get in a flight now an then. Less than one a week at present! I'm not sure why you'd need to refer to stuff about FSUIPC without access to your FSX/P3D stuff? [LATER] Despite my argument against ;-) I have Zipped up my FSUIPC Documents folder and used the ZIP to replace the 4.92 package which was up there till now. I've added the Changes document too, as otherwise you only get that in the Installer pack. Pete

Are you using Profiles in Files? If so, check your Profiles folder -- that's where they go! Please update to the currently supported version (4.942) before posting again. Pete

Accompanying the Installer in the downloadable ZIP is a document about Installing and Registering. It explains that all of the ancillary files and documentation is installed in the FSUIPC Documents folder, inside the FS Modules folder. I think it even lists the files which are installed there. It's been this way for all of the time FSUIPC has had an installer. Pete

Er, how would you restart the Server without closing FS and restarting it, or doing what I just suggested, which isn't possible with a hotkey -- well at least I don't think it is! I run ASN quite happily on the same PC as FSX. Doesn't seem to present any pronlems. I don't have many other programs on there -- Aivlasoft's EFB server, OpusFSI's server (used only for the views, instead of EZDOK), and Prosim's MCP. None of them impinge on FSX noticeably, but of course they won't be tying up the network at all. Pete

There's one thing I'd like you to try, to see if it helps at all. Next time it happens, or you think it is impending, go to FSUIPC's options and on the first tab disable WideFS. OK out,wait a while (till WideClient says waiting for a connection), then go back in and re-enable WideFS.. Hopefully WideClient will still be trying to reconnect and will then do so. This might cause the underlying network driver stuff to release it's buffers and start over. If it does help, it might be worth me adding a KEYSEND parameter to the Client's armoury to force it to reconnect on instruction from the Server, which could then be triggered by keypress or button. I really can't think of anything else. I have an 8-PC network here, of which 4 are usually kept pretty busy most of the day (running cockpit displays and scanning all the switches and dials). I don't like long flights, so things like Radar Contact are only running for an hour or two at a time, but we do fly two or three flights without reloading anything else sometimes. Not often, though. I find FS itself runs far better if it is restarted between flights. Pete

Very good for a "Lua beginner" :-), but I think you should look at using events instead. I've posted some ideas in the thread in User Contributions. Ask questions if you need to. Pete

Nice idea, but starting and Killing threads is a rather inefficient way of doing things. Why not use event.button to trigger the braking on / off and have the Lua plug-in loaded initially by an [Auto] line in the INI? You'd need to either test the button in the loop as well, or use the events to set asnd clear a value or flag which is tested in your loop, so it can exit. Alternatively, but similar, use event.param in a similarly loaded plug-in, and just have your button events using luavalue with different parameters for on and off? Again, you'd test in the loop. Or, again, event.flag. and assign to luaset and luaclear for on and off, and test the flag in the loop. Any event-based plug-in is far better than one which is continually started and ruthlessly 'killed' (the latter action is equivalent to using Task Manager to terminate a hung process. It isn't very nice). Killing threads used to be the only way before I devised the event system. With events the plug in is loaded and compiled just once and lays dormant until the event occurs. Regards Pete

I don't know. I don't know "kACARS". But I can check that FSUIPC is okay if you find the FSUIPC4.LOG file in the P3D Modules folder and paste it into a message here. Make sure you close P3D first. BTW, you are lucky I even saw your posting here, because you added to a thread which last saw access in 2007, a full 8 years ago! Please never do such a daft thing again. Just create a new thread with your own title for a fresh subject or one so long separated in time! Regards Pete

There's nothing in WideFS itself that is going to change after so long a period. I think it must be a Networking problem, but it will be lower down, in the Windows drivers or hardware. Both WideClient and WideServer always log any actual errors which are reported back to it by the Network, and none have occurred. They also log errors like missing frames (they are sequence numbered), so your UDP protocol is also behaving well, not getting frames out of order (else they'd be logged). I really don't know what to suggest. Does the WideClient displayed frame rate deteriorate over time (you can display it in its title bar)? If so maybe it is just that the client programs aren't getting the feed they need in the time they need it in. However, your logged performance data looks reasonable: Server: Throughput maximum achieved: 30 frames/sec, 4002 bytes/sec Throughput average achieved for complete session: 14 frames/sec, 1142 bytes/sec Average receive rate from "SPEEDY": 0 frames/sec, 38 bytes/sec Client: 30235630 Reception maximum: 30 frames/sec, 3989 bytes/sec 30235630 Reception average whilst connected: 29 frames/sec, 30 bytes/sec 30235630 Transmission maximum: 17 frames/sec, 9447 bytes/sec 30235630 Transmission average whilst connected: 0 frames/sec, 39 bytes/sec 30235630 Max receive buffer = 4608, Max send depth = 13, Send frames lost = 0 30235630 **************** Individual client application activity **************** 30235646 Client 3240 requests: 8304669 (Ave 274/sec), Data: 931163112 bytes (30801/sec), Average 112 bytes/Process 30235646 Client 3100 requests: 58821 (Ave 1/sec), Data: 8369784 bytes (276/sec), Average 142 bytes/Process RCV4's requests appear to be sent at good regular intervals: 30235646 Client 3240 requests: 8304669 (Ave 274/sec), Data: 931163112 bytes (30801/sec), Average 112 bytes/Process though the difference between maximum and average transmission rate is quite marked. Maybe the send buffers in the Client are getting clogged (I mean, here, the Windows driver or hardware driver buffers): 30235630 Transmission maximum: 17 frames/sec, 9447 bytes/sec 30235630 Transmission average whilst connected: 0 frames/sec, 39 bytes/sec which of course agrees with what the Server saw: Average receive rate from "SPEEDY": 0 frames/sec, 38 bytes/sec I really do not know what to suggest. Perhaps see if there are new drivers for the networking part of your systems? I'm not going to be changing any of the Networking code in WideFS, which hasn't been touched now for about 15 years (it still supports IPX/SPX which was the best protocol ever for local networks!) and has been successful all that time without tinkering. I'd probably do more damage than good if I did try to mess with it. Maybe there are some Network analysis tools which can help get to the bottom of this? Pete

Yes. Persistence pays. The problem isn't so common these days, but it is still some sort of timing conflict in SimConnect. I've not seen it reported yet for FSX-SE (so it's worth trying that),, and I the checks which fail are not applied in P3D. Pete

Sorry, but there is no special "P3D version". There is only the one version FSUIPC4, and I'm afraid changing all the code to deal completely with joysticks via the later DirectInput facilities is not only a lot of complex changes, which I'm not really willing to undertake at this stage, but it would also involve updating to later versions of the Visual C which would make supporting FSX more of a problem. I would also be concerned than FSUIPC would suffer more of the joystick connection losses which the FSX/P3D method currently does. Maybe if there is ever a 64-bit version of P3D and there is justification for FSUIPC still (it would be a new product, of course, maybe FSUIPC5) then I can change it over -- assuming I'm not so old that my brain isn't working well enough by then (I am 72 already!). Meanwhile, you can, if you wish, construct drivers for your devices using Lua plug-ins and the COM libraries "HID" interface facilities, which can be made to handle any joystick device of any configuration. BTW if LINDA should cope but fails, wouldn't it be a good idea to pursue a solution ni that direction? Pete

Sorry, I do not have the iFly737 and do not know how they programmed it. Perhaps you can find out how to start it normally, using keyboard and/or mouse? Once you know how to start it using normally supplied facilities only THEN think about assigning switches or buttons! Maybe iFly supply some documentation, and possibly they have a Support Forum too? Pete