Pete Dowson

I did all that, and it worked perfectly. But I did find a problem which I think I can fixto get the Window details saved correctly in the FSUIPC INI file you have to close the window using the "AdvDisplay" toggle Hotkey (in FSUIPC's HotKeys tab). It seems FSUIPC isn't correctly detecting a manual closure nor the closure due to FS closing. Maybe the coordinates you based your computation on weren't the ones you thought? I'll fix the saving of Window data when the window is closed. Whilst I'm doing it I'll see if I can detect when the window is resized or moved, so that I can save then then, too. If I can it should save all this messing. I must admit I did most of my testing using the Lua display window, as it is far easier to get that created and destroyed. Of course, terminating a Lua thread closes the Lua display in much the same way as the hotkey for the RC window, so I never saw the main problem. Mea culpe. I'm afraid this won't be fixed this week as I'm away from tomorrow till next monday. But I'll be on to it then. Regards Pete

Oh, for a specific aircraft. Sorry, I don't know anything about that. Two probable problems with that idea. First is that maybe his multiplier means the number of increments sent with each "click" -- you cannot have a fraction of an increment command. Second, judging by your results, his code doesn't like fractions and is mis-converting your values like .1 into something else. I'm still not understanding. why not use just one MCP, the one which works? Why are you wanting to use two? I don't know any aircraft with two in any case. The default aircraft don't support any of that, and if your chosen add-on aircraft does you'd still be able to program buttons on the VRInsight to set those modes. For LNAV and VNAV you'd need an FMC too. Do you have one which works with your aircraft? Regards Pete

Sorry. What is this about? What are you multiplying? You can block any of the display commands using the filter facilities, as I think i mentioned. But unless you them programmed them yourself you'd then just have useless displays. If you don't want to see them why not just put some sticky tape over them? It would make them less misleading than just having them plain not updated to accord with FS. Why not use it, then? Regards Pete

Only the same was as there was with FS9 -- FSUIPC provides the means for the applications which know about MP traffic to inject it into the tables. There's no difference there between FSUIPC3 and FSUIPC4, so I think you need to look at the application. Is that different? BTW I'm surprised they use MP in FSX. I thought for FSX all those programs injected traffic using AI and SimConnect, not MP. Regards Pete

Yes, exactly. FSUIPC won't change it at all, only pmSystems and the Offset Byte Set command will. Are you watching the pmSystems switch as you use the offset control? Don't forget the "start" is momentary -- it is spring loaded back to "on". So after you write '2' the switch should move to "start", then move back, which will set the value back to 1. But then the EGT should rise and settle correctly when running. After that you can engage the APU generators. FSUIPC has no use for pmSystems offsets. they are totally between your assignments and pmSystems. Pete

That sounds like a problem which existed on some installations which is certainly corrected in 4.602. It only occurred with some setups with buttons but no axes assigned in FSUIPC and it was related to the new way buttons are read. Could you please download the update from the Updates announcement above and see if that fixes it? Just copy the DLL into your FSX modules folder. No re-installation needed. Regards Pete

Hmm. Don't know why. I don't even know how to set it, but I will if I can find it! ;-) Pete

Sounds interesting. I don't know how much direct side force it would need. Probably depends on whether you were fully loaded or not. Did you turn the ailerons into the wind as you should? I don't know. You'll need to ask in an aircraft-knowledgeable forum. It will be the surface LAYER, and surely you would certainly not land any aircraft in a 60 knot crosswind -- you'd divert to a place with a more suitably aligned runway. So a surface wind limit still makes sense if you want to be able to land anywhere you choose. Regards Pete

Sorry, I don't know the PMRJ software at all, only the Beoing PM suite. For that the APU operation consists only of: 1. the APU switch (560F, the one you found) 2. the APU Generators, 5624, 5625 and there are APU bleed and APU fire switches. Bleed is needed for the jet starter. As far as I know all of the APU logic and the subsequent management of electric circuit energizing and bleed air provision is incorporated into the pmSystems program itself. I've no idea if that works with the PMRJ suite or not. Sorry. You really need to ask PM support. If all you are asking about is how to program buttons or switches to write to FSUIPC offsets, then that's easy -- just assign to the appropriate "Offset" control ("Offset byte set" for the above offsets), with the offset you found and the parameter set to whatever value you need to write. Regards Pete

There are two ways. The most useful is to use the Log Lvars lua plug-in, which will give you a real-time display on screen as they change, like those we used to test VRInsight switches. The other is simply to assign a keypress or button the the List local panel variables control in FSUIPC's assignments -- then you have to refer to the list produced in the FSUIPC Log. Pete

