Pete Dowson

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

What's "Msg #14"? I would have thought it would be only polite to actually enter some text in your message, not just baldly shove a log file under my nose and expect miracles! After all, don't you want to provide any other information at all to explain why you don't know what the problem is? After all the log does actually tell you what is wrong, if you look at it -- see above! It "needs details from Server Broadcast" because it hasn't been told where to connect to. If it isn't receiving broadcasts then either the Server or the Client is running an older operating system which didn't support them, or they are in different Windows workgroups. Since you don't tell me anything about either PC, nor even what version of FS you are trying to use, I can't say much more about why it isn't seeing them. Read the section in the WideFS User Guide entitle "Configure your network", and especially note paragraph 3 in that section. Next time you ask for help please bring rather more useful data with you, please, and maybe a few words of explanation. Pete

First an aside. Why do so many folks mis-spell the easy English word "definite" as "definate"? It seems to be happening more and more these days. Has someone spread a bad dictionary around? I run ASX on a remote PC. FSX + ASX + FSUIPC4 have been running here most of the day quite happily. If I could reproduce it I could investigate, but I'm sorry, I can't. And so far you are the only one who can -- I think there are many others using ASX with 4.25. One thing I do note: You are using SP2 rather than Acceleration. I've only got one PC with that version. I'll try that tomorrow. I wonder if all of the other testers/users running ASX are also using Acceleration? Maybe you hadn't previously actually tried the only Beta which worked with full smoothing on SP2? Certainly most of the full smoothing tests have been with Acceleration installed - until 4.241 the SP2, SP1 and RTM versions of FSX didn't have full smoothing enabled, only partial -- and 4.241 was the last Beta before 4.25. I tell you what you can try: add the line NoHorribleHack=Yes to the [General] section of the FSUIPC4.INI file, and try again. That stops the hooking and blistering I do with SIM1.DLL, and effectively makes 4.25 act just like the Betas prior to 4.241 did on SP2 or before. The Log will indicate you only have partial smoothing, and the wind changes will probably cause some ratcheting on the ASI etc. Let me know. Meanwhile, tomorrow I'll try to set up ASX linking to my only PC still running FSX + SP2. Regards Pete

If it only lists 4 joysticks, and none of them the throttle quadrants, where are you seeing the two throttle levers you are seeing? I don't understand. In your axis assignments in FSUIPC you had these listed: [Axes] 0=0X,1,D,11,0,0,0 1=0Y,1,D,12,0,0,0 2=0Z,256,D,23,0,0,0 3=1Z,256,D,22,0,0,0 4=1R,1,D,10,0,0,0 5=1U,1,D,9,0,0,0 and all those (X Y Z R and U) axes are always recognised in the standard Windows joystick API (there's also a "V"). The joystick numbers, 0 and 1, correspond to the first two entries in the Joyview list - they'll be numbered 1 and 2 there I can see from the above that your throttle levers are: 1 U = Throttle 1 1 R = Throttle 2 0 X = Throttle 3 0 Y = Throttle 4 You also have the Delta set to 1 for all those -- not really recommmended. That could make FS spend all its time reading the joysticks. I thought you said you'd restored them to 256. Not sure why you would fiddle with such things in any case? Joyview might not get the names of your devices, that's not relevant, but it most certainly should see the values being received from them. When you open up the relevant joysticks (click the little +) then select "joyGetPosEx(), it shows you all 6 axes (X Y Z R U V), the 32 buttons (as a 32-bit value) and the POV hat. As you move the axes you should see the values change. That's the whole point. And you still haven't confirmed that you've calibrated these axes in Windows! Regards Pete

Thank you. I 'm really glad all this stuff is so appreciated and so well used. Carry on the good flying, may it last a long long time! Regards Pete

This is normally the result of having a ComCtl32.DLL windows library, probably installed by a video driver installer, which is a mismatch for the main graphics library part of the Windows update level you are using. FSUIPC does not "size" its windows at all. That is all done according to font and system settings in Windows, and it not under FSUIPC control at all. You might be able to get it looking right by going into your desktop settings (right click on a blank part of the desktop, Properties-Appearance) and choosing a more normal font size ("normal" being best, usually). If that doesn't work then I'm afraid it may be a matter of trying to repair your Windows installation -- the ComCtl32.dll from the Windows installation disks is needed. Regards Pete

That is bad. What are the actual values from the axes (the "IN" values) [Oh, it's okay -- I see yoou've given then further down]. You don't need to run FSUIPC to check these values. Try the little Joyview program attached. If those truly are the limit values, and your slopes are all set to 0 (linear, not curved), then all FSUIPC is doing is scaling the incoming values to the values needed for FS, which are 0-16384. So it is effectively simply halving them and adding 8192 to make them positive. Well, you can immediately see the problem I hope. Your throttles 3 and 4 are giving totally different input values, even though the limits are the same! That's really bad! There's nothing FSUIPC can do to change the INPUT values -- those are coming from your devices, or at least their drivers. Seems that the calibration needed there is in Windows Controllers (i.e. the Saitek drivers). Check the input values in Joyview, attached. Regards Pete joyview.zip