• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

EVENTS Wiki

Messages
1,564
Country
thailand
In a recent thread, I stated, “To consolidate a few widespread comments on Events, I'm wrapping up a wiki entry”. Right. More to it than I appreciated, but with significant help from Tom Aguilo, I gave it a shot. “Events for XML beginners” wiki.

To anyone with interest or energy to point out errors – please do. I'll upload a version to the FSDevelopers wiki site later if it passes the smell test.

Thanks go to Tom Aguilo, Bill Leaming, Paul (Gypsy Baron), Rob Barendregt, Manfred Jahn, Doug Dawson, Roy Holmes, Roman Stoviak, Arne Bartels and others whose forum posts here and at Avsim were consulted.

Cheers,

Bob
 
Last edited:
Manfred,

Nice! Thanks very much for catching typos and providing comments that will upgrade the doc. I will incorporate your suggestions. In the wiki entry, I'll also include links to the relevant forum posts and SDK websites.

Especially thanks for pointing out my careless mistake on the MyVarA 10, 20, 30 part. I can't even copy and paste my own script correctly... the trap routines should be

Gauge00: (L:MyVarA,enum) 10 + (>L:MyVarA,enum)
Gauge01: (L:MyVarA,enum) 20 + (>L:MyVarA,enum)

Good catch of a subtle point on visibility. The panel.cfg could say visibility=0 but if the window is opened while the sim is running (drop down menu), then I guess event traps will work! You're right ... Also, I wrote this with 2D in mind, so I may be missing some important issues related to Events and VC windows. Hopefully, someone will let me know...

On the water rudder and the aircraft.cfg point, I need to look into that more, but as far as I can tell, the trap routine works fine without any changes to the aircraft,cfg. I am testing on a Flight1 Cessna421 and ctrl+W moves the prop and throttle. That a/c doesn't have reversible props, but regardless, the trap routine triggers the THROTTLE_SET and PROP_PITCH_SET events. Hmmm, I am missing something, what is it?

I use BlackBox3 extensively for gauge diagnostic purposes, and that's what gave me those values. I use the HDD file output capability quite a lot too (requires LOGGER which is also on the BB website). That enables me to make graphs as shown in this thread which I often need to do to understand whats happening. I'm partial to BlackBox because my son wrote it, but Doug Dawson also provides a diagnostic gauge (a module) on his website and Tom Aguilo's XMLTools (not released yet, but soon) will have a similar feature. Doug has many cool things in his bag of tricks and Tom's new XMLTools will be a must-have. I don't know how anybody gets very far with XML scripting without something like BlackBox.

Khop khun makk khrab,

Bob

Wiki now uploaded to FSDeveloper Wiki site
 
Last edited:
Bob,

Great work!

Also, I wrote this with 2D in mind, so I may be missing some important issues related to Events and VC windows. Hopefully, someone will let me know...

A very important issue is that event trap routines in XML gauges are disabled when the user is in External view. Code-fired events still work fine but not their <On Event> capture sections. This is a PITA for those who like to manage systems (ie the autopilot) via keystrokes while flying in External view. XMLTools includes a class that brings a solution to this problem, enabling XML event trap in any view mode.

On the water rudder and the aircraft.cfg point, I need to look into that more, but as far as I can tell, the trap routine works fine without any changes to the aircraft,cfg

That's correct. Any event defined in the SDK can be triggered either by code, keyboard or mouse input regardless of the type of aircraft being flown and/or what is defined in its aircraft.cfg file.

Tom
 
On the water rudder and the aircraft.cfg point, I need to look into that more, but as far as I can tell, the trap routine works fine without any changes to the aircraft,cfg. I am testing on a Flight1 Cessna421 and ctrl+W moves the prop and throttle. That a/c doesn't have reversible props, but regardless, the trap routine triggers the THROTTLE_SET and PROP_PITCH_SET events. Hmmm, I am missing something, what is it?

It may set throttle and pitch But does it actually backtrack when on the ground? I'm pretty certain that requires specific settings in the cfg (which may already be there, though).

Here is what I got via the Sim Outhouse forum:

