Pete Dowson

You probably need help for that program, which I'm afraid I've never heard of. But it sounds like you've not installed FSUIPC. Regards Pete

Your registry isn't correct for your FS9 installation. You should fix that. There's a program available from someplace that will fix it for you. Ask in the FS2004 Forum. Why on Earth are you opening "FSUIPC documents"? I asks you to find FS9.EXE so you must go and find FS9.EXE and select it, as it clearly says. That will be how it gets to know where FS9 is! There's no othere way if your FS9 installation is faulty, as it evidently is. Regards Pete

Hmm .Strange. I'll do some tests here -- but it'll be tomorrow. First, though, can you tell me exactly which version of FSUIPC you are using (the version number). And check whether the one in the download Links subforum is later. If so, please update first and test again, just in case. I don't want to spend time testing it if it is something already fixed. You can set it where you like along your axis. That's the point. Or am I misunderstanding you? Pete

Oh, yes, of course. Sorry. The only thing FS will see is the final "OUT" value, as you can see if you do the logging. But if you don't have the correct stick sensitivity mode set, I think it does something extra based on the timings of incoming values. Depends on the slope. You can see in the graph the changes it makes. But possibly in the part of the graph that "max input" point reaches it is approximating the linear point too? Do you mean the pair of centre values, allowing a null central zone on axes like elevators, ailerons and rudders? They set the range over which 0 (centre) is sent. A centaral dead zone is used to prevent slight jitter or accidental movement affecting those controls. On throttles it defines the idle area in the 4 throttles calibration when a reverse zone is calibrated. It doesn't apply to brakes. Pete

Maybe throttle sensitivity is the problem? See if it still occurs with the throttle lever(s) parked in a dead zone (idle or full thrust, which should both be calibrated to avoid jitter). Or if you are assigning throttles through FSUIPC you could increase the Delta value a bit. It would give you fewer discrete throttle positions but also less sensitivity to jitter. Regards Pete

No, it certainly shouldn't have that effect. The slopes still calibrate between the minumum and maximum possibly FS values, but just distribute the intermediate values differently -- flatter centre, steeper sides, or vice versa. Obviously if you change the slope after editing the values you'll undo those edits. The OUT value is what is being sent to FS. You can see exactly what gets sent by using the AXIS logging, which logs the actual controls being sent. I've no idea how FS decides to lock brakes, but for realism I would have thought it would be related to the ground speed and therefore how fast the value changes in any case. A sudden hard application is surely more likely to lock than a steadier one to the same level? A strong but steady increase should not lock them -- it's must relate to the speed decrease as well as the surface friction? So what you are probably seeing with a steeper end slope is a higher application at higher speeds. To prevent brakes locking surely you press steadily, not suddenly, or "feather" them (press/release/press/release, gradually increasing the press time over the release time) -- as in car driving in wet weather. I don't think reducing the brake effectiveness is a realistic or desirable approach. There's no formula. The range from minimum to maximum is divided into 128 points, as plotted on the small graph you see on screen, and the actual values are linearly computed between them. It's too inefficient using complex algebra -- tables are used and the same tables plot the curve you see. Try and relate your brake pressure to the ground speed and not a specific pressure value. I think it must be the faster (ie earlier) application which is confusing you. Also make sure you have the FS "stick sensitivity mode" set correctly -- see the advice on the in the FSUIPC user guide. Regards Pete

Are you sure you posted this in the right place? It looks like you need iFly support? Pete

Well, apart from continuously toggling the flight director on and off (about 20 times per second): 534531 *** EVENT: Cntrl= 66288 (0x000102f0), Param= 1 (0x00000001) TOGGLE_FLIGHT_DIRECTOR the only AP commands were: 534671 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 0 (0x00000000) AP_VS_VAR_SET_ENGLISH 534671 *** EVENT: Cntrl= 66124 (0x0001024c), Param= -100 (0xffffff9c) AP_ALT_VAR_SET_ENGLISH 534671 *** EVENT: Cntrl= 66103 (0x00010237), Param= 1 (0x00000001) AP_PANEL_ALTITUDE_ON 534671 *** EVENT: Cntrl= 66102 (0x00010236), Param= 1 (0x00000001) AP_VS_SET I assume the aircraft code is doing that FD toggling, though why I have no idea. It seems to be unrelated to your button usage, though, doesn't it? So, now you know what you need to send FS to enably the VS. You can make the one button send those 4 controls one after the other. you wil have to edit the FSUIPC INI file to do that. The log above shows you the control number ("Cntrl= ..." and the Parameter (Param =) for each of the 4, so it is easy enough. Something like this in the [buttons] section: xxx=Pjoy,button,C66036,0 xxx=Pjoy,button,C66124,-100 xxx=Pjoy,button,C66103,1 xxx=Pjoy,button,C66102,1 where xxx are incrementing numbers after those already used, and of course joy,button identify the joystick and button number. Regards Pete