The only thing FSUIPC might do when you takeoff is to change from steering tiller to rudder, if you have both axes assigned. But it is proportional -- at 0 knots on the ground it it 100% tiller, at 60 knots whether on ground or not it is 100% rudder, at 30 knots on the ground it is 50% tiller, 50% rudder. But that assumes you are assigning and calibrating to the tiller. If you did that and forgot about also assigning and calibrating the rudder, then what you say might happen, but it would only be a sudden change assuming you take off well under 60 knots, which seems unlikely. Otherwise it would have gradually gone wrong as you accelerated for takeoff. Apart from that, FSUIPC cares nothing at all about whether you are airborne or not, and most certainly doesn't change any axes assignments, values or calibrations depending on whether you are on the ground or not. So, assuming you've not been messing with the tiller, then what you are observing must arise from a different source. I don't see how the USB ports know when you've taken off either. It has to be something in FS or an application interfacing to FS. Nothing outside will know or care whether you are on the ground or not. So this suddenly started happening of its own accord, without you changing anything at all? [LATER] Just noticed your later message. You say: I'm now thinking your improvements might have been more to do with you starting again with a fresh INI, and that previously you had assigned the steering tiller and not calibrated the rudder. Regards Pete

They are a lot better in FSX than in any previous version, but still not right for all aircraft. Since the aircraft just moves with the air when off the ground it should feel fine. Gusts are not the same as turbulence which is much more noticeable in the air. But with 60 knot gusts on the ground I would have thought most aircraft would be grounded. What do you mean by "unrealistic" weathervaning? Not enough? In 60 knot gusts I'd have had to tie my training aircraft (when I used to fly for real) down really well and hope for the best! It removed all realistic wind effects on the ground by reducing any cross-wind on the aircraft to 1 knot, no matter which way you were facing. It was intended for those who simply found they couldn't taxi in a straight line with any wind present at all. It shouldn't really be needed as you should be able to use a combination of rudder and aileron to overcome most "safe" wind speeds. (For definition of max safe cross and tail winds look them up in the specific aircraft performance manual). But FS9 and before had poor ground friction so the effects were certainly a bit exaggerated at times. There's no way to do real direct wind control in FSX without setting Global mode, which makes the weather the same everywhere in the world. If I used that to provide a taxi wind control on the ground then you'd have lost the world's true weather after takeoff. Best to tie down your aircraft in such weather and go fishing! ;-) More seriously, programs like ActiveSky do provide good direct control facilities and limits on surface winds, things like that. That's really the best way to go. Regards Pete

Maybe, but Explorer file exchanging doesn't mean other programs aren't blocked. No, everything for WideFs is okay. It is a networking problem. I've no idea how to fix network problems except by trial and error. That's always worked for me, eventually. sorry. I'm placing bets on that wireless arrangement. Can't you try a wire, just to check? Pete

That's okay. That's okay too. So, it sounds like a simconnect problem -- these are quite often caused by attempted FSX re-installs, because SimConnect is never properly uninstalled. Is there an FSUIPC4.LOG and INI file? If there's a log file, show it to me. Regards Pete

In that case, the most likely reason for this: is because the devices have "gone to sleep". You need to disable Windows power management on all your USB hubs. Check their properties in the Windows device manager. There's really no other possible explanation. "Re-scanning" in the Axis assignments does nothing but wait for an axis to change -- if FSUIPC can recognise an axis changing in the options then so it will normally. There's no difference. This other problem: Sounds like rudder trim is taking over. have you got the rudder trim axis assigned somewhere? Unless your pedals are actually faulty there's nothing else I can think of which could do what you say. Regards Pete

Sounds like you are using an old version of FSUIPC. Please update to the current versions (3.98 or 4.60). After you've updated to a supported version, re-check your rudder and come back if it is still not right. Pete

Sorry, but I cannot support such an old version. Please always make sure you are using a currently supported version before posting questions. You can always find out by reviewing the Announcements in this Forum. The install log shows everything is okay, except for the very much out of date version. After installing the current version (4.60), check the DLL.XML file, which you will find in "C:\Documents and Settings\Administrador\Datos de programa\Microsoft\FSX It has probably been corrupted by another installer. I've seen several instances of that recently. If you rename it and reinstall FSUIPC4 again it will create a working one for FSUIPC4, and after you've checked that we can look at the bad DLL.XML to see what was wrong with it. It could be as trivial as a missing ">" -- i think there's a rogue installer around which does that. Regards Pete

I replied by email, but would prefer to keep everything here, please. You can paste Logs into messages here (enclose them as "Code" using the button provided, to keep everything tidy). Don't bother with INI files unless you've been messing with them. Anyway, you have some sort of Network problem. The error reported, as shown in the client Log, is: Error on client pre-Connection Select() [Error=10060] Connection timed out That's all Windows tells us. The Server never sees anything at all from the Client, so I suspect there's a block -- a firewall probably. You'll need to deal with that. I suppose you did check that your FS PC has IP address 192.168.1.3? Wireless networks are always more finicky. I would never advise them for WideFS connections, they are too prone to lose stuff or cause many retries, clobbering things quite well. I know some folks use them okay, though, for relatively low load uses. There's some stuff in the WideFS docs about wireless, folks contributed. But there's some block anyway. Firewall at the FS end probably. Regards Pete

