Pete Dowson

What "modules" folder do you find outside FS's folder set? Which version of FSUIPC are you talking about, please? If you mean the version 3.93 installer just released, then that finds FS via the Registry. Why do you think you shouldn't copy? The installer remembers absolutely nothing whatsoever. It only goes by the Registry entries which point to each of your FS installations. What "temp" files? Nothing about FSUIPC or its installer makes any Temp files at all. What does that mean? There is nothing possible to stop installation. What does the log show? I really have no idea what you are talking about here. Please provide more information. The version of IE is totally irrelevant, and XP home never gives any access problems. 1. Version of FSUIPC 2. The installer log, which is either saved in the Modules folder, or can be saved from the on-screen display -- as in fact the instructions provided request. It sounds like your registry entry for FS does not actually point to your true FS installation. How did that arise? There are freeware programs available to fix the registry -- in fact, if you don't do that, you will find it a problem with other add-ons. Why did you reach that false conclusion that you cannot copy files? I really don't know how you arrived at that. Very puzzling. They are just files. Regards Pete

Let me get this straight: everything was okay before you reinstalled FSX? Did you try uninstalling it first. Can you describe exactly what you did? This: indicates that your FSX installation is broken. The side-by-side libraries providing the SimConnect interface are somehow disconnected. Are you running just the basic FSX, or FSX + SP1, or FSX + SP1 + SP2, or FSX + Acceleration? In each case, when installing, you should run FSX between each stage of the update so that the next update stage finds all the right files in the right places. Depending on what version of FSX you are dealing with, you really need to repair the SimConnect part of the installation. This may be more easily done by uninstalling FSX, then deleting the SimConnect WniSxS folders (see the FSX Help announcement above for help in finding these) and re-installing everything properly. Almost all the SimConnect problems folks get into seem to arise from attempts at re-installing things. It seems to always create more problems than it solves, unfortunately. Regards Pete

You most certainly have a corrupted download, then. You should have tried downloading it again -- many thousands have unzipped it with no problem. You are the only one to report otherwise, so it certainly isn't the file. Anyway, which ZIP file are you talking about? not the old 3.90 version still, superseded by 3.93? Regards Pete

Yes, but that was just placed there just a short time beforehand so that it could automatically fix the GlobalSign root should the signature check on FSUIPC.DLL fail. The installer would automatically run that program, then re-check the signature. Either way, the program is redundant afterwards -- if you read the whole log you'll see what is actually happening. Things are a lot more sophisticated than merely copying files into as folder, and a lot more than most users will accomplish should they get into problems! Pete

1. I had to move to the Installer method as too many folks were getting into trouble with Vista and Win7 installations, where FS's default installation goes into Program Files folders which are protected, and where, unless they run Explorer in "elevated admin mode" they only see the aliassed folders, where changes aren't effected. 2. Similar considerations applied to the registration process, whilst from an Installer it is easy. 3. Nothing is deleted! Why do you even suspect such a thing? You can, true, remove Registration if you like (to help those who succombed to temptastion and tried using one of the pirated keys floating about), but otherwise files are only replaced, as they should be! 4. For the next release I am already planning to install the documents separately, into an "FSUIPC" folder, but this version of the installer was an urgent release because of user problems. I always try to help, not hinder. The installer is derived, quickly, from the FSUIPC4 one which has to create its own dedicated "Modules" folder in any case, so putting everything in one place was sensible. All the extras and goodies are available in the Updates and Goodies Announcement here in the Forum where they've been now for years. It seemed pointless automatically lumbering folks with them in the install, especially when they remain unchanged from release to release. The shorter explanatory document included in the ZIP does tell you this. Regards Pete

