Pete Dowson

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

Can you try again now, please? The SimMarket Manager says it should now be fixed. He also did say that "there can't be many simmers over there as it is the first time he's heard about the problem in all these years too!" ;-) Thank you for pointing it out! Regards Pete

If you check the log you'll probably find that it is actually disappearing and re-initialising the SimConnect connection when messages from SimConnect dry up! If that happens there will actually be little intervals of 2-5 seconds with no FSUIPC4 service. I hope all this will be cleared up in the first update MS issue for FSX! Regards Pete

strange, then, no one has mentioned this in the three years plus my modules have been selling there -- you'd think someone in the Isle of Man would have been a customer of SimMarket some time over the years. I ask the management. No, the method isn't email, but by raising a "problem ticket" on the web. I'll let you know what the manager says ... Pete

What would that say, then? "Look folks, you may get a virus warning from any of my files, in fact just about any compressed or Zipped files you may ever download. Some of those warnings will prove false, and such is the case with any of my files as of course you can always trust me and my suppliers ..." What good is that? If someone takes one of my files, adds a virus to it and supplies it, then you'll also get a genuine virus warning. The same applies to any and all possible downloads. All I can do is make sure my programs do not run if they are tampered with. I cannot guarantee that for any others, nor can I predict what may trigger a virus checker or not. my files are changing all the time in any case. In all the versions of all the files I've ever provided, only two or three have ever provoked any such warning and then in only one or two virus checkers. There's no way I'm going to "assure" folks their virus checker is lying, nor can I prevent the virus checker programs from doing a suspect job. WideFS 6.71 has been available for a month now and downloaded by thousands. Yours is the only report of it triggering a virus checker. Sorry. It's one of those cases of buyer beware, I can't do it from this end nor can I give absolute guarantees except as above. Any general statement would be totally misleading, and since it only applies to a very very small minority of virus checkers and their particular update levels, file versions and file contents it is hardly something to worry anyone. Pete

It sounds like SimConnect is not properly installed then. I can only suggest trying to re-install it -- see the FSX help at the top of the Forum. If you do choose to reinstall FSX completely, do the deletion of that Simconnect path first, as I don't think the FSX uninstall cleans that up at all. Regards Pete

Erin the extreme that would mean they would virtually not move at all over most of the range of the stick, so I really don't understand how you can get them "moving too easily". In that case they are not actually assigned in FSUIPC's axis assignments. You cannot have them active in both places and assume they will work. If the axes are assigned in FSUIPC's Axis assignments dialog for direction to FSUIPC's calibration, the Calibration part will show "direct" for that axis. If it doesn't then you've not actually assigned them. Were you using FSUIPC's axis assignments before version 4.062? You do realise that 4.061/2 have experimental DirectInput changes included, and were placed here for testing? You should know that there's a problem of them not "sticking" in 4.062 (see http://forums.simflight.com/viewtopic.php?t=58407 ) unless you do a scan each FSX session. I now have confirmation that this is fixed in 4.063 which I'll post here later today. Regards Pete