Pete Dowson

No, the subtraction is done in FS when FSLook asks for that Gauge Token. It's a clunky inefficient interface which I made only to help original C programmed Gauge makers. The interface and method is not suitable for production programs. I'm not sure I can offer an alternative to the subtraction at present. How are you handling conversion of all the other funny FS units, such as Latitude/Longitude, is any case? Or is it just that you don't allow values derived from more than one source? Anyway, I'll check into it for you and see if I can find a way. If I have to calculate it this won't be done continuously, but probably once every few FS frames. Regards, Pete

They are Gauge variables, available to FS gauges. It is best not to actually use any of the values listed in the second table in that document. They are not guaranteed nor maintained. Please refer to the first, very long table. You should find everything you want somewhere in there. Just not by the Gauge token name, or in the same format. That is a calculated value. It is not efficient for FSUIPC to keep calculating it just in case anyone may want it. To get this for yourself, simply read the Ground Altitude (offset 0020) and the aircraft altitude (offset 0570) and do a subtraction. Regards, Pete

Stutters near ground are almost always down to stuff like autogen and other ground scenery. Try turning something down. You may also get them with busy airports if you have the AI traffic set high. In version 3.12 FSUIPC is collecting more information on AI traffic now, but the time difference should be minimal -- by all means experiment with a lower value for the "TrafficScanPerFrame" parameter in the FSUIPC.INI file. By default it is set to scan 10 of traffic per frame. On faster PCs values even as high as 100 there seem to make no differences, however. The routines are fast. Alternatively you could program a button or key to reduce traffic density on approach. The new controls "Traffic Density Set" or possibly "Traffic Density Toggle" can be used for this. They are in the drop-down list in FSUIPC's Keys and Buttons pages. Be warned that whilst reducing AI traffic doesn't cause much of a hesitation, increasing it again stops FS for a short time whilst it re-reads the Traffic file (a progress bar appears). Regards, Pete

FSInterrogate is using FSUIPC, so it is identical. I've no idea what is in 05D2. What values apart from 0=North do you see? What view direction are you trying to adjust? I provided an easy to use selection for the main view directions at 3126, but I never found a way to tell which the current view direction was. I don't know what 05D2 is, so, sorry, I've no idea. Regards, Pete

I have a slightly modified version of FSUIPC, version 3.121, which may or may not fix this problem. If the sufferers who've written here already can contact me on petedowson@btconnect.com, I'll send this for testing if that's okay. In short, I found a possible timing problem, a sort of gap between an aircraft being loaded (i.e. the AIR file then panel) and my detecting this occurring. If any of the new gauges attempt to register during that period, there is a chance that their registration will be accepted then (hence the "ModuleOk" message), but then their access gets denied when FSUIPC actually sees that the aircraft has been changed. I don't know why this should be different in this version compared to 3.11 -- that part of the code hasn't changed. But in between these releases I have upgraded from MS Visual Studio C++ 6 to Visual Studio .NET 2003 with a new C/C++ compiler (version 7). It produces more efficient code (hence the smaller DLL file size), but evidently the timing changes this introduces are enough to cause this problem on some systems. Anyway, I've closed that hole, but since I couldn't reproduce it here I need it testing, first, before I release it. Please? Thanks, Pete

Ah, thanks to James, yes, I spot the error here. The first FSUIPC_Write above needs to be an FSUIPC_WriteS (for Write String). I forgot, VB is a bit weird with passing strings -- C and C++ pass the pointer, VB doesn't unless you force it to. Or something like that. As James' code snippet also shows, you still need to add a zero at the end -- it seems VB strings unlike C/C++ ones aren't stored naturally with terminating zeroes. Thanks James! Pete