I assume you mean "brake" (the thing that slows airplanes on the ground, and cars and bikes) rather than "break" which is a gap or a hole or a bug in something broken. Brake axes on pedals are nearly always reversed -- they go from high value (full on) to zero (off) as you press them, so always need reversing before calibrating. Sounds like the MD11 needs a lot more brake pressure to release the parking brake than you are applying. Either you haven't calibrated AFTER selecting REV in order to ensure you get maximum braking when you press fully, or you aren't pressing hard enough. Always allow some space at the extremes in order to ensure you get full off and full on results despite axis variations. If you follow the calibration steps in the FSUIPC user guide you will achieve this. In the only calibration section you have it looks like you've not bothered to calibrate the brakes at all, as those figures certainly look like the defaults. They are not only unlikely to apply, but it means you've left no dead zones at either end. I note that you have three Axes sections, presumably because you have different axis assignments for each of the two MD11's and another set for other aircraft, yet you have only one Calibration section for all. That doesn't make a lot of sense really. Furthermore, although you've assigned all the axes directly to FSUIPC's calibration, the ONLY axes then calibrated (although only to default settings) are the brakes -- none of the others are being handled, so what's the point of assigning them? Regards Pete

Okay. Thanks for letting me know. Good that you nailed it! Regards Pete

You shouldn't need to do that, unless you aren't using a fully updated install of FSX. FSUIPC4 and SimConnect use pipes, not TCP/IP, since FSX SP2 or Acceleration. No idea without more information. Please show me the FSUIPC4 Install log, which you'll find in the FSX Modules folder. Also, see if there is an FSUIPC4.LOG file -- if so, show me that too. Please also ALWAYS state version numbers. Regards Pete

Whilst I'm sure FSCommander can be used via the network, as it is an FSUIPC client application, most certainly FSNav cannot be, and it is an FS Module which runs inside FS and doesn't use or have anything to do with FSUIPC at all. I expect FSCommander builds its database by scanning the files, especially the scenery, in your FS installation. It might be able to do it across a Network -- in which case the path to FS would be the path to FS on your other PC (a Network path like \\computername\..., to a folder shared correctly on the FS PC). This communication is via Windows, it is nothing whatsoever to do with FSUIPC and WideFS. However, I expect it would be much faster to also install FSCommander on the FS PC, generate the data base there, then copy it over to the Client. Questions about all this should be answered somewhere in FSCommander's documentation, help, or on its website. Else ask them for Support. I'm afraid I don't have and have never used FSCommander, so I cannot help further. Regards Pete

Okayactually I just experimented with installing FS9 onto my otherwise FSX-dedicated W7 64-bit system, to see what was going on. When you say: this is perfectly correct, but all of the "Wow" stuff is to do with ongoing compatibility. When the FSUIPC Installer does this: it does find it, in that "Wow" place, because Vista and Win7 map it correctly. A bit of Googling and I found this partial explanation: "WOW stands for "Windows on Windows". In the 32-bit NT days, Windows used WOW to support 16-bit software through a process of "thunking" in which an application's 16-bit calls were translated to talk to 32-bit DLLs". I think Vista and Win7 64 are using similar mechanisms for 32-bit compatibility. But they still have to auto-translate references to the 32-bit entries otherwise they have no true compatibility -- things will fail to run correctly all over the place. ;-) Regards Pete

You can't really do that, unless they use the same Gauge (.GAU) or DLL (.DLL) module, because they are linked to it by a reference parameter. Additionally the macro entry numbers (line numbers) must be contiguous and correct, of course. The TAB key only checks the macro details you set BEFORE they are written to the file. The assignment of buttons or keys is completely dependent on macro filename and macro name, which are encoded numerically according to the file number in [MacroFiles] and the line number in the referenced .MCRO file. Well, not so much alphanumeric order -- the macro numbers need to be contiguous, but it is more the cross-referencing between macro file, macro number and GAU or DLL module which needs to be correct. All of that is encoded into the Button Assignment in one 32-bit number. Anyway, glad you got it working. I'm afraid there are no easy short cuts from making each macro for each panel. Regards Pete

