Pete Dowson

It still hasn't arrived. From what you say it certainly sounds like something is writing to the display control area in FSDUIPC. The log would tell me thast. Please check you sent it to the right email address, the one I gave you. I also sent you an email yesterday, saying the same thing. Still no reply yet. Regards, Pete

Needn't worry about the video stuff, you can put the original FS9.CFG back now. It's best to run FS in Windowed mode until we resolve this in any case -- you never know, there may actually be an error message box awaiting your attention on the Windows screen. Try it and see. So, what add-ins have you got installed? Let's look at the Modules folder. BTW I'll be offline now till tomorrow, later on (maybe evening UK time). Seeing the eye surgeon first thing, and he uses those drops which dilate the eyes. I won't be able to use the PC most of the day. Regards, Pete

Hmmm. The log shows nothing is trying to access or use FS by then. Are you loading this ATR aircraft from the initial menu (the hang is occurring when it is loading the UI generated flight.flt). Try one of the default aircraft. Try deleting (or rather, temporarily removing) your FS9.CFG file (it's in the Documents and Settings\\Application Data\Microsoft\FS9 folder). FS will build another and start with default flight settings. There are some other things which seem to hang when FS is present too -- the first FS9 version of FSNav, for example. That was fixed fairly quickly. It doesn't even use FSUIPC, but does some checks which don't work when FSUIPC is present. If loading a default aircraft doesn't help, and you are sure it isn't FSNav, check your Modules folder, see what other add-ins there are there. Let me know. Regards, Pete

You aren't trying to use FSUIPC to calibrate the flaps lever into any plastic notches on the device, are you? FSUIPC can't do that. It just takes the complete range of the flaps lever and divides it across the appropriate number of flap detentes for the current aircraft. Just make sure that you can get to the minimum (OUT = -16383) when the lever is full forward (flaps up), and the maximum -- eg 16369 on a 9-detente aircraft, like the 737). I don't know what you are complaining about with all those !!!!!!!!!!!!!!!!!!!!! -- what's that about? The range of control values FSD needs is max -16383 flaps up to +16383 flaps down, but FSUIPC converts the continuous range into increments, to avoid stupid positions mid-detente, or situations where FS is wavering between two of them because of slight jitter. With the 737, for example, the increment between detents, as shown in FSUIPC's options (the position BELOW the flaps calibration) is 2047. This is actually only half the increment now needed, as it derives from the internal programmable interface value of the flaps control. Using 4094 gives: Flaps 0 = -16383 Flaps 1 = -12289 Flaps 2 = -8195 Flaps 5 = -4101 Flaps 10 = -7 Flaps 15 = 4087 Flaps 25 = 8181 Flaps 30 = 12275 Flaps 40 = 16369 These values work well with the 737. Likewise, you will get different values and different numbers of detentes for each aircraft. Well, as you can surely see, around half of the values will be negative. Why is this surprising? These are the values required by FS for that axis. The only thing I find odd and rather annoying with the TQ6 is that it has a very non-linear action -- the values seem to change too fast at either ends, and the centre area (where you get your -7, as do I) is very large. I assume this is more to do with the pots being used. That sounds good and exactly what should be happening. Again, why all those !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ????????????????????? That sounds good too. Again, the input FS wants on that axis is -16383 to +16383. Why is all this so amazing for you, so much so that you overuse exclamation marks to the extreme? I'm not sure how GoFlight intended the flaps lever to be used with the optional notches fitted -- I couldn't work out how to put them on in any case. To fit the calibration on a notch by notch basis would be quite a big job for FSUIPC. I did manage to do it in my PFC driver, but that has a specific known axis input to deal with. Regards, Pete

What version of FSUIPC? There was a bug affecting spoilers in version 3.40. You need 3.411, the current version. See the release notes at the top of the Forum. Regards, Pete

Test them in the air. FS seems to want to auto-deploy them if you use them on the ground. Why not try calibrating them in FSUIPC? As for linearity, it sounds like you have two different types of pot. Regards, Pete

