Pete Dowson

Which was when? Last year, or recently? I'm trying to get a feel for whether this problem is something that has developed, maybe through FSUIPC changes, or in fact is some sort of bug in the PSS code. Ah. Implying that it was designed for FS2002? Have any updates been provided for FS2004, or since FS2004 was released? Incidentally, the log shows nothing wrong, but I see that you also have PMDGoptions.DLL installed. Could you just try it with that temporarily removed from the Modules folder? Okay, please let me see the log from that, and also try without PMDGoptions.DLL installed. Regards, Pete

In that case it almost certainly is a registration problem. where's the Log? Yes, you said that. It's on the Schiratti site now, I just checked. Enrico is fast today! :wink: However, if it is a registration problem it still won't work -- but the Log should be more useful. Is it related to whether FSUIPC is user registered or not? That would be a big clue! So, has the problem suddenly just appeared, recently? If so what changed? If not, why hasn't it been reported before? Is the aircraft actually made for FS2004 or are using an FS2002 aircraft in FS2004. Or, even, are you using FS2002? Finally, I notice you wrote "everytime I load PSS Dash 8 up at my location ..." Does the "at my location" part imply that it is okay when loaded up someplace else -- i.e. related to scenery? Regards, Pete

Is your FSUIPC user registered? If not it may be that the aircraft is failing to register itself correctly and doing lots of retries. An FSUIPC Log file would be useful in that case. Otherwise, please first retry it with version FSUIPC 3.40 which is being released today. If there is still a problem we'll have to work out how to get additional information. Odd that there have been no other such reports. Is this a very new add-on aircraft? Regards, Pete

Is this on WinXP ? It may explain why some folks (not all) get odd problems with FSUIPC versions 3.20-3.30 with my button PollInterval changed to a default 25 mSecs. However, these were only with Win2K and Win98/Me, never WinXP. In the imminent version 3.40 of FSUIPC I am defaulting the PollInterval to 50 on Win2K and Win98/Me, leaving it at 25 on WinXP. Okay, glad you benefitted. Best regards, Pete

Can you not simply reverse it? For instance, if there are 3.28084 feet in a metre, there are 1/3.28084 metres in a foot. Right? All you need to know is the relationship between the two units used and you can then convert either way. That is all the documentation is doing, specifying what the FS units look like. It was never intended to write the code for you, either way. Have you tried coding anything yet? Have a go. If you'd like to show me what you've done I can maybe suggest corrections or improvements. Regards, Pete

No, none which interface into FS's Weather DLL, sorry. I can't modify data I don't see. There are different routines in FS's Weather.DLL used to read weather (which FSUIPC certainly does all the time) and write weather (which it only does when requested by an application program or specifically set user options). I really do think it would have been a little more reasonable of you to at least look at FSUIPC before making suggestions for additions which have been there for years and which would have been quite obvious even from a brief perusal of the documentation. For example, the "minimum weather defaults" button was actually added about 5 years ago to allow WidevieW to copy exact weather from the server without FSUIPC "filtering" it on the Client. This is clearly documented and has been for a very long time. If there is any conflict between your add-on and mine then I have no idea what it is, but it certainly is not FSUIPC wilfully changing any weather. I have absolutely no idea what you program does, but since I assume we are both trying to make things work through hacking into FS code without any help from Microsoft it is entirely possible that things are not compatible. But you will need to do some analysis (debugging) to find out where things are going wrong. Regards, Pete

Providing the Attitude Indicator is working -- i.e. up and running without vaccum failure -- and the aircraft is flying level or at least not changing attitude too quickly, then they are about the same. But the 057C And 0578 values are the true aircraft values, not what the instrument may tell you. However, surely for a motion platform it is accelerations you want, not static measurements? After all, it is accelerations the human body feels. The accelerations in all 6 axes are available too -- offsets 3060-3088 for instance. FS terms for the 6 defining values are LLAPBH -- Latitude, Longitude, Altitude, Pitch, Bank, Heading. They are all together in sequence at 0560-0580. The term "yaw" means twisting about the vertical axis, which is heading in normal level flight or relative to world axes. Regards, Pete

