Pete Dowson

Because by that time the tables are set up to deal with that aircraft only. If you were able to do that, you'd lose the aircraft-specific setting for that aircraft -- when you exited from the options by pressing "OK" (which is when they are saved), what would you expect to happen for the current aircraft? I did have it with such flexibility and more originally, but different folks expected different results and everyone (including me) got confused, so I made it nice and simple and clear-cut. Then it always works the same, no surprises. The best way to set al this stuff is to do everything you want to do generally, without it being aircraft-specific. Most things then apply okay to most planes. Only then do you start making specific assignments to specific planes. Then, if you add a new third party plane, you have your defaults operating naturally and only need to make specific changes. Yes of course. You can edit the stuff in the INI file as much as you like. Best to make a backup copy first, just in case. Regards Pete

Yes, of course. It's what we call "calibration". Before setting any detentes or increments, establish the minimum and maximum positions, allowing a little "dead zone" at either end to allow for jitter. If you are doing this in FSUIPC, you will find step-by-step numbered instructions for calibrating properly in the User guide. Regards Pete

Well, I suppose it must be possible, as other programs do it. I have no idea how at present, but I could no doubt look it up. But it seems odd to receive this for the first time after over seven years of WideClient availability and use. You do know you can have it totally invisible, don't you? Just set "Visible=No" in the [Config] section. Is there a particular reason for your request? What would you do with its "mini-icon" in the corner? Regards Pete

Most of those aren't continuous variables so aren't in any way affected by any attempts to gain efficiency. Of the continuous variables, as an example, you don't really need to have the AGL accurate to 1/65536ths of a metre, do you? The flap angle values are only an exception because of the apparent need to test for "special" exact values such as exactly 0.0000 ... Well, sorry, but you are looking at it the wrong way around. What I have to do, to counter all the changes between different versions of FS, is try to create compatibility -- there's actually none of it to break in the first place without all the work that goes into it. The work involved in each and every release is slow and painstaking, and much of it depends upon feedback. This is no different now, with the new methods used in FSX, than it was before. In each version I have had to find different ways of getting compatible information, and there are always some areas which are not quite right in the initial months following each new release. Without folks using, testing, observing the values and feeding back there would be many more differences continuing well into an FS version's lifetime. Believe it or not I am still occasionally told of differences between FS2002 and FS2004 values which I then rectify. Oh, and I'm not trying to "speed up FSUIPC". It makes no difference to FSUIPC. I am only trying to reduce the impact on FSX's performance, which is dismal enough as it is. I have always been engaged in such improvements in all releases, it is just that this particular one affected your program, and I agreed to fix it. Okay? Regards Pete

Hmmm. Sounds like it must have been either a corrupted DLL.XML or a Simconnect.xml installed. Glad it is sorted now! Regards Pete

You should never need a link -- as I said "above". Just scroll to the top of this Forum where all my Announcements are, and you will find Announcements of all new Interim versions. There are links to new versions, notes on changes and so on. Do you NEVER scan the Announcements? The whole point of them and this forum is to help users, but you have to look!! :-( Pete

That doesn't sound correct. The "Rudder" (which the 'R' usually stands for) is the Z rotation. The U and V would be the X and Y rotations, though which way around they'd be assigned I've no idea. There are no "rules" about this, you take what you get. Where do you see the CHTQ axes being classed as X Y Z R U V in any case? That sounds more like what I would expect. So the TQ does have these letter actually stamped on the levers? Really? How odd. Why did you decide to use FSUIPC for all the assignments? It's pretty good at doing things you cannot do in FS, but I would have thought that all the things you want can be done pretty easily using FS's own assignments? Are the assignments in FSUIPC's "Axes" tab sending FS controls and then being calibrated in FSUIPC, or are you having them sent direct to FSUIPC's calibration? I don't seem to have much information about what you are doing, and your report this time seems to bear no realtion at all to the problems you complained about before. Well, the reverse most certainly does reverse the direction of change. But that's all it does, and you need to do that first. The other axes which often need reversing are the brakes and spoilers. Er, are you saying that the flap direction is correct on the default 737, but not on the PMDG one? If so there's something mighty strange going on there. I think you need to clarify things please. Are you calibrating the flaps in FSUIPC with the detentes facilities? Let me see the [Axes] and [Joystick ...] sections form your FSUIPC.INI file, and try FSUIPC Logging -- you can log Axis controls then operate the Flaps lever and see what is happening internally. Regards Pete

That all sounds very interesting, and it does actually look like English, but I'm afraid I fail to understand very much of it at all. Sorry. If anyone can explain it to me I'd be grateful. I assume it is good, because the "hugs" bit at the end sounds friendly enough! ;-) Regards Pete