Erno, I think that's wrong. As the A/P is actually managing to keep a correct attitude for whatever it is being told to do, the aircraft is stable at that pitch with that trim -- assuming your elevator controls are doing nothing, i.e. centred or left wherever you put them. When you then disengage the A/P the aircraft should, by definition, remain stable at that attitude. That certainly is the case here, for all default aircraft. In fact one "cheating" way of getting an aircraft into perfect trim in FS has always been to engage the A/P, let it trim, then disengage it. As far as i know that hasn't changed for many many versions. Of course it is not realistic for it to use trim in this way -- a true autopilot pitch control would operate the elevator AND then trim out the forces, just like the pilot would. But this would be no good at all for FS, because it would, indeed have the result you say -- with the elevator non-centred for a particular pitch, when the A/P is disconnected, the user's auto-centred elevator axis would immediately cause the aircraft to be out of trim. In other words, Microsoft have done it the way they've done it specifically to avoid the problem you say you've got! No, that would actually be rather catastrophic, except in very sophisticated cockpits where some sort of motor control can move your elevator axis for you. As I said, the way it is is not realistic, but is done to ensure you do NOT get the very problem you seem to think you get! Think about it. If in a climb it pulled its elevator stick back and trimmed out, as it should, and you then disengage it and let your *centred* elevator suddenly take control, you'd be diving before you know it! I really do not know how you are achieving that -- I cannot make it do it here, and when you think it though you must surely see that what you are saying isn't logical. As long as the A/P always uses trim only, the centred (or original, if not centred) position of your joystick should be correct when you release the A/P Regards, Pete

Erno, I think that's wrong. As the A/P is actually managing to keep a correct attitude for whatever it is being told to do, the aircraft is stable at that pitch with that trim -- assuming your elevator controls are doing nothing, i.e. centred or left wherever you put them. When you then disengage the A/P the aircraft should, by definition, remain stable at that attitude. That certainly is the case here, for all default aircraft. In fact one "cheating" way of getting an aircraft into perfect trim in FS has always been to engage the A/P, let it trim, then disengage it. As far as i know that hasn't changed for many many versions. Of course it is not realistic for it to use trim in this way -- a true autopilot pitch control would operate the elevator AND then trim out the forces, just like the pilot would. But this would be no good at all for FS, because it would, indeed have the result you say -- with the elevator non-centred for a particular pitch, when the A/P is disconnected, the user's auto-centred elevator axis would immediately cause the aircraft to be out of trim. In other words, Microsoft have done it the way they've done it specifically to avoid the problem you say you've got! No, that would actually be rather catastrophic, except in very sophisticated cockpits where some sort of motor control can move your elevator axis for you. As I said, the way it is is not realistic, but is done to ensure you do NOT get the very problem you seem to think you get! Think about it. If in a climb it pulled its elevator stick back and trimmed out, as it should, and you then disengage it and let your *centred* elevator suddenly take control, you'd be diving before you know it! I really do not know how you are achieving that -- I cannot make it do it here, and when you think it though you must surely see that what you are saying isn't logical. As long as the A/P always uses trim only, the centred (or original, if not centred) position of your joystick should be correct when you release the A/P. Regards, Pete

You appear to have all sorts of serious errors which I've never seen before. But the log shows nothing going wrong for a long time! the first error logged is after 3212 seconds (over 53 minutes!). The "couldn't allocate buffer" message is also most peculiar (I've never seen it do that before either), but then 126976 bytes is rather a lot -- the largest block normally handled by WideFS is 31000 bytes. What are you seeing happen "after a few minutes only", just that message box? I've never seen that before and have no idea what it means I'm afraid. That is something in the run-time library installed on that PC. You say: What does "stopped manually with the mouse" mean? I don't understand that. And if you'd "stopped" it, how is it carrying on for 53+ minutes? What operating system are you using on each client, this one in particular, and the Server? I don't think the Server should be throwing up those errors: Provided it gets at least one of the two protocols it shouldn't be raising any errors for the other -- but i'll double check that here. I assume your other clients are okay, so do you mind telling me what's unique about the problem one? Is it, do you think, related to the applications you run there (try moving them and running something else, just to see)? Or is it something different about the operating system, memory, and so on? Regards, Pete

Strange. I've not heard of that one. Can you try again then show me the FSUIPC.LOG file you'll find in the FS Modules folder? Regards, Pete

Since you can reproduce the flashing Advdisplay text so reliably, perhaps you can help nail it, or at least work out whether it really is the video drivers or something in the PMDG code. In the FSUIPC Options, find the Logging page and enable IPC Write logging. Now reproduce the error. Don't make a long flight, please -- in fact best to stop after you've made the error happen (say, langing lights on, see error, landing lights off, close down). ZIP the FSUIPC.LOG file you'll find in the FS Modules folder and send it to me at petedowson@btconnect.com. Next time you load FS don't forget to go into Logging and turn the IPC write logging off, else it will gradually fill your disk! :wink: One other thing to try. Right click on the AdvDisplay window and set it to operate with multiple lines only -- this should filter off single lines (to the normal FS display) leaving multi-line usdes such as Radar Contact. Let me know, please. Regards, Pete

Okay, good. And you set the value to 2 (or whatever) and length to 1? Regards, Pete

