Pete Dowson

Sorry, I'm not even really sure what a "profile" is in this context. Is it something to do with the Saitek drivers supplied? Have you tried the Saitek website, if they have one? Otherwise, you may be luckier asking on the FS2004 Forum. Regards, Pete

Offset 3110 (control number) and 3114 (parameter, if any) is where you write ANY control -- be it a standard FS control, or an added FSUIPC control. It has nothing specifically to do with any aspect of FS. Please check it in the table. Writing to FSUIPC offsets from EPL is not an easy thing in any case. Are you using EpicInfo for this? You can only write 16 bits at a time via "soft axes", so it gets very complex (you need up to 64 bits for controls, for instance). I would have thought there would be better ways of spending time programming EPL, really. :wink: You don't need to if you control the timing of the button state changes in EPL. For that matter it isn't any different doing offsets of button programming except the latter much much easier. Regards, Pete

Sorry, I really have no idea why FS would do that. FSUIPC is only passing on the information it gets. In fact I think that those locations are mapped directly into FS's own data areas. You mention 3070, 3078 and 31D0 and call them "pitch" accelerations, but the Z axis in FS is the longitudinal one -- forward/backward. The FS team name them in terms of screen-type orientation, Y up/down, X left/right, Z forward/back. Both 3070 and 31D0 are Z-axis, not pitch values. 3078 is a pitch acceleration. Is that the one you mean? Maybe you need to add some form of digital filtering into the values to smooth out the spikes? Regards, Pete

Sorry, it is an offer from SimMarket when purchasing both together -- it saves some work and acts as an incentive. There's no mechanism for discounting separate purchases. Regards, Pete

They are not offsets! How did you arrive at such a misconception, please? Surely my documentation is not that bad? :cry: They are FS control numbers -- you are looking in the FSUIPC added control numbers list. Controls are programmed to Keys or Button presses. Please review the text at the start of the list in the Advanced User's documentation. You can send then to FSUIPC across the IPC interface if you wish -- use offset 3110, as documented. But from an EPIC you seem to be going about it in a very odd and complex manner. Going back to your first message: If the rotaries are producing button presses, simply go to FSUIPC's Buttons page and program the controls there. That's what it is all about. I used EPIC up till a few years ago, and most all of the facilities for buttons I ever added were intended to be used this way. Why are you trying to find offsets? More puzzling is that you go on to say: In fact all of those offsets most certainly DO work -- when written to with the correct values, those values will change on the FS A/P MCP displays. But you need to get the units correct, of course. As documented: 07CC is a 16bit word arranged so that the full range 0-FFFF gives 0-359.999... (this is a standard way of representing headings in FS). 07D4 is a 32 bit value with metres in the high 16 bits and 1/65536ths of metres in the low 16 bits (i.e. the whole value is 65536 x metres). and so on. If you are simply trying to increment or decrement values like this by 1, obviously they won't change very fast -- the heading will change to 360/65536ths of a degree, and the altitude by 1/65536th of a metre, for each such increment/decrement. I don't understand why you want offsets when you so clearly can use either the standard FS controls or the extensions added by FSUIPC which you have found and listed. Simply program the buttons. Regards, Pete

Sorry, this is 100% a question for PM support. The flaps display is completely under PM module control. There's nothing in any of my code anywhere that can in any way affect any graphics in PM software. Regards, Pete

The only way to do that is to put a shortcut to WideClient in your Windows "startup" folder, so that Windows runs it after loading. Have your PM programs started by the "RunReady" parameters in WideClient.ini. Then WideClient will sit idling in the Client PC, and will connect only when it sees the Server and then run the PM programs. Of course. There's no way the link \\CDUis going to get the program actually running in the client. That's just a path telling Windows where to get the program to be run. So it will be running (very inefficiently) from the folder on the client, but within the current PC -- the one running FS. Since WideClient cannot normally run in the same system as FS, you get that error. I don't know of any way of getting a program to run in a Networked PC without having something there which is ready to run it for you. In this case, that "something" would be WideClient, which you need to have running first. Regards, Pete

Okay, found the problem and fixed it. It was recent additions, refinements, using a couple of FS variables not actually present in FS98. Sorry about that. Please use the attached version 2.571 of GPSout. Incidentally, you don't need FSUIPC installed in FS98 to make GPSout work. Regards, Pete GPSout2571.zip

Even if it didn't work, it is part of my job to make it work. That's what technical support is about. I don't think there's ever been anything which "hasn't worked" for long -- I fix things as fast as I can, usually within a day or so. Bug fixing is always top priority, as I loathe having any of the horrible little critters in my programs. Pete

So far all software developers have found that the free SDK and all the support they get is well worth the price of registering FSUIPC as a User. A program does not become a "freeware" application just because you write it for nothing. The point of providing free keys to freeware applications is so that your users, those to whom you are going to supply your wares, do not have to pay for FSUIPC -- after all, they may not need anything from me at all. However, if you are insistent, and do not come back for much support nor requests for additions to FSUIPC, then I could arrange a freeware application key for you. You would be the first such developer, so disappointing, and I would not like it to become a precedent. Please read the Access Registration document in the SDK. I'll need information -- send details it lists to me at petedowson@btconnect.com. Note that it may not work in debug mode (I know VB doesn't, but I don't know with Delphi). Regards, Pete