Nearly all of the FSUIPC weather options are only applied to weather sent via the IPC interface in any case, and by default nothing in FS's own weather is ever altered. It sounds like you are still using very early versions (3.00-3.04) which did indeed have some unwanted affects on FS weather. As noted in the FSUIPC History documentation, that was all corrected a very long time ago. By default, if the user has registered FSUIPc, there are a couple of options affecting weather supplied through FSUIPC, but there are none enabled by default for any other weather. Furthermore, if the user has not registered FSUIPC, none of the options are applied whatsoever. No it does not, at least not by default. Please go and get your facts correct first. Evidently you've never looked at the First panel, because there has ALWAYS been such a button there!!! They only need disabling if they've been enabled, and 90% can only be applied to IPC supplied weather in any case. Please, go get a copy of FSUIPC and take a look for yourself. It is evident from what you write that you've never even looked at it! EXACTLY! Please do just go and find out what you are talking about please before asking for things which are either not at all necessary or already supplied! Even if you don't want to register it you are surely able to look at the documentation!? Regards, Pete

No, that is not true. If the options are off it does nothing with the weather. Please check the user guide. You have some options incorrectly set. Flashing is absolutely nothing whatsoever to do with FSUIPC. Turn render to texture off in FS and use only 100% 3D clouds. You evidently completely misunderstand, then, or simply have not bothered to read anything about it! :cry: FSUIPC's interface to FS is free for all freeware. You simply need to apply for a free access key. Fees are only required from commercial operations (just like Adam Szofran's FS6IPC), and for users, the fee covers the many (and growing) additional user features which are not directly part of the IPC interface. Both already exist, and by default FSUIPC doesn't touch any weather not coming through the FSUIPC interface. Please download the FSUIPC ZIP and take a look at the User Guide. You are evidently misunderstanding a great many things, both about FSUIPC, and FS. Please do some more research. Regards, Pete

Moved from private message: Sorry, can you explain more about what the problem is? If it is just re-using the same button for different things, you can use every button differently in each aircraft -- just make the assignments "Aircraft Specific" in FSUIPC. The Epic one isn't applicable unless you use an EPIC card or EPICUSB device. The polling interval is irrelevant for GoFlight buttons because, as noted in the documentation, the GoFlight system is by a call-back from their driver -- there is no polling involved, their driver calls my routine when anything happens. Displays aren't handled at all by FSUIPC. As I said, I do have a display module on my list of things to do, but it isn't imminent. Sorry. Regards, Pete

