Pete Dowson

FSUIPC4 cannot possibly do anything to any textures or graphics, nothing whatseover! In fact without any program using it FSUIPC4 does nothing. It is an interface, it has no proactive parts operating by themselves. And it most certainly has no influence whatsoever on any graphical elements of FS. You must look elsewhere to solve your problems. Please stop posting here, you are wasting your time! Regards Pete

All Intel processors are little-endian, i.e. least significant byte first, and that's how all FSUIPC variables are stored. But I don't know whether the DLL reverses things internally. If you read everything as a Byte array, which is how the FSUIPC interface itself treats everything, then you will know what you are getting and can treat it appropriately. Otherwise, why not simply read something known (eg from FSInterrogate) and look at it. You'll soon know then! Regards Pete

You are mixing up two completely different things. FSUIPC4 can have no possibly influence on any textures, or any graphics whatsoever in fact. See the helpful hints from Andy. Pete

Really that should be sorted out in the modelling of the aircraft, probably the inertia values in the AIRCRAFT.CFG file, for example. I'm not really familiar with that stuff, but perhaps there's an aircraft modellers forum somewhere here or in AVSIM? If you assign the controls through FSUIPC then there is a delay facility provided. You need to assign the axes, then edit the FSUIPC INI file. Find the relevant axis and add "/n" after the Delta value (256 by default). The "n" is the number of milliseconds delay, so 1000 = 1 second delay. Please see this thread, not far below yours: Axis /delay deletes line in .ini update You'll need the very latest FSUIPC update from the Announcements above, as there was a bug in this facility. A light aircraft will do, if you are already fast enough. Of course it will very much depend on the weight (fuel load + payload/passengers) and amount of flaps set. But you should never just pull the yoke back far, just a little at first, then more -- you may get a tail strike if you raise the nose too quickly. Regards Pete

