Pete Dowson

You posted your Support question in the FAQ subforum, where it is just luck that I saw it. Please, for Support, always use the Support Forum! You can have different email addresses by the names MUST be the same. There's no way round that and it is clearly documented. Something's got to actually identify one person! All you can do is ask SimMarket if they would reissue one or the other with the other name. You'd need to raise a problem ticket for that. Pete

How do you work out whether are port is listening? I don't know how to do that. What is "webclient"? Anther utility program? You appear to have supplied an FSUIPC4 log file and the FSUIPC4 INI file. But those aren't really relevant -- except that the FSUIPC log ends way before the point that the WideServer activity would start up. The sim has to be ready to fly before clients are linked, and the Log entry indicating this would be: 78687 System time = 09/09/2013 09:29:16, Simulator time = 09:28:12 (08:28Z) 80918 Aircraft="Boeing 737-800 Paint2" 85941 Starting everything now ... As you see, in my very basic FSX installation it's can be quite a while before that stage is reached. It won't happen whilst FSX is stuck at the initial selection menu. You seem to have supplied a Log stopped at only 9 seconds into the session. Why? Furthermore WideFS has its own logs -- WideServer log on the Server and Wideclient log on the client. It is those i would need to see. If the Client log says the connection is refused than it will be because that's what Windows told it. It simply reports the error returned by Windows. it is probably a firewall problem on one or other of the two PCs. Or both. BTW in future if you do send an FSUIPC4 log file please close FSX down first. That completes the log with additional useful information at the end. Pete

Sorry, can you re-phrase that as it seems not to make sense. I have no thoughts on them at all really. if they are the results of correctly calibrating to the positions you want, and work with the aircraft you use, then they are fine. I don't have your hardware or your aircraft, so I've no comparisons to make. Did you never bother to do the axis logging as I suggested, so you could see what was making your throttles drift? Or was that drift just a misunderstanding of what an Idle engine does? Regards Pete

Please first update to FSUIPC 4.92. I'm afraid I don't know anything about the T7, but it may need special attention like the 737NGX. Pete

See my first answer. The only other ways, if the A321 will obey the older Throttle commands, are either: 1. Give up part of the main lever movement for reverse, calibrating idle some way forward of the detente, or 2. Assign one or more separate reverser axes. You'd probably be best off using the button type assignment I mentioned. Pete

I am not at all surprised. Mouse macros operate by jumping directly into the code part of the Gauges, at the point where the mouse click would be processed. Every time the code is changed you have to re-make all affected mouse macros. There's really no other way. The process of making the macros is the process that fills in all those addresses you see in the macros -- they are code offsets in the respective GAUge or DLL file. I'm not really sure why you are using mouse Macros in any case. Didn't a Mr. Jouni Tormanen create an "IFlyToFsuipc" program to map the switches etc to FSUIPC offsets? Regards Pete

Wow! How interesting! I suppose firmware is cheaper in the long run (written once) than adding the switches (every time)! <G> Pete

I assume the software you are using is Jouni Tormanen's "IFlyToFsuipc"? I'm afraid I have no details of that software. You'll need to refer to its documentation or ask the author. FSUIPC only comes into it because the offsets are assigned, en bloc, for Jouni's program to use. Even that is in some cryptic form I do not know. Sorry. Regards Pete

Yes, but you are confused between engine rotation speeds (N1/N2) and throttle control settings. The throttle control is not directly linked to the N1 or N2 values, the latter are a result of the throttle inputs, they are not a copy of the throttle control value! The idle N1 of 34% is obtained by a control input from the throttle of zero (0) when the THROTTLEn_SET controls are used, or -16384 when the normal FS AXIS_THROTTLEn_SET controls are used. The latter have no reverse range at all. FSUIPC can only provide a reverse axis control with the THROTTLEn_SET controls which have the idle at 0 and every negative value, down to -4096 (by default) as reverse thrust (the -4096 is when the AIRCRAFT.CFG defines the max reverse as 25%, 25% of 16384, full thrust, is 4096). Naturally the throttle value cannot be negative before being zero. Is should be possible as far as I know, though it may be some "realistic" implementation by PMDG -- you'd have to ask them. Try it on the default 738, for example. But as far as FS and FSUIPC are concerned, It is nothing to do with N1 or N2. It is simply the throttle input value that matters, not the current N1 or N2, or anything else to do with the engine simluation. BTW surely your engines are pretty much idling by the time you touch down? Before the flare you should have pulled the power right back already. Landing is just a stall at the right height for a soft "crash". Regards Pete