An "offset" is ismply the difference between one number and another -- the amount one is set off from the other. The numbers in the context of FSUIPC represent hypothetical memory addresses, and were originally actual addresses within FS98's "GLOBALS.DLL", which is what the original FS6IPC.DLL provided access to. So, an offset of 53 (decimal) would have then referred to a position in that DLL 53 bytes from a known "start" poiunt (actually the data linkage point inside FS98). In FS98 data representing various things inside FS were stored at different offsets within GLOBALS.DLL. So, to access those data items programs interfacing through FS6IPC provided two values -- the offset, and a size. More than one item of data might be accessed at once, and in the extreme, back then, the whole set of FS98 data could have been read by an offset of 0 and a size of about 8192. The offsets for specific data items have been maintained despite the demise of GLOBALS.DLL, by a lot of programming in FSUIPC, which is designed to maintain this illusion of a block of memory containing data. Thus particular offsets (normally known by their Hexadecimal value rather than decimal) still refer to specific data items and some have been identical, through FSUIPC's programming, all the way through FS98, FS2000, FS2002 , FS2004 and FSX (and some even CFS1 and CFS2 on the way). An index to data, ordered by their offsets, is maintained in the FSUIPC SDK. If you are a programmer, then certainly, if not then it is unlikely. Regards Pete

Ah, no I don't believe I've read that before. Maybe it was me who missed it. But thank you! It is very useful information and should certainly help others too. Regards Pete

The installation is okay, as it says, though 4.06 has been superseded by later interim versions here - up to 4.063 now.. Of course not. I am not trusted by you until you trust me. You do that in the initial security warning you get when running FSX after installing FSUIPC4. There's a drop down where you can say "trust anything by this publisher". There's no way anything of mine is going to act so maliciously as to mess with your trust list! That will be because you said to run it and add it into FSX's list. But next time you get an update for FSUIPC4 you will have to do that again. And each time you do that for every piece of software it adds a line to your FSX.CFG file. That's okay, but it isn't going to affect your trusted publisher list. And what are the earlier entries? Maybe they are in a mess and things don't get that far? In later versions ( 4.063 is downloadable above) I put the FSUIPC4 entry at the start to avoid problems with other programs or users messing that file up. Hmmm. Either the DLL.XML file is messed up, or there's a simconnect.xml file which prevents local clients, or simconnect is not correctly installed. (The latter seems to happen quite a lot). Downloading and installing FSUIPC 4.063 should fix the first two, but if the problem persists you'll need to try repairing the Simconnect installation, as described in the FSX Help announcement. Regards Pete

Found the problem. Somehow, and I have no idea how, the complete section in the Resource File for the Connection Check dialogue was missing! This resulted in the attempt to set the displayed dialogue failing, and this is then retried at intervals, with the connection checks never actually being performed. Very strange! I've fixed it and tested in in PFC verison 2.02 which I will incorporate into the PFCDLL Zip later tonight. THe update will be available here first and on the Schiratti page in due course. Thanks for telling me! Regards Pete

Not something I know much about, but have you checked these offsets? 2EF8 CG percent, as a double (FLOAT64). This is probably the position of the actual CoG as a % of MAC (?) 2F10 CG_MAX_MACH 2F18 CG_MIN_MACH The fuel can be changed and it does have the desired effects. The payload can be changed but this has no proper effects in FS2004 until you enter the payload menu dialogue and okay it. I think in FSX that should be fixed, but I don't have confirmation at present. Regards Pete

Okay, thanksI'll check it here. Regards Pete

