Pete Dowson

Eryou mean MOVE the detentes? Change the number of flap detentes or change the angle? Sorry, I'm lostI know of no way of changing any of that. It is pre-defined in the Aircraft.CFG file, or possibly for old versions the AIR file, surely? I'd like to know how to do that in order to make my flap operation mask facility work better. Please, tell me how you manage to separate these things. You are doing this from an external program, or is this a Gauge or DLL? If you are actually writing a program to do these things, why not just read the relevant joystick axis yourself, using joyGetPosEx, same as FSUIPC does? If this is from a Gauge or DLL internal to FS actually controlling your own graphics lever, why not simply assign your flaps axis to a different, otherwise unused FS axis control, monitor that via the built-in PANELS facility for doing such things (register_key_event_handler), move your lever accordingly and IF the flaps should be working okay, send on the appropriate flaps operation by trigger_key_event? I think RAW values are more usually in the 0-255 sort of area. Check by setting the RAW option in FSUIPC Axis Calibrations. Scaling is part of Windows calibration, scaled values are those read normaly. The joyGetPosEx facilities will only provide RAW or Calibrated for all 6 axes on a joystick, you can't mix them, so you might be limited as to which mode according to how the others are being used. Ah. So you are writing a gauge/panel? I therefore really don't understand the requirement of FSUIPC. If you are writing a program which is running in FS, why not simply read the axis yourself? Anyway, after sleeping on my idea I decided it was too messy. If I were to do it (if I could see the need, which now I can't), now that I know it is for programmatic use, not for some existing interface program, I think I would opt to implement is all via offset writes and reads, like the FSUIPC HotButton facility. You would register an intrest in an axis and FSUIPC would scan it for you and return regular updates. However, all it would be doing for you is sending a joyGetPosEx function to Windows, so I'm not sure it is useful UNLESS the application is running externally and therefore possibly on another PC, via WideFS. Regards Pete

Since nothing whatsoever has changed in the Client end of things, the above error must surely also occur on the same PC with the same WideClient and the same INI settings whether ot not you run FS9 or FSX. In fact WideClient doesn't even know whether you are going to be using FS9 or FSX or even FS98 at the the time it tries to open the COM port. In this particular example "Port=WideFS" on the Client could never have possibly worked on FS9 either. In the Client INI you must tell it which COM port to send the data to. It cannot open a port called "WideFS"! The WideFS setting is for GPSout, to tell it to send it to Wideclient instead of a COM port. What WideClient are you expecting WideClient to send it to? If you had it all working on FS9 why did you change the Client end at all? Regards Pete

It won't be the latest then. That was released last week. ;-) No. It doesn't seem to here, or at least I've never noticed them missing (though there's usualy such a lot going on at final approach, with RC and AI to contend with, that I may simply not have noticed). The patches which it applies are actually in no way related to marker sounds, or markers at all. However, the patches were arrived at by experiment, to find a way to avoid crashing FS9, so I suppose there's a possibility that there are side effects. After all I am making the ATC part bypass some code. I just don't see how the ATC stuff affects markers -- unlike COM frequencies, of course, which play a major part in the ATC operation. There's really nothing I can do about it either way. The patches are at the very last place possible to stop the condition which causes the crash. Microsoft know all about what causes the crash, and say it is fixed in FSX, but they were not willing to help me devise a certain work-around for FS9. Sorry. Regards Pete P.S. I assume you have checked that the marker sound switch is not "off" in the radio switch gauge?

This is "Pete Dowson's FS Modules" forum, as you can see from its name. Not "Pete Dawson" -- you only needed to see the name at the top to know you'd contact me here, without getting the name wrong of course ;-) Are you saying that somehow FSHotSeat makes FS9 play the sounds? Are you sure? I don't know how it does that. Most programs which play sounds do so themselves, using WAV files or similar. Check the FSHotSeat folders, whatever, for the sound files. Does FSHotSeat install any DLLs or Gauges into FS? If it needs such internal support for its actions, other than FSUIPC of course, then it will not work in FSX of course as the internals have changed considerably. I am pretty sure that it will be only using FSUIPC to obtain the AI traffic details - their states, positions, and so on. It should then surely be simply playing the sounds as appropriate. The FSX version of FSUIPC (FSUIPC4) provides all of the same AI Traffic information as FSUIPC3 did for FS2004 and FS2002. It is compatible in all these matters. I really know nothing about making sounds in FS -- there are no facilities in FSUIPC for creating sounds at all. There was a module called FSSounds.DLL or similar. Does it use that? If so you'd need someone to produce an FSX version of that module. Regards Pete