Apart from the sound playing facilities in the Lua plug-in libraries, there are no facilities in FSUIPC for manipulating sounds. In fact I don't know of any way to manipulate FS sounds directly. There may be an add-on which replaces sounds with more realistic ones, but detecting windows being opened and so on would mean having that provision built into the add-on aircraft. Regards Pete

You are most certainly making a mistake then. You must enter all three parts -- email, name and key, EXACTLY as originally used. You should cut and paste the details if you aren't sure. The registration system has not changed since you purchased your keys, and the operating system or computer you are using is irrelevant. And of course make sure you enter the FSUIPC3 details for FSUIPC3 and the FSUIPC4 details for FSUIPC4. Earlier you did not say your keys were refused, you said Perhaps you'd care to explain the difference? Exactly what do you mean? By the way, please do make sure you are using current supported versions: 3.99 or later for FS9 and 4.70 or later for FSX. Regards Pete

Nor me, necessarily. All of those from FS are listed by the names Microsoft chose for them. FSUIPC reads them from the tables in the FS module called "CONTROLS.DLL". The best way to decide what you want to assign is to enable "event logging" in the FSUIPC Logging tab. Then, when you use an FS control, using the mouse on screen or a normal FS keyboard shortcut, the event it caused will be logged and the log file will include the name. Most of the names are actually reasonably explanatory. There are only a few which are a bit obscure. And, unfortunately, there are also a few which don't work -- ones which Microsoft added to the tables but never got around to providing any code for! In addition to the FS controls, FSUIPC adds a few of its own. Those are listed in the Advanced User's guide installed in your "FSUIPC Documents" folder, in the FS Modules folder. That's where you'll also find the list of FS controls -- but no descriptions, sorry. If you have specific ones you want to ask about please do. I may or may not know what they do. Regards Pete

No. It wasn't an axis assignment then -- must have been a button, assigned in [buttons] section. I know early editions of Saitek yokes had a problem sending a spurious button press when other things were used. Maybe you have a similar fault on your equipment. Regards Pete

You posted your support question in the Announcements subforum for some reason. You are lucky I spotted it -- I've moved it here where it belongs. Well, sending that command wouldn't disconnect the A/P (it would be stupid if it did, wouldn't it?). You need to see what else is being sent -- enable event and axis logging in FSUIPC logging, and try again, then look in the Log and see what controls or commands are being sent. The iFly 737NG is reported to be rather over-sensitive to yoke movements, so it might simply be that the USB scanning done by Windows when you press a button is seeing a slight jitter in the elevator or aileron read-out. If that's the case you could probably deal with it by either calibrating a larger central dead zone on the yoke, or maybe finding the sensitivity setting i read about in the iFly configuration and reducing it. Failing this I think you'd need to check with iFly support. I'm told it is very good. Regards Pete

If iFly don't provide any controls or keystrokes to operate things, and you can only do it with a mouse, then I'm afraid you can't do it with FSUIPC. There is no mouse emulation. You might be able to use something like Luciano Napolitano's "Key2Mouse" to convert keyboard combinations into mouse operations. Otherwise ask iFly. I'm sure they had the intention of making everything usable for cockpit builders so they should have thought of that too. Wasn't there talk of an SDK? Regards Pete

You had an assignment to the brakes in there then. It wouldn't help me for anything, but if you want to know what you had assigned to the brakes I can tell you from that. Just post the [Axes] section only in a message here. Pete

That's normal. The VS dial isn't usually operative until VS is engaged. Note that you usually need to set an altitude to climb or descend to first. If the aircraft uses standard FS controls you should be able to find out by enabling event logging in the FSUIPC Logging tab, then operating the aircraft using the mouse and checking the FSUIPC log to see what controls were sent. You could also check what you are doing in a default aircraft such as the default 737. If the aircraft doesn't use standard FS controls then you'd need to seek alternative means. Check the "User Contributions" subforum to see if there are any clues there. Regards Pete

FSUIPC doesn't invent numbers. If the brake controls are arriving, it shows them. Use the Axis logging and check for yourself. Even if it was, it cannot get assignments to brakes unless something recognises them as assignments to brakes. You are missing something. All FSUIPC is showing you are the values FS is getting. The calibrations tab is nothing whatsoever to do with assignments -- it doesn't read joysticks, only FS controls! Remove the FSUIPC INI file from the Modules folder to force FSUIPC to make another. If there's then no brake movement it's an assignment in FSUIPC which you've missed. On the other hand, if you still get movement on brakes it must be in FS, unless Saitek drivers can themselves send FS controls (which is extremely unlikely). Regards Pete

They can only do that if you have an assignment to do that. Maybe you have assignments both in FS and in FSUIPC? Well, that's going to be complicated then. Maybe the Saitek drivers are also assigning things? That's three places for you to look, to start with! ;-) Nothing is ever linked between an axis and an FS control without an assignment somewhere. Regards Pete