Yes, but I just noticed that FDS (Flight Deck Software --- http://www.flightdecksoftware.com ) say they support the Aerosoft MCP too, and FDS is relatively recent -- certainly long after Aerosoft stopped MCP support. So I really must assume there's an SDK available, or else some clever folks have decoded the original Aerosoft driver. The only Aerosoft kit i have is a Piper Arrow III console (the "GA28R") -- a full analogue-gauge equipped front end for a Piper Arrow III. It is only one of 5 they made, apparently. They supplied a driver for it, but it won't work on 64-bit Vista or W7 and has its serial port interface rather limited in how it operates. Andrew Maclean kindly supplied full interface details for me and I've now written a little DLL which interfaces directly to it and FSUIPC4 and drives it very efficiently on my Win7 64-bit system. I'm sure someone could easily do something like that for the MCP, given the information which I think must surely exist. Note, however, that my GA28R driver does NOT allow the buttons to be assigned anyway you want. They do drive the GA28R as a PA28 Arrow III, interfacing to the inner equivalent functions in FSX (only -- I'm not doing one for FS9). So in that sense it is similar to the Aerosoft MCP driver -- that drives the built-in MCP in FS, right? There's no way I could use my Piper Arrow console to fly a PMDG 747 or MD11! ;-) Regards Pete

What language are you programming in? All languages have ways of combining conditions, whether as alternatives ("OR") or joint reuirements ("AND"). This inlcudes the Lua language, for FSUIPC plugins, even if you only do it by nesting "if" statements. You can also even do it in FSUIPC INI file button programming, though it doe get a bit messy. You can only have one Offset condition on each line, so you'd have to use them to set flags and make subsequent conditions both flag and offset conditioned. But I cannot really help you more until you tell me how you want to program things. I wish you would not refer to other threads like this. Why not post in the other thread? It is not easy to cross refer. However, "initialbutton" is a facility to assume certain (probably non-existent) button presses have been made to be actioned as soon as FSUIPC and FS are up and ready. They are never processed again. It is to allow certain cockpit initialisations to be dealt with. These days this is really very much put into the shade by the ipcInit and ipcReady Lua facilty, where you can do almost anything on initialisation. Just set your eyepoint, open the doors, and save the flight, setting as you new default situation. Things like that never need any extra facilities for me or anything else. Regards Pete

Okay. I suspect that if the switches look like latching toggle switches then they will not be momentary in any case. I can point you in the right direction, either way -- when you know what they do! Regards Pete

Really? Are they all buttons, then, or truly latching toggle switches? The the latter and they are operating only momentarily, then they should give a different switch number when going off to on than from on to off. Can you clarify, please? You can program a button to switch on with one press, and off with the next, alternately. In fact all of the FS controls called "Toggle" operate this way. And the standard FS Parking Brake control is also a toggle (the control normally assigned in FS to Ctrl+.) You need to tell me what FSUIPC sees when you turn it on, and then when you turn it off. If you are correct in saying it is only momentary, then how will anything ever detect it being turned off? I suspect that either you are mistaken, and it isn't momentary, or it is but it indicates a different switch number when operated on-to-off. Regards Pete

Strange. Perhaps the offset is only telling you where the switch is, rather than allowing you to control it? Perhaps there's another mechanism for that? Yes. I'm afraid this is a question for Bart. I don't know how his software works. Sorry. Regards Pete

That's up to you. with the Lua method you have the opportunity to manipulate or calibrate the values, which you cannot do with the Offset control, which would simply write what it sees, No, i really don't want to do that. I'd have to remove two of the 4 possible assignments for an axis, and I cannot remove capabilities like that to make room for a minority requirement which is easy enough to do via INI file editing. After all, most button conditional programming or multi-action needs also have to be met by INI file editing. If I was really good at user interface design I'd make everything doable that way, but I'm not, and even the simplest things in a UI take me longer than complex facilities internally. Regards Pete

I don't know. The copy of the FDS offsets list Bart sent me back in November doesn't include 6E6F. It lists these two values 47 BATTERY SWITCH – OFF 48 BATTERY SWITCH – ON but those are for offset 6EF7 ("FSUIPC Switch input values"). Maybe he's changed them? Actually my copy is dated May 4th 2008, and the used offsets in the list I have are from 6D88 to 6DF7. However, I know he changed the "D" to "E" at my request last November because he was using offsets allocated to some other programs. I gave him a proper allocation then, 6E00 to 6EFF. Anyway, once you have obtained the correct offset, whatever it might be, just use the "Offset Byte Set" control, with the given offset (xXXXX) and the correct parameter. If that doesn't then work, try FDS's support -- I am sure it is excellent. [LATER] I've just found the latest offsets list, in FDS's "Resources" section, and the switch operating offset is still 6EF7. If you are trying 6E6F then it isn't surprising it isn't working! Where did you get that from? Regards Pete

It isn't the size of the box that's the problem, but an incompatibility between two parts of Windows -- the part which is in charge of dialog boxes and the COMCTL32.DLL component which manages extra controls to do those tabbed inserts. FSUIPC itself doesn't set sizes -- in fact it doesn't even attempt to (I wouldn't know how). The whole contraption is specified in terms of character widths only -- and one one such set, not a different set for the container and contents. So there's no user programming control over how it turns out. All the code is just basic Windows dialogue programming using additional controls to get the tabbed parts operating. I've never found out how this incompatibility arises -- I've had at least 20 different PC systems through here (I have 12 at present) and none have ever had the problem. but I do know that some video drivers appear to install their own copy of COMCTL32.DLL, and that this is sometimes not compatible with the version of Windows installed. So, there are two things you can try: one is to change the selected Windows font size. How you do that depends on your version of Windows I think. On XP, for instance, you right-click on the desktop, select Properties, then "Appearance". You'll see a Font size selection where you can make it bigger, or maybe smaller. Try changing it and see if that fixes it. Here such changes merely change the whole dialogue size, including the Tabs, so it makes no difference, but Windows 7 users say it does make a difference, and it is even more likely to when the COMCTL32.DLL isn't the official one which came with Windows.. The other thing to try is different video drivers -- possibly the makers have by now discovered their error in replacing COMCTL32.DLL and will fix it. Though there's a possibility, I suppose, that the bad one will remain installed. Possibly running Windows repair could fix it, or trying to find the original DLL on the Windows install disk and re-installing just that. This does get a bit difficult though. Incidentally, this occurrence isn't all that frequent. It seems to be reported around 2-3 times a year, over the whole lifetime of FSUIPC (that's now coming on towards 10 years). I think all of the previous sufferers have fixed it one way or another, but rarely if ever come back to say how. So please, if you do make progress, come and tell us. And please do mention the version of Windows you are using and, oh, the video card and drivers. Regards Pete

By "FDS" do you mean Flight Deck Software, http://www.flightdecksoftware.com ? If so, how are you trying to program its overhead logic in FSUIPC? Do you have the documentation for the FDS offsets? This might be a question more suitably placed in FDS's own Forum -- apart from the hardware directly supported by Bart I'm sure there must be plenty more users doing their own thing, whether with GoFlight or other kit. Provided you obtain the offset usage documentation from FDS I think it would then mainly be a matter of using FSUIPC's "Offset ..." controls to do exactly what you want. This is the way it is with Project Magenta, for example -- PM publish their offset usage openly on their website. Regards Pete

It could only do that if the Aerosoft MCP driver either fed those buttons into Windows as genuine joystick type buttons, or set the virtual button offsets. I recall that, in fact, I first invented the 288 virtual button bits in the FSUIPC offsets specifically for the Aerosoft driver to map the 288 possible buttons it supported! This is for extra button boards you connect to the MCP via its expansion ports. But I'm pretty sure, now I remember that, that the main MCP functions were pre-programmed into the Aerosoft driver, that it interfaces directly to the correct FSUIPC offsets to do its job. Actually, wasn't it Aerosoft themselves who provided the extra drivers? One for Project Magenta as well, I think? Well, yes, it would need some sort of SDK for anyone to do any sort of new drivers. If there were an SDK I'm sure someone could knock up a more generalised interface program for it which would allow FSUIPC button assignment. So they must have an SDK for the MCP, or at least enough information to produce such a driver? Yes, but only by driving the correct offsets to make it work as an FS MCP. Maybe you could ask other cockpit folks over in http://www.mycockpit.org/forums . I'm sure there are plenty of other Aerosoft MCP users there. There's even one chap who's making stick-on backlit fronts for it in correct Boeing 737 colour! Regards Pete

I suggest that you first update your FSUIPC to a supported version. The current one for FS9 is 3.90. I cannot offer any assistance for old versions. Regards Pete

Sorry, it's a long time since I had one of those, but Iseem to remember it was pretty flexible. Lots of folks use them, even with Project Magenta. And doesn't it come with a good enough driver? What's your real question? What are you wanting to do that you can't? Please don't confuse FSUIPC with any sort of hardware driver. FSUIPC is an interface into FS -- hardware drivers interface to FSUIPC, FSUIPC interfaces to FS. There's no hardware access code in FSUIPC. Regards Pete

There's nothing in FSUIPC4 which would do that. Sounds like a bad file somewhere, maybe a saved weather file. Best thing to try first is to rename or delete your FSX.CFG file so that FSX creates a new one and avoids loading your possibly corrupt default flight. Are you using a fully updated FSX -- both SP1 and SP2 (or Acceleration)? Crashes in WEATHER.DLL were quite common with the original release. If you want support, yes. I only support the current version. No. none of your FSUIPC settings are ever changed as a result of upgrading to the next version. Regards Pete

The Lateral CG percent value is now available in FSUIPC4 offset 2E78 (64-bit double), in version 4.523 from the Updates announcement above. I've not checked it -- I wouldn't know whether it was right or wrong. I guess in FSX the only lateral CG offset would arise from unbalanced fuel? Of can the payload be one side or t'other? Regards Pete

The updates are available now, in the Announcement. I was going to do something else before release, but I had a look and it isn't easily feasible. Pete

I've been doing some more work this week on FSUIPC, and I tried an experiment. If you assigned your axis to any normal FS control, such as the flaps, whatever (it doesn't matter), THEN load up the FSUIPC INI file into a text editor, you can change the assignment to be one to an FSUIPC offset control. To take an example. In my [Axes] section, of the INI file, I had this line: 2=BR,256,F,65696,0,0,0 This is basically assigning joystick B, axis R (*rudder) to the FS "Rudder Set" control (number 65696. If I change the 65696 to x020066C0: 2=BR,256,F,x020066C0,0,0,0 and tell FSUIPC to reload the assignments (in the Axes tab), then the axis value is written to the 16-bit word at offset 66C0. The x0200xxxx format is from the list of additional FSUIPC controls given in the Advanced User's manual. I could, if needed, actually have the value going to FS's rudder as well as offset 66C0: 2=BR,256,F,65696,x020066C0,0,0 In fact you can do up to 4 different actions, using the 4 places here. Note that having done this you cannot edit or reassign that axis in the dialogue without losing this action. The dialogue does recognise the "Offset word set" control, and lists it so, but it will write it back with a zero offset because there's no way in the dialogue to specify offsets. You end up with x02000000 which you'd need to change again to include the offset. I hope this helps you. Sorry about the delay. Regards Pete

Okay, another elementary error, which has been there for as long as the delay facility has! Fixed in this weekend's updates. Thanks for finding and reporting these. Seems you are the only one being so ambitious with FSUIPC facilities! I'll have to elect you my top Beta tester! ;-) Regards Pete

Okay. I've at last managed to find time to investigate this. It's a definite bug, and it looks like it has always been there, both in FSUIPC3 and 4 (and FSUIPC's 1 and 2 before them). Seems not many, if any, folks use these facilities! And it applies to Buttons as well as Keys. So it's a good catch indeed! ;-) It's easy to fix and it will be fixed, along with some other things, in the next updates -- 4.523 and 3.916. I should have them ready and uploaded by tomorrow, or so. Best Regards Pete

latest 4.522 Okay, I'm looking at it now. Pete

As stated in the relevant Announcement at the top of the Forum (please peruse these for answers to questions first), you only need to open your account at SimMarket to retrieve keys. This applies to most of the products they sell. I only do development and tech support. Regards Pete

Sorry, all I was given is included in the SDK. I don't know what to suggest if the author is not available. Can you not try something and tell byte order from the results? Is Java likely to use a different byte order to the standard Intel one? Regards Pete