Sorry, I do not know this quadrant. What's "MEL"? How are its controls assigned in FS? If FS sees them in its assignments, then they can be seen in FSUIPC -- perhaps you are looking on the wrong pages in the FSUIPC Joysticks tab? How many separate engines does it handle? Elite has never once consulted me about their use of FSUIPC, and they've used it and the SDK for their commercial ventures without any agreement or thanks or payment, yet they continually blame it for all of their errors. I am therefore not really very favourably disposed to support their products at all. However, if you can investigate these assignments a bit more and tell me how things are connected to FS then maybe I can assist you. Regards, Pete

But didn't the wording "you can apply a fixed brake pressure here, or else use the byte at 0C01 to apply brakes emulating the keypress" suggest otherwise? It is explicit in saying that 0C01 (for example, here) is an alternative to this, after all. Regards, Pete

Well, the first looks to be simply that WideServer wasn't ready: As you see, the connection was okay after WideClient was running for 71 seconds. The error after 9 was probably simply because the Client couldn't connect to the Server whilst FS was still loading, or not even loaded. The other error: was obviously where FS had been closed down. The shutdown request has been seen, but the Client takes that as a request to close client applications, that's all. Regards, Pete

I think that may be a PM PFD problem. At least, there was something exactly like that happening to some folks with the CDU. Have you asked PM support? HmmmWhich ones do you think are "interesting"? Does the log end there, BTW? Regards, Pete

I don't know the latter two, but please update to the current FSUIPC (3.44). I really cannot support old versions. Sorry, I've no idea. All that FSUIPC does when you click on the FSUIPC entry in the Modules menu is open a dialogue -- a standard, run-of-the-mill dialogue window using standard windows tools. Maybe something you've installed has corrupted or changed part of Windows itself? The main library module used is COMCTL32.DLL. Regards, Pete

It is a function of FSUIPC. It emulates exactly the way those locations worked in FS98 (and, in fact, how the keypresses (F11, F12) work). The whole point of FSUIPC was originally to provide FS98 compatibility in FS2000. Those locations are still emulated for backward compatibility. Yes, of course. Just set the brakes directly. The brakes are operated at offsets 0BC4 and 0BC6. Regards, Pete

1. You are using an out of date version of FSUIPC. Please only ever use the latest. I cannot support old versions. Current is version 3.44. 2. Did you bother to look at the log? Somehow you have entered your user name and email address, but no valid user key. You are not user registered, therefore your program cannot gain access to FSUIPC for anything other than checking the version number. Here, look: and You are repeatedly reading these things approximately every 110 mSecs, which merely fills the log with these illegal access reports. You need to register your FSUIPC with a validly purchased user Key. You also should update to version 3.44. Regards, Pete

What does the FSUIPC Log file show (close FS first, then show me). Are you using a user-registered FSUIPC? If not, your program should be getting an unaccredited error. If so, maybe there's a problem with your user key. Have you tried using FSInterrogate and FSUIPC IPC logging as I suggested? Pete

I don't know Delphi, so I don't know how it evaluates something like height * 3.28084 / 256 but I'd use (height * 3.28084) / 256.0 in C, just to be sure. Does "round()" take a floating point number then? Again, in C IAS / 128 would give an integer, not floating point -- you'd need IAS/128.0 for that. Please try using FSInterrogate in parallel with your program, to see what it is getting -- it is very usefull as it shows the values in all sorts of formats (and, by coincidence, it is also written in Delphi). Your "0" for ground altitude may actually be correct for all I know. And use FSUIPC's IPC read logging so you can see what FSUIPC is actually supplying you. These debugging aids are there to help! Regards, Pete

Sorry, I don't do that. You might find it somewhere else on the Internet -- do a search -- but I don't want to hear about anything regarding older versions. If you have problems with the current version, please explain them here. Regards, Pete

Sorry, I think you are more likely to get answers to that over in the FS2004 Forum. This really is the wrong place. Regards, Pete

If it can only write one location, or is limited to 1, 2 and 4 byte values, then, it isn't actually your ability in question, is it? It's a limitation of the software driver you are using. It seems a very odd way to implement joystick axis control. Are there others using this method? It basically bypasses everything and acts like an external autothrottle control. I don't see how any aircraft implementation would work with that except using FS's own A/T. Or maybe you can program it to detect the A/T engagement and suppress inputs then? As far as special Airbus thrust values, I really don't know anything about those. You will certainly need to discuss that with Enrico. Regards, Pete

Of course. You always had that choice in any case. Regards, Pete

If it only writes to offsets, try writing the controls as I suggested. Pete

Quite honestly, I am totally lost :? , so I assume it must be 100% a PM issue of some sort. Are you writing a program to read your throttle levers and write the calibrated results direct to FSUIPC offsets? That direct method of throttle control would be one used by non-FS auto-throttle implementations as well, so it will get very tricky. Are you writing the auto-throttle code too? If, for some reason, you are just wanting to bypass normal joystick axis assignments and driver calibrations I think you still need to use the same controls -- either AXIS_THROTTLEn_SET with parameters -16383 to +16383, or the older FS98 compatible ones, THROTTLEn_SET. If you need to do this via offsets then do so via the two 32-bit values at offset 3110. Regards, Pete