Pete Dowson

Most of them aren't FSUIPC controls, but FS controls -- the names are obtained directly from the CONTROLS.DLL in your FS Modules folder. They are also listed in the "List of FS2004 Controls" included in the FSUIPC.ZIP package. I am pretty sure that all controls which end with the word "SET", or, for that matter, begin with the word "AXIS", take parameters. However, not all of them will work, and in some cases the parameter values needed are downright obscure! Regards, Pete

All the weather in FS2004 is dynamic. It is changing all the time. If there was any wind, it will have probably blown the rain clouds somewhere else -- you could go look for them if you know the wind direction. FSUIPC doesn't control weather. You need a Weather control program for that. If you want to use FS2004's own downloaded weather and you want it maintained you need to tell it to download it at intervals. It may still stop raining though. It does do so in real life, and that's the point. If you want completely static, unchanging, weather, I'm afraid you will have to go back to FS2002 or earlier. FS2004 doesn't do it. Regards, Pete

FSUIPC performs the same sorts of actions from connected buttons no matter whether they be for PM or FS or whatever. If the same rotary swtches work okay for non-PM controls, then there is something going on specific to PM. If they are the controls where I set a bit and they clear a bit, it sounds like the clearing part is not occurring. I don't know which PM controls you are using -- for many PM functions there appears to be several alternatives. However, all FSUIPC will be doing is following the instructions in the PM offsets documentation, which you can find yourself in the PM site. To check that FSUIPC is indeed doing the correct things, you can Monitor the appropriate offsets (check in the PM documentation), with all changes being recorded in the FSUIPC LOG. I can then look at that for you if you like. If you are not sure how to proceed, let me know the precise programming details for the controls you are having problems with and I'll give some more advice. First, though, you may want to seek assurance from PM support that the controls you are trying to use have been designed to work correctly with PMRJ -- most of the ones I programmed in FSUIPC only used to work if you had the MCP or FCU also installed -- they were actualy routed through there. The general advice from Enrico at the time was to use the "GC controls by parameter" controls, which send values to offset 04F4. I know he did try to improve this support for more direct action, and this was certainly done for Airbus and Boeing, I really don't know about the PMRJ stuff. When you do ask for support here, please always confirm the version numbers of the modules of mine that you are using -- WideFS and FSUIPC in this case. If they are not the current supported versions (as detailed in the Announcements), please update them first. Regards Pete