Thanks very much to you, I found it and fixed it. I'll work on releasing 4.05 tomorrow, as I feel this is serious enough to warrant an update. The cause appears to be simple, but quite tricky to identify. In all my FSX installations (and I've actually tried one again to cross-check), the path which gets put into the Registry is SetupPath="......" i.e. the correct path, but ending in a '\' character. In your case: C:\Games\FSX\ would have worked okay. The omission of the expected final '\' causes the derivation of the other pathnames from this root to go wrong. I've now changed the code so that it works happily with or without that final '\' character. There are some other changes I've been making, in FSUIPC4.DLL itself, which I need to test, then I'll release 4.05. It may be Thursday or Friday by then. Thanks again for reporting this. Regards Pete

Not at present, at least not without writing a program to do it. Oddly enough it has never been requested. Out of usable axes? That doesn't sound possible! Even FSUIPC calibrates over 40 and there are others that can set values like axes. Perhaps you could explain what you want to do so I can suggest solutions? Looking at what could be done otherwise to meet your perceived solution, the only thing I can think of off the top of my head would be the possibility of expanding the Axis Assignment section, right-hand side, where you can assign controls to ranges of axis movement. At present you can assign any control there, including the FSUIPC Offset setting controls. Normally the parameter this takes would be fixed, but supposing I allowed a special entry for the parameter, say * (an asterisk), to mean "this axis value", and, even more special, for this to operate as long as the axis value is changing within that range? (Normally there are only the entry and exit events). The simplest case would be a single range from one axis extreme to the other, in both directions, assigned to the Offset Word Set with parameter *. This is only a first thought, and it may seem a bit contrived, but there's nowhere else where it would fit without a lot more work. BTW are you talking about FS9 or FSX or both at present? Regards Pete

I'm Peter Dowson. Did you really mean me?? Does it need one? What is it doing which is specifically FS version dependent? Into fSX? Where do they get installed in FS9, for instance? I don't quite follow. I thought FSHotSeat played its own sounds, not added them into FS's repetoire? I don't know a Pete Dawson, but as Pete Dowson I certainly know nothing about FSHotSeat, but all about FSUIPC. I'm really not sure what you are asking of me. I have no idea what FSHotSeat needs which is FS version dependent. You will need to be more explicit please. Regards Pete

Yes, thanks. I see what it is doing, but I don't know why yet -- it isn't consistent. That is what is so puzzling. I do see what it is doing, but I need to understand why it is behaving differently here. No, I don't want you to change anything, only confirm that the Installer was reading the SetupPath correctly, which you've done. I'm going to temporarily change my SetupPath to match and trace through the code path. I'm sure I'll have it fixed in the morning. Thanks! Pete

Have you moved FSX after installing it, or re-installed Windows, or rolled back the Registry at all? Otherwise I don't understand why your Registry doesn't have the "SetupPath" entry for FSX, pointing to any folder at all. Hmm. Yes, that's odd -- it seems to have lost the FSX path from the constructed final path. I'll check that here. It was certainly doing it correctly on an earlier version. It is difficult to re-test all the combinations, especially when many of them do require an incorrect FSX installation. The main problem is that the SetupPath isn't in your Registry, or it isn't where it might be expected. The installer uses that to locate FSX correctly. If you are familiar with RegEdit for looking at and editing the Registry I can tell you where to look and maybe you can tell me what's in your Registry relating to FSX so I can understand why it is wrong. Meanwhile, I'll look at the Installer itself to see what it dropped the FSX part of the path. But it'll be tomorrow (Wednesday) now. You should be able to simply move that Modules folder into the main FSX folder (drag and drop in Explorer) to get you going for now, but please let me know about the Registry and how you may have got FSX into this state, please. Regards Pete

Sorry, I don't really know what you are talking about. All the FS values supported in FSUIPC offsets are detailed in the FSUIPC SDK documentation. Please look there. If you cannot find what you want there then it probably isn't supported by FS, or it is by another name. Please don't send me any photos. I don't know anything about helicopters in any case. Sorry. you need to find out what information it is you want, then see if it is available. Regards Pete

Good! Thanks for letting me know. It is strange, but I've never heard of a need to change that value before. It's something for me to think about -- in the recent WideFS documentation update I've more or less relegated all that to a Technical document not really meant to be used much, hopefully. Maybe I ought ot mention your problem and solution more prominently in the Troubleshooting section at least. Regards Pete

