Pete Dowson

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

There's no "registered" versus "unregistered" version. When you register the software is just the same, you merely unlock the user facilities. It copies the IN values into each idle field alternately when you press the "Set" button above those fields. It has no choice, that's all it can do -- copy current value. But YOU have to push the button when the values are okay! If you push them when the INput value is -16384, then you'll get -16384. FSUIPC will not invent mystical unused numbers to go in there. They have to be values supplied by your lever at the positions you set. Evidently 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. Didn't I read others saying that the reverse on those throttles are by a button being pressed by pulling the levers back? I suspect you cannot use them the way you hope, unless you are prepared to have the idle further forward, and the reverse operating back to that detente. There's a CH-hangar website which contains lots of assistance for CH users. There's also a sticky thread here called "FSUIPC Guide for CH Users" -- have you looked? I think you need to learn a little more about your CH TQ so you can decide what to do with it. Regards Pete

At least one of the SimConnect DLLs appear to be missing from their proper places in the Windows WinSxS system. Either that or the permissions set on those folders prevents the WinSxS system operating. I'm curious still -- you didn't answer my question "Did it work before you registered?". Why did you specifically mention the fact that you'd just registered? Was that related to the problem at all. Also, the fact the you are posting in a thread related to deleting folders in Vista 64 leads me to think that you may have messed up the SimConnect installation altogether. Why, for instance, did you post the link to where it shows you how to change permissions and delete files? I assume you've tried deleting the SimConnect folders themselves and repairing FSX bas plus the SP! and SP2/Accel updates? All I can suggest at present is that you try the very latest FSUIPC4 update, from the Updates announcement above. That's a bit more flexible how it links to SimConnect (because it has to link to ESP's version too). But apart from that it looks like a re-install of Vista may be necessary. Regards Pete

The only part of WideFS which goes on the client PC is the oddly named WIDECLIENT.EXE. It shouldn't really be that confusing when it is named like that? The part of WideFS which stays where it is, on the Server, is WideServer.DLL -- that's included inside FSUIPC4 for FSX, but inserted into the FS Modules folder for FS9 or before. You seem to have got the Server running, so all you need to do is put the WideClient.exe program on your client PC, and run it. The Client is provided along with all the WideFS documentation in the downloadable file called "WideFS.zip". The names of the files surely suggest that they might contain what you need? It should have been easy enough to get that far from the first few sections of the WideFS User Guide, surely? If you can't read English perhaps you can get help with translation? Regards ete

Sorry, I've never heard of "Windev" nor "W-language". How are you trying to use FSUIPC_Read and FSUIPC_Write if you cannot use FSUIPC_Open? They are all part of the same library. Yes, the code for FSUIPC_Open uses the filemapping calls. The sources for the whole interface are provided in several languages in the SDK -- C, VB, Delphi at least. If you understand these calls, check the source. I can't do more that what is shown in the relevant source files! Regards Pete

Why are you adding this to a thread entitled "Delete system folders in Vista 64"? Did it work before you registered? If you remove the FSUIPC4.KEY file from the FSX Modules folder, does it work? What does the FSUIPC4.LOG file show? That's the first place to look. If it isn't producing a log file, then it isn't even being loaded by SimConnect. The Installer also produces a log and that will contain useful information too. The first place to look, surely, in in your own folders, for logs and the like. Why make it harder first? Pete

Don't you think you should be doing some debugging? I can immediately see two things wrong just with a casual glance: 1. You are reading a two-byte (16bit) value into a single byte variable. That alone is going to corrupt something. 2. You are comparing that (one byte!) value, which would, if it were possible in one byte, be in units of 100 x statute miles, as documented, with a floating point double (0.3) -- it will of course NEVER be less than 0 as it is unsigned! You also seem to be using a Key, IKB3BI67TCHE, which I don't think is a valid application key and which certainly hasn't been issued to a "test.dll" as far as my records show. You shouldn't really be writing to offset 8001 on every cycle. If you want to do one-off things like that, do it after the Open2() call, just the once. However, with any reasonably recent version of FSUIPC you do not need to write any key anywhere. Why not try using your debugger? Also make use of FSUIPC's logging facilities -- you can log your IPC reads and writes. Pete