No, but apparently there's something called "Currency" which may be a 64-bit integer with a sort of fractional part. From what I remember you can read it into one of those, copy it to a double floating point variable, and multiply the result by 10000 to get the true 64-bit integer values. At least that's what i seem to recall -- check the other threads (there are most certainly some here -- I do wish you'd take advice and go look!), or perhaps just look it up in a VB book.

Yes that what happend. You are most certainly making an elementary arithmetic error then, somewhere. I have now checked this thoroughly. The formula in my documentation is accurate. The only slight inaccuracy anywhere is in the FS displays, where is seems to usually round UP to the next whole number of gallons even if the value is .000001 over! The values you can read and write via FSUIPC are more accurate than the displays. Does FSInterrogate read anything anywhere? The current version will not actually connect to FS unless FS is up and running first BEFORE you run FSInterrogate. There's a new version coming which is a lot better and will connect/disconnect as needed, automatically. They are only split up like that in FSInterrogate because that version cannot handly 64-bit integers. Please use the Programmer's guide documentation as your main source of information. It contains much more explanatory material. All the help you should need is in the documentation NOT in FSInterrogate. Read those values into a 64 bit value and apply the formula given. There have been VB examples for this in threads in this Forum, and no threads have been deleted. Pete

I think I've found the reason, and fixed it. Odd that it's never been reported before. The problem is not so much in the actual program but the dialogues -- it was only looking for COM1 - COM8. If it is not too inconvenient for you to try your earlier COM port number again, but with the attached version 1.942, and confirm, please, that it is then okay, I'd be most grateful. Thank you. Regards, Pete PFCDLL1942.zip

And when you try to set 14.3 you get 15? Is that what you are saying? I really can't believe it is that much out. Let me check with FSInterrogate. [Later] I really don't know how you are seeing such large differences. Take the default 737 for instance. Values read by FSInterrogate with FS paused (engines are running so the fuel is changing, which is why I paused it): Centre tank: Capacity 2313 Level 99.81263% (the integer read is 8372890 which is 99.81262% x 128 x 65536). Thus US Gallons = 2308.6661 Left Tank: 1500 Level 99.67475% US Gallons = 1495.1213 Right Tank: 1500 Level 99.67475% US Gallons = 1495.1213 Going to the dialogue in FS: Centre = 99.8%, 2308 Gallons Left = 99.7%, 1496 gallons Right = 99.7%, 1496 gallons Left 99.7% These values match to within one part in 1496! How can you figures be correct? Please check things using FSInterrogate. See if your figures match its figures. If not, you have got something wrong! For each tank there's a CAPACITY offset, which is how many US gallons 100% represents, and a LEVEL, which is the value you read or write to tell you how full it is. The CAPACITY offset is right next to each LEVEL offset, so I'm amzed you've not noticed it. Having got the level and the capacity you can easily work out the number of US gallons. Regards, Pete

I'm not surprised. If FS wants a 32-bit integer you cannot sent it half of a 64-bit floating point number and expect it to make any sense. The two representations are completely incompatible as it is, and taking only the lower 32 bits of a 64-bit floating value will give you something totally meaningless. In fact it's that sort of thing that some Random Number generators do! What EXACTLY do you really want to fix? Do you want to be able simply to adjust the amount of fuel in the tanks, or do you want some value in some menu in FS to exactly reflect what you want? I don't understand. Why not, instead of reading percentages in FS's dialogues, read the fuel levels on the gauges? That is surely the only thing that is relevant, isn't it? Maybe, whoever derived the units used in those locations got them slightly wrong? This dates from way before my time, from FS98 and FS95 before that. Maybe instead of being 128 = 100% it was 127.76541 or some other number which has some special significance. I do not know. I would be extremely reluctant to change the documentation now even if it is slightly wrong, because there are so many programs using this stuff quite happily that I would not want them all to have to change. If all you want to achieve is to get a certain figure in the dialogue, then set that figure in that dialogue, read what is in the FSUIPC offset for that tank, and write that. This is the only way. You can read the value either in FSInterrogate or using the FSUIPC monitor (right-hand side of the Logging options page). Regards Pete

Oh, it certainly shouldn't mind. I'll check that. Thanks. Pete

Of course, because 95/(128*65536) is ZERO (there's no room for fractions in an integer)!!! In a double floating point variable it would be 0.0000113, which is still as zero as dammit. Please go find a calculator and check this for yourself. I shouldn't have to do simple sums for you. Any small number divided by a very big number is going to turn out a lot smaller! Think about it! It can be, of course, because of rounding, exactly as I said in the earlier message. If you get 100% being read as 99.9999999% you are also logically going to get 100% being written as 100.00000001% and something (probably the display you are taking so much to heart) is rounding up. If you are just trying to fiddle numbers on the display you'll need to experiment. Otherwise, just use the formula EXACTLY as documented. BTW please read your own code twice before writing, otherwise this exchange will go on forever with little progress! :wink: Regards, Pete

Yes, of course. My reply is the message in this thread immediately before the one in which you said "Please read my last reply, maybe you can help". Please scan again! Regards, Pete

I think I replied to all now, didn't I? Pete

Not the pressure, no, just the switch. Decrement will turn the switch anti-clockwise, increment clockwise. The INC/DECs work just like any other FS INC/DEC control in that respect. These controls are FS controls, not specifically FSUIPC, and designed for use with a pair of buttons or a rorary encoder. Yes, that works. But it would be much more efficient and easier to use the extra control fro this precise purpose which I added in FSUIPC. Please look down the drop-down list again. It is documented in the FSUIPC User documentation this: You just ise the same control with a different parameter. You mean a button to retard the throttle, engage reverse thrust, operate the ground spoilers, and set the autobrakes? No. I don't think real aircraft have those either. The procedure you adopt is to set the autobrakes to RTO before takeoff, keep your hands on the thrust levers until after V1 (you can't RTO after V1), and if an RTO is needed, pull the throttles back, engage reverse and hope the autobrakes cut in. On most modern real airliners the spoilers should go up too, but the default FS airliners don't do that. Regards, Pete

That sounds very much like you have two PFC drivers installed at the same time. One is getting the COM port (the frst one loaded) whilst the other is overriding the menu. Never rename previous versions and leave them in either the FS Modules folder or the main FS folder. Regards, Pete

Probably just rounding. It probably really says 49.999999999% really, but you are truncating it to the integer below. Just add half the divisor to the dividend before dividing. Please check the document. What does it say offset 0B7C contains? It's the proportion of fuel ("%") MULTIPLIED by 128 and 65536. You are writing just 95. In percentage terms this represents 100 * (95/(128 * 65536)) % or just 0.0011325% full. This probably looks like 0 to FS. For 100% you'd need to write 128 * 65536 or 8388608. You should realy have been able to work that out from what you did to the the value you read. Didn't you notice all those numbers in that code? :wink: Regards, Pete

Hi John. thanks for helping here, but it is me who is confused now. Are you saying that a VB "Integer" is 16-bit, like a C "short"? If so, I really need to remember that, because a C "int" is as long as the native processor's standard registers are -- 16-bits on a 16-bit machine, 32 on Intel and AMD current 32-bit machines, and presumably 64-bit on 64--bit machines 9when compiled with 64-bit complilers). This is also confusing me. In a 16-bit signed value, it is impossible to have any numbers bigger than 32767. The one that LOOKS like it should be 32768 is actually -32768, the largest NEGATIVE number in 16 bits. This is because the topmost bit (bit 15) is uses as the sign bit. Your code would be what might be used to convert a 16 bit value READ (from FSUIPC) into a 32 bit variable which has been previously cleared to zero as I stated earlier. It is a method of propagating the sign bit and is the same as this (I'm using pseudo-code here, no real language): IF ((y AND Hex.00008000) NE 0) THEN y = y OR Hex.FFFF0000 I'm not a VB programmer, but from what's been exchanged here I'm really really glad I am not because it looks to be a very loosely defined ambiguous language! :wink: Best Regards, Pete

