Pete Dowson

Yes, it also happened. After I got the FIRST error message, I tried to change the trigger, thinking that it might be a syntax error. But the error appeared every time after that, regardless what I actually entered. The only cure was to disable all triggers and restart FS. So you are probably right, and it happens when loading the plane. We still seem to be talking at cross-purposes here. There are still serious inexplicable conflicts in what you say which prevents me understanding what you are seeing. You say "Yes, it also happened" in answer to the question "you did NOT mean actually operating the A/P switch, for example?", but you end by saying "So you are probably right, and it happens when loading the plane." All I can derive from this is that (a) it happens when loading the plane, AND (b) it happens when you operate the A/P switch in FS The former is probably because PANELS.DLL is calling upon SIM1.DLL to suply data before an aircraft is fully loaded, but the latter can only be down to a problem with the Sound itself, as far as I can see. There's no point in me solving one part if the other is still a problem. So, please, can you be more specific? Just a simple statement of what you do and what you see, including WHEN you actually operate the A/P switch itself. Have you tried using the FSUIPC offsets instead yet? Does this fix the aircraft loading problem but not the sound-crashing problem when you operate the switch? I am out most of tomorrow, so there will be a delay in further replies. Apologies. Regards, Pete

What "goofy work-arounds"? I really don't see why you've got such a thing about something so simple. What difference does it make when ActiveSky is started? If it changes the wind direction at the departure airport you still need to restart the AI traffic. The FS menu isn't even created then. Anyway, don't many folks, like me, have FS starting up without that "fly now" interface? Mine boots straight into my default flight. The only time I ever see the initial setup dialogue normally is to get into the Scenery Library options -- and that's only because MS removed them form the World menu. If you mean can I trap keys being used in a dialogue, no, that isn't possible. Windows directs them on instruction from the main message loop in FS. Well, quite honestly, I really don't see what you are considering goofy. You seem to be making something very complicated out of something very simple. And if its "realism" in your set-up procedures you want, you certainly wouldn't be using that start-up dialogue, would you? You would fly from A to B and have your default flight set to the last saved flight so that next time you loaded your aircraft would be where you left it at B. And so on. I also don't see what you solve by changing where or when the weather program is started -- when the wind direction is changed, the runways being used by AI Traffic and announced by ATIS will be wrong. How does anything you've said change that? If FS was even able to allow ActiveSky to set weather before FS is actually running properly, alll that would be immediately negated when you press "fly Now", because that is the moment that the flight you've defined, with the weather you've defined, is executed. Considering that they don't "allow" (or rather, provide for) any sort of third party control over the weather at all, in any shape or form, I would have thought wishing for something even more esoteric was a bit daft. Let's wish for a weather control capability first! Regards, Pete

How? WideServer is not starting till it is safe to do so, so how is it going to tell the clients? If you want applications to start before they can talk to FS, simply use Run instead of RunReady. Also, why would you want such a thing? Do you think there's anything they could do even if I could arrange it? Regards, Pete

Sorry, FSUIPC does not offer any calibrations for slew. You need to get the controls reasonably well calibrated in Windows first. Then use FSUIPC just to make the flight controls and so on more precise. Since FSUIPC is dealing with flight controls only, the Slew controls don't come into it. Alternatively, just use the keyboard for Slew, like I do -- it's more precise in any case. To do this, go into FS's Options-Controls-Assignments and delete all assignments of axes in slew mode. Regards, Pete

Ah, so I did misunderstand you when you said "Whenever I tried to change a trigger ..." -- you did NOT mean actually operating the A/P switch, for example? That's how I read it. In fact you now seem to be saying that the error occurs during the load of the aircraft -- Esound is somehow getting to run before FS has loaded the aircraft, hence the panels crash. Right? OR do you really mean this apparently conflicting statement (in answer to me asking "It occurred whilst everything was relatively stable?": Once we can understand each other, so I can picture what is actually happening, which is difficult at present, then I can make the best suggestions. If it is because of access whilst FS is still loading, then some small changes to Esound (to check certain new FS flags, for instance) could probably fix it okay. Alternatively I could trap errors and discard them, which may or may not answer everything. But my main problem is that Esound isn't suitable, as it stands, for re-compiling using my current development system. If it was then either of these solutions could be achieved quite quickly. As it is, it is about a day's work to move it over. I can probably fit that in soon, but not this week or weekend, I'm afraid. Please clarify exactly what is happening, resolving some of the conflicting statements, and I'll make some decisions on this. Meanwhile, if this hypothesis is correct, it would have probably failed in the same way on your system in any version of FS -- it's just extremely odd that I cannot make it do so here. You may be able to do what you want better using FSUIPC offsets instead. Regards, Pete [/i]

I've just tried your exact CFG file, except with my devices and different (FS) sounds, and it works fine here in FS9.1. How can I make it fail? Incidentally, I note that you start the Autopilot Active sound in a loop when the autopilot is switched on, but you have nothing to terminate the loop, so it will continue forever after then. Well, more flexible and a little less dangerous, but all of the early uses of Esound were using the gauge tokens. It shouldn't matter. Sorry, I don't fully understand that part. You mean the Panels DLL error did NOT occur whilst loading an aircraft? It occurred whilst everything was relatively stable? If so, then I certainly don't understand that -- there's nothing in the Esound access which won't work with a stable setting. Furthermore, if you mean it doesn't crash until you change something (e.g. switch on the A/P) then it really isn't going to be related to token access -- Esound will have been looping like mad reading that token in any case. Things to check: 1. Are you using the current version of Esound? (2.572). 2. Does this occur with the default FS panels? 3. Does it occur with default FS sounds or only your own creations? Item 3 is looking the most likely. If, as you say, either "nothing happened", or a panels.dll crash occurred, but only when you expected a sound to trigger, then it seems most likely that the WAV files you are trying to use are clobbering something in FS. Esound doesn't play sounds independently from FS, it is using DirectSound and, if these are on the same sound device as FS, blending them into FS's sounds. I'm wondering if it is possible that your WAV files are not compatible with FS's WAV files. Regards, Pete

I can look at it, but I can assure you that there's nothing changed between 9.0 and 9.1 which would affect Esound. For token-named variables it does use panels.dll, just as a gauge would do (Esound started life as a gauge). PANELS.DLL will crash quite readily if token value requests are made of it when there's no aircraft loaded and ready -- e.g. during initial loading and during relading of flights and/or aircraft. However, in those times Esound doesn't really get a look in, and I've never seen a crash brought about in this way. It shouldn't be a problem at all for FSUIPC offsets -- Esound calls FSUIPC for those and the latter provides the protection for unloaded aircraft. Mind you, I haven't used Esound for many years. I simply do a re-test and make minor adjustments if necessary for each FS release. My standard test may not be extensive enough though. I just tried again with 9.1 and cannot get it to fail. At what point do you get a failure? Have you actually programmed it to do anything yet? Maybe if you sent me your Esound.CFG file to try here? BTW isn't pmSounds able to cope with virtually everything now? Regards, Pete

Odd, I've read all the threads there and I didn't see that. Never mind, must have missed it somehow. Are you using FSUIPC 3.411, the current release? Please check the Release details at the top of this forum. One bug in 3.40 which was corrected in 3.41 is listed in the details and affects spoiler calibration. Please do read the notices in this forum, especially the details of new releases, and always make sure you are using the latest version before posting problems -- I can't support old versions I'm afraid. Regards, Pete

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