Pete Dowson

Yes, that's the normal maximum reverse thrust provided. It's set in the Aircraft CFG files -- in fact FSUIPC converts the -4096 extreme into the max reverse value set for the aircraft, which is usually less, in fact. It won't show any value other than the -4096 in the calibration, but it should be converting that value to whatever the aircraft sets. The value it uses is available in FSUIPC offset 0B00 (as a proportion of -16384: e.g. -4096 for -25%). That forms the lever limit of the calibration. Please always state version numbers of my modules when asking questions or reporting problems. Regards Pete

There's no version 7.3 of FSUIPC. The highest number so far reached in 4.311. FSUIPC doesn't do ANYTHING on its own. It is an INTERFACE program, to allow other programs to talk to FS and control it, and to allow you, the user, to OPTIONALLY assign and/or calibrate joysticks in all sorts of different ways. It gets the blame for all the world's ills, but it is rarely if ever the source of the problems. If you have any issues whatsoever with any joysticks just because you registered FSUIPC then there are only two possibilities: 1. Either you have a complete mess in your FSUIPC4.INI file, resulting from messing about assigning things and not calibrating correctly, i.e. not following any sort of documentation. To fix this simply DELETE the INI file before loading FSX. Then FSUIPC will do nothing. 2. Or you have some additional program or aircraft panel or gauge which uses FSUIPC to do these things and which is itself going wrong. One reason for that might be that your registration has been made will an illegal or discontinued or expired Key. But another might simply be because of a buggy application. You'll have to go through a process of elimination to discover which it is. Regards Pete

Good. I'll not be making a full new User release till something like mid-October, but i'll try to post a version with this change up on the "FSX Downloads" announcement within the next week or so, before I'm off on a short break! ;-) Regards Pete