What a strange language VB is. You are saying that just because I store 0 in "GndAlt" in one line, it cannot be changed later? What is the point of a variable if its value cannot be varied? The reason I said to set the Integer value to 0 BEFORE reading into it from FSUIPC, is that an Integer is 32 bits (4 bytes), and FSUIPC is only setting 16 bits (2 bytes). Unless the compiler automatically initialises your variables to zero (which is not usually the case for local variables), there could still be rubbish in the upper 16 bits which will make the value useless. Regards Pete

Examples? Is there a vertical mode for it to follow? Compare the values with the position of the horizontal FD bar in a default FS gauge. How do the changes relate? Have you cross-checked what you are reading with the values displayed by FSInterrogate, or the FSUIPC Monitor (Logging page, right hand-side, set type FLT64 for both offsets, display on screen by AdvDisplay checkbox)? Regards, Pete

You just caught me. My next message will certainly not be till Monday (well, late Sunday at best). I'm afraid I have no idea what a "Variant" is. If it isn't a 16-bit integer then it is wrong, because that is certainly what 0B4C contains. I think, usually, VB programmers have to use Integers, which are 32 bit, and so have to set them to zero first (otherwise the high 16-bits could contain rubbish off the heap or stack). I notice you label this as "Fuel" -- you do realise that 0B4C contains the ground altitude, in metres, to the nearest metre, don't you? Please look things up in the table in the Programmers' Guide. BTW, one other thing. It is very inefficient to do "Read" then "Process" if you want to read several values. The reason the two operations are separated is so that you can build up your list of requests via many Reads and even Writes, then transfer them to FSUIPC in one Process call. All the Read and Writes are within your own code, but each Process call means a process switch, which takes a lot more time, relatively. Regards, Pete

So, you are using normal fonts in Windows? And you have no other programs installed which may affect Windows? And you even tried to Restore Windows to a time earlier when things were okay? And then you completely re-installed Windows and FS -- and after all of these things it is still the same? Please confirm. After all, these are amongst the steps I suggested and which you have never answered, yet you say you have done them all! I have absolutely no idea, you must take it up with them -- they are wrong, and in any case it is completely unrelated to your problem. I won't say that again, you ignore me in any case. I will not be able to reply again now until Monday as I am away all weekend at the Blackpool conference (see http://www.ifcblackpool.com). Regards, Pete

Maybe if you showed what you were doing even I could hazard a good guess? But please forgive me. I will not be able to reply again now until Monday -- I am away at the Blackpool flight Sim event (http://www.ifcblackpool.com). Regards, Pete

I'm afraid I'm no good in VB, but hopefully others may jump in. If you scan through the many threads here you will probably come across a few examples as well. Also, please make use of the FSInterrogate program will will find in the SDK. Look at the variables you are interested in, see how they arrive and the conversions they undergo. It is very instructive and you will understand more about what you need to do. Regards, Pete

OOPS! I did it again -- sorry. I edited your message instead of posting my reply. that's twice recently, after never before for two years! Senility is setting in rapidly! Ugh. Anyway, you know what you said, so: This means that they are unverified, and possibly won't be maintained in future FS versions. In general these are items that are currently in the second table in the SDK's "Programmer's Guide" documentation. That second table lists things "discovered by accident", as it describes there. There used to be many many more in this category. Gradually the values they contain have been analysed and understood and used. As a result of this they've been gradually moved from the second table to the first, along with explanations, and thus have become "supported". Entries which are "supported" are those which I will give priority to finding in each successive version of FS. Those which are "not supported" may or may not be found, and take a lower priority in any case. That is what that means. Okay? Possibly, eventually, someone will investigate those values more thoroughly, offer explanations, and actually use them for something significant. If they want them in future FS releases they would then need to give me all that information with their request for ongoing support so I can re-categorise them. This process has been ongoing now for four years or more. You will notice credits listed to many folks who have contributed in this way -- browse through the Programmer's Guide document some time, you'll see what I mean. Regards, Pete

No idea. Do you have examples? Pete

The TCAS_DATA2 stuff isn't used by PM, it was added much later. Sorry, I don't know why pmTCAS doesn't show them -- it certainly should be able to if TrafficLook copes. When you say "all traffic except mine" do you have other MP traffic showing (e.g. inserted by AIBridge from SB2, or from SB3 directly)? If not, maybe it is deliberately restricted to only deal with true AI traffic? As a freeware module it may be restricted. I have TCAS in PM's Boeing ND, but not flying with MP traffic I really don't know if that deals with a mixture either. Maybe they only show one or the other? I can only suggest that you send a question to the PM support address, see if they can help. You might also want to try one of the freeware TCAS gauges for FS, such as Lee Hetherington's ILH_TCAS, see if that does any better. Regards, Pete