Yes, I get that on my main flight PC, the one where I have the latest video drivers and nVidia Inspector set to give me the best display -- plus the external FPS limiter. Horrible, isn't it? It isn't FSUIPC which maintains or updates those displays, but FS or SimConnect by request from FSUIPC. And it doesn't happen on two other systems i run (including my test and development PC). I'm pretty sure it must be related to video settings somehow. So, sorry, I've no answer, except experiment with different screen settings, video driver options, etc. Luckily I only use screen overlays for testing (e.g. the Logging on-screen option in FSUIPC). If you do find out exactly what causes it, what actin can stop it, do let me know please. Regards Pete

There's no difference that side of FSUIPC. All the differences are in the way FSUIPC gets data from FS, and that is happening for all data all the time -- SimConnect feeds it to FSUIPC when it changes, asynchronously, and whether any one asks for any data or not.. So, I really doubt that it is the reading of the data which is responsible, but whatever your program is doing with it. Run the test with your program only reading it and not displaying it. What is the most likely problem is that your PC is much more loaded running FSX than it was with FS9, and your extra activity is affecting FS's performance. Regards Pete

Yes, that's easy to see: Public Class Form1 Dim airspeed As Offset(Of Integer) = New FSUIPC.Offset(Of Integer)(&H2BC) Dim onground As Offset(Of Short) = New FSUIPC.Offset(Of Short)(&H336) You are reading 0336 which isn't used as far as I know. Regards Pete

The only way I can think of is to read the pathname for the loaded plan from offset 0130, and load that and decode it. That wouldn't give you "nearby VORs" though -- you'd need a data base for that. Regards Pete

Well, there are an infinitesimally small number of problems arising such as yours, so they must have something right. Anyway, use that in your argument for a revised registration. You still need to raise a problem ticket with SimMarket. I can't do anything for you. Sorry. Regards Pete

There's no pre-processing except for the data being checked and found to be representing a button which has has been programmed in FSUIPC. Then the data received won't cause an event, only a button signal to FSUIPC. What other pre-processing do you think there might be? It is an intercept on one of the two devices involved in the SerialFP2 < ---> FSUIPC <---> VRIdevice relationship. The intercept occurs after the programmed button check, but before any filters set in the INI file, and before the data is passed along the chain (either way, to SerialFP2 or the device). But this is also after it has been copied to a possible secondary read channel. And, of course, as you found, it only works for a VRI device opened by FSUIPC initially, as a result of the INI settings. Regards Pete

Sorry, I have no idea what "FO_JoyStick64 Link FSUIPC_OUT Offset $3340 Length 4 commands" are in the first place. Please, if you want to learn more about FSUIPC interfacing, download the FSUIPC SDK. By "keys" do you really mean "buttons"? As documented, offsets 3340 and following are the offsets for 288 virtual buttons! Is that what you mean? I think you need to refer to the support for the software you are using to interface to FSUIPC, because I'm afraid i do not understand your terminology at all. Maybe they can explain it? Regards Pete