Step 1
Find an aircraft that needs reverse pitch props and go to its aircraft.cfg file.
This should work for all constant speed prop aircraft. Go to the prop section and find this:
prop_reverse_available = 1
minimum_on_ground_beta = 1
minimum_reverse_beta = -14
If the section is already like this, leave it, if not change to the above values or add them.
Step 2
Next go to
beta_max =
Now take the value there and subtract 1 and make it a negative # and put it in the
beta_feather =
Area.
(If there is no feather value they will need to be added)
Step 3
You must make sure that the
power_absorbed_cf =
Has a value of 0.1 if not props will go out of control.
Also make sure that the
min_rpm_for_feather =
is 0
Step 4 test!
Use the steps below to test while aircraft is at a standstill. If it moves backwards you did it!
(Note: make aircraft is not overloaded before testing.
Use in the sim
To make the props reverse do these following steps:
1. Once on ground hit Ctrl + F1. (Or move prop pitch lever all the way back
2. Then hold Ctrl + F2
You will see on the rpm gauge that the rpm drops below its usual minimum. As soon as you see that, then advance the throttle.
3. To return props to normal hit Ctrl + F4. (Or move prop pitch lever all the way forward
4. That’s it!
 
It may set throttle and pitch But does it actually backtrack when on the ground?

No, no, you're right, it (that particular airplane) doesn't backtrack on the ground. The C421 aircraft model does not feature reversible propellers. I completely agree that to accomplish the simulation effect of reversible props, the aircraft must be capable of it in the first place and that may be more involved than setting prop_reverse_available=1 in aircraft.cfg. Your interesting process, above, is very good to remember.

The only point I was trying to make is that the <On Event="TOGGLE_WATER_RUDDER"> trap will fire the THROTTLE_SET and PROP_PITCH_SET events. I'll certainly work on the wording to make it more clear.

Thanks!

Bob
 
A very important issue is that event trap routines in XML gauges are disabled when the user is in External view. Code-fired events still work fine but not their <On Event> capture sections. This is a PITA for those who like to manage systems (ie the autopilot) via keystrokes while flying in External view. XMLTools includes a class that brings a solution to this problem, enabling XML event trap in any view mode.

Thank you Tom, I would never have discovered that myself. I'll revise the doc then upload the wiki.

Bob
 
Last edited:
Right, it's in section Gauges > XML: Events and Traps, direct link:
http://www.fsdeveloper.com/wiki/index.php?title=XML:_Events_and_Traps

Bob, thanks again for a most useful tutorial. Have you got anything else up your sleeve?

@Tom: Do you have any further tips on making those event traps work in spot view? Didn't you say you were working on a utility that might do this? Searching "XML tools" doesn't come up with anything...
 
@Tom: Do you have any further tips on making those event traps work in spot view? Didn't you say you were working on a utility that might do this? Searching "XML tools" doesn't come up with anything...

Yes, XMLTools contains a class (XMLEVENTS) that will let XML event traps work in Spot view. It is not released yet, but soon. The module and example gauges are ready, just working on the documentation.

Tom
 
Bob, thanks again for a most useful tutorial. Have you got anything else up your sleeve?
Good question, not sure. Might depend what pops up in the forum. If you had not posted the water rudder thread, I wouldn't have gotten so interested in Events. Probably I will finish off the fs9gps guidebook to include the FSX-only vars but that's not so critical. Maybe Tom's XMLTools will spawn some ideas. I'm an amateur and only do XML, so everything I try is just based on empirical observation - pretty limited.

Anyway, thanks again for helping on the Events wiki. I think it turned out ok and consolidated a lot of everyone's knowledge (haha, mostly Aguilo's) into one document. Bob
 
Last edited:
Yes, XMLTools contains a class (XMLEVENTS) that will let XML event traps work in Spot view. It is not released yet, but soon. The module and example gauges are ready, just working on the documentation.

Tom
Hi,

The method I used sofar is the following:
- Define a 2D window in the panel.cfg with size 0,0 with a gauge containing the trap code, ident= "x", and nomenu=1.
- In another gauge, placed in a VC section, this window is forced open by a Open_window event for this ident "x", using Doug Dawson's WindowStatus gauge to prevent unnecessary Open events.

Another way:
- Define a 2D window in the panel.cfg with size 0,0 with a gauge containing the trap code, ident= "x", and nomenu=1 and type=Special.
- In another gauge in the VC, open this window via the ident and an Open event; only once, during initialisation.
The definition type=Special keeps the window opened when switching views.

Note that this event trapping is only a problem in FSX; in FS9 is works fine if the trapping gauge is in the VC section (so it's always loaded at start).

Rob
 
Rob, those methods are good shortcuts.

Actually with XMLEVENTS there is no need to use any extra/invisible 2D window at all.

And yes, in FS9 it works ok in VC because there is only one .MDL file. FSX has two , and it seems the specific .MDL for external views doesn't have access to Panel event traps when it has the focus (a bug maybe?)

Tom
 
Rob, those methods are good shortcuts.

Actually with XMLEVENTS there is no need to use any extra/invisible 2D window at all.

And yes, in FS9 it works ok in VC because there is only one .MDL file. FSX has two , and it seems the specific .MDL for external views doesn't have access to Panel event traps when it has the focus (a bug maybe?)

Tom
Hi Tom,

I'll certainly give XMLEvents a try when you release it....

As to your explanation on why event trapping works always in FS9 and depending on visibility in FSX:
I might be wrong, but I don't think it has to do with one or two .MDL files.
Because the same problem occurs when you:
- Fly in 2D panel view, while the event trap code is in a gauge in the VC section.
or
- Fly in VC view, while the event trap code is in a non-visible (but once-loaded) 2D window.

Moreover, in FSX, event trapping now works exactly like key trapping (ON KEY) in FS9. (Key trapping in FS9 had the same problem as event trapping now in FSX).
So maybe MS copied a bug in key trapping in FS9 to event trapping in FSX; or it's just by design ... (who knows ... : ) LoL )

Rob

PS: Does XMLEVENTS give the same solution for ON KEY as fro ON EVENT ??
 
Last edited:
Rob,

You're right, it seems to only depend on the XML gauge's visibility status. I didn't try ever the 2D panel view option, surely because I never fly in 2D view...

XMLEVENTS only deals wit ON EVENT routines, ON KEY was not considered. I always supposed ON KEY traps were only useful in a gauge that has the focus, but if you can give me some examples otherwise I could think of an alternative to include in the next version.

Tom
 
Rob,

You're right, it seems to only depend on the XML gauge's visibility status. I didn't try ever the 2D panel view option, surely because I never fly in 2D view...

XMLEVENTS only deals wit ON EVENT routines, ON KEY was not considered. I always supposed ON KEY traps were only useful in a gauge that has the focus, but if you can give me some examples otherwise I could think of an alternative to include in the next version.

Tom
Tom,

I could give you numerous examples : )
For the kind of (control-type) gauges I usually make (like in all of my VTOL stuff) , ON KEY traps would be very usefull for gauges that are in a View that DOESN'T have the focus.
In general: it allows the simmer to control the state of L:Var's via the keyboard (or via external devices that emulate keystrokes), without the need to use mouseclicks only.

The reason I generally don't use ON KEY for my gauges (and use unused Events as a "proxy" instead), is:
- BECAUSE of this visibility problem (but that only applied to FS9, since in FSX ON EVENT has the same "visibility" problem as ON KEY).
- And more important: using ON KEY to control L:Vars assumes that the user is actually not using the keystroke I define in a gauge, for another purpose. Because it would make the gauge user-configuration dependant.

Rob
 
Rob,

The problem with <On Key> captures from hidden gauges is this would enter in conflict with <On Event> captures. For example, if you press B key in Spot view, how would you know what is the correct procedure to execute, <On Key="B"> or <On Event="BAROMETRIC"> ? or maybe both?. I believe that a workaround could be programming a class to capture keystrokes via Simconnect and act accordingly.
I will think about including this option in an XMLTools' update.

Tom
 
Hi Tom,

As far as I know a main functional difference between ON KEY and ON EVENT (Default FS behaviour):
- On EVENT: captures the event, but the event is still executed.
- ON KEY: captures the keystroke, but if an event is assigned to that keystroke, the event is NOT executed.

This behaviour of ON KEY (preventing execution of an event, if assigned to that key) actually is a very usefull feature sometimes.
The only problem being that I (as a designer) make assumptions on the actual user configuration of key - event relations.

Rob
 
Hi Tom,
As far as I know a main functional difference between ON KEY and ON EVENT (Default FS behaviour):
- On EVENT: captures the event, but the event is still executed.
- ON KEY: captures the keystroke, but if an event is assigned to that keystroke, the event is NOT executed.

Yeah, that is a well known and logical behavior.

The point is actually making ON KEY and ON EVENT work simultaniously, being the proper reaction user configurable by XML code.
I guess with Simconnect it should be possible to do but I'll need to take a deep look on this.

Tom
 
Back
Top