Pete Dowson

Yes, isn't that what I said? Sorry. The whole reason the FSUIPC_Read and FSUIPC_Write calls are separated from the FSUIPC_Process call is to allow you to read and write more than one little item at a time. The FSUIPC_Read and FSUIPC_Write calls are really nothing whatsoever to do with FSUIPC. They are just supposed to make life easier in your programs (though in the case of VB they may be making it harder by the look of it!). All the code for those procedures is inside your program. The only call which deals with FSUIPC is FSUIPC_Process. That sends a specially formatted message to FS which causes a Process Switch (i.e. your program loses the processor, FS gains it) and allows FSUIPC to process all the read and write requests you queued up. The process switching takes A LOT LONGER that the processing of the reads and writes is likely to -- the latter are rarely as much as 1 millisecond (thousandth of a second) altogether, whereas the process switch could easily cost as much as 10 or 100 milliseconds, an order or two more. So, if you request 10 items separately, i.e. each with their own Process call, you could be using up 1000 milliseconds just for process switching (time wasted to both your program and FS), plus the 1 millisecond (max) for the actual work requested, instead of 100 milliseconds for the one process switch plus the 1. The more stuff you ask for so inefficiently the more processor time you waste. Regards, Pete

AhI have no idea why Traffic 2004 would install FSUIPC. I don't think they use it for anything at all. Furthermore, FSUIPC does not have anything to do with any "Tools" menu. The only program I am aware of which provides traffic "Tools" via such a menu is the Traffic toolbox from Microsoft -- that is a DLL downloadable from Microsoft's own FS web site. I think you may be getting mixed up between something else and FSUIPC? Regards, Pete

Well, first you are only reading 1 byte, which would only contain the first character in any case -- please do check the sizes of the various offsets, these are shown in the table. You cannot get many Aircraft names in 1 character! Anyway, it probably wouldn't come out correctly in any case because of the strange way strings are formatted in VB. I think you need code to deal with it. Hopefully, as before, you will get a VB programmer to show you. I hate to keep saying this, but VB is a big pain for me and support. In C, C++, Delphi, even Assembler, it would all be so straightforward! ;-) By the way, I hope, when you have these things figured out, that you are not doing "Read/Process" pairs all the time. It would be extremely inefficient, both for you program and for FS. You want to bunch all your Reads and Writes then do one Process call to send all the requests over to FSUIPC in one visit. Regards, Pete

What's difficult? Sending a control to FS? That only involves writing one number to offset 3110. I don't understand. Apart from the fact that I think, for VB, you need to use FSUIPC_WriteS (for Write String), and also that you have used a length of 1 byte for what looks like a string of 4 characters (plus terminator, so 5), I'll have to leave this to a VB programmer. I think VB uses a completely different string format to FS (and to Windows for that matter). Both Windows and Flight Sim use 8-bit ASCII encoded characters with a zero byte at the end terminating the string. I think VB normally uses 16-bit wide characters or Unicode with a length byte at the start. There are more things put in place to trip up VB programmers than in any other language you can use. Sometimes I think even Assembly code would be easier! ;-) Pete

What "new fsuipc"? I've not made a release since 3.48 in April. What version were you using before? What do you consider "new"? What "traffic radar" program are you referring to? Your subject line says "traffic look", but my own TrafficLook program has no "tools" option nor a "toolbar". Please be a little more specific when you ask for help as I need to know more in order to answer adequately. Also note that there has been no chasnges in the traffic information system in FSUIPC for many a release, and it is certainly still working well. Regards, Pete

Sorry, I don't understand. You mean reloading scenery progress bar? To force FS to reload scenery after you've moved the aircraft like that you need to send the "Refresh Scenery" control (look it up in the List of FS2004 controls supplied with FSUIPC). You can do that via offset 3110. It isn't so much that as me being frightened of losing my cool and getting irritable. I really am not a good teacher (ask my children!) and I can, these days, recognise when my patience has expired -- and that's when I have to stop or risk getting horribly unpleasant. On top of that I do not even know VB -- and what I do know of it makes me horrified that such an inconsistent and illogical language (to me at least) is an entry for new programmers. Regards Pete

Great! Thanks! Pete

Yes, this is what that control does. See, in the FSUIPC user documentation: You need to set the parameter if you want a different value. FSUIPC doesn't actually know what the setting was in FS before hand, it simply changes it to 0% if it is enabled, or 100% if not -- unless you give a parameter. Do you press the "Confirm" button after making any such changes? This control accepts parameters 0 - 100, not decimal points or % signs. For 50% just enter 50, press Confirm when you are happy with what you have set. Regards, Pete

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