Pete Dowson

That's what the History document is for. Regards Pete

This is a FORUM. All forums have a list of threads, started by inquirers such as yourself. But right at the top of the forum, before all those, are ANNOUNCEMENTS. These are VERY VERY important as they are my way of informing everyone about my programs and helping them help themselves. I've not idea how you arrive at a Forum and not see the Announcements right at the start. How do you do it? :-( It seems my time trying to help folks in this way is wasted on many. I thought Announcements were bound to be seen by everyone. This is VERY disappointing! :-( Pete

In that case the first so-called [General] section is not seen by windows as a [General] section at all. I notice you always type this as (General), with round parentheses -- if it is like that then it is not a section at all and will be ignored. The lack of a [General] section cannot stop you programming a button -- perhaps you could explain what you did and why you think that was unsuccessful? Button programming does not involve reading anything from the INI -- it only writes the results there for the next reload, and they go into a [buttons] section. Well the easiest thing normally is to paste it into your message, and use the "List" button to wrap it into a scrollable window. It just arrived. There's nothing wrong with your FSUIPC. The reason the first [General] section doesn't work is because it looks like this: Section names must have the line to themselves. Windows won't like all those ^^^^^ you've put in front. The rest of it looks okay. You have quite a few Buttons already programmed, Axes assigned, and calibrated. The only reason you are getting the "second" [General] section is because there isn't a recognisable first one. If you have any suspicions about whether FSUIPC is "working" or not, the INI file isn't the place to look. you should look at the Log file, as i said before. Regards Pete

Aha, now we are getting to the truth of it. Are you saying that none of your axes are seen as axes by FS or by FSUIPC? How are you assigning them, then? How are you seeing that little rudder movement? Obviously I am still not understanding everything you are saying. The Axis assignment facilities in FSUIPC are for DirectInput or Windows joystick axes -- axes that can be seen and assigned in Windows' programs. If your system is getting this information into FS in a different way, then the steering tiller assignment (or any other assignment) is not possible in FSUIPC's axis assignment facilities. If you can access FSUIPC offsets through your system, and provided you can send a control value AND a parameter (the control value to identify the axis, the parameter for the axis readout), I could add a facility via offsets 3110 (command) and 3114 (parameter) to get axis values sent "direct to FSUIPC calibration". The command values would be something like 64000 - 64044 according to intended axis, and then you'd calibrate in FSUIPC as usual. You wouldn't use the Axis assignments facility, that would be bypassed. This is not difficult to do, but it isn't implemented at present. If you think it can be your solution, let me know. Regards Pete

Please see the Announcement above about what to do when you lose your keys. Pete

Sorry, but you'll need to explain some of that. It sounds like you are not using FSUIPC at all for this, so maybe that's the problem? -- What are "Phi Values" and "FS Values"? Where are you seeing those? -- When you say "using Rudder control (Fs Var Assignment) to communicate with FSX" what exactly does that mean? None of these terms seem to relate to anything i provide for the steering tiller axis in FSUIPC, so I wonder why you are asking me the questions in the first place. Perhaps, if you could say EXACTLY what you are doing where, and exactly where you are seeing what, I might understand and be able to help. Please don't tell me things in terms of what Phidgets software may or may not say. I don't know it and so it doesn't help. If you need help with that you'd need to talk to the authors/support folks for that. If you want to use FSUIPC for a steering tiller axis you must assign both the tiller and the rudder axes in FSUIPC, selecting "direct to FSUIPC calibration", and then calibrate both. FSUIPC then uses the tiller axis to drive the FS rudder when on the ground and at airspeeds of less than 60 knots (an adjustable figure), and the rudder in the air and on the ground above 60 KIAS. Below the changeover speed control is divided proportionally between tiller and rudder, so that, for example, at 30 knots it is half-and-half. Regards Pete

If it is installed and producing a Log file, it is running. If there are any problems they would be logged. Regards Pete

You could certainly use the Trim Indicator value at offset 0BC2 to drive a motorised trim wheel. You'd want the motor driven directly by your electric trim rocker switches on the yoke when not using the A/P, only driven directly from the offset when the A/P is controlling it. You'd also need to stop it feeding back into the sim when the A/P is in control -- there's an FSUIPC option for that. For the practical matters you'll want to post on the cockpit builders forums I think. Regards Pete

All the names have numbers assigned. I posted a list in an earlier thread here -- did you try a search on "PANEL_ID"? Here, I just did: viewtopic.php?f=54&t=74623&p=458360 And, as it says there, you can usually find out the ID number by using the FSUIPC event logging. Regards Pete