Hmmm. What does 2^1 mean in VB? In C it would give 3, as ^ is the "exclusive OR" symbol. In my document it is just used as a power indicator, "2 to the power of 1". As I said in my last message, that is 2, so just set it to 2. To work out powers of 2, take 2^0 as 1 then multiply by 2 for each power higher. So, for instance, 2^3 is 1 x 2 x 2 x 2 = 8. The sequence goes 1,2,4,8,16,32, etc. Your FSUIPC_Write is wrong as well. You didn't read my last message very well I'm afraid. I said you write 1 byte, not 2 as you have there. As for that VarPtr stuff, sorry, that's a VB peculiarity which I have no idea about. I would have thought you'd have to derive the address somehow -- look in your VB books. The error "ByRef ..." sounds as if it is to do with that. How did you manage to read or write the other stuff you said you'd handled? As for providing it in C, that would most certainly confuse you even more judging by the VB example! :wink: Sorry. I'd better butt out now and leave it to VB folks! Regards, Pete

I wrote to them about then and asked them, and they said they couldn't reproduce it. I think this is the main problem. I expect if either they or I could reproduce it we could track down what is going on. Is your Advdisplay window locked or docked? if it is docked, can you look at the Advdisplay section in the PANEL.CFG file for the panel, and see what it is docked to, please. Better, show me the section entirely. If it is docked, see if it happens with it "locked" instead. That's why I thought originally that it must be something in their code that was somehow interfering, but if it is I don't understand why it is so rarely occurring (or at least reported), and why we can't reproduce it at all. Regards, Pete

Well, with most things you would have the read it, change the bit (or bits), then write it back. There's no other way. However, for this particular offset, the documentation does explicitly say "Write bits to operate toggles. Don’t bother to read it, there’s no meaning to anything read." Here it just means write a value with the required bits set and the others not set. So, just write a 1 byte value with the appropriate bit or bits set. i.e. for, say, NAV1 (bit 2^1), write a 1 byte value of 2 (because 2^1 = 2). If you want to operate all four swap buttons together you could do by sending 15 (2^3 + 2^2 + 2^1 + 2^0). In general, though (not in this case), you'd need to read the value first. The light switches at offset 0D0C are like that -- they are 1 when on, 0 when off. To turn one on you'd read the 16-bit word, logically OR in the bit value for the light you want to turn on, and write the 16-bit word back. To turn one off you'd do it similarly, but AND the value read with the "NOT" of the bit -- i.e. with a pattern containing all bits set except that one. I cannot give you VB examples, I don't know VB, but check in your VB manuals of documentation and find the logical bit operations. All programming languages provide OR, AND, NOT and even exclusive OR (XOR) which I won't explain here, as well as shifts left and right. They just use different symbols or names. In C the logical bit AND is &, OR is |, NOT is ~, and XOR is ^, whilst shifts are << (left) and >> (right). But they'll be different in VB. Regards, Pete

No, we didn't understand that before. It doesn't happen here and PMDG couldn't reproduce it. I can only think it is specific to particular video cards and/or drivers. Try windowed mode, try 2D panel instead of VC or vice versa, try different options in FS (eg render textures option). If we could get the two folks reporting this together to say what video cards and drivers they are using then maybe there'd be a clue. Have you looked on the PMDG forum to see if there are others there? Regards, Pete

Other aircraft aren't "showing up" where, in the FS aircraft menu, or are you talking about AI aircraft on screen or multiplayer? FSUIPC doesn't have anything to do with the appearance of aircraft in menus or on screen. If you have problems with multiplayer (as used by Squawkbox for instance) I'm afraid you'll need to ask elsewhere as it's an area I know nothing whatsoever about. And AI aircraft are to do with scenery files -- if they aren't showing up it's more likely due to your scenery library file not pointing to wherever your AI traffic BGLs are. Regards Pete

The thing with the landing lights was reported once some time ago, but neither I nor PMDG could reproduce it. I think the original person reporting it was using an older version of the aircraft than either of us, so it might be worthwhile trying an update. I can't really imagine how the landing lights can have anything at all to do with text displays in a completely separate window, but I presume it's something to do with video drivers and complex interactions at that level. Regards, Pete

