Attempting to trap VIEW_RESET event

[rpmc]

I'm attempting to trap events associated with View commands mapped to the keyboard. For example, when NUMPAD 4 is pressed, the outside view looks left and the following trap successfully runs script A:

<Keys>
  <On Event="VIEW_LEFT">
    do script A
  </On>
</Keys>

When NUMPAD 4 is released, the outside view returns to the forward view, and an event logger (using XMLEVENTS Logger) shows that the sim threw VIEW_RESET simultaneously with the numpad release.

I want to be able to trap VIEW_RESET and run script B (in other words, I want to run script B when the numpad is released), but the following does not successfully trap VIEW_RESET:

<Keys>
  <On Event="VIEW_LEFT">
    do script A
  </On>
  <On Event="VIEW_RESET">
    do script A
    (L:ViewReset, enum) ++ (>L:ViewReset, enum)
  </On>
</Keys>

(L:ViewReset, enum) ++ (>L:ViewReset, enum) was added as an additional check, but it never increments.

Is it possible to trap VIEW_RESET? If so, what is wrong with my construction above?

Thanks in advance.

Bob

 

[Deleted member 1281]

Bob, tried your code here, and on my rig L_ViewReset does increment when releasing Num 4.

I noticed that pressing Num 4 issues a stream of Num Left events, so whatever "script A" does it would have to be handled with caution.

 

[Deleted member 1281]

Edit, tried this with some obvious stuff:

<On Event="VIEW_RESET">
  (A:LIGHT LANDING, bool) if{ (>K:LANDING_LIGHTS_TOGGLE) }
  (L:ViewReset, enum) ++ (>L:ViewReset, enum)
</On>
<On Event="VIEW_LEFT">
  (A:LIGHT LANDING, bool) ! if{ (>K:LANDING_LIGHTS_TOGGLE) }
</On>

Works as expected!

 

[rpmc]

Interesting. Thanks for that. I'll try it on a couple of laptops rather than my desktop to see if I get different results.

I just noticed a sloppy typo in the VIEW_RESET trap example - it should be "do script B".

Anyway, here are my actual scripts; they are simple. This time, I added a (L:ViewLeft, enum) ++ (>L:ViewLeft, enum):

<Keys>
  <On Event="VIEW_LEFT">
    -90 (>L:SWIVEL CAM YAW, degrees)
    (L:ViewLeft, enum) ++ (>L:ViewLeft, enum)
  </On>
  <On Event="VIEW_RESET">
    0 (>L:SWIVEL CAM YAW, degrees)
    (L:ViewReset, enum) ++ (>L:ViewReset, enum)
  </On>
</Keys>

And, XMLEVENTS Logger result:

L:ViewLeft returns 1 and L:SWIVEL CAM YAW returns -90 as soon as I press NUMPAD4, but L:ViewLeft never increments beyond 1 even though the event logger shows the stream of VIEW_LEFT events.

When NUIMPAD4 is released, L:SWIVEL CAM YAW does not return to zero, and L:ViewReset remains at zero, having never incremented, despite the sim throwing a VIEW_RESET.

There is something I'm missing about the event handler system, I guess. Off to try this on some laptops. The sim, BTW, is FSXA.

Bob

 

[rpmc]

Edit, tried this with some obvious stuff: ...

Manfred,

Thanks again for you helpful input and examples. I have to think more about what's going on with my rig...

Bob

 

[Deleted member 1281]

You mention 'outside view' in post #1. Are you jumping from VC view to 'spot' or something? If so, maybe the Keys gauge isn't active in external view? For me, when in the VC, Num4 rotates the view to the left, but stays within the VC, even goes full circle if pressed continuously. Cameradefs params could be a significant factor, too, I suppose.

 

[rpmc]

You mention 'outside view' in post #1. Are you jumping from VC view to 'spot' or something? If so, maybe the Keys gauge isn't active in external view?

I should have said external view rather that outside. I'm testing this all in 2D up to this point, and the view is what the pilot sees.

 

[Deleted member 1281]

Ah from 2D view, I got it. Works just as well here: the landing lights code (with the counter added to both events) increments continually while pressing and once when released. (Because of the conditional clauses the landing light switch istriggered only once.) Perhaps try the code so as to see whether your gauge is 'live'. Your event logging seems to indicate it isn't.

 

[ddawson]