Yes, but the problem with those is that such lines do not conform to the INI file formatting, so in any improvements I make to the way the file is handled would get them lost completely. They just don't exist as far as the PrivateProfile system is concerned (the INI file is handled using that Windows API). To counter this, in the performance improvements I've now made to FSUIPC's handling of the INI files (for quicker loading and saving), I deliberately pre-process the INI file and precede any lines which would otherwise get lost with "!n=" prefixes. They have to be numbered so that you don't get more than one the same in any section. This method makes the lines a true part of a real INI file, but the ! prefix stops confusion with active lines. The completely empty lines are lost too, yes, sorry, but I did think it looked silly having loads of lines like "!n=", and I think they'd probably get lost too. The INI file format, at least for the [buttons] sections, has allowed for comments to be retained for a long time, but, as documented, these have to look like part of the INI structure. The way to do comments always was n=; where "n" kept its place in the ordering of the Buttons parameters. That was when FSUIPC used to always erase and re-write the complete section in numerical order. Now that is doesn't do this, the ordered numbering isn't really warranted, but you still need some sort of xx= prefix. For a "blank" line I'd recommend something like !n=; with no text following. But better organisation/separation would arise from something like !n=;======================================================== or similar, don't you think? Regards Pete

You see the tiller move the rudder in FSX? How is it assigned, then? FSUIPC3 only sees the basic 6 original Windows joystick API axes, but the FSUIPC4 implementation uses DirectInput, like FS, and recognises all the axes that it supports (8 normal ones plus 4 point-of-view hats), so if FSX sees it then FSUIPC4 certainly should. Where are you looking? What version number is this "latest FSUIPC software", please? The term "latest" is meaningless -- it means the latest you saw. I've had folks using a year old version thinking it was the latest. The version number is easy enough to find, please always use it. Regards, Pete

Weird, but it is certainly all to do with video drivers. You said ...so what did you change relevant to video? Could there have been an automatic update? I'd look for alternative (older or newer) drivers for your card if I were you. I notice the ATI Catalyst drivers for Vista are up to version 9.1 already -- but you can also still get all the 7.x and 8.x drivers, up to 8.11. Regards Pete

In all previous occasions this has been reported it was identified as a video driver problem -- some drivers are not good at changing from standard full screen mode to Windows GDI mode in order to display a standard dialogue. The usual immediate solution is to change into Windowed mode for FS (ALT+ENTER) -- Windowed mode is almost always just as fast as full screen mode (and in fact has better re-draw capabilities, and less blurries). The dialogues appear normally in Windowed mode. If you prefer to run in full screen mode then switch back afterwards. If you want a fuller long-term solution then you need to look to driver changes for your video card. As far as I know all the current main drivers for the more up to date cards work well. Regards Pete

What's the "drop in fsuipc missle switch", please? In FSX there's a "release droppable objects" control, which you can assign a key or button to. Is that what you mean? The only other controls with 2drop" in them are related to fuel tanks I think -- they appear in the FS9 listing too. Regards Pete

Ah, yesoffsets 2400, 2500, 2600, 2700 provide this for Engines 1-4. But actually it is "PROP RPM:x" or "GENERAL ENG RPM:x" depending on which one is actually changing -- it varies by aircraft type. I think the reduction ratio is needed for those which don't update the "PROP RPM", only the "GENERAL ENG RPM" value. i think it is the same problem in FSX, for some aircraft. But I wouldn't swear to it, and maybe it got changed in SP1 or SP2 in any case. If you find out how to get it, let me know and i'll see what i can do for it in FSUIPC. I did think of trying to hack into the RPM gauges to see how they got it, but then it occurred to me that they probably just work with the percentage of max figure -- they don't need the actual, that is just a dial inscription. Or do they? Sorry, all the stuff relating to the innards of aircraft systems is a mystery to me. I just exposed what i found or that folks found before me (a lot was carried forward from pre-FSUIPC days, from FSW95 and FS98). Let me know if you find anything concrete and useful. Thanks, Pete

You should really have read more about ASA first, then. It clearly says that it uses SimConnect for FSX, only FSUIPC when using the FS9 version. Please check your ASA documentation, or ask the HiFi Simulation folks, whose product it is. They've been developing for SimConnect ever since FSX was in Beta, some years ago, and ASX, the predecessor to ASA, was 100% SimConnect. No FSUIPC/WideFS use at all. You can run SimConnect clients across a Network -- if you have the Deluxe or Gold version of FSX. You would need to install SimConnect on the client PC too. The ASA Documentation surely covers this. I don't need any logs if you are now up and running. Not that I know of. There's a partial list, probably quite out of date, down the right-hand side of the main http://www.schiratti.com/dowson download page. Regards Pete

Okay. Thank you. I've had a browse on the WinDev website. It looks quite interesting -- I'd never even heard of it before! Shame they don't provide compatibility with the standard Microsoft LIB file format, else you could simply link the existing LIB file into your project and call the FSUIPC_ functions direct. They do allow direct links to Microsoft DLLs, so one other way would be to compile a DLL version of the FSUIPC Library. [LATER] The brochure on WinDev, on their website, clearly says that it supports C++ as well and that you can call routines in that language from your W-language code. So why not just use the C source from the FSUIPC SDK directly? Regards Pete

