Pete Dowson

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

So don't you make any time for any other process (apart from the process switches enforced by the FSUIPC Process calls)? That's why I thought a message or timer based system best. Where do you get to process Windows messages, or is this loop in its own thread? What's the key got to do with it? Don't bother with that. Just check the slew mode flag at the appropriate FS offset. Regards, Pete

So don't you make any time for any other process (apart from the process switches enforced by the FSUIPC Process calls)? That's why I though a message or timer based system best. Where do you get to process Windows messages, or is this loop in its own thread? What's the key got to do with it? Don't bother with that. Just check the slew mode flag at the appropriate FS offset. You seem to be trying to make it difficult for yourself :) Regards, Pete

Version 3.08 is way out of date now. I would be advising you to update FSUIPC to 3.11, but now you might as well wait a few days for 3.12 (and a new TrafficLook) which I hope to release over the weekend. Why are you editing the INI file? You have a registered copy of FSUIPC. Just go to the Technical page in the FSUIPC Options (ALT M F) and make your selection there. However, Airline + Tail number is not an option I provide. the Airline name goes with the Flight number -- that's how they are referred to by ATC. Only the GA aircraft will have the tail number in that mode. That's correct. If you are using FS2004, wait for FSUIPC 3.12 and the updated TrafficLook. This provides departure and arrival airports (ICAO ids) for all aircraft, both airborne and ground. You would also find TrafficBoard very useful. The version for FS2002 was really good, and the one for FS2004 is being prepared now, I understand. It's derived from the FS reference number for that aircraft, and is unique. It is actually the negative of the ID in the FSUIPC slot, which is used by TCAS programs, TrafficBoard and Radar Contact, amongst others, to keep track of things. I've not really got much time to spend on applications -- TrafficLook and WeatherSet were really just written to test FSUIPC's data, and as an example of what can be done. However, in the new version of TrafficLook you can move the columns around and re-size them, and all that is remembered. The printout is in the same order, terminating according to page width (landscape) -- so you could do what you want to that way. Alternatively you could "print to file" and get a text representation. Anyway, have a play with it when it is released (with FSUIPC 3.12) and if you still want a "copy to clipboard" facility let me know and I'll put it on the list. It'll only get done when I'm held up on one of the many other things I have to do, though! Oh dear. Please check the Announcements at the top of the forum now and then. FSUIPC 3.11 was released on the 10th October, over a month ago now! Regards, Pete

I thought that timeout only applied to conflicts -- i.e. where two aircraft are facing each other and not able to move. The time was reduced in response to complaints about this in FS2002. It is a possibility, if only it could be found. I'm not sure how to do such a thing, but I will make a note in case I come across a way. Regards, Pete

Yes, just enter the registration again. Copying the key file is not enough. There is no back-handed spying by FSUIPC. Regards, Pete

I calculated 512 Bytes because each FLOAT64 is 8 bytes len. In 512 Bytes there are space for (only!) 64 FLOAT64 variables. Use 32 bit floats (C !"float" type). They are most certainly accurate enough for most purposes. In fact for most gauges you can use words or even bytes -- Fs's turn coordinator and slip ball use one byte each! Depending on how fast you want to update these, and whether you are running on the FS PC or via WideFS, you can re-use the same few bytes for many gauges. You just write the gauge number and its indication, wait for the gauge number to be cleared in acknowledgement, then write the next. I'm not saying you should do this, but some gauges need fast updates, some don't. Multiple fuel gauges, for instance, are an example where a serial update would be fine. Regards, Pete

It's just that if FSUIPC does all these "little" things, it will be huge and slow. I have to resist them, I give in to too many as it is. When something is so easily possible without a fiddle in FSUIPC, then I resist more strongly. This is one such. If an external autopilot can control FS precisely, split second by split second, it must be very easy to "fix" any change in Sim Rate. If your users are getting away with it for a whple second, or even a significant proportion of one, your timing is too lax. I don't know what you mean exactly by a loop, but I would certainly implement it all as a TimerProc, entered very frequently (even up to 55 mSecs -- one timer tick), counting entries, and doing different things at different intervals, eg "AND" the count with 3 for something repeated every 220 mSecs, and so on. Where did you learn that? There are (or used to be) a limited number of timers, but FS works on timers, quite fundamentally. All you need is one SetTimer specifying a TimerProc, then base all your other actions on multiples of the entries to that Procedure, i.e a count. Sorry if this is in C terms and you use VB or Delphi, but I'm sure the facilities are the same. You can certainly check for slew mode the same as you can check for a Sim Rate change, and stop it directly. Checking for a sudden change of location (not by slew but by direct placement) is another matter. I'm sure you can do that too -- if you check position every 10 mSecs or so and compare positions you should be able to calculate an impossible speed. Just calculate the distance between them and allow a maximum speed. There's no other way. Regards, Pete

Use 6420-661F for now. I'd prefer this to be smaller. Most applications (greedy Project Magenta excepted) manage on a lot less. If others need allocations yours will be split. But 512 bytes for inter-module communications is quite big. I'd advice against sending text data or complete flight plans this way. It is better to have files in a common folder and just use the communication here to synchronise and signal. And multiple uses of other areas can be signalled by "data type" indications in one location, and a handshake from the recipient in another. The area 6420-661F inclusive is currently marked "temporary" for you. If I need some of it before you release it, I will be back! :lol: Regards, Pete