If this is with FSX, then you need to determine the camera numbers from the CAMERAS.CFG file (in the same folder as your FSX.CFG file). For example: [CameraDefinition.005] Title = FlyBy Guid = {6B79DD49-9B4A-439D-BF40-ACBF157B0BA0} Description = This is the description of the fly by view. and [CameraDefinition.007] Title = Nearest Tower Guid = {60BC0819-BD04-4AF6-8954-8FC8AA3545FF} Description = This is the description of the tower view. But those and others doesn't have a "HotKeySelect=N" parameter, so there's no way of selecting it directly. I suggest you try adding such parameters, following on the numerical sequence (it looks like 1-4 are already used). Then you should be able to select them with the Camera selection controls. Regards Pete

That's okay, it doesn't use FSUIPC then, not for that. It is you, the user, using FSUIPC to map keypresses to actions. Regards Pete

Good. Erthere's only one active Registry at a time. If you look at the Registry via Regedit, or the Installer looks at the Registry, the entry there for FS9 must be for an FS9 installed on that operating system. Registries aren't portable, you can't move a Registry from one system to another! Well, that might be another route, but since FS9 is a 32-bit program (as is FSX), and since all programs looking to add to it will also likely be 32-bit, they are all going to look for it using the standard 32-bit references. I'm not sure why there's another in "Wow6432Node", but i suspect that's part of the Aliassing Vista and Win7 use to get over the 'Program Files' protection for non-Vista aware programs like FS9. So why the reference to the Registry? Sorry, I'm a little confused now by your report. Can you clarify, please? Regards Pete

There's absolutely no difference whatsoever in how FSUIPC works in Win7, 32- or 64-bit versions, to how it worked in Vista or XP, 32- or 64-bit. I don't know what is happening on your system, but it is unlikely it is anything do with your change in operating system -- unless, that is, the Saitek drivers are wrong or your installation is buggy. Are you sure you aren't experiencing that spurious button problem a lot of Saitek users have complained about, and for which I added the transient button suppression option? Why not use FSUIPC logging, log Buttons/Keys and Events and see what button presses are occurring and Events caused? Regards Pete

It utilises FSUIPC? Really? I'm pretty sure they aren't paying any licensing fees, so that's ratherannoying! Sorry, I know nothing about it, and it certainly isn't using any special portion of FSUIPC that I know of, with any permissions, so if they are using it illegally I couldn't say what they are up to. You'll have to ask them. Sorry. Regards Pete

That's not much information to go on, is it? What version of FS? What version of FSUIPC? How is that axis assigned? If in FS, have you made sure its sensitivity is set max and dead zone set min? What mapping options have you enabled? Pete

I'm amazed that it's as much as 200nm for AI. No wonder it's such a frame eater in FSX -- I'm pretty sure it was much less in FS9. No. FSUIPC4 is acting almost entirely a SimConnect client. SimConnect was supposed to take over the whole job of application interfacing, and improve on it. I did the FSUIPC4 interface to it as a compatibility layer to get as many apps available as early as possible. The SimConnect interface is identical whether its clients are running on the FSX PC or on any networked client PC. There's no difference, certainly nothing extra "locally" as you put it. Maybe you are confusing it with the TrafficInfo interface? Regards Pete

Is it as much as 200nm? That's only for MP, then, is it? I thought AI traffic was only generated in an area of radius 80-85 nm. I don't know about multiplayer aircraft as I've never got involved in MP at all. FSUIPC's facilities for providing AI data are really limited to normal TCAS or local ATC use, as the tables presented are limited in size - it shows only the nearest 96 airborne aircraft in any case, up to that radius (max -- default is 40 nm). I suppose a SimConnect client program could get more for MP if its truly available. Regards Pete

What offset are you after? Nothing is mentioned about offsets in this thread. Are you posting in the right place? Regards Pete