You are making a mistake then. ZIP your FSUIPC.KEY file and attach it to an email to me at petedowson@btconnect.com . Inlude the new registration details you are trying to use,, and the FSUIPC.LOG file from FS using the version you installed. Regards Pete

Yes. Most external autothrottle programs do, and my own drivers for PFC and Aerosoft GA28R cockpits do so too. I think there are some add-on aircraft using such a method too. The offset isn't a percentage between 0 and 100, but a value between 0 and 1 (or negative for reverse) in 64-bit double float format. It should work okay in FSX as SimConnect lists the variable it is tied to as writable, but I've never tried. I've always used the original offsets dating back to FS98 days, the 16-bit integer values in the 088C etc ranges. Whether the offset(s) you've chosen work in FS9 or before I don't know. They link direct into values in SIM1's innards. If the Sim engine is using them as source data they'll work, but if they are result data they won't. You can't. You can map -0.25 to 1.0 onto -4096 to +16384 by simple arithmetic -- multiply by 16384. If you really have a value from 0 to 100 then you have no reverse, so multiply by 16384 and divide by 100 to give you all the positive range. If you want to allow the throttle to be disconnected by options FSUIPC provides for things like external auto-throttles or fly-by-wire applications you should consider using the offsets 089A etc instead, as described in my offset documentation. Regards Pete

You must be using an old and unsupported version of FSUIPC, then, as the last two user releases have allowed different email addresses. Just download and install the current version and enter your new WideFS registration when you are given the opportunity by the Installer. Please, before posting questions here, always check the Announcements at the top of the Forum. They will tell you what versions are supported amongst other things. Regards Pete

I expect someone who knows this sort of code will chip in and help, but my first reaction is that "integer" is probably the wrong type for these one byte (8-bit) values. Normally in a 32-bit environment an integer is 32 bits, or 4 bytes, so you are reading, into each of those variables, 4 times too much data and thereby getting a completely wrong result. Regards Pete

If you mean the scrolling message bar, again FSUIPC can only do anything with than when it is a message it is sending to FS on behalf of another program. The same message bar is used by FS's own ATIS and other things. FSUIPC has no control over fonts or position or size. Yes, they are not the same, they are part of the gauge system. The only stuff using the fonts which you say look corrupted are the assorted FS message windows and the red warnings like PAUSE, BRAKES, SOUND, COCKPIT, and so on which occur in the corners unless you've got them disabled. Regards Pete

I'm not sure why you are posting this here. Try the main FSX forum, see if anyone else has had such a problem. The only time I've ever seen that has been after a faulty video driver update -- in that case uninstalling the video drivers and installing a newly downloaded version fixed it. Maybe there's some corruption happened in your video driver settings. FSUIPC can't change the colour of any text in FSX unless it is sent via FSUIPC. You mention the "Ctrl+Z" texts tooI assume you mean the Shift+Z details? FSUIPC has nothing to do with those. Regards Pete

Odd -- that doesn't seem to happen here. You get that with all default aircraft? FSX or FS9? Sorry, I don't understand this part. Where do "macro" commands come in? If you are only talking about add-on aircraft, like PMDG or LevelD and so on, then what you are seeing is probably related to the use of keyboard commands being used in SerialFP2. I've not tried any of that, but I most certainly would not like all those controls sending heaps of keyboard commands. The queues get too long. Unfortunately, the normal method for keeping the MCP display the same as the value set in the aircraft MCP cannot work for PMDG aircraft and some other add-ons, because their MCP is implemented internally to their gauges and the values cannot be read by program. If you want to use external hardware instrumentation like the VRInsight devices, then really the PMDG aircraft are the wrong choice. You need to use default aircraft, or at least aircraft which use the default autopilot. some though do come with an SDK to allow external devices to be interfaced -- the Level D aircraft, for example. In other words, if all your difficulties are with the PMDG aircraft then the only answers are either to not use the VRI MCP or to not use the PMDG aircraft. I think trying to use them together you will always have to ignore some of the readouts. If you mean will Sim-Avionics work with, say, PMDG aircraft, then the answer is no, I don't think so. Sim-Avionics, like Project Magenta, replaces all of the systems in your aircraft. They have their own autopilot, overhead, and instrumentation. That's the whole point. You take all that outside of FS. You can use any flight model in FS, just no FS panels. The default aircraft would be fine. Incidentally, for the VRI MCP-combi radio panel, I am changing FSUIPC so that you can program the radio buttons after all. This would enable you to stop them working, -- easier than adding a filter. This change will be in 4.602 and 3.982, later today. Regards Pete