Pete Dowson

Ah, right. In that case something is very much amiss. Well if it is only happening when Wideclient is running, then it must be the network, but it doesn't appear to be coming through to WideClient in any sort of failure report. Mind you, with less than 4 seconds of operation and apparently no application running, Wideclient wouldn't have had anything much to do in any case. When you actually run a WideClient application does that run normally or slow? Are there any errors in the Log then? Don't just look at the Client log -- there may be problems reported at the Server end. I really don't know what else to suggest. If you are using a Network card, try swapping it, or try uninstalling it and reinstalling it. See if there are later drivers, and so on. With no actual errors I can't understand what is holding things up, and as you say the same Network card and drivers operate okay when it is playing the part of the Server instead. Most odd. I think you may need to find a Network expert for this if you can't track it down yourself. Try Katy Pluta ober in the FS2004 Forum. She's been able to help me several times. Regards, Pete

What do you mean by "needs"? For instance, depending on PC type and some other things, FS "needs" 100% of PC cycles. I think "uses" is a better word than "needs" -- it soaks up idle time. You can only determine whether it "needs" those by seeing if other things run as well without it stopping or slowing significantly. Apart from calls from applications, WideClient also works off calls to it from Winsock (the network part of Windows), plus a 'watchdog' timer (WM_TIMER) message to keep track of responses. Between them these determine how much time it uses. Quite honestly I cannot understand why you are looking at CPU usage in any case. What is the actual problem you are trying to resolve? CPU usage is not a problem in itself -- it may help determine what is going on when there is a problem, but should otherwise be completely ignored. No, there's nothing shown wrong there -- it often happens that WideFS takes two tries to connect, as here, because of initial setup exchanges. That is nothing to worry about and only occurs in the first few seconds. It was perfectly connected at 20179 (20 seconds after loading), but then for some strange reason you closed it down almost immediately (23744, less than 4 seconds later), before anything but its own protocol data checks had been exchanged. Why bother to load it if you aren't using it? After loading WideClient try running your application program. Regards, Pete

Oh, I see. Even when you change aircraft not simply re-select the same one? There's also an FS control "reload user aircraft" or something like that. Doesn't that reload the textures either? No. But if you want to see what it is loading and unloading during startup you can see that, live, using "DebugView" from http://www.systeminternals.com. That utility will also show FSUIPC's logging, live, if you add "Debug=Please" to the [General] section of FSUIPC.INI, but you shouldn't do this normally as it invokes extra code in FSUIPC and therefore can impair performance (though this may not be measurable). BTW, I get a difference similar to your 48 seconds and 10 seconds, but not with FSUIPC installed or not. The first load takes about 40 seconds or so but all subsequent ones on the same PC takes 10 or less. This is with a 1 Gbyte memory. I don't have any PCs left with only 512Mb -- that was fine for FS2002 but I think WinXP + FS2004 really do need more. The "sweet spot" is more like 768Mb now, more with more things running. I'm still wondering if the difference on your system between FSUIPC installed or not is that -- the memory is spilling into virtual memory (and therefore swap disk space). There are ways to speed up virtual memory, like having fixed and equal top and bottom limits and making sure the disk is defragmented before Windows creates the resulting file, and so on. But in the end it is really best to avoid the need to swap out to disk. I suppose the memory chip prices have risen again now, but I took adbantage of the plummet inprices not long ago to upgrade all my PCs to 1 Gb minimum. You could try using something like EndItAll to kill all other unnecessary processes off before loading FS. If this helps then it is definitely lookingl ike memory. Regards, Pete

Hmmm, don't remember off-hand (this part is about 5 years old now), but I think it is pretty linear. Pete

No, sorry. All of its parameters are in the FSUIPC.INI file. Just delete that if you want it to start afresh. BTW I am sorry, I realy don't know what you've got going there, but I am a little astonished at how desperate you sound about it. How often are you starting FS each day? If you were loading it and closing it continuously it would make sense, is this what you are doing? Regards, Pete