The correct numbers are 7.04 and 6.71. Is it getting the decimal point in the wrong place? I'll check that here..... No, it certainly should see it as 7.04, not .704. Apart from that, since the Version 6 Wideclient will always be used with the Version 6 or 7 Server, maybe Enrico needs to take the mismatch comment itself out. On FSX the Server code is part of FSUIPC4, so its number willl reflect that of its host code, even if the actual Server part doesn't change. It is too intricately related to not change the number. Regards Pete

So you DO have the checkbox enabling FS weather to be changed set? Sorry, but it still isn't clear from what you say. This is contradictory to what others have reported, but it may be down to some of these FSX weather peculiarities I mentioned. How have you got the FSX weather changes slider? That may make a difference. Also, I don't think the weather overrides work with themes -- are you using downloaded weather or your own specifically set weather? Finally, how long are you waiting for the weather to change, and do you look all around you, not just out of the froont window? I've noticed that even if I go into FSX's weather menu and set clouds, they don't seem to appear very quickly looking forward, but if I look to the side or behind there are lots of clouds already drawing! It is all very peculiar. I think some similar strange things happen with the visibility. If you enable Weather logging in FSUIPC4, then try again, wait a while, then look at the log. You will see that FSUIPC4 is reading the weather from up to 9 stations around the aircraft, modifying the weather so read, and writing it back. It does this over a period of many seconds (all 9 may not be set for 20-40 seconds) to avoid any noticeable performance hit or stutter, and repeats regularly round the 9 stations which of course may be changing as you fly. The format is a sort of enhanced METAR, but the visibility parts are pretty standard. You will be able to see what it is trying to do. When I do that I notice several things: 1. The weather being read starts off looking sensible, but gradually becomes rather odd. Some parts suffer definite erros, like visibilities of 0000 being read back - I actually put in a detection for that so I don't send it back. 2. Often FSX only seems to obey parts of the METAR being sent back, even though most is the same (albeit necessarily in a different form -- see below *). It seems to make inexplicable changes. 3. It is often very hard indeed to relate any of the weather being reported by the surrounding stations to that actually experienced at the aircraft, looking out of the window or reading the values on gauges. * As if reading METARs wasn't difficult enough, Microsoft implemented a different format for those METARs when reading weather to that it demands when writing it! This is subject of ongoing negotiation, as it isn't at all satisfactory I'm afraid. No, more a stage of development of FSX. The weather interface it presents is by no means finished. Probably not, but that is more difficult to answer because with FSX I don't know what to expect. Possibly with different weather settings in FSX you might get what you expect, as others have done. By checking the Log as above you can see if FSUIPC4 is doing what you might expect, and you can see how FSX responds. Whether that is then reflected in what you see out of the window seems to be rather variable at present. Some folks are saying it works okay (which isn't often my experience) but I think you are the first to say it does nothing at all. I think those happiest with FSX's weather at present are those using ActiveSky or FSMeteo. You'd then want to uncheck the option in the Miscallaneous tab. Regards Pete

Well, that's rather an extreme statement. They certainly don't work as well as I'd like, as the underlying support in FSX isn't yet working. The results they produce are sometimes not quite as one would expect, and occasionally seem to be downright weird. What external weather program are you using? If you are wanting it all to work with FSX's own weather, you need to enable that. Because of the odd effects of applying some of the options, the action to apply any of them to FS's own default weather is disabled initially. There's a check mark on the Miscellaneous tab in FSUIP4 options to enable it. Each of the Weather-related sections in the User Guide does mention this. For instance in the Visibility section it states this in the second paragraph: I have high hopes of real improvements to come in the weather handling, but it needs an FSX update. Unfortunately, given the other problems discovered in Simconnect since FSX was released I suspect that the improvements we need in such facilities will have to take second place, so I have no idea what sort of timescale we are looking at. Regards Pete

There's no such thing built into FS, so it must be implemented by programming in the Gauge software itself. It may be done by using the elevator and aileron trim facilities, but if it is using the standard FS A/P it would be trying to compensate. So either the whole A/P is being programmed in the Gauge software, or it is merely changing the V/S in Altitude Acquire mode (for pitch) or the Heading bug (for bank). When panel programmers introduce non-standard (i.e. non-FS) functions, they can do it via mouse or by keyboard or (as in the PMDG panel case) both. They normally cannot do it by using FS controls, since of course the appropriate ones do not exist (these are non-FS functions). It would be possible for them to borrow otherwise unused FS controls, but I suspect they feel that mouse and keyboard support should be adequate. If the panel supports keyboard shortcuts for those mousable operations, then you can program joystick/cockpit buttons to produce those keypresses. If the panel does not, and only supports mouse operations for those functions then the only solution I know is to use something like Key2Mouse by Luciano Napolitano (the WidevieW author). Regards Pete

Please just download and install the current version (4.04) of FSUIPC4. As noted in the Announcements above: It really is best to scan the Announcements for changes from time to time -- especially if you have any problems. I do always change the Date in the title so you can see when there is something new to read. Regards Pete

Hmmm, only if you hadn't updated your FSUIPC.DLL for "many months", it says. That "many" adjective really stretches to about 36 or so now -- the INI file has been substantially the same throughout the life of Version 3, and the program itself deletes anything which is no longer supported in any case. The main reason for removing an earlier INI file would be if you got something like the Joystick calibrations or buttons programming in a mess and wanted to start afresh. Regards Pete

Sounds like the only possible explanation! ;-) Regards Pete