There certainly isbut I'm at a loss at present. I simply cannot reproduce this. Can you turn on FSUIPC's read and write IPC logging please, keep the session short, just enough to show the problem, then make sure to close down FS and Zip up the FSUIPC.LOG and send it to petedowson@btconnect.com. The one log I've seen so far looks fine, but isn't with FS closing at the end, so shows me a little less, and there's no IPC logging. I have the PMDG 737NG and cannot make it go wrong even with my registration removed. I can only assume that my version of the 737 is different somehow, so perhaps you could include in the Zip the relevant AIRCRAFT.CFG and PANEL.CFG files, please? If I can think of anything to try to find out more I'll let you know. Maybe I'll try some code changes and send you a version to test. Write to my email first. Regards, Pete

But they are connected to the aileron control, and would be provided for in those FS models simulating them. Sounds like you want to make some adjustments to the aircraft modelling - AIRCRAFT.CFG parameters or possibly AIR file editing. That would be programmed into the visual modelling for the relevant aircraft, but still count as part of the ileron control. there's no separate control that I know of. Regards, Pete

Very strange. I can't reproduce it here. I'm really puzzled by this. I am tied up now till probably midnight tonight, then I shall think on it further. Sorry. Pete

Not that I know of, no. The 0BD4 and 0BD8 read-outs are just that, read-outs. Do any real aircraft allow separate control? When would you use it? Regards, Pete

I use both Win2000 and XP, makes no difference. FS still works with straight ASCII for these things. They sound like the wrong functions. It sounds like there's a "VB format" and Unicode, neither of which are correct. I expect VB is "wide character" if not specifically Unicode. Use your debugger and see what the actual data looks like. If every other byte is zero, it is the wrong format. Sorry, I don't know VB. You'd need to look up how to convert whatever it is VB is using into standard ASCII text. It must be a common requirement. Most of the world's software still uses standard ASCII for so many things. Regards, Pete

Is your string in ASCII? FS uses straight ASCII strings, one byte = one character, with a zero terminating byte. The only previous time anyone had the problem you describe was because he was compiling with something set to give 16 bit (wide or Unicode) characters. I don't know VB at all, but that is probably your problem. Regards, Pete

This is a joke, right? I hope so. :cry: PMDG only uses FSUIPC for its TCAS, there's no support in FSUIPC for any of the rest of that stuff. The fact that an FS aircraft loses two engines shouldn't have anything to do with FSUIPC. FS is responsible for providing engines, FSUIPC is only an interface for programs to get information they wouldn't otherwise be able to get. If this is not a joke, you may have something else going on there. I can take a look if you can supply the FSUIPC.LOG, and also there should be a file called FSUIPC_reg.bin in your C:\ root drive. Can you find that. Zip both up and send them to me at petedowson@btconnect.com. Regards, Pete