Oh, good -- I shall annotate them appropriately in the documentation! Thanks, Pete

If the number you are talking about is subject to an upper limit, then yes. There are lower limit facilities as well -- I do hope that it is clear which are upper and which lower? The METAR vis extension facility makes some visibilies larger though -- in the U.S. many automated vis measuring devices report "10 SM" for anything measuring 10 miles upwards, and similarly in Europe for 9999 (metres -- roughly 6.2 miles). So the "extend METAR vis" option makes a random extension between that amount (10 SM or 9999 metres) and whatever upper limit applies. Regards, Pete

I don't think it is possible to add AI planes at run time, they need to be precompiled into traffic BGLs. and then they pretty much follow pre-defined paths and timings. However, by all means get the Traffic SDK from the Microsoft website and have a look. A better bet would be to use Multiplayer and inject your additional aircraft that way. You'd need to keep control of it through the MP interface too. Regards, Pete

Not at present. How would I get such information? I don't really know anything about BGLs, textures, scenery in general. Sorry. Does that still work in FS2004? I've not had it verified. It was something found by accident in FS2002, no searching was done. Things are so different in FS2004 I wouldn't know where to start looking I'm afraid. That would be nice, for radar, but I've really no idea how to even start. Very sorry. I've never really known much at all about FS's scenery interaction. Regards, Pete

Not sure about how you draw a profile, but the localiser and glideslope deviations available in FSUIPC offsets 0C48 and 0C49 are accurate, but in arbitrary units. If you want degrees you'd need to work out some calibration. Best way to do that is use the FSUIPC Monitoring facility (Logging page, right-hand side) to display the values live on screen and note down the exact numbers for each position. Regards, Pete

That is all handled by the PM group, not by me. As with SimMarket I only see summary statements once a month or so. If you have any query please contact PM. Regards, Pete

Those options in FSUIPC work at the lowest level, just on the visibility before it is implemented in FS, so they override anything else, no matter where the other stipulations come from. Since 7000 metres is a lot less than your limit of 50 nm, the METAR value should prevail. Yes, there's a layer, you can check in FS's weather dialogues or using WeatherSet or ATIS. Pete

Yes. The original paragraph, above, from which you took it did say so, viz: excepting, of course, the original didn't have the word emboldened. :wink: Regards, Pete

I've now found what I think are Aircraft-related wind values: AIRCRAFT_WIND_X AIRCRAFT_WIND_Y AIRCRAFT_WIND_Z I'll check some more, but if these X and Z coordinates are related to the aircraft orientation, as I think they are, then writing to these may be a better bet than using the "wind at aircraft location" values. They are double floats and also in metres per sec. If they look like they might be useful I'll map them and let you know the offset details -- possibly I could sustain all these once written, releasing them back to FS control after you write 0.0 perhaps. Regards, Pete

Neither. Are you looking in the wrong columns? 50 = P 65 = e 74 = t 65 = e which spells Pete. I've been in computers using ASCII (well, EBCDIC originally) since 1963. The alphabet and numerics I know by heart! :wink: Regards Pete

There's no such thing really. There are application keys, which are in the name and details of the program, and user keys, which provide unrestricted access to all the facilities in FSUIPC as well as all access by applications. This is why most all developer's use a user registered version of FSUIPC whilst developing -- this helps offset the work involved in developing and maintaining the SDK, and in providing unlimited support. Most all the facilities in the SDK have been added directly as a result of developer requests. Sorry, I don't know VB sufficiently to help with the specific question -- it looks very odd to me! I hope other VB rogrammers can help. Regards, Pete

Sorry, I don't really know CPFlight apart from the fact that they make a nice MCP and have accreditation for FSUIPC access. Don't they have any support? Have you tried? What do you mean? There is only ever one FSUIPC! According to my records the company called CPFlight have a driver which interfaces to FSUIPC called FS_COM. I assume you would need that to make whatever it is you have work. I have nothing else listed for CPFlight. I think the driver is for their MCP, but possibly they do other things too? Regards, Pete