Yes. And you need FSUIPC4, not FSUIPC3 -- it is a new, completely rewritten version. FSUIPC3 worked for all versions of FS from FS98 to FS2004, plus CFS1 and CFS2. FSUIPC4 works for FSX and ESP (and it would have worked on the next version of FS too, if MS hadn't killed it). Regards Pete

If you are still having difficulty Registering, please try the new FSUIPC installer I've made: http://fsuipc.simflight.com/beta/Install_FSUIPC3922.zip This will install FSUIPC version 3.922 plus the set of (as yet unmodified) 3.92 documents, and finish off by offering you the option to Register. This should overcome any "administrator" problems as Installers automatically have sufficient privileges. Let me know how you get on, please. The next major release will be made this way and will include the document installations in this way. Regards Pete

First, don't you see any difference between 0x029C and 0x290C? You cannot program at random like that, you must take a LOT more care!! And where do you get any example for writing a 12 character access key (which your "chOurKey" is -- count them!) to the one byte offset 0x029C? Even you just quoted that it was only one byte long. Can't you even see that 12 bytes don't fit into one byte? What is the point of sending an example Key to it? What do you think you are doing? The Key (which as it actually says, and you are even quoting, has to be obtained from me, Pete Dowson, not from an example in a document) is an unlock key which only needed ever to be written to the 12 byte area at offset 0x8001. So why are you writing it to 0x290C? What did you think that would do? You just stated it! You need to send value 1 to turn it on, 0 to turn it off. Why don't you actually READ what you quote to me, instead of quoting it so blindly without even reading it? This exchange is getting nowhere. Unless you take more care in reading what is written I see no point in me answering any more of your questions. I really do think you need to learn a lot more about programming, I'm afraid. Do NOT try starting programming by writing a program to interface to FSUIPC. Have a go at a "Hello world" example from a programming tutorial book first, please. You need to understand basic concepts like variables and values. Regards Pete

Bits don't "work". Bits are just 1 or 0. They are the smallest unit of information a computer can handle. The word "bit" comes from "Binary digIT". There are 8 bits in a byte. There's really nothing more to understand. They do absolutely nothing by themselves but represent a state, like on or off, or as part of a number, or a program, or a character, or a picture. Relationship between what? 0 and 1? There isn't one. The word (2-bytes) at Offset 0x0262 is set to value 1 to pause, or to 0 to unpause. It is as simply as that. Why do you want to decode the offset? That's just an address, a code, a number. 0x0262 is binary 0010 0110 0010, but so what? It is also decimal 610, which you could use instead, but why bother? What are you wanting to manipulate the address of the variable for? The offset just identifies which value it is you want to change, it is NOT the value itself! I really do think you need to learn a little more about computers and programming before tackling a program, and especially before attempting to use C/C++. It is not suitable for beginners in any case. The offset is a number, a token, a name if you like, for the value you want to change. Think of it as a name -- think "Lights" instead of 0x0D0C and you'll be half way there. Why don't you look at the examples provided in the SDK then? Can you see the bits about the FSUIPC_Read and FSUIPC_Write functions? Can you not see that the Offset is one parameter and the value is another. When you learn a bit more about programming you will find out about variables, which have names (but can have numbers, or pointers, just like offsets), and values, which are numbers or characters or strings which go into those variables. Or think of the offsets as an array of memory bytes and the numeric value of the address of those is the offset. A slot number. NOT the value which lies inside the memory. Pete

You can cut out jitter at the cost of lower resolution by increasing the Delta value in the FSUIPC assignments, from 256 upwards -- this makes it ignore changes less than that amount. However, with both assignments via FSUIPC and direct to FSUIPC calibration there shouldn't be a problem in any case with any recentversion of FSUIPC because of the arbitration it performs -- favouring the input with the largest deviation. This facility is described in the History document for FSUIPC as follows: This should work provided your axes are providing values such that zero, or somewhere near zero, is the neutral position. This will be the case with most if not all commercial yokes. Sorry, that still makes no sense to me. You pull the elevator axis and hold. If you then level the yoke, it levels the elevator. How can you hold a positon and returnit at the same time, and what is the "gauge" you refer to? But it should be in a neutral position if you leveled the yoke as oyu just said. Sorry, I don't understand the term 'step function' applied in this context. Please tell me, what are thre calibration values for the yoke in the FSUIPC INI file (i.e. min/centrelo/centrehi/max)? What version of FSUIPC are you using? how are you assigning them? You have not provided enough information yet. Regards Pete