If you are placing the gauge in a 2D panel window, the 'on event' tags will not work unless the gauge's window is visible.

 

[rpmc]

Perhaps try the code so as to see whether your gauge is 'live'. Your event logging seems to indicate it isn't.

If you are placing the gauge in a 2D panel window, the 'on event' tags will not work unless the gauge's window is visible.

That was it. The gauge containing the trap script was 'visible' as a separate window on the screen, but not until I undocked it, did the traps work as I wanted.

Rookie mistake.

Bob

 

[Deleted member 1281]

Splendid , congrats.

Like many other users here I usually have a separate window called Keys containing a gauge called keys.xml with all the key traps, I make that visible=1, ident=10002, and type=SPECIAL.

To ensure that this is always open I run a (re-)initialization gauge from the VC where, among other things, I set

10002 (>K:PANEL_ID_OPEN)

. So far this hasn't let me down.

If you want the verbose version of this , let me know.

 

[rpmc]

The gauge that contains my key traps, Compound_Rotation.xml, is configured as a separate window with visible=1 in panel.cfg. When I launch the aircraft with a 2D Main Panel (haven't gotten to VC tests yet), Compound_Rotation opens and is 'visible', but in a docked state. In that state my key traps do not function completely. I get one increment of L:ViewLeft and -90 stored in L:SWIVEL CAM YAW, but after that, no apparent key trap script activity. That is, until I undock Compound_Rotation, then the traps work as I had intended. I knew a gauge's window had to be visible for key traps to work, but I did not know they had to be also undocked. When I test this with a VC, there will be more things to discover, I'm sure.

Your keys.xml sounds like a best practice, and I will look into that later. Question regarding the initialization gauge: what method do you use to prevent PANEL_ID_OPEN from firing before the event handler system is functioning? If that's in the verbose version, then, yeah, I'd like to see it.

By the way, in a previous thread, I asked if there is a way to open a window in an undocked state. No solution came out of it but Doug had an idea and graciously said he would put that on his gauge project list.

Bob

 

[DragonflightDesign]

Go to Avsim.com and search 'HOORAY! How to force sub-panel to open "undocked..." '. It's in C but you should be able to convert to XML.

 

[Deleted member 1281]

Here you go, a sample config, FWIW. Can't really say what exactly makes Win04 behave, but it does, both on first loading and on loading a saved flight, interior and exterior views.

First, panel.cfg:

[Window Titles]
Window00=Main
Window04=Keys

[Window04]
Background_color=0,0,0
size_mm=1,1
visible=1
ident=10002
nomenu=1
type=SPECIAL
gauge00=Bev!Keys, 0,0,1,1

[Vcockpit01]
gauge51=Bev!Sim_Bev, 0,1,1,1  // Bev is my current project cab/folder

Second, initialization routine in Sim_Bev.xml, as suggested elsewhere in this forum

<Element><Select><Value>
(L:ReadyToReceiveEvents, bool) ! if{
  (>K:CABIN_SEATBELTS_ALERT_SWITCH_TOGGLE)
  (A:CABIN SEATBELTS ALERT SWITCH, bool)
  if{ 1 (>L:ReadyToReceiveEvents,bool) }
} els{
  (L:AircraftInitialisation,bool) !
  if{
  <!-- initializations go here -->
    10002 (>K:PANEL_ID_OPEN)
  <!-- ... more initializations -->
    1 (>L:AircraftInitialisation, bool)
  }
}
</Value></Select></Element>

Finally, Keys.xml with, e.g., Bob's code:

<?xml version="1.0" encoding="utf-8"?>
<Gauge Name="Keys" Version="1.0">
<Size X="1" Y="1"/>
<Keys>
<On Event="VIEW_RESET">
  (A:LIGHT LANDING, bool) if{ (>K:LANDING_LIGHTS_TOGGLE) }
  0 (>L:ViewReset, enum)
</On>
<On Event="VIEW_LEFT">
  (A:LIGHT LANDING, bool) ! if{ (>K:LANDING_LIGHTS_TOGGLE) }
  (L:ViewReset, enum) ++ (>L:ViewReset, enum)
</On>
</Keys>
</Gauge>

 

[ddawson]

You can use my Window Status gauge to check whether the window containing your trap gauge is open or not.
If it is not, you can use the KANEL_ID_OPEN event to put it back on the screen.
This method will keep the window open, even in an external view, without taking the trouble to undock it.