Erthere are no Buttons and Keys specified in [General]. They have their own sections, [buttons] and [Keys]. There's also [JoystickCalibrations] and probably several other sections, depending on what you've been doing -- [Profiles], [Axes] and [Monitor] for example. No, there must only be one [General] section. Have you been editing the file? Or could your PC have possibly suffered a crash during FS, so maybe corrupting the file? That's not relevant. If you use Aircraft specific settings, or Profiles, you just get more [buttons.xxx], [Keys.xxx] and [JoystickCalibrations.xxx] sections, one for each sepcific aircraft or profile. No, not at all. The INI file [General] settings are only read once, dring FS initialisation. All duplicated sections would mean is that the settings you get could be from either one, but not both. I've no idea whether Windows finds only the first matching section or the last -- probably only the first. I think you should assume your INI file is corrupted and delete it. If you have lots of Button or other assignments, cut and paste from the old file into a new one. With FS2004, or FSX? For FSX the low speed (2.4GHz) of your processor would mean you need very low graphics settings in FSX. But with FS2004 your system should zing. Unlikely. check the FSUIPC Log file. You could always compare your frame rates with and without FSUIPC installed, just to check -- it's only a matter of removing it temporarily from the Modules folder. Regards Pete

Ouch! That's one of the main cause of really bad SimConnect problems. It is not actually possible to properly uninstall the shared libraries for SimConnect, so when you reinstall it makes rather a hash of things. I hope Windows 7 sorts this out, but as it doesn't appear to be a problem for programs with proper uninstallers I suppose the Windows guys would blame the FSX uninstaller for being deficient. Version 4.20 is pretty old now and certainly not supported. Please refer to the Announcements above for details of supported versions and get yourself updated. You will probably still get the same error with 4.40. Really you will at some time need to repair your SimConnect installation (the FSX Help Announcement gives some guidance there), but it is really messy and you may end up having to re-install Windows too. However, because of some changes I've had to make to FSUIPC4 to make it work on ESP as well, after installing 4.40, the latest Update (4.435) from the Updates Announcement above may just manage to work on your messed-up installation. Other SimConnect clients may not, however. Regards Pete

Well it looks like you changed something else in your system as wekk as Registering, because FSUIPC4 simply cannot link to a SimConnect DLL. I've never actually seen a log showing the same symptoms as yours does -- it isn't simply a WinSxS problem -- Windows seems to allow the Side-by-Side check to pass, but then the actual exports in the SimConnect DLL aren't found so FSUIPC cannot link to it. It's as if you have the SimConnect folders all correct, but either the SimConnect.DLL module inside them missing or replaced by incorrect files with the same name. No, it wouldn't. ASA is a SimConnect client, like ASX before it. Neither use WideFS or FSUIPC at all for FSX. Well it looks like your repair did not work. Did you remember to change Permissions back to "TrustedInstaller" BEFORE running the DFSX DVD repair and reinstalling SP1 and SP2? If not, then those attempts would certainly have failed. Regards Pete

6D88 is already allocated. Why are you trying to select a specific offset? The process of getting offsets assigned is merely to work out how many bytes you need, then apply to me for an assignment. I will check the register of offsets usage and provide you with the address. 33 BITS or BYTES? I wouldn't assign less than 16 bytes -- that's 128 bits. Write to me at petedowson@btconnect.com. I will reply then, by email. Regards Pete

Bob Church seems to have identified the reason your levers had no reverse zone in any case. I wouldn't have known that -- all I can explain is what the software is doing and why that is so. Regards Pete

Thanks Bob. So when I said "your levers are designed to provide a full range only from the detente to full max. The part of your levers before the detente are obviously not providing a different value." that was correct, except it is "designed" by software setting rather than by hardwareI'm glad there's an easy solution. The inquirer doesn't seem to like my replies, even though I was telling it as it is. Best regards Pete

There are three separate "Set" buttons, one over the full reverse, one over the two centre/idle ones, and one over the max. The relevant buttons set the values beneath. All it does is copy the input value to those slots. If your IN value says -16384, then that it what you'll get. No, I don't think they do. I only try to be factual. if you think I'm explaining at too low a level, you should see the complaints I get if I explain at what I would consider a more expert level. If trying to explain things well comes across as "condescending" to you then I won't respond to you any more. Sorry. I'm only trying to help! I'll let someone you might like better take over, maybe someone who's actually got a CH TQ. :-( Pete

No, not at all. FSUIPC_Open does all that for you! All you have to do is use FSUIPC_Open! That's the whole point! :-( Either YOU have to do all your own code for the interface, OR you use the library facilities provided -- i.e. FSUIPC_Open, FSUIPC_Read, FSUIPC_Write, FSUIPC_Process and FSUIPC_close. The WHOLE of the interface is represented in those functions. YOU do not have to do ANY of it!!! If you really want to do your own interface code instead, you need to do it all, not pick three Windows API calls out of FSUIPC_Open. All of the FSUIPC functions are interdependent. If you are just learning to program from scratch here, I think you should be looking for a different project to start with. Otherwise please look at the examples provided in the SDK and stop trying to pull odd bits out to use separately. I cannot help you with that -- if you want to write your own interface library code, do so, but you'll need to do it all, not just bits of it! Regards Pete