There's been no change in how all that works for many versions, dating back at least a year. What were you using before? Are you sure you haven't opted to bypass the connection checks (it's an option in the main page) -- if you have the checks will only appear if the COM port can't be opened, so you can select another. What FS version are you using and are you running full screen or Windowed? What does the PFC.LOG show (it is in the FS Modules folder). Regards Pete

No problem, glad you are all sorted! Pete

These are really old facilities aimed at programmers, who would have ready reference to those Windows Message values and parameters. You can look them up on the Windows sites if you don't have a compiler system for Windows, but really you'd be far better off using the much easier FSUIPC controls provided. First, are you sure it's a keystroke you need and not a Control? What are you wanting to do? If you do need a keystroke, you can send FSUIPC-added controls via offset 3110 to do the same thing, only making FSUIPC do the complicated parts for you. Look in the Advanced User's guide for FSUIPC and find the controls numbered 1070, 1071 and 1072. These equate to the three "Key Press" controls assignable in FSUIPC's Buttons drop-downs for FS controls. The Advanced Guide also gives you the Key and Shift codes you need. Regards Pete

You'll need to spell out exactly where you've assigned what. It sounds as if you have the axis assigned in more than one place. Are you using FSUIPC's "Axis assignments" facility, or FS's Assignments, or both? It sounds like you are using both. Not a good idea. It certainly sounds like you are trying to use both. You need to choose one or the other, or else be very very careful not to assign the same axis in both places. In that case what you are calling the "V" axis IS the "R" axis. Why do you think it's "V"? Is that stamped on the lever? What else, other than FSUIPC, uses those XYZRUV names? FS and Game Controllers certainly don't, normally, as they use DirectInput. Only the little "joyview" test program from Thrustmaster uses the old Windows API nomenclature, outside of FSUIPC. If FSUIPC recognises it as R, it is R. I think you need to explain how you are identifying that "V" axis as V, when it is clearly R! Regards Pete

Hmmm. I thought those were both the same, but maybe the former sends a CLOSE message long enough before the EXIT control gets obeyed to make it work, sometimes at least. Do you have FS asking for confirmation of the closure? If so it maybe that -- it will give time for the Save to work, but of course if you then decline to end the session it won't be the final state. There's a third way to terminate too -- CTRL+C -- which is the FS "EXIT" control, a shortcut really for the menu entry. Unfortunately, none of these methods seem to give me that final flight here. Regards Pete

Oh, right .. I'll report this too. Thanks! Pete

Ha!! It used to be the other way around -- that FSUIPC4 was better first, though the Installer added it to the end. To get around that I delayed the start of FSUIPC's initialisation. So what is happening now is the initialisations are occurring together again! :-( This is a serious SimConnect bug which I darn well hope gets fixed pretty quickly as it is a real pain the the butt! The installer puts the entry at the top now then tidies up the rest, adding correct terminators when missing, to get over some serious editing errors made by users and other installers. It was the best way to get a correct DLL.XML file, or at least correct as far as the FSUIP4 entry. I'm not going to change it back again now. You can get FSUIPC4 to initialise itself immediately, as it did in the first place, by adding StartImmediately=Yes to the [General] section of the INI file. Er, no, I'm sure you must mean 4.06, because the change to rebuild the DLL.XML file went in at version 4.061 (please check the History document). Eryou actually get one? I kept trying to make that work, but I cannot create one just before FSX closes, which is where I really want one. It does try -- on the EXIT control, and a SimConnect 'Quit' message, and on a CLOSE message being sent to my Window, but none of this works on either of my FSX installations -- FSX closes too quickly, after I send the Save Flight request to Simconnect, but before simconnect sends it on to FSX. This is why it isn't documented, as I didn't think it worked at all. Can you tell me how you close FSX please? Regards Pete

Is that all? Odd to choose one of 8 possible flap angle indicators just for that. And even the percent values (30E0 and following) should be more speciific. The traditional values for such basics are those at 0BE0 and 0BE4, which have been valid and guaranteed since FS98 days. All the values above 2000 are extras which really need feedback to prove okay. I'll change it to be more accurate, but these sorts of things are overheads in FSX, as they depend on TCP messages arriving from SimConnect. In previous versions of FS these offsets were simply mapped through to memory locations inside FS. For most real-world values, the general philosphy should probably be to treat values in "ranges". In this case 17/256ths of a degree is as good as "flaps up", for instance. Anyway, I'll fix it, so look out for 4.064 or maybe 4.07 in due course, maybe a few days. Regards Pete

Ah. As part of the changes I've been making to speed up FSX when FSUIPC4 is installed, I tell SimConnect not to send changes of less than some specified significance. The Flap angles at 30F0 and following are in degrees x 256, but I don't currently get notified of changes of less than a degree. I can change that, but it seems excessive to be notified of every change of 1/256th of a degree. I'll change these to be more accurate, but can you tell me what you need these for, exactly, and why a value of 17 (representing about a sixteenth of a degree) is a problem? There may be many other variables like this, but I have no idea who uses what and how. The more traditional (since FS98) flap indications down at 0BE0 etc are working okay. Regards Pete

Haven't you tried 4.063 available above? I pretty sure I fixed it way back in version 4.061, directly after the reports above! Pete

Can you not buy it as Eduardo Passos? The WideFS registration is checked in the Server part, not the Client, so it is a function of the specific FS installation. If you do so and still have difficulty (but I don't think you will) just send me both sets of details (to petedowson@btconnect.com). Regards Pete