You don't seem to be getting any replies to this. I don't use any of those panels so I really don't know what options they have for control other than by mouse clicks, though I'm pretty sure that the PMDG 737NG (if that is what you have) does provide keypress assignments for many of the main functions. If they only support mouse clicks then the only way you'll be able to use external hardware will be by using something like Luciano Napolitano's "Key2Mouse" program (http://www.wideview.it/key2mouse.htm), and then assign buttons to keys to drive it. If you think of the GoFlight buttons, switches and knobs as simply joystick buttons, then you will see you can assign keypresses to them in FSUIPC's Buttons page. When you operate a GoFlight 'button', FSUIPC will recognise it* and you simply assign whatever you want, as described in the FSUIPC User Guide. (* if FSUIPC doesn't recognise your GoFlight buttons then you need to go get new GoFlight software and install it -- FSUIPC accesses the GF stuff through correctly installed GF drivers). The only special case to deal with are the rotaries. FSUIPC provides 4 buttons per rotary -- slow and fast in each direction. Don't use the 'repeat' option in FSUIPC with rotaries, they do the repeating for you. Also remember that, because you will be assigning keystrokes, you cannot expect the values to keep up with fast turning of the knobs -- the keyboard buffering and Windows message queuing imposes a constraint. This is why I provide a "fast" mode. You can also make things go a little faster by assigning the same control to the button 'release' as well the 'press'. FSUIPC does not drive the displays on your GF equipment, so you will find the MCP operation a bit disappointing. I do have a display module on my list of things to do, but it isn't imminent. Regards, Pete

Even using the keyboard trim controls (Numpad 7/1)? Using the FS control I mentioned? Did you monitor those locations I mentioned? It sounds like the PSS cockpit code is continuously re-writing a trim value, presumably 16384 or -16384. This is sounding similar to the "stuck" elevator problem which the Wilco 767PIC was prone too -- the reason I added the so-called "spike removal" options in FSUIPC (technical page). Please let me know the results of monitoring those offsets. If it is, indeed, similar to the old 767PIC problem then maybe I could extend the elevator spike removal to also operate on the elevator trim. But I need to know exactly what the stuck value looks like, please. Same with the 767PIC spikes. I think they must have been down to some timing differences. Ahso it isn't similar to the 767PIC spikes, then. It's simply the normal trimming with A/P engaged on the ground? I'm a little confused now, then. Are you saying the trim getting stuck isn't the problem, it is more the disconnection of the controls? If so, please monitor offsets 310A (as type U8 ) and 3328 (as type S16). The former is the control for disconnecting things. If that's an odd number (e.g. 1 or 3, etc) then the elevator is disconnected. 3328 is the value of the elevator which would be applied if it were not disconnected -- you can see if that is responding to your control input. Maybe the A320 sometimes forgets to clear the 1 bit in offset 310A. You can construct an FSUIPC control to clear it for you to check. Assign a Key combination or a spare button to the "Offset byte set" control, with the offset "x310A" and a parameter of 0. That should release all controls back to you. However, maybe the A320 keeps resetting it. Keep monitoring 310A and see what goes on. Was the A320 designed for FS2002, then, not FS2004? Regards, Pete

Well, is it a secret? Maybe the log message would be useful for me to tell what is happening? And do you only find the log message when looking in the log file? How do you know it is occurring when you create a flight? You cannot easily see the log when running FS. Also, how are you creating a flight -- pressing ";" and giving the flight name, or using the Flights menu? "After a few months"? What have you changed? Software doesn't just sort of "wear out" like hardware. The log message says this? There is no such log message! Can you please be a bit more specific. Stating with the version number of FSUIPC would be a good start, please. And, certainly, if you get a Message Window saying FSUIPC is already running then you have two installed. Maybe you renamed an old one but left it in the modules folder? Maybe you put one in the main FS folder as well? Please check these things. Having two copies of FSUIPC running is a big no-no, which is why the check was added. To check the version of the running copy of FSUIPC, go into its Menu in FS (ALT M F) and read it on the options window which appears. To check the version number of any of my DLLs just right-click on them and select Properties-Version. Patches for what? Regards, Pete

No, not just you, but I think those who are affected fix it by turning render to texture off. This isn't needed on all video cards, but it does work in the cases I know of. Haven't you tried turning it off? Regards, Pete

When you use the standard EXTERNAL interface to FSUIPC, there is a block of memory obtained and marked as a memory-mapped file. By default this is the maximum supported memory (31k I think). It is this memory which is passed back and forth between your program and FSUIPC using Windows memory sharing system by file-mapping. The Read and Write calls do nothing except add requests to that memory. If you add too many and overfill the memory, they report a failure. Only the Process call actually does anything as far as FSUIPC is concerned. In modules and gauges which are running inside FS, using memory mapping is horrendously inefficient and wasteful, so the interface is just a little different. The ONLY difference is that the memory has to be part of the caller's global or allocated memory. Since only the caller knows how much it might need and how it wants to allocate it, this is left to it, and you simply pass the details in the Open2() call. It would be wasteful to assume 31k when you only need 1k, for instance, and every caller needs its own separate memory, so it is more efficient for it to own this. As to how much, you just need enough for the maximum number of simultaneous Reads and Writes you will make per Process call, plus the red-tape overhead of about 16 bytes per call., plus a little more. All as clearly explained in the package. How did you miss it? Sorry, what does that mean? Really? You've not even read the little there is! It seems like you've not made any use of the documentation I have provided -- please look again into the internal users ZIP and find the "FSUIPC Internal Access" text file. This method has been in existence and used without such problems arising for over four years now. Most gauge and module writers evidently seem to find it enough. I took a lot of trouble to make sure there was very little change to make to move to this interface. Would you rather it was all completely different? :cry: Regards, Pete

The problem is, that message is telling you WHY WideClient cannot run! It cannot "function normally"! By not running it is also not obeying any of the parameters, especially, for instance, those parameters telling it to load and run your programs. It seems to me that it is the most unfriendly and annoying thing to have a program fail completely and not tell you why. Regards, Pete

What, just terminate without doing anything? That's rather unfriendly. Why would you want that? Or do you mean somehow passing on all the parameters (Run/RunReady etc) to the running copy and letting it "restart" or something? That's quite a lot of work. Regards, Pete

For sure that sounds either like a bug in the A320, or possibly something going wrong with the CH controls when they've not been used for a while. In the latter case could USB power management be the culprit? I don't know much about it, but I have seen other time-related problems reported with USB devices. That is pointing to the A320 code. Did you try resetting trim as I suggested? Need to find out what the common differences are then. For this I think you need to be in the A320 forum. ... but only after a lengthy flight. Or it is only when you use the MCDU? All this really needs to be studied by the A320 support folks. I'm afraid I have no idea. There's certainly nothing in any of my software that knows anything about CDUs or lengthy as opposed to short flights. ... and you cannot override it with the trim controls, even the AXIS one I mentioned? You can use FSUIPC Logging to monitor the trim setting, as it seems you have no trim indication in your cockpit. Go to FSUIPC's Logging page and look at the right hand side. Set the offset for monitoring to 0BC2. This is the trim indicator. You can also monitor the trim control input at 0BC0. These are not in angles but units such that 16384 is max deflection (-16384 max the other way). Check one of the options below for the display method -- the AdvDisplay one is usually best, it shows on screen then. How long has this been happening? You say, since you first got the aircraft, but when was that? Which version of FSUIPC were you using then? Regards, Pete

It's the Holy Grail of flight simulation -- smoothness is really more important than frame rates, but more difficult to measure. There are heaps of threads about how to get FS to run smoothly in many forums. There's even a business set up which I think is doing a good job telling folks how to set up their systems. And the answers tend to be different according to the type of scenery you use -- photorealistic seems to be better with different settings to plain repeating texture scenery. Sounds like things are arriving in little batches. Possibly this is a result of Windows timeslicing, plus message queue handling, on a system not really fully up to the task. In my opinion there is no system currently available which will drive FS at 45 fps consistently without stutters. Set the frame rate limiter to 20 or 25 and try again. Other things which may help include using a Pentium with hyperthreading, and run FS in one "virtual processor" and your application in another -- FS only seems to run in one in any case. Also, try not using slew mode. It isn't really necessary. You can use pause mode or zero sim rate mode, or, in FS2004 only, even normal running mode. I don't know it at all, but it is probably designed for this and does interpolations, by time, for you. If it suits your needs, why not use it? They are results of simulation, not controlled directly. The gauges which measure what is happening will do that. You make it happen, the gauge will follow (unless you are in a mode where the gauges aren't updated). If you want to control cockpit indications directly you probably need to design your own gauges which read private values you can control yourself, like Project Magenta and other external cockpit implementations. Regards, Pete

It's ICAO. But which airport? FSUIPC knows nothing about airports. If you mean "nearest to position", then I haven't come across a way from inside FSUIPC to get such computations done for me by FS, though I assume it may do it somewhere for itself. The way most programs work is to make a database by scanning all the scenery files to locate the airport details. I did make a program to do this for FS2000/FS2002, but unfortunately the format changed in FS2004 and I've not had to to investigate this enough to write a new program. There is a database of Weather Stations readily accessible in FS's files, but this will omit smaller airfields which are not also METAR stations. Regards, Pete

That's something you have to try, then tell me. No, that is not true. The 100 millisecond Sleep is only executed if the SendMessageTimeOut fails (i.e. times out after 2 seconds!) and the retry count is not expired. The purpose of this is to give a 21 second window over which the Message has a chance of succeeding during times when FS simply isn't processing its message queue, as when it is reading large files from disc and so on. Mostly it would only ever happen to use the 100 mSec sleep when FS is in a menu somewhere or loading up an aircraft after being in a menu. The 100 mSecs is nothing compared to the 2000 seconds already lost through the SendMessageTimeout failing. That depends on how often the user goes into menus, how slow the disk is, how fragmented the disk is, how much real memory is (to allow more caching and prevent thrashing) and so on. The better shape your system, the less often, and perhaps never if you have things right. The call causes a Process switch. How long does that take? I don't know, you'll need to measure it. But whatever method you use will have process switches when you have separate processes. Depends on what you write. In FS98 and before, writing to values in the GLOBALS.DLL actually directly affected what FS was doing. Easy, fast. Since FS2000 more and more things are removed from that sort of operation and made procedural. Actually OOPs -- calls to specific virtual functions on classes in containers in other classes in other containers. Ugh. Just like Windows itself, as machines have become faster and bigger, the software has bloated to match. Did I ever tell you I hated OOP? I'm a machine programmer by training and at heart and I find hacking through the monstrously complex machine code in FS very difficult and annoying these days, so much apparent inefficiency. It isn't the programmers fault, it is Windows and C++ and compilers. Not sure it is true synchronization, but it's the best I found -- it latches on to one of the regular chains which is also used to update gauges and so on. I don't know, but I wouldn't have thought so. Try it and see. The problem is more how to ensure smoothness, no jerks and stutters, which is why I would always recommend using the FS frame rate limiter to set a low enough value that FS can always achieve reasonably easily, then matching that in your program. I suppose you could try 2 updates per frame, etc, but I'm not sure what it would accomplish. But definitely don't make them irregular if it is possible to avoid that. Er, try threads? I'm rather confused now. Are you writing an EXTERNAL process or an internal FS module? If the latter then what are you doing looking at the IPCuser source? You must use the Module User's library code -- see the separate ZIP in the SDK. That, of course, invlolves no process switch, no memory mapped files, just a normal SendMessage call with no timeouts, sleeps, and no retries. Look at ModuleUser.c. I'm made an newer version of ModuleUser which can be used from any thread -- the current one should be used only from the main FS thread. However, the new one needs a new version of FSUIPC too. Regards, Pete

No, there's nothing in FSUIPC that cares about or has anything to do with any CH controls. It sounds rather like you have the aircraft configured in such a way that the autopilot is using a rather extreme elevator trim setting, which is still set when you release the A/P. Try configuring a button or keypress to centre the trim. In FSUIPC you can do this in the Buttons or Keys page -- select the Axis Elev Trim Set control in the drop down and make sure the parameter is 0. The airbus uses Fly-by-Wire and that is emulated in the PSS product by disconnecting all the controls and reading the values, through FSUIPC instead. This part was inoperative in versions 3.328 to 3.331 of FSUIPC only, due to an error on my part. But if you were experiencing this you would have not had any control before engaging the A/P in the first place. Finally, in case it is an Airbus bug, maybe not relinquishing the elevator when you disconnect its A/P, you should post your problem on the PSS website and see if you can get help there. Regards, Pete

This is normally a video card driver thing. Two things to try (which I thought were covered in the ActiveSky documentation?): 1. In FS use Options-Settings-Display-Hardware and change the "render to texture" option -- normally switch it off. 2. In FS use Options-Settings-Display-Weather and make sure the 3-D cloud percentage is at max -- i.e. 100% I'd recommend the latter anyway, to stop those horrible false clouds flickering. FS uses facilities to "morph" from one weather state to another. There can actually be flickers even so, but they are rarer. Unfortunately Microsoft publish no information whatsoever about how to get into the weather and all my thousands of hours of hacking into the code failed to find any way to operate the morphing for external programs. Regards, Pete

They are all mixture controls as far as FS is concerned, though I think the "condition" controls have an idle position and a cutoff below -- sort of like the throttle with a "centre" idle and reverse below (reversing prop too, come to think of it). If you want to use FSUIPC to calibrate a null idle zone with a minimum cut-off position below you need to do this in the page with 4 separate mixtures on it (page 4 of 8). Currently you'd need two mixture control levers for a 2-4 engined plane as I haven't provided a single lever mapping facility in the way I have with throttle and prop. (Not sure why not, guess no one asked yet!) Regards, Pete

Interim versions 3.328 to 3.331 included an error, introduced when the jitter filters were added, which stops fly-by-wire. I've sent a fixed version (same as above -- two fixes in one version! :wink: ) to Norman who I think is PSS's webmaster. Regards, Pete