Pete Dowson

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

Sorry, I don't keep keys nor do I have a database. All of this is dealt with by SimMarket. If you scan the Announcements above you will find one which tells you what to do. Regards Pete

That's really odd, because all those suppressions do is bypass little sections of code. They don't ADD anything at all. Possibly it makes it worse for you because by not including a little more computation in the regular frame loop it is going infinitesimally fasterbut it really is an infinitesimal difference, possibly 100-200 more CPU instructions out of many hundreds of thousands. It makes no sense to me at all. Only the very last Beta had the full wind smoothing in for SP2. All of the others were the same but acting as though "NoHorribleHack=Yes" was set. The action of that parameter is to cut out the hack which wasn't previously being performed on SP2 and before. I'm perplexed. Sorry. Pete

Yes, it is. Oh, right. I never understood all that stuff. Sorry. Goodyou are obviously nowhere near as "illiterate" as you made out! ;-) Regards Pete

SIM1.DLL is the main simulation engine of FS. There's no other. I think originally (going waaaay back) the idea was to have different modules for different types of aircraft, but that is certainly not implemented in any recent version, as far back as I can remember. That'll be the turbulence emulation -- either suppress it (in Winds and Clouds tabs), or move on to version 4.251 and try that. I'm still developing the wind effects. I'm amazed that as a 4.241 Beta user you've not read anything here first about all the developments we've been doing and testing on all this!? Regards Pete

All the recent implementation of wind smoothing is by hacking. One part is a tidy call interception between on FS module and another. That nearly worked except that the odd incorrect wind slipped though and caused "ratcheting" (horrible jerks) on the ASI and other instruments. To get rid of that i had to do something really horrible -- patch SIM1 (dynamically, in memory of course) with a blister into a routine of my own. that is my "horrible hack". The METAR reports should stay the same. Whether the surface wind at the aircraft is the same as the local METAR report (assuming there is one close by -- that is never guaranteed) is in the lap of FSX. Ah, right. Panning. never did like it -- it works well with TrackIR provided you have an FS virtual cockpit for orientation. In a cockpit like mine, with a real window onto a projected scenery view, panning is abysmal, so i never use it. Yes, that's the idea with the normal flattened centre slopes in FSUIPC too. I didn't know FS did it so well. Not as it stands. I'm not really sure how I could implement such an option .. just for panning? Regards Pete

Those are NOT SimConnect errors!!! If they are being logged other than at FSX startup time, or when you run the FSUIPC4 Installer, then they are a RESULT of SimConnect activity being blocked, causing FSUIPC to retry the connection. No, it is the other way round. it is the crash which is stopping SimConnect responding which is causing FSUIPC to try to reconnect, and it is that action which creates the Log entries. You have it all back-to-front. The PMDG 747X is a heavy user of SimConnect. I suspect that either you are still using FSX RTM or SP1 (i.e not the SP2 or Acceleration updates), so forcing both FSUIPC and PMDG to use TCP/IP connections via SimConnect, or, just possibly, you are using SP2 or Acceleration, but the PMDG 747X routines aren't updated to use it, and so are still reliant on good TCP/IP operation. Assuming it is a TCP/IP problem you need to be looking at things like memory availability (TCP/IP buffers use it up very quickly), virus checkers, firewalls, and similar security checking programs, all of which put hooks and filters in the way of fast TCP/IP communications, even in the same PC. Aha! There you go. Update FSX to SP2 and the loading on TCP/IP by FSUIPC (4.20 or later) disappears immediately. I can't speak for PMDG's usage. Regards Pete

Surely for the first line to get there originally, you must have rejected FSUIPC's loading at some stage? Do you know what that values on those parameters do? Why -1 and why 2? I Think the rest of that weird "filename" is some sort of hash-check so that FSX can tell when it changes, so presumably you'll get something again next time. Best to tell Windows you trust software from "Peter L. Dowson", and then you won't be bothered. I think you can do this in Internet Explorer. My next PC will have Vista 64, but I don't think it is that which is a factor here. Regards Pete

Any private (home) or freeware use of the FSUIPC interface is "legal". If you intend to make use of FSUIPC for a commercial product then we would need to discuss terms. That applies to FSUIPC3 and FSUIPC4, so, yes, FS98, FS2000, CFS1, FS2002, CFS2, FS2004 and FSX are all included. Regards Pete

As well as this, please also try 4.251, available in the FSX Downloads announcement above. I doubt if it will change anything, but then I see no reason why 4.25 changed what you had before either, so you never know. Regards Pete

No, you would only be replacing damaged modules or ones which other installers (like video driver ones, sometimes) replaced wrongly. Did you first try setting the Normal font size? Regards Pete

Sorry, can you clarify this. Are you saying you can do what you like, get all the smoothing actions, etc etc, (and WITHOUT "NoHorribleHack"), without a crash provided you don't suppress any of the wind effect options? In other words, when FSUIPC is actually doing more complicated things with the winds it works, but when these random speed and direction changes aare simply by-passed, it doesn't? Weird. Is this 3 seconds per knot/degree business relevant? Please confirm EXACTLY what you are saying here. It could be very important. Regards Pete