[quote name="diddel on Aug19 I bought FSUIPC 3.08 with my credit card. After a ' date=', blue screen "

There's no difference what offsets you want to use. If you want to write a program you need to know something about programming. If you know nothing, then starting with Windows programming AND FSUIPC interfacing at the same time doesn't seem like a good idea. Try some examples in a "Dummies Book of Programing" first. If you are only thinking of exercising PMDG switches and A/P settings and the like from buttons, dials and keypresses, then I may be adding these as additional controls on the Keys and Buttons pages in FSUIPC in any case, much like the additional controls there already for Project Magenta. I cannot make any commitments to this until I know more about the interface, however. No. There are simple examples in each of several different languages in the SDK. Questions posed here usually get someone responding with help and example code. I'm not the right person to try to offer any tuition. I make a lousy and impatient teacher I'm afraid. You wouldn't like me if I tried! :? Regards, Pete

I'll add it to my list, which is getting longer and longer -- things are adding faster than I can subtract them at present. Pete

I think all the PMDG staff are very busy, which is probably the problem. I picked up this statement from a message in another forum: "PMDG is working hard to finish the next patch (update SU2), which will fix all the reported bugs with the FMC and MCP. The update will also include wings views I believe and merge a few features that were originally only going to come with the -800/900 series." Anyway, I've written to PMDG as well to ask them for a progress report on the programming interface. I'll let you know what they say. Regards, Pete

I don't know. What version of FSUIPC, please? Did you first register it with version 3.00 or 3.01 and with the ö in your name? There was an error in the first versions with non-ASCII characters which was fixed pretty quickly. Either way, I can check this and correct it for you. Please send the registration email from SimMarket to me at petedowson@btconnect.com. Regards, Pete

I've been hoping PMDG would publish their programming interface soon, but I've seen no sign of it yet. Have you asked them? There's no such thing as "the FS2004 version". The SDK was updated with some FS2004 stuff when FS2004 was released, and continues to be updated with new stuff at intervals. I've got quite a lot more to add to use right now. but there's never any "re-learning" to do. The interface is still the one designed for FS98, just expanding with new data and capabilities as FSUIPC and FS develops. No, you are not wrong, I don't think it should be hard, but I think the PMDG team are busy and find it difficult to spare time on what, from their point of view, is not a particularly rewarding job. It's really the same as for the official Microsoft FS SDKs, none of which have appeared for FS2004 yet. They are "spare time" jobs, not what they are paid for. But by all means ask PMDG again, and let us know what they say. Regards, Pete

I've found a way to send standard FS controls to AI aircraft, and I've added this facility to FSUIPC version 3.12, due to be released this weekend I hope. It can also delete selected AI aircraft. But all this is handled through the IPC interface, and depends on someone writing an application to figure these things out. That isn't me. I'd much rather be able to send ATC instructions to these guys than actually try to control their engines or flight controls, but I don't know how to do that. If I ever find out, I'll add that too. It wouldn't be an FSUIPC action, but some clever utility using the facilities I am providing. aybe it can reduce thrust, or similar. Regards, Pete

It should be precise -- the "about 3 feet" is probably one metre (3.28084 feet). The High value of the Altitude (the 32-bit integer at offset 0574) is in metres. The Low value, the 32-bit (unsigned) integer at 0570 is in units of 1/65536ths of a metre, or about 0.00005 feet (though I doubt if it ever goes that accurate). It sounds like you are not reading, or are losing somewhere in the calculation, the fractional part of the value. Of course, measuring an aircraft's altitude to the exact millimetre or inch is a bit daft without defining it more in any case -- where are you measuring it from? The pilot's eye, the centre of the prop, the CofG? I don't usually bother with the fraction myself, the value in metres seems quite adequate for most purposes. Regards, Pete

Just watch out when the altitude is negative (which it won't be often, but it is possible in some parts of the world). Test the High part for < 0 and if it is you need to take extra steps because both parts are negative but only the high part is signed. I don't know VB enough to code it for you. Compilers that support 64 bit integers ("long long" or "_int64") types are an advantage in these cases. Regards, Pete

I know it's about 10 miles, but I don't know how to change it. If you find out elsewhere, please let us know. Regards, Pete

The heading shown on the FS panel is the same heading PM will be reading. If it is displaying something which is altering for winds then it sounds like he is effectively calculating track even if it is displaying as Heading. Nothing in this area has changed in FSUIPC for 4 years, and I don't recall any such PM problem before, so that's why I assumed you were using something new in PM's code. FSUIPC cannot use winds or anything else to "fiddle" a heading value, it must report the heading as provided, i.e. where the nose is pointing. Regards, Pete

Sounds like there's a mix-up between "Track" and "Heading" to me. Why don't you ask Enrico? I really don't know what PM is doing there. Why? FSUIPC is an interface to FS data. It is providing PM with the aircraft heading (which is where the nose is pointing, not necessarily where it going) and the wind component. You can switch PM's ND between TRK and HDG modes, What does it say at the top? Try the other mode, see what it says then. And compare what it says with what a regular FS gauge says for heading -- they should agree as they get the data from the same place. Are you by any chance using Enrico's own A/P modes, still in Beta I understand? If so change back to the original PM modes and see if that fixes it. Maybe there's a bug in the new code. Either way it is certainly something for Enrico to look at. The FS A/P holds correct headings fine. Regards, Pete