What's a "repeat" issue? I had to put an 18fps limiter on the POV repeats because if I left it free-running it was far too fast -- you simply couldn't pan to any place predictably. So, if your FS frame rates are at least 18 the panning should be fine, though things may bunch up in SimConnect (don't forget it is an aysnchronous interface). This is especially likely if you have several SimConnect clients. 2 seconds? That sounds far too fast for me for it to be properly useful. I recommend using the FSX native panning in any case. The facility in FSUIPC is bound to always suffer having to work through SimConnect and its TCP/IP or Named Pipes interface. (I assume the latter for you? If you aren't using SP2 or Acceleration then that's really a must for good SimConnect performance). No idea how you can see it as "much worse". Definitely I would expect worse but very usable, as reported by everyone else. Stuttering of inputs is almost inevitable through SimConnect. That's why I bypassed it for direct-assigned axes. I can't do that for panning. You are really trying to use FSUIPC for something it is not designed to do and cannot achieve 100% satisfactorily. That said, the axis assignment method looks as good here as assigning it in FSX, but then FSUIPC is the only SimConnect client when I'm testing it. I really have no use for a POV controlled pan action on my cockpits where additional SimConnect programs are operating (TrackIR on the VFR cockpit, ASX via a Network on the airliner cockpit). Sorry, but I have actually exhausted all possible means of driving the panning facility via FSUIPC. A lot of folks are happy with it. Those that aren't should assign it in FSX. Regards Pete

Ah, I see. Yes, I suppose that's an interesting solution. You must really really like the PMDG aircraft to go to such lengths though. Good luck with it, and keep in touch. If you want to experiment with the new LUA programming interface I'm adding to FSUIPC, let me know. I've got no documentation as yet but I can knock up some notes which would supplement the manuals on www.lua.org. Regards Pete

After checking, in fact the cycle time, default, appears to be 8 seconds, so on average there would be a 4 second delay, but it could be as much as 8 seconds. However, having looked at it now i am reasonably sure there is no reason at all that it needs to be delayed to the next local weather update (scan to populate the offsets). so, I've made some small changes and tested them, and i can get an instant clear weather response now. i don't think there are likely to be any unwanted consequences, but the version of FSUIPC4 I'm working on has a lot of other changes which I'm still testing and which are completely undocumented, so I'm not going to make a general release yet. However, by all means download and try 4.311 using the following link: http://fsuipc.simflight.com/beta/FSUIPC4311.zip Let me know. Regards Pete

Ah! Now i understand ... ... all this is very complicated, and a lot of it is, i think, a hangover from FS9 which may not be needed now. Currently the NW_CLEAR request merely sets a flag which is actioned on the next interpolated weather scan. And that is partially determined by a user parameter and partly by things like frame rates. The implementation was a necessity on FSUIPC3 because trying to call the "clear weather" routine in the Weather DLL asynchronously could ceash FS9. The "NWI weather clear actioned" message is in fact the time where the flag is noticed and the clear action undertaken. I've checked, and what has changed in some recent version (several months ago at least -- early this year in fact) is that, unless you actually opt to have FSUIPC try to filter FSX's weather, the interpolated weather scanning is quite infrequent -- the 3-5 seconds you see in this log is quite typical in fact with the default options. Sorry, when i reduced the frequency this side effect never occurred to me. In fact I don't really think all this delay / flag setting / action later is needed in FSX. I shall have a look at that code and see if i can sort it out. It's just never come up before as being a problem, it seems. I'll get back to you tomorrow or at least before the end of the week. Regards Pete

I'm not sure of the point of doing this if you have to have the panel visible on screen. Surely the only use of knowing indications is to display them on real hardware instead, not as well? I assume you can reliably get to a pixel you want for any resied scaling? Er, now that does confuse me. What has an FSUIPC offset got to do with any of this? Or do you mean set some user-assigned bit which will be used by some hardware LED driver? No, sorry. I've never been into graphics, and really anything involving testing unwanted images on screen seems to me to be missing the point of having a hardware cockpit. Wouldn't it be better to just find a model which can be utilised correctly. Or, do as many have done, use external logic for the systems you are trying to integrate from the PMDG model (i.e. via such programs as Project Magenta's pmSystems. If this is all for FSX, you may be interested in some additional programming facilities I'm currently adding to FSUIPC4 -- to allow user threads running programs written in LUA (see www.lua.org) to be instigated automatically or via control assignment (like the FSUIPC Macros), with easy fast and efficient access to FS innards via FSUIPC offsets. I think these would be capable of being used to simluate many of the subsystems currentl;y needing sophisticated add-on panels. Well, the facility for Lua plug-ins was the next logical step I saw after doing the macro facilities. No, actually I don't have any PMDG offsets -- in fact I don't use any PMDG panels, so i have no use for them. Also, I would not publish such information because I have a good relationship with PMDG and they see this information as proprietary. Regards Pete

Well There's nothing I've changed knowingly in any of the button side of things. No, I didn't say that. I said I'd changed the axis assignment method to make it smoother and advised the person who was using button assignment to change to using the axis assignment. I have never said I'd changed anything about the button assignments. Well for FSUIPC4 there was always the alternative way, but it didn't work for panning, only for 2D cockpit view selection, because it never repeated (because of the delta). The change to provide smooth panning via the axis assignment was done after experiments proved it could work. No facilities were removed, only new ones added. Regards Pete

No, i haven't. I've merely changed the "delta" for assigned POV axes to 0, so that every scan can give an input to FSX. If you haven't assigned the POV as an axis then it should have absolutely no effect on POVs assigned as buttons -- not only is it entirely different code but it is using an entirely different Windows interface! On FSUIPC4 the POVs (up to 4 of them) have always been assignable in the axis section -- part of the benefit of moving that part to DirectInput. The Buttons section with its single POV is unchanged and still uses the Windows "joy" API. Nothing should have changed for anyone not assigning the POV as an axis. For those that are using axis assignment for POVs the change is simply more smoothness due to the auto-repeats. Please explain how you are coming to the conclusions you state. I just cannot see how you arrived at such a suggestion!? Pete

There is actually no way to clear the weather directly in FSX. FSUIPC does it by selecting the "clear weather" theme, as you can in the Weather menu, and also setting a default clear weather Metar as the default "global" weather. How long it then takes FSX to alter all the weather stations which have currently got local weather is a variable, I have no idea how long that would take. however, it should start from the local ones, so it shouldn't be a long long time. Eroverwritten with what, exactly? The sequence sent to FSX would be in the correct order. I don't see how or why it should disregard later weather settings in favour of, what, "CLEAR WEATHER"? FSUIPC merely sends the commands to FSX. It has no way of knowing what FSX is then doing. SimConnect must be processing the commands it receives in the order they arrive. I've no idea how stuff from an earlier command can take precedence over a later one. I've never seen that. You should email me, yes. Is it freeware? Regards Pete

WideServer is the part which runs on the Server, in the FS Modules folder. Hence the name. Applications aren't part of WideFS. You share a monitor between two PCs. Fine I do that a lot. There is only a problem if you want to see things on PC2 whilst flying. If it is only running ActiveSky you don't need to see that once it is running. Why? If you have a third monitor why not connect PC2 to that instead of sharing the FS monitor? And if you have a laptop, surely that is PC3? You don't throw away the computer part of a laptop just to use its screen ,surely? And how do you wire it up? That makes no sense. Regards Pete

You forgot to paste the files in! Pete

Oh, right. That's the first time I've ever seen it referred to as "CF9". It's normally FS2004 or FS9. On FS9 it appears in the FS menu on its own, just as "PFC". In FSX is is in the Add-Ons menu. There are later versions (3.827 and 2.305, respectively) available in the "Other Downloads ..." Announcement above. It might be worthwhile trying those. Regards Pete

Though it takes the blame for most of the world's ills, in fact FSUIPC does nothing of its own accord. It is but a tool, an interface for other programs, and user settings such as buttons, axis calibrations and so on. If anything is different with it running then it is likely something using FSUIPC which isn't able to use it otherwise. Check all your add-on programs. In case it is down to something strange in the settings you made in FSUIPC, delete your FSUIPC.INI file (found in the FS Modules folder), so that it returns to default settings. Regards Pete

Good. Thanks for confirming. Pete

What is CF9 please? I'm afraid it isn't a program I've heard of. Are you sure my modules work in it? What versions of FSUIPC and PFC, please. I always need to know version numbers. Please show me the FSUIPC.LOG and PFC.LOG files from the Modules menu. What PFC equipment are you trying to use? Regards Pete

It probably depends on how they are programmed and maybe on the aircraft model/panel programming. Does pressing the '.' brake button on the keyboard release the parking brake? Pete

The only bit which goes on the client PCs is the "WideClient.exe" program. Er. I don't understand. How isd the video card on your second PC providing a second monitor for your FS PC? That doesn't make any sense. Only those which run outside of FS and use FSUIPC to talk to it. After all, WideFS is only a remote FSUIPC interface, nothing more. Of these: FSCopilot, FSInn, VATSIM, an ACARS program, Teamspeak, AIBridge and ActiveSky, I suspect only ActiveSky is eligible, Teamspeak/AIBridge only if you can move FSInn.. Certainly Squawkbox can be run on a WideFS client, but I don't know about FSInn -- you'd need to ask them. Of these: FSNav, TrafficView, cockpit panels and AI aircraft views there is nothing you can move as they are all internal to FS. Regards Pete

Okay. But I also think you need a decent null zone set for toe brakes, to avoid accidental braking when moving the rudder. Regards Pete

Well, yes, by program, but it is actually realistic for pressure on the toe brakes to release the parking brake. In fact the way the parking brake is really applied is by brake pressure on the pedals then locking that pressure on with the parking brake lever. in other words, the brakes are the brakes which are the brakes. If you want to fiddle with offsets, the toe brakes are disconnectable via bits in 341A, as documented. Maybe you've not spotted this? Regards Pete

Actually you didn't say that, you said "... installed your upadated version", which could mean any version as they are all updates in effect. It's only ever unambiguous when you give the Version nmuber. You'll have to rerun the Install program. There's nothing wrong with that, it only takes a few seconds and makes no changes to your settings. Pete

You are out of date then! :-( Please update your FSUIPC installation. The currently supported versions are 3.82 and 4,30, as made clear in the "Supported Versions" announcement above. I cannot support old versions and you should always check that you are up to date before seeking help! The advanced user's guide is always included in the installation (it is always in the ZIP for FSUIPC3, and always installed with all of the other documents in your Modules folder for FSX). The current issue is dated July. Pete

Sorry I've no idea what on Earth a token is needed for at all, and certainly not how it relates to the type of data, so I can't help with that part. I assumed you knew VB.NET, as a user of that system, but not about FSUIPC and C type structures and arrays. There's no tokens used in the FSUIPC part of the interface so that must be some VB.NET contrivance. I know folks do read and write FSUIPC strings and double floating point values in VB.NET, so it must certainly be possible despite the "token" only being an integer. I suspect the token isn't related to the data type so much as a way of identifying the bit of memory it occupies, a kind of C pointer replacement? If so it shouldn't matter what form the data takes, so structures should be okay. Regards Pete

In the ServerIPAddr parameter -- use that instead of the name in the ServerName parameter. The documentation does tell you these things. No. I don't know how to FIX your issue, as you have something badly set on some part of your Network -- the part operating the DNS, so probably your router. I cannot fix that, I don't even understand mine! You need to seek help in the router documentation or its support. It isn't anything to do with FS or WideFS at all. To work-around it instead you can try what that other thread says, specifying explicitly the server's IP address. To do that you have to use the ServerIPAddr parameter in the Wideclient.INI file, and also add "Protocol=TCP". In order to stop your IP address changing, select it explicitly in the Server. Don't let it be assigned automatically. Please do refer to the WideFS User Guide. The section entitled "Configure your network" does explain these parameters and how to assign specific addresses. Pete