Pete Dowson

This is why I supply TrafficLook inside the FSUIPC package, so you can check FS9.1 and FSUIPC at least. Any other traffic program, whether a display program or simple TCAS gauge, will be getting the information in exactly the same way as TrafficLook if it uses FSUIPC. Okay. That's all right then. However, I am still rather confused -- the correct version of TrafficBoard for FS2004 is 3. At least that's the version I have. How is it you are still using version 2 in any case? Or are there two different programs both called "TrafficBoard" (mine is by Josef Dirnberger). [Later] Looking back in the thread I see you were referring to "MRAI TrafficBoard". What is the "MRAI" bit? Regards, Pete

I don't know what you tried to download, but it most certainly isn't FSUIPC. I've never heard of the file MSIti64.exe, sorry. Pete

As far as I'm aware, the Robinson isn't modelled as a helicopter. It seems to be an almost completely standard light aircraft with reciprocating engine. All the internal data for it related to that, not to helicopter data. Before Microsoft added helicopter stuff to FS, folks used to make helicopter models using normal aircraft definitions, just trying to design the characteristics for flight to more or less match a helo. Sometimes they were almost successful. Yes, that's defined in the AIR file I think. It may even be changeable in the AIRCRAFT.CFG file these days though. Offset 0609 is nothing to do with FSUIPC. It is set by FS. All I know is that the value gets there from the aircraft definition. Did you think of looking in the AIRCRAFT.CFG file at all, by the way. I just did, and found this straight away: [GeneralEngineData] engine_type = 0 //0=Piston, 1=Jet, 2=None, 3=Helo-Turbine, 4=Rocket, 5=Turboprop Compare that to the one for the Bell: [GeneralEngineData] engine_type = 3 //0=Piston, 1=Jet, 2=None, 3=Helo-Turbine, 4=Rocket, 5=Turboprop See? :wink: Regards, Pete

Okay. I hope you get it sorted okay. Regards, Pete

According to the expert, Bob Church, you have two choices with the CH TQ -- either use the CH Control Manager to sort it all out for forward thrust with reverse handled via F1 and F2 keypresses actioned by its buttons (the ones either side of the detente), or, use FSUIPC. He tells me that users can get help on all this over at http://www.ch-hangar.com. Best regards, Pete

No, F2 reduces thrust. It doesn't just operate reverse -- it reduces forward thrust as well. It just happens to keep reducing it when it gets to zero. Regards, Pete

I understand that, of course, but: FSNav does not use nor depend upon FSUIPC. It never has. In fact it isn't likely that anything internal to FS would use FSUIPC for such a simple thing as operating a switch available to all via FS controls or Key Events. Pete

Those are controls for accessing offsets, where the offset is embedded into the control number. There's really no need to use any of those from a program which can access offsets in any case, and, in fact, there is no way provided for you to use them that way. As with all the controls they are for using directly with buttons and keypresses via FSUIPC 's Buttons and Keys pages on screen in FS -- you don't need VB or any other programming language for that. Oh, I give up! :( :( How can you have possibly assumed that? A list of controls which happen to allow you to access offsets and which never otherwise mentions offsets (let alone headings)? I am really at a complete loss here. I spend hours toiling over these documents and yet you manage to get things so completely twisted like this? How? Just because a word "offset" appears some place in a section doesn't mean the whole thing is a list of offsets. This is crazy! :cry: THE OFFSET LIST FOR FSUIPC IS IN THE PROGRAMMERS GUIDE, which is part of the FSUIPC SDK. It is the SDK you want. The advanced users guide is an extension to the User's Guide and does not list offsets at all, it is not its job! Pete

But they are neither registers nor offsets!! Where do you get that idea from? They are control numbers, extensions to the FS controls. Surely the heading for that section makes it perfectly clear: You really need to read these thing a little more carefully, especially when programming. When you program computers every little detail has to be correct. Just scanning a document too fast and automatically assuming a list of numbers equates to a list of offsets is rather a serious error. FS controls existed since FS5 days, probably before. They are not an FSUIPC invention. FS uses them to assign buttons and keys in its Options-Controls-Assignments dialogues. They appear in the DEVICES.CFG and other FS CFG files. All FSUIPC does is allow you to exploit more of them in more ways. On the http://www.schiratti.com/dowson page you will see lists of FS2000, FS2002 and FS2004 controls. I included an up to date list of FS2004 controls in the FSUIPC.ZIP, for folks to use when programming keys and buttons. However, they can also be used through the FS interface via offset 3110 as I already mentioned. You missed the easy ways of doing things and proceeded to do something which is obviously far more work. Maybe next time it will be easier, eh? :wink: Regards, Pete