It was the phrasing "Increment and Increment fast at the same time" which confused me! Have you assigned the same ordinary increment / decrement control to both the Press and Release action? That's normally essential for rotary encoders -- each click either presses or releases the button. By assigning to both events you get twice the speed already, yet can still adjust by one increment when needed. In order to scan the encoders frequently enough to get most, if not all, clicks, when it is turned fast, you can also change the scanning interval -- the "PollInterval" parameter as described in the Advanced User's guide. It defaults to 25 (mSecs) for a 40 per sec scan rate. You could try anything, even down to 1, but I'd recommend trying something like 10 or 12. I've not really found any circumstance where these steps don't give you a good enough value changing facility. You may perhaps be getting mixed up with the GoFlight encoders, which actually send a different signal (button number) when turned fast compared to when turned slow. This is documented in the User Guide. I don't remember whether any one ever used both fast and slow increments on other species of encoder. However, yes, it would be possible using a Lua plug-in. If you don't find the ways I suggested adequate and you want to try using a plug-in, it would need to be one which received the button presses and timed the gaps between successive ones, sending the ordinary inc/dec if the time was greater than some value (to be determined experimentally), otherwise sending the fast one. This would tend to give you odd numbers most of the time because the first press would always be slow. However, obviously that could be corrected then by a separate slow turn. Ideally such a plug-in would be loaded to be resident (i.e. via the [Auto] method), and use the event.param function to call the routine to deal with the action. The buttons would be assigned to LuaValue <plugin name>, which passes a parameter value (deciding the action needed) as ipcPARAM. For an example of a plug-in which uses timing to program as many as THREE different actions to a single button, see the "TripleUse.lua" plug-in in your Examples pack in FSUIPC Documents folder. It doesn't use event.param, only event.button, but then it is only dealing with one button and didn't need the luxury of being assignable to a button. Regards Pete

Assing decrement to CCW and increment to CW. Why would you want to assign both to CW? Pete

As far as I know there's really no axis range you can use before the detente. But pulling back the throttle presses a button. You can assign that to the ThrotleN Decr (N=engine nmuber) with repeat allowed. I think that's what most do. In the 4 throttles calibration tab check the NRZ (no reverse zone) option -- do this before calibration. Pete

Good. The "never" option is available in 4.92, which will replace 4.91 tomorrow (probably within 8 hours, in fact). Pete

Maybe it's interlinked with the speedbrake which if armed should auto-engage on touchdown? A bit weird if it is. Any other reports on the NGX forum? It can't really be specifically FSUIPC because FSUIPC doesn't care about touch down. Axes are left to their own devices, literally in fact! Could it be to do with VNAV and/or just AutoThrottle? I would presume you disconnected the A/T on final approach or earlier? Pete

What do you mean by 'other'? There's only one log file, and there is ALWAYS a log file produced if FSUIPC is ever run. If there's no log file then FSUIPC has never been run. I suspect you don't know what you are looking at. Please see the FSUIPC installation or user guides for details of how to find files in Windows Explorer. Pete

4.90 is not supported. 4.91 is the earliest supported version for FSX/P3D, and 4.92 is released tomorrow. No. SimConnect returns that error if the weather is at that moment not obtainable. This is usually because it is being updated by an external agency. It is a harmless error and is only logged because of the logging options you have selected. FSUIPC knows nothing about full screen / windowed screen changes, but it has been reported that crashes during such actions are quite frequent. I think it must be down to drivers. I seem to have no problems with the latest nVidia drivers. Error 0x000000fd is documented like this: "This bug check with the blue screen error, or stop code 0x000000FD DIRTY_NOWRITE_PAGES_CONGESTION indicates that there are no free pages available to continue basic system operations. This bug check usually occurs because the component that owns the modified non-writeable pages failed to write out these pages after marking the relevant files as "do not write" to memory management. This indicates a driver bug." which concurs with my view that it's a video driver problem. As far as checking in FSUIPC is concerned, unfortunately the error data is of little use since it refers to an out of date FSUIPC. I suggest you wait for 4.92's release (in less than 12 hours I hope) and try again. If you still get a Windows log referring to FSUIPC, let me see it please. Regards Pete

