Pete Dowson

Okaysomething must have changed. I'm a bit tied up till next week, but it is on my list to look at. I'm sure I'll be able to fix it. Watch for another update in the FSX Announcements above. Thanks & Regards Pete

WideFS has nothing to do with drives and needs no mapping. It does not need access to folders on the networked PC at all. I think you may be getting mixed up with something else altogether? If you have a problem with WideFS not connecting, show me the WideServer and WideClient logs. However, if your problem is related to FSCommander not being able to access files it needs in remote folders, I'm afraid this isn't related at all to WideFS and you need FSCommander support. Regards Pete

I think if you are running ASX on the same PC as FSX that all makes complete sense. It really is better, in my opinion, the other way around, though, when ASX is safely over on another PC not getting squeezed by FSX's instaible appetite for processor and memory! ;-) Regards Pete

Seems really good then. Seems odd having all that really up-to-date modern kit (much better than anything I've got at present) but have to struggle with a very old plastic yoke on a game port! Regards Pete

Ok what? Please cut and paste the complete install log into a message here. Then maybe I can help you. Pete

What do you normally do then? Maybe I can't reproduce the crash because I am doing things in the wrong order? I know you said you ran ASX on a separate PC. Do you usually get it fully running and waiting for FSX first? Maybe the problem is related to the FSX/FSUIPC4 initialisation phases only? Possibly I've not been testing that part in the same way. Please let me know and I'll re-run the testing on my one and only FSX SP2 PC. Regards Pete

Okay, thanks. As far as I recall (I'll check the code when I have time), the simpler version in FS9 operated by these rules: 1. If the FS value is non-zero, and your parameter is zero, save this for use instead of your parameter, and set zero. 2. If the FS value is non-zero, and your parameter is non-zero, just set zero. 3. If the FS value is zero and your parameter is non-zero, set your parameter value. 4. If the FS value is zero, and your parameter is zero, and we have a saved non-zero value, restore that saved value. 5. If the FS value is zero and your parameter is zero, and we have no saved value (because we started off like this), then set 100. I think that covers all possibilities. The additional or other sliders brought in complications. It simply tries to maintain the same proportions with the others, but I can't remember what happens if it can't -- probably caps them, so that you then effectively lose the relationship. If it doesn't appear to be doing all this, let me know and I'll analyse the code instead or trying to remember! ;-) Regards Pete

Sorry, I don't know any Armostrong electronic. I'm not really into hardware -- most of my stuff is PFC ready-made and I'm very happy with it. Regards Pete

Well, I don't either, unless you don't want adjustable reverse and would prefer the whole range of the lever to be used for forward thrust control. Otherwise, I understand folks use the button to engage reverse thrust. Are, there's a detent as well, is there? That's nice! Even more reason for ignoring the button and having a reverse zone on the lever. I fully agree. Even more so now you've told me there's a detente. Well, sort of. You simply make the minimum setting (the max reverse setting) the same as the lowest of the centre idle settings, so there's no reverse range at all. Easy enough. Regards Pete

The toggle swaps between the previous value and 0 or 0 and the the previous value, unless you set a specific value in the parameter field. If you want to set a specific percentage then you need to use the Traffic Density Set control. It does try to maintain the proportional relationship between the airline and GA values, where it can. But it really does depend how they are set, relative to each other, to start with. Its criteria is the Airline setting. You would need to manually set them both to 100 first, so that they are seen as equal. Then they should change together. What's wrong with assigning them on-line, in the normal Button assignments dialogue? Seems odd editing an INI file for such a simple requirement. No, I think I programmed it so that 0 took the current value in FS, whatever it is, as its alternative to 0. Yes, it should do that for the airline traffic. The other is maintained in whatever proportion they were in. No idea, sorry. If you tell me your exact starting values, in FS (FSX I presume? You don't say), and your setting for the Toggle control, I'll test it again here. It's a bit of a hack even in FSX as Microsoft didn't provide it via SimConnect. Maybe something about the way I'm hacking it changed between FSX RTM and SP1 or SP2 -- I've not really used it since RTM. For this reason you need also to tell me your FSX version details (and FSUIPC4 version too of course). It should toggle to 0. Then next time to 100. But if the GA level was, say 60%, it couldn't set that to 120% so the proportions would go wrong. I'm not sure without looking at the code whether it reduces both to maintain the proportion, or merely caps it. Ah. We should have started with that. Okaytell me what you start with for the sliders, then what you do, and what you end with. I'll try it here. It might be a few days though. Regards Pete

Sorry, I have no idea which version of FSX the PMDG aircraft requires. That is a question for PMDG. The flight controls should work okay. The autopilot implemented by PMDG is their own and I don't know of any hardware which will drive it directly, though I think they had some contract arrangement with GoFlight. PMDG have never released any form of SDK to allow others to interface to their products -- at least not without some hefty fee up front. You would need to pester PFC if you think they ought to be paying PMDG a load of dosh for you. At best you might find keystrokes are assignable to some of the PMDG functions, but then you would need to purchase a Registration for FSUIPC4 and program all of the relevant PFC avionics buttons and dials to send keystrokes to PMDG. Not very pretty I'm afraid, but I nkow some folks have done such things. Well, I do the freeware PFCFSX.DLL which interfaces their hardware to FSUIPC4.DLL You need to install the latter first, then the former. I wrote the PFC stuff for my own use but PFC liked it more than their own so use it instead. I think their consoles are very nice indeed, but no hardware is really suited to any of the PMDG models as they really designed it all to be driven on-screen, with the mouse. I think they never have considered cockpit builders a useful market for them. I do use PMDG flight models myself, but with no panels -- all of my instrumentation, including the autopilot, is from Project Magenta, which is handled all through FSUIPC4 so it is easy to integrate with PFC goods. Regards Pete

Okay, thanks. This would presumably be where ASX is running on the same PC as FSX? John and I both have ASX on a separate networked PC, and I usually don't start ASX till FSX is not only started, but ready for cockpit preparation. That way I know ASX will give me the weather for my chosen start location. Best Regards Pete

No, don't try to send any file. Just open it, in Notepad perhaps, then cut and paste its contents into a message here. Pete

You are thinking of WideFS, and, sorry, the remote connection would only apply to buttons and switches. There's no facility for remote axis controls. I did experiment once with this but the latency (although measured in fractions of a second) wasn't nice when flying, being akin to a very low frame rate and making you over-control. I know Networks have become a lot faster these days and so, except for fighters and stunt planes, the remaining lower latency (maybe 20-100 mSecs) could be tolerable for airliner and slower GA aircraft, but the demand hasn't been there and generally it is much better connecting axes directly. The normal game port supports 4 axes and 4 buttons, max. CH did do a driver which used the 4 button connections in combination to provide up to 14, but they still look like 4 button lines, they are just decoded in the driver together. There are certainly two different qualites of game port adapter -- those which support 2 axes + 2 or 4 buttons, and those which support the lot. You'd need to read the description before buying. The question really then becomes whether the CH driver, the one with the 14-button decode routine, will recognise the device correctly connected via USB. I suspect you need to contact CH and ask their advice. First, though head here and look/ask: http://www.ch-hangar.com/ No, it doesn't handle devices directly. It simply uses the Windows facilities for reeading button and axis values. It has no idea how they get there. Windows has generic "4 axis, 4 button" drivers which will be assignable. The problem would be to decode the 4 button lines, resolving the combinations into 14 buttons or whatever. Maybe CH's own decoder would be available or work as it stands. I just don't know, sorry. There is a fall-back position, which would be to use FSUIPC's conditional button programming to process the 4 buttons and derive 14 possible actions from them. But that is pretty complex. Regards Pete

Ah, thanks for the heads up. I shall update my copy. That must be a different problem. FSX crashing only with FSUIPC4 options set just "so" must be down to me somehow, but I am unable to repro it or understand it. If you are getting ASX crashing that most certainly needs reporting to HiFi Simulations. Regards Pete

Good. With regards to "realism" I do have a little feedback already from a real-world 747 pilot, who says that the wind directional fluctuations in FSUIPC are good, but he thinks the wind speed changes are not actually large enough (!). Quote: "LIGHT+-5 KTS, MOD+-10 KTS, HEAVY+-15 KTS, SEVERE+-20 those values are much closer to reality and I don’t see any issues controlling the airplane in either regime A/P or MANUAL". Those fluctuation values are 5 times my current ones! You could try that by setting TurbulenceRate=5.0 in the INI file (though this would also increase the directional changes to 5, 10, 15, 20 degrees, too much I suspect). I think I shall have to have it set two values, thus TurbulenceRate=1.0,5.0 for the directional changes and speed changes independently. Look out for this in 4.253, probably next week now. By default WeatherSet is reading the Interpolated Weather at the aircraft. This is exactly as reported by SimConnect, and it seems to vary a lot. The weather is actually changing all the time in any case -- slower or faster according to the slider in FSX's options, but never static. But one of the reasons it appears to change so much, layer-wise is that, as the weather is 'developed', presumably because of bugs in the code, FSX generates many spurious wind and temperature layers. These used to build up and up until, in fact, the METAR string exceeded SimConnect's maximum allowed, after which they got truncated (or caused a crash in the RTM release). To fix this, when FS is allowed to change FS's own weather it removes these spurious layers and writes the METARs back. These are directly changing the nearby WX stations, and thus the interpolated weather. On your second message: Yes. In fact it wasn't right in 4.251 -- the target to which the speed and direction was moving was computed incorrectly. If you'd like to test things further, could you see if you could find the highest value for "TurbulenceRate" (between 1.0 and 10.0) with which, with moderate turbulence set (i.e. "2") the 747X still flies correctly? I should then be able to set the default rate for speed changes to half of that (but I'd leave the directional value at 1.0 I expect, considering the Captain's comments). Thanks for all your feedback. It is very useful. Best Regards Pete

This is a duplicate thread, somehow. See viewtopic.php?f=54&t=68875 for my original answers, except for this addition: Ah, no, that's the "spike remover" on the Miscellaneous options tab. That merely removes any absolute minimum and maximum values from the input, on the basis that they aren't real. If you use those you have to calibrate with a little bit of leeway at the extremes so that the real inputs never get such spikes. The ones from the Wilco aircraft were if software origins, not from the joystick, The filter facility being discussed before is the one operated by the "Filter" checkbox on the joystick calibration pages. Regards Pete

Shouldn't think so. Loading a flight directly sets so many things inside the sim engine out of reach of FSUIPC or anything else that if it can't be done by flight loading then I don't see how it can be done any other way. I can actually say that I have never noticed any "re-spooling" in any case, and I start off with saved flights more often than anything esle in the course of testing facilities. Hmm. I don't know what is going on there, but you could try pausing before saving so it comes back paused on reload. In FSX you can also set airspeed when setting an initial position and attitude, but not in FS2004. I don't know of anyway of presetting all of thev engine values, but they should re-initialise as in the saved flight. There is a facility in FSUIPC for freezing an aircraft's position without affecting its actual engine or other settings. it is still "flying", just not moving at all. This is the usual way of setting up an exercise like approaches. such a feature is actually built into FSX too -- so there are effectively duplicate controls now for freezing -- FSUIPC's and FSX's. Regards Pete

I think those are your best bet by far, short of upgrading your yoke to a USB model. Regards Pete

Well, I can't reproduce any problem, and so far no one else has reported anything similar at all. Admittedly I never use any FS plans or feed plans into ASX. It isn't something I even know anything about I'm afraid. Maybe you could try it "plain", just in case it is related more to that side of things? Meanwhile, it really makes no sense at all that any of the suppressions cause a problem, as all they do is bypass small bits of code computing changes to the winds -- and if turbulence, gusts and variance are not present in the aircraft's wind or cloud layer in the first place, the exact same path through the code is taken -- i.e. "suppress turbulence" (etc) is the same as "there is no turbulence" (etc) as far as FSUIPC is concerned. You can see why "it does not compute". So, sorry, I've no way of knowing what is wrong on your system at all. I can only recommend that you don't suppress any of those features. I don't think you will need to on the versions I am working on now in any case -- 4.251 has a better turbulence emulation, improved again in 4.252 which I shall upload later tonight, and 4.252 has the gust and variance emulation working nicely too. There will be further changes as I work on the "realism" aspect of these, but I think you should find that they are eminently usable already. If I do get further similar reports to yours we may have a chance of narrowing it down by comparing things in more detail. Until then, apologies for leaving this in abeyance. Regards Pete

What destination? What has this got to do with FSUIPC, please? Does FSPassengers even use FSUIPC? I don't think so, otherwise surely they would have agreed a licensing deal for it? In any case, there is no destination known to FSUIPC for user aircraft, only for AI Traffic. I'm not sure why you think such information is provided that way -- don't you have to give FSPassengers your plan or something? I think you need to find the correct support site for FSPassengers. Regards Pete

No no no! Please re-read my message above! :-( Seems you have a broken FSX installation, without a working base version SimConnect. You will need to repair it. First see the "FSX Help" announcement above. You need to delete one of the SimConnect side-by-side folders, else it won't be repaired. There won't be one until the FSUIPC4 Installer creates one. If it hasn't even got as far as that you have problems. Since you couldn't find that, why didn't you save the Log file, as I asked, and paste it into your message, also as I asked? I cannot help further without that information -- it is produced EXACTLY so that all the relevant information is available. If you continue to ignore it we will get no where! :-( Pete

No thank you. It won't say both, but it sounds vaguely like your FSX SimConnect installation is corrupted. I don't want to see pictures -- the Installer creates a Log file, which may be in your FSX Modules folder. If so, show it to me here. If not, then when you get the error, click on the Save menu entry on the Log shown on screen, save it to a text file somewhere easy for you to find, then show it to me here. Just paste the contents here. No pictures please. Pete

Hmm, odd that if this is such a common problem, I've never heard of it? Is this something to do with lack of proper Game Port support in modern Windows versions? If so, would a USB=Game Port adapter sort it out. After all the main driver interface would then presumably be a modern USB type. The original Game Port system required the low level drivers to actually sit in a tight loop measuring the decay time of a capacitor! Well, it is axis-oriented, not controller, and it is a low-pass digital filter very approximately set for something around a few Hz (sorry, I don't remember how many -- maybe 2-5), so it may or may not help. If you are using FS's own assignments, then considering the polling frequency in FS is only about 6Hz, it probably is no help at all. FS's own axis assignments will poll a lot faster, so the filter may be more efficient, but if your axis is giving the wrong value at 5-10Hz, with insufficient "right" values then I don't see how any filter can derive any good value for you. It might be a good idea to visit some of the more hardware-oriented forums to ask this. As I say, I've never heard of such a problem before. I assume you are actually using a real Game Port, not a USB one? If so, I reckon your best bet is to get a USB adapter and try that. They aren't too expensive. That's not possible if your wrong value as as frequent or more frequent than the polling interval -- if it filtered that much you'd have a very unresponsive axis in normal use. Regards Pete

One thing occurs to me. When you are doing these tests, are you always starting with FSX in the same place, or close, when ASX is initialising the weather? Could it possibly be something in the ASX data itself which is acting as the trigger, something which possibly was different when you were testing the earlier Betas? Could you try tests where you move your aircraft a long way from your normal starting position before starting up ASX? Maybe even a sampling of different locations throughout the World? If you do find a difference, perhaps you could save a copy of the ASX weather which causes the problem, ZIP it up and send it to me at petedowson@btconnect.com. Obviously, if you get the same results no matter where you are, it is unlikely to be down to anything specific in the weather data. I might be clutching at straws here, but I have nothing else to clutch at. Regards Pete