By "check offset 3110" I meant read it upthrough that offset you can easily send your AP ALT INC and AP ALT DEC controls from your program. The offset is designed to allow any FS controls to be used through the FSUIPC interface. Since version 3.40 you can also send FS-added controls which include the accelerated ALT Inc/Decs (in 1000's). Registers? I list nothing about "registers"? Where are you looking? Are you confusing FS control numbers with offsets and calling them registers? Please clarify. I don't think any code in any language provides any access to machine registers, if that's what you mean. The VB code isn't mine, of course, I don't know VB. Regards, Pete

In your case the "upgrade" being to FSUIPC 3.411? Or something else? There's been absolutely no change to the AI tables FSUIPC supports. Check with TrafficLook, for example (the test program for traffic which comes with FSUIPC). It works fine. I doubt that it's anything like a similar problem. So far, since 3.411 has been released, there have been four reports here of problems which seem to me like registration inaccuracies -- i.e. apparently registered versions using an incorrect key. I've asked in all four instances for details to be forwarded to me so I can check this out, but so far none have been forthcoming. I'm not naturally suspicious but it does seem a little odd. I'd like to resolve the questions which are posted, but if the poster doesn't supply the details, for whatever reason, I can't really do much. There's no "critical" level in FSUIPC. It shows the nearest 96 -- if there are more than 96 the others are simply not included in the tables. Regards, Pete

That's rounding. The problem is that internally FS works in metres even for the altitude. You should be able to get the metres value accurate enough, though. The A/P Alt value measures down to 1/65536th of a metre, after all. I don't know what the encoder is doing, but if it produces button presses why not simply program them to do that? If you want to send FS controls from your VB program, check offset 3110. I even included the list of FS2004 controls in the latest FSUIPC package, and you can also use the FSUIPC-added controls listed in the Advanced User's document (all except the offset ones, for which of course there's no need in any case). Regards, Pete

Ouch! What sort of programing language restricts you so? That's awful. I've always thought VB was pretty terrible in any case (string handling problems, difficulties handling pointer-using interfaces which are very common in Windows, and the daft way it converts hexadecimal 0FFFF to FFFFFFFF with no warning unless you know some magic like postpending an & or something). I'm please you sorted it out though. Regards, Pete

I've no idea what you are trying to do there. What on Earth is that great long list of value conditions for? Just set the ALT by writing the value to 07D4. Convert feet to the units required by (value * 65536.0)/3.28084. Do your calculations in floating point first to avoid losing fractions then convert to a normal 32-bit integer (fixed point) before writing to 07D4. If you want to keep to multiples of 100 feet you'd need to increment your original feet value in 100's, or, if you are deriving the value from something else, convert it to the nearest multiple of 100 by something like 100 * ((value + 50) / 100) using fixed point values. Regards, Pete

As I said, they won't deploy if your main thruster(s) aren't securely at idle -- meaning the throttles are giving zero OUT value. There is an interlock to prevent deployment of reverse thrust when there's any forward thrust set. Seems you need to calibrate a bigger null idle zone on your throttles. -5404 for full thrust is okay, a bit more than the nominal 25%, but as I said, it varies from aircraft to aircraft (it's defined in the AIR or CFG file for the aircraft, I thonk). Rgards, Pete

That's wrong. Reversers work by pulling them towards you! Idle (no reverse) is full forward. You have it the wrong way around! You can reverse it if you like (there are now two ways -- the "Rev" checkbox or the option below), but the default is the more realistic. Just calibrate it correctly. The left hand box (under the "reverse Set" button must be lower than the right-hand box (under the "Idle Set" button. All the calibrations throughout FSUIPC work that way -- calibration values increase left-to-right. Also the reverse is interlocked to an idle position on the thrust levers, so, after calibration, for normal flight you have the reverser full forward and operate the thrust levers (throttles). To engage reverse you pull the thrust levers right back to a stable, calibrated idle, then pull the reverser back. Yes, because you are trying to set reverse with a higher value than idle. Reverse is negative thrust, it has a negative value, or certainly a lower value than idle, for sure. Regards, Pete