Strange, though. Thanks for letting us know. Pete

That couldn't have changed anything, I'm afraid you are fooling yourself somehow. WideServer.INI is not used at all in FSX -- that is only used with WideServer.DLL, which isn't used on FSX. You shouldn't have copied ANYTHING whatsoever from the WideFS.ZIP into the FSX modules folder, though it won't matter -- it'll all be entirely ignored. In FSX, WideServer is built into FSUIPC4.DLL, and the INI parameters are included in a [WideServer] section in the FSUIPC4.INI file. And in any case if the INI parameters are missing the same defaults as supplied are assumed. Pete

No, of course not. Why are you re-registering in any case? Have you moved to a new PC or re-installed Windows? If you are simply updating from one version 3 to another version 3 you simply copy in the new DLL, exactly as per instructions. That's it, nothing else to do, your registration stands. If you are trying to re-register and it isn't being accepted then you are entering something wrong. All three parts MUST be absolutely identical to the original registration, as notified. Regards Pete

Probably give up and wait for MS to release a fix I expect. I don't think any of the SimConnect problems are really as common as they may seem to be, scanning a Forum like this. There will be many thousands of successes. I myself have so far installed FSX on five different PCs, some with only WinXP's security stuff operating, at least two with the full Norton, and one with Kaspersky Antivirus pre-installed and operating, and I've seen no problems with installs, uninstalls (of Betas), nothing like that. On the other hand, like everyone else, I'm having dire problems with FSX performance unless I cut way back on nearly all settings; on two PCs I get odd "crashes" to the Task Bar for no apparent reason (FSX is still happily running, but you can open a window or screen to see it!); switching between full screen and windowed or vice versa is precarious and often seems to hang (that one is reminiscent of early FS2004 problems); and on all the PCs I've got FSX has a tendency to hang quite easily when night flying. Weird. Day time flying seems to be the rule for now. And all these things have occurred with and without any add-ons or add-ins, so it isn't all SimConnect at all. All I can say is it is a good job I've not yet deleted FS2004! ;-) Regards Pete

The ILS frequencies are in the R4.CSV file it produces (and in the R5.CSV file the latest verdion also produces). I think it's the 7th parameter on each line, isn't it? Didn't you look? It's also the last parameter on each line in the "runways.csv" file. The runway heading and MagVar is also there, but not the ILs heading which may be different if offset (as at Innsbruck, for example). Pete

Oh, right .... shows how much I know. They don't actually TELL me these things! I can get copies of what looks like an emailed receipt including keys. I thought it was the same. Thanks for the clarification! Sorry Jean-Jacques! I'll know for next time! Regards Pete

The email contained NO keys? Are you sure? I have a copy here and it has the keysSimMarket have never got it wrong before. It an email about ORDER #: 289373, wasn't it? After the Quantity line, there's three lines for Register Code, with your Name, Email and the two keys. Then the price and shipping cost (0.00 of course). Please take another look! This is very worrying -- an automated system such as the one they are using shouldn't throw out an odd email as you are suggesting. If it can there may be more serious errors. Don't show it here, but if you are sure you cannot see the Keys in the Email, please sent a copy of it to me at petedowson@btconnect.com, so I can take it up with SimMarket. Regards Pete