Could your throttle levers be doing that? Or maybe you have conflicting assignments? Try using the axis logging in FSUIPC (loggng tab in the options) to see whast is happening. The LOG file is placed in the Modules folder, but it may be more useful if you did a test with FS in Windowed mode and enabled the console logging option so that the logging occurs on screen in real time, beside the FSX screen. Regards Pete

Same place as the INI file you must already have looked at! There's only one current version (soon to be 4.92). The difference in facilities depends whether you pay for a key and register it. There are no Lua plug-in sound facilities in FSUIPC for unregistered users. Regards Pete

Hmm. Very strange then. Maybe they are using the FSUIPC offset facilities, the same ones Lua uses. Are you sure your FSUIPC isn't very much out of date? They were added in version 4.70 in April 2011 as a feature for Registered Users. I assume you have Registered correctly? I wonder, then, how it does that if it can't find the sound card? That makes no sense at all. I think you need help from the author. If you add these lines to the [General] section of the INI file: Debug=Please LogExtras=32 then FSUIPC will log sound details.Do that and show me the Log file, but close FSX down first. Pete

FSRAAS doesn't use FSUIPC for sound. The sound card details in the INI file are only used by the FSUIPC Lua plug-in sound playing facilities. However, the fact that neither FSRAAS nor FSUIPC sees the sound card is probably a symptom of the same problem. Your card probably isn't installed correctly, or at least the drivers aren't registered in the Windows registry. Try uninstalling via the Windows device manager and letting Windows reinstall. How is FS sound working? Is that using a different sound output? Pete

No, all PMDG aircraft for FSX interface directly with SimConnect. FSUIPC is not used at all. You can check that SimConnect is correctly supplying the weather to FSUIPC either by logging weather (FSUIPC Logging tab) and looking at the Log file, or probably easier by using the WeatherSet2 utility, available in the Download Links subforum. Regards Pete

Ah, sorry. Yes, after going back to the very first message in the thread I see I got confused on the way! Yes. I would probably have suggested this early on had I not confused myself! Anyway, as long as all is well now ... Regards Pete

Do you mean the plug-in Lua file which patches the frictions table in SIM1.DLL? There is a default patch set which doesn't need the plug-in, just inserting a fixed set of values. Check the "PatchSIM1friction" parameter in the FSUIPC4 Advanced Users guide. Well, that's what changing the table entries does. Why not look inside the file and see what it does? Or read the Lua lbrary documentation for it? Really? I've no way of measuring it. How can you tell? What values have you tried? This isn't really my area of expertise, all I provided was programmable access to the ground friction tables. Regards Pete

No, you missed the question yet again! How did you measure the 1 in the first place, when the logging clearly shows 0 being sent? What told you the actual view was 1? Yes, but that also answers no questions. Why would you want to switch to a view and back again so fast, afraction of a second, that the timing, as you called it, would come into it? Yes, of course. FS only reacts to changes in an axis value. Else it would spend most of its time sending itself controls for every connect axis for no reason at all! But that doesn't matter, because you don't care about an axis not changing. It only means anything when it changes. Aha, finally the last section of your explanation does clarify some things. But still not the forward view of 1. Where does that come into any of this and, again, how did you measure it? Regards Pete

Well I'm certain one of the options i listed will work. And FSUIPC won't "ignore" anything if you tell it to handle it. Right. I wondered about that. It seemed unlikely for PMDG to do something completely different again. (Though saying that, it does seem that Aerosoft did something completely different between the Airbus X and the Extended version). Regards Pete