FS2004 bug or what ??

[rcbarend 37]

For the experts ... :-)Here's what I'm trying to do.For a certain xml gauge, I'm trying to find a way to simulate mouseclicks by keyboard keys or joystick button pressing.Now, one way of doing this, is by using "unused" events for that aircraft type, as an intermediate for communication between the keyboard/joystick and my gauge.Eg., for aircraft that does not have an Afterburner, assigning keys to the Afterburner events and then monitoring these events with an OnEvent section in the xml gauge allows me to control a certain gauge function via these Afterburner events (via the assigned keys/buttons).Now, this "tricks" works fine for aircraft with jet engines.Eg., I can use use the events- TOGGLE_AFTERBURNER- TOGGLE_AFTERBURNER1- TOGGLE_AFTERBURNER2- TOGGLE_AFTERBURNER3- TOGGLE_AFTERBURNER4to get the effect I want. However, the giving the events (either from a gauge or an assigned key/button):- TOGGLE_AFTERBURNER1, for a one, non-jet engine aircraft (like the default Cessna 172)or- TOGGLE_AFTERBURNER1 and TOGGLE_AFTERBURNER2, for a two, non-jet engine aircraft (like the default Baron58).causes FS2004 to CRASH...NOTE: NOT event TOGGLE_AFTERBURNER !!Now, I could imagine that this "trick" wouldn't work (like the Afterburner A:parameters are disabled when the aircraft has no Afterburner enabled), but crashing the sim is another thing ...:-(This would mean that if I have assigned these events to joystick buttons, and I accidentally press this button while I'm flying a Cessna172, the sim crashes.Can somebody confirm this behaviour (or preferably explain it :-) ), because this sounds like a real BUG to me.Cheers, Rob Barendregt

[mgh 89]

I'm no XML expert but I don't think you can call this a bug.Assigning keys to an event you know to be non-existent and then expecting it to work is being a bit optimistic surely.

[rcbarend 37]

From my original post:""This would mean that if I have assigned these events to joystick buttons, and I accidentally press this button while I'm flying a Cessna172, the sim crashes.""As said, by itself this has nothing to do with XML gauges.I agree that this is a "trick", and as such, I cannot "expect" it to work as I would like (allthough it did work OK in FS2002).But the point I'm making is: obviously FS2004 allows me to give valid and supported keystrokes/events, allthough not functional for a certain aircraft type and given either intentionally or accidentally, that will CRASH the sim.And that, to me, qualifies as a bug :-)Rob

[mgh 89]

A bug is when an application fails when it's being used properly.You knowingly issue an afterburner command on an aircraft that doesn't have a jet engine and then complain that flight simulator crashes. That's not a bug, it's a reasonable response.

[phjvh 0]

Rob,Also very busy to catch events via the etc. section.I noticed the same phenomenon even with something trivial likeGear-event catches another Gear-event etc. in a perhaps not logical ?? order.The sim freezes and a hard reset of the comp is the only way to do business again.A lot of experimenting then finally gives the wanted result.Yesterday over 30 "Hard Reset's"! Jan"Beatus Ille Procul Negotiis"

[rcbarend 37]

Being a professional SW developper myself, MY opinion is that ANY user interaction with ANY computer software application that causes the program to crash, IS a bug.Even if the program developper didn't expect/foresaw this user behaviour.But OK, let's agree that we disagree on this :-)Rob

[phjvh 0]

Hi,As a, still not perfect, example a now functioning failure:(after many crashes!)Used is a simulated hydraulic system of the 767.When R&C hydraulic systems fail, there is a total brake failure and steering problem as in reality.When brake source is pressed, some pressure is available via the C sys "standpipe" and things start functioning again.(L:R hyd sys failure,bool) ! (L:C hyd sys failure,bool) ! and if{ 0 (>L:brake and steering failure,enum) (>K:AUTOCOORD_ON) } els{ (L:brake source,bool) (L:C standpipe quantity,number) 10 > if{ (L:brake and steering failure,enum) 1 == if{ 0 (>L:brake failure,enum) (>K:TOGGLE_TOTAL_BRAKE_FAILURE) (>K:AUTOCOORD_ON) } } els{ (L:brake and steering failure,enum) 0 == if{ 1 (>L:brake failure,enum) (>K:TOGGLE_TOTAL_BRAKE_FAILURE) (>K:AUTOCOORD_OFF) 16348 (>K:AXIS_RUDDER_SET) } } } Jan"Beatus Ille Procul Negotiis"