Do you mean "FSInterrogate", as supplied with the FSUIPC SDK? If so, then of corse that only includes those locations documented in the FSUIPC Programmer's Guide and populated by FSUIPC. The use of all the private user application areas is entirely a matter for those applications. It would be nice if application writers did provide FSI files for FSInterrogator to support their products, but this would only be meaningful in those cases, like PM, where the interface is open for programmers to use. As it is, for PM, you have the PM Offsets document on the PM documentation web page, and the SYSVAR lists in the pmSystems package. .That's not true. You can always read them -- write them too for that matter. FSUIPC does not prevent anyone reading or writing any of the application-allocated offsets, but of course they are really only of any use if the application is actually running. What do you mean "not known"? Of course they are "known". They are known simply as offsets in the memory it maintains (and communicates via WideFS) for the applications which have 'claimed' them, whether this be PM CDU, PM PFD, PM MCP, PM Systems, or any one of many other applications. You can write to them and read from them at any time. There is absolutely no restriction. but if nothing else is running which uses them, it will be just your program talking to itself, won't it? You are severely misunderstanding something most fundamental if you think that. You can write a value to 5602 and you can read that value back. What makes you think you can't read it? Are you getting an error? Why are you so convinced that there's anything complicated going on here? It's just a repositary, a way for two or more things to communicate. If you're only running one program, what are you trying to communicate with? Regards, Pete

The only thing I can think of is that it is hanging on the Epic access. Try running it with the EPIC driver removed -- EPICINFO actually can be run with no EPIC, just for logging purposes for instance. If it runs okay with no EPIC then it is likely to be some clash there. I'm afraid you'd need to seek support from the EPIC folks then. I don't really use EPIC these days and, apart from making it work with each new FS release, I've not worked on EPICINFO for years. The other thing to do is check the contents of the EPICINFO log file. I'll look up one of mine so we can compare. BTW please always mention version numbers -- Version of EPICINFO and FSUIPC (the latter is needed by EPICINFO). Regards, Pete

Received via Email along with files as requested: Aha! This line is the clue: 75735 Module "FSFlightVentures.dll" access registration is okay If you remove the FSFlightVentures DLL you will see there's no problem. There's a little bug in the FlightVentures DLL (resulting probably from a misunderstanding in my rather brief documentation of some of the more complex FSUIPC interface features) which actually falls foul of a correction to a bug which was present in FSUIPC 3.40 and earlier. Both of us have actually "fixed" it recently. The author of FlightVentures has fixed it, and also I've changed FSUIPC too so that it copes with the way FlightVentures was coded. I don't know if the FlightVentures fix is out yet, but meanwhile I have emailed you an interim test (read Beta) of FSUIPC (version 3.426). Please be sure to replace this with the official release (3.43 I expect) in early December (I hope). Regards, Pete

One thing which will do exactly what you say, and that is if your FS9.1 installation is actually a mixture of FS9.0 and 9.1. You can check the modules using the list I posted in my FS9.1 announcement at the top of this Forum. I've fixed FSUIPC for such mixed up 9.0/9.1 updates but the new version isn't ready for release yet -- hopefully 6th December or so. If the FS9.1 update looks complete according to that list, then please try again, then Zip up the FSUIPC.LOG and FSUIPC.KEY files (from the FS Modules folder) and send them to me at petedowson@btconnect.com. I should be able to work out what is wrong from those. If you miss me tonight, I'll be out all day Saturday at the UK FS show in Birmingham, but I'll get to it on Sunday. Regards, Pete

No, sorry. GPSout is actually an FS DLL (module) which only runs inside FS. It pre-dates FSUIPC by quite a way and probably WideFS too, though I can't remember that long ago I'm afraid. A program could be written to run through the FSUIPC interface. I don't think GPSout uses anything which is not, nowe, available from FSUIPC. But it is another separate job and not one I have time for at present I'm afraid. What would be the reason for this, by the way? I don't think GPSout has any measurable affect on FS performance, that is not unless you are asking for a lot of data (too many sentence options) and you are also setting too slow a line speed and/or too short an interval for updates. For the usual need, 2 or 3 sentences once a second, the default 4800 bps should be fine, but try for the highest speed your receiving program can be set to. Currently I use something like 115200 with FliteMap. Regards, Pete

Ah, sorry. Missed that. Easily done when you are only looking at additions to the end of the thread -- your earlier one must have crossed with mine. Anyway, glad it is sorted. Shame it isn't automatic though. Regards, Pete

That's exactly what slew mode is -- yet you say you've tried that with no difference. The other ways include pause mode and setting the simulation rate to zero. I think the only way you will get it relatively smooth is to try to synchronize FS and your update rate. For instance, if your updates are regulated to 20 per second, set the frame rate limiter in FS to the same. No idea what coordinate system is used, but the best scenery uses satellite data to position things, so I guess the system is the same as whatever the satellite data is using. If you are talking about specific sceneries, then whose are you comparing it to? Most good add-on scenery is a lot more accurate than the defaults. Regards, Pete