No, sorry. Why? Pete

No sorry. Best to ask others their opinion. Regards, Pete

I gave up trying to figure out FS's time shenanigans. Try the freeware "FSRealTime". I use that. Make sure you get the FS2004 version though. Regards, Pete

It will be faster by by-passing PANELS.DLL and the sending of the control via Windows message queue (that's all PANELS.DLL does with the key events). FSUIPC writes directly to the switch location in the simulation engine. Of course, you have to offset that against the call, via a SendMessage, you need to make to FSUIPC. I doubt you'd be able to measure the difference really, and it won't matter in any case unless it's a frequent event. Not really. You could try intercepting the control -- you'd need to subclass FS's FS98MAIN window and trap the WM_COMMAND with that control number. Not sure what you'd do with it though. Regards, Pete

Please try again, then close down FS. Get the FSUIPC.LOG and FSUIPC.KEY files from the Modules folder, ZIP them up and send them to me at petedowson@btconnect.com. Regards, Pete

What product? FS2004 I presume you mean? Well, on the contrary, I do think it is their fault. When the wind changes direction the ATC should reassign aircraft not actually on finals to the new runway. It doesn't matter where the weather comes from -- the same applies to FS's own weather settings or downloads! Someone has mentioned that since the FS9.1 update this does happen, but I've not noticed it. Mind you, I don't get time to fly that often. Sorry, you've lost me. I just meant, instead of toggling it twice when the weather is set, do the first toggle earlier, so that FS doesn't waste time driving AI aircraft around when you are going to remove them later in any case. Remember, the process to get them restarted is to toggle them off, then on again. There's no reason those two actions need to be together. The first one (switching off) seems to be almost instantaneous in effect, so I guess you don't need to count to five or anything in between. Sorry, this is not an area I've researched. Well, I'm an Ultimate Traffic fan, with a lot more than the default, so it affects me a lot more. I've always used 100% It needs to be in the program. I don't know how to enforce that. I have similar issues with the only program I run in addition to FS on my FS PC -- Project Magenta's MCP program. It runs okay in the background, but during loading it displays a PM identity graphic which forces Windows from FS full screen mode (on 3 Parhelia monitors) into windows just to show me, minimising FS as a result. I always have to click the FS icon in the task bar afterwards. I keep meaning to have words with Enrico about that. Regards Pete

Ah, right. Strange. Anyway, glad you are all sorted. No need, it can stand in case others are interested. I only delete topics containing profanities or generally consisting of upsetting stuff. Luckily I've not needed to do more than twice since establishing the forum. We have a nice crowd here. Regards, Pete

I know next to nothing about Airbus's I'm afraid, and certainly nothing much about the PSS cockpits. Maybe someone here can help, but I think you'll be better off asking in the PSS forum, if they have one, or at least in the FS2004 forum near here. I don't think there's anything in FSUIPC which will have any such influence on the PSS code one way or the other. Regards, Pete

It isn't really a lot to do with any version of FSUIPC, other than using a version 3.12 or later, when the Traffic Density Toggle control was added to the Buttons and Keys lists of controls. I don't know about 'best' method. Before I added that control the method some folks used was to wait until the weather was set for the departure airport, then change airports -- go somewhere a good 50-100 miles away at least. Then return. FS will restart its traffic. With the FSUIPC control, I just run FSMeteo (or ActiveSky), let it set the weather up whilst I'm busy pre-flighting, generating my plan and setting up Radar Contact and the FMS, then, when the weather is clearly set, press my key combination which is programmed to "Traffic Density toggle" -- twice (first time zeroes the traffic, second restores the previous percentage). That's it. Actually, thinking about it, it would probably be a bit better to toggle it "off" to start with, so FS doesn't both with AI traffic for a while, then just toggle it back "on" when ready. Someone did ask if the weather program could do this automatically, and I did say, yes, it could -- since version 3.40 of FSUIPC -- as the added FSUIPC controls can be instigated through the FSUIPC interface just like the FS controls. Maybe this is where the confusion arises? I think the person who asked was going to go off and suggest it to whoever writes his favoured weather program. For myself, I am not really in favour of it being done automatically because, whilst zeroing traffic is almost instantaneous, toggling it back to, say, 100%, can take a noticeable time during which you get a progress bar on screen. How long it takes depends on how much traffic you've added. Personally, I'd rather this was under my control. Regards, Pete