Pete Dowson

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

The stop is easy as there is a control for that, but I think the only way to start one is via the menu, isn't it? Regards, Pete

Good. No, that's okay. I just don't want it generally downloadable yet. Regards, Pete

Okay, in that case I think I've fixed it -- that option should only affect the throttles but through an error it affected the elevator trim axis too, which evidently the PSS airbus uses. I'm sending you an interim test version of FSUIPC to try. Please let me know if it is okay once you have re-enabled that PFC option. Regards, Pete

I only found out how to do the white on green method, as described in offset 3302. Are you using an out-of-date SDK by any chance? Pete

I don't know what data the ACARS is using. You can see what is available from FSUIPC in the Programmer's Guide, part of the FSUIPC SDK on http://www.schiratti.com/dowson. Programs like FS FlightKeeper do manage to keep quite a detailed log through this information, I suspect it is more than enough for your needs. Regards, Pete

I don't know ADVtext. If you mean AdVdisplay, one of my modules, then both foreground and background colours can be set -- in fact the background can be matched to one of your panel colours easily. It's all in the pop-up menu along with all the other options. Please look at the documentation supplied. Regards, Pete

This is a bit mixed up isn't it? You flew WITHOUT GPS and it crashed, but the last thing you did was add GPS? Can you clarify please? Er .. I'm still confused. What's the "GPS unit" in this context? There is absolutely no relationship between GPSout.dll and any weather facilities in FSUIPC. In fact GPSout doesn't even use FSUIPC in FS2004, it is completely independent. I'm really not at all clear what you are describing (too many "GPS"?) but if you would like to explain I will try to make some suggestions if I can think of any. GPSout cares not one iota about any "GPS unit" -- what is that? Do you mean hardware attached to the serial port, or something else? GPSout, when installed, always does the same thing, it simply sends data to the serial port all the time. It doesn't care if anything reads it. It is 100% output, no input involved, and it only stops when you close FS. If you mean you have your receiving apparatus, whatever it is, connected but not "active" in some way, try unplugging it. Maybe it is that device causing problems? Regards, Pete

Again, on this: I'll look at providing a "reverse" checkbox for each axis into the FSUIPC joysticks section. If it isn't too difficult, I'll slip it into the next version. Regards, Pete

Well, as described in the FSUIPC user guide -- you can provide precise null zones in centre and min/max areas. Also, you can compensate for an off-centre device, you can apply response curves to give variable sensitivity, and in the next version you can apply anti-jitter digital filtering. Regards, Pete

On landing it's only when actually on the ground. If you want it otherwise it's best to use the manual method and assign a hot key (FSUIPC Hot Keys page). Pete

Please read and join in on the thread entitled "FSUIPC & PSS Airbus". Regards, Pete

Please be more specific. WHAT doesn't "start" and how can you tell? There's no such file used by WideFS -- there's a WideClient.ini for each Client and a WideServer.ini for the Server. More importantly there's a Log for each and this will contain useful information. Regards, Pete

That's no good for me. Please send the WideFS notification and your current FSUIPC.KEY file to me, petedowson@btconnect.com, and I'll try to see what is wrong. Regards, Pete

No, that won't work because FSUIPC insists on the values being in order. I think some of the calculations also depend on that. Regards, Pete