It stops the wind smoothing, the spurious layer correction, everything. Of course. That option is featured on the Winds and Visibility page -- you have to enable it to get any smoothing facilities. It is all clearly documented. None of this helps. We already assumed it was the wind smoothing hacks causing the problem. What concerns me is that with "NoHorribleHack=Yes" the actions going on are EXACTLY as they have been since the smoothing experiments startedweeks ago, yet to say you only got problems since 4.25. It makes no sense to me at all. Pete

Something extremely odd is going on in your system. All that parameter does is cause the Wind Smoothing system to revert to what it was before I hacked into the SIM1.DLL to find a way to stop the ASI ratcheting. Of course, because wind smoothing and all that stuff is defaulted off. Pete

Not with FSINterrogate because that can only see the data FSUIPC is getting, and I've listed all that for you in the documentation. Not since FS98 days has the FSUIPC offset list actually been just a set of addresses in a memory block. Some of it was in FS2000, much less in FS2002, almost none in FS2004, and most certainly none at all in FSX. All the stuff in the FSUIPC4 offsets, bar a couple of little hacks, is from SimConnect Variables. I can get more of those than listed, if requested, but your failures don't appear. If there's no key Event for it listed (eg in my FSX controls list, see your FSX Modules folder), then it's a Menu-only facility. In which case you can only do it via the menus. Regards Pete

No, sorry. And it isn't an area I would want to get into, now that the future looks like being with SimConnect instead. Most developers in your shoes have implemented their own TCP/IP connection to a routine in the FS server talking to FSUIPC (or SimConnect). Regards Pete

In that case the broadcasting should certainly work fine. It sounds like your PCs are not in the same workgroup. Check that (My Computer Properties, Computer Name dialogue) and change one to match the other. Looks like you need to use cut and paste, because it won't work with "SeverName" as the parameter, it needs "ServerName", as it says. Why on Earth not simply copy what it tells you then? Why do you think I give such explicit examples? I pointed you to the exact paragraph. It gave you the two lines to insert. What more could you ask for? You used the ServerName line but not the Protocol line? Why? :roll: Regards Pete

Obviousy, it tried to influence the weather in the way SimConnect provides -- by setting METARs at the surrounding WX stations. It will still do this if you enable any of the other options, like adding random turbulence, cirrus layers, visibility restrictions, and so on, and it will always try to write back METARs it reads with multiple fals spurious layers without those layers. All that presumes you enable the option for it to change FS's weather. Without that option, nothing is changed except weather being set THROUGH FSUIPC. I'm not really understanding you here. The wind smoothing now doesn't change the METARs, so you won't see what is happening -- unless you read the ambient winds at the aircraft. It is those which are being directly manipulated. They are rarely related to any specific WX station in any case. Of course. That's always been the case. If you want everyone to have the exact same conditions then no one can use any FSUIPC weather options at all. Naturally. As it was in all previous versions of FS. I would most certainly not be in favour of that at all. You should always be able to reach the extreme deflections defined for that aircraft. If those deflections are defined too great for the model, it is the aircraft configuration which needs changing. Quite right too, in my opinion. Anyway, FS's sensitivity does effectively reduce the range, which is why I always tell folks to set that to maximum if they calibrate in FSUIPC -- otherwise all they are doing is spreading a diminishing amount of axis movement to the full deflection range. Surely what you want is a flatter (less sensitive) response over the central area, going steeper at the extremes so that the maximum deflection can still be achieved. That is exactly what the slope facilities in FSUIPC are for! You really also always want to change the FS stick sensitivity mode, in FS's CFG file, as instructed in the FSUIPC user guide. Regards Pete

Right. So the Server must be running WinXP or Vista. But what is the Laptop running? If not XP or Vista you would need to add the parameters as described in the paragrpah I pointed you too. Are both PCs in the same WorkGroup? If not the same applies, as Broadcasts only go to Workgroup members. Where's the WideServer log file, please? That too is relevant you know. What instructions? You've obviously not added the ServerName and Protocol parameters, for instance. I'm sorry, I've no idea still what "Msg #14" means. Regards Pete

Sorry, I don't know how to answer you. If wind smoothing is enabled (and it is an option) it tries to smooth the wind changes at the rate defined by the user. This isn't new. It tried to do this before, by changing the winds in the WX station METARs. That wasn't very successful at all, but it did mean that if a Flight was saved, the WX file it created would have included been the changes, not the proper winds. (Ugh). The current method is almost identical to the system used in FS2000, FS2002 and FS2004. Didn't you ever have to deal with any of those? Unaffected by FSUIPC, you mean? It is not affected at all if none of the weather options are enabled -- particularly the one to change FS's own weather (even with just that enabled, FSUIPC still tries to reduce the ridiculous number of spurious wind and temperature layers FSX creates over a period of time). An unregistered user cannot enable the options, so they are in the same boat, weather-wise, as a registered user who doesn't enable any of the options. No idea, sorry. Obviously any weather option used differently by two people will result in differences. What else can I say? It always has been, it is no different now. You can write a program to disconnect axes, read the original value, scale it and write to on. You can do that directly in SimConnect or via an FSUIPC client. Regards Pete