I spent a lot of time experimenting over the weekend, trying to use these offsets to implement both taxi-winds and wind smoothing. I've not really got anywhere yet -- there's a strong possibility that the weather input to the sim engine is NOT via these values. But one thing I have found out for sure -- 3480, the Z axis wind component, is NOT the vertical wind. FS is consistently following the system it has for the other dynamic values (see the Notes at the end of the main table in my Programmer's guide): X = Lateral Left-Right Y = Vertical Up-Down Z = Longitudinal, forward-backward. I think this is related to True North, not the aircraft orientation. I don't know what you discovered earlier, with half the Z component, but maybe lift changes are being influenced by changing the air flow over the wings, not by Y-component air velocities. Anyway, maybe you need to concentrate on the location for Y not Z, assuming it is actually used in the sim engine. I'll continue experiments on the others for taxi and smoothing, but I am not holding out much hope yet. Regards, Pete

Not that I know of, no. You can clear the engine down with the FSUIPC clear all weather facilities (both from a program and via the hot key). Possibly the fact that you are re-loading the flight it just saved means it thinks it doesn't need to. Try renaming the saved flight so when you load it it looks like a different one. You'll need to rename the WX file too to match. Or you could try clearing all weather AFTER saving the flight and before reloading it. Regards, Pete

Okay. 16 x 16-bit words for raw values (though currently the max range is 0-127, it may well change in future), and a 16 bit word containing control flags for connection (0) disconnection (1). I'll look for 34 bytes space some place. If you don't mind a rough beta with some other stuff half-baked and undocumented (probably nothing relevant to you in any case) I can probably add this this week. Is that too soon for you? For an official release it would be July sometime, though. Regards, Pete

Sorry, I know nothing at all about AIBridge, and I've never used Multiplayer. None of the pictures you included mean anything to me. Have you got the latest version, from Jose's page? http://jcboliveira.flysplash.org Password? Does it need a password? Sorry, this is most certainly something I know nothing about. Regards, Pete

Sorry, no -- there is no difference on any of my three PCs with the start-up time, with or without FSUIPC. As I mentioned, FSUIPC is really not doing anything to speak of until after the menu phase, and when FS is ready to fly. Even then it isn't doing much until asked by other programs. Of course right at the start it does read its INI file and KEY file, and start a LOG file. Check those (in the Modules folder) see if they are very large -- they should all be pretty small. Even if they were large that would in itself no slow things down. But possibly your disk is short of space, or has not been defragmented in a good while? The only other thing I can think of which might slow loading times is a shortage of memory. Whilst FSUIPC doesn't itself add that much more to the FS memory requirement, it does add a little and that may just be enough to cause some swapping out to hard disk if you've not got quite enough. Regards, Pete

Not sure what you mean. I don't know any program which passes offsets from EPL itsef to FSUIPC. The EPICINFO module allows soft axes and POVs to provide values to specified offsets, via parameters in EPICINFO's CFG file. FSUIPC does provide button and switch programming for EPIC. You just go to the Buttons page in FSUIPC options, press your EPIC button (or operate the switch) -- FSUIPC will recognise the button/switch and allow you to assign functions to it. within the many functions you can assign there are facilities to access a sepcified offset too. Also there is a program called EPICMapper, or something like that, which may do the job too, and FSCommunicator handles EPIC stuff as well, I believe. Regards, Pete

Sounds easy enough -- would this be post-calibration in PFC.DLL? For all axes or only those not allocated in PFC? With an option to disconnect the assigned function? I'll make a note and put it in the next version. Unfortunately the next release will probably not be till July sometime as I'm part way though some quite massive changes for the new PFC MCP and the Jet Cockpit (see http://www.flypfc.com). Maybe I can send you a Beta some time earlier though. Regards, Pete

No. I think DDE actually uses the same method as FSUIPC's "inter process" data passing though -- i.e. memory-mapped data. The interface used for FSUIPC was established way back in FS95 days by Adam Szofran. Regards, Pete