[mgh 89]

I have developed software internally for my company. I know how much extra error-checking code is needed to get from an application that works when *I* run it to one that is foolproof when run by others - and even then it wasn't always foolproof:(Fully error checking everything in Flight Simulator (including API calls as well as users issuing commands to functions that don't exist) would be a major task and could reduce its speed significantly. You have to draw the line somewhere and in my view Microsoft has got it in about the right place.I'd still call it a limitation, not a bug ;)

[phjvh 0]

Had a wrong copy.For the interested the functioning one:(L:R hyd sys failure,bool) ! (L:C hyd sys failure,bool) ! and if{ 0 (>L:brake and steering failure,enum) (>K:AUTOCOORD_ON) } els{ (L:brake source,bool) (L:C standpipe quantity,number) 10 > if{ (L:brake and steering failure,enum) 1 == if{ 0 (>L:brake and steering failure,enum) (>K:TOGGLE_TOTAL_BRAKE_FAILURE) (>K:AUTOCOORD_ON) } } els{ (L:brake and steering failure,enum) 0 == if{ 1 (>L:brake and steering failure,enum) (>K:TOGGLE_TOTAL_BRAKE_FAILURE) (>K:AUTOCOORD_OFF) 16348 (>K:AXIS_RUDDER_SET) } } } Jan"Beatus Ille Procul Negotiis"

[taguilo 33]

Hi Jan,1) Why not use RUDDER_SET instead of AXIS_RUDDER_SET ?. You will be saving a step...2) Why deflecting the rudder to almost max (16348)?Just curious :)Tom

[phjvh 0]

Hi, Tom,Was just a copy of lots i'm testing.Not so familiar with the section.This one let you go brakeless right against the jetway on the pilotside when no proper set-up, fun.Jan"Beatus Ille Procul Negotiis"

[Guest zip]

Hi Rob,with you 100% - if you give any software an unhandled or undefined situation, a GPF is no longer proper software engineering etiquette. But, this is FS, and that section of code was probably developped in the days of "Keyboard missing - press F1 to continue"...Which brings me somehow to the point of offsets - I suspect that when you use an offset that isn't expected, or a command that results in setting or using an offset that isn't expected, that has for me generated write protection fault or a null pointer. If you ever run FS in debug mode and set it to break on all unhandled exceptions, usually it's one or the other.There are probably "safe" variables to use, and using an unused axis is probably not a bad thing (think of an axis value as a bit vector for example - that's a few switches).I would steer clear of model specific variables.This is probably why I still like C++ gauges over XML is that you do have access to the windows API, meaning, directinput, and you can trap mouse clicks, joystick buttons and key strokes with a complete bypass of the FS "structure", but the code is significantly more complicated.Etienne

[taguilo 33]

>This is probably why I still like C++ gauges over XML is that>you do have access to the windows API, meaning, directinput,>and you can trap mouse clicks, joystick buttons and key>strokes with a complete bypass of the FS "structure", but the>code is significantly more complicated.>>Etienne>>Hi Etienne,With XML you can trap mouse clicks, joystick buttons and key strokes as well, via the system. When mastered, you can make FS behave EXACTLY like you want, something that keeps me amazed day to day... Sure you need to program a lot but, on the other hand, is in my opinion WAY less complex than C++; and you have another advantage: FS won't crash each time something goes wrong with the code (with a few exceptions).Regards,Tom

[Guest zip]

Tom, Agree with you 100% - both have significant advantages, and both have significant drawbacks - I guess it's a matter of what poison you pick :)Etienne