GFDisplay query/suggestion

[Murray Crane]

Pete,

First off, you do the FS community a great service with your wonderful software, and GFDisplay continues the tradition. My thanks to you.

Is there a way in GFDisplay to do timed display activations?

IVAO's pilot client, IVAP, has an offset for transponder IDENT (set it to x01, IVAP sends an IDENT to the IVAO network and resets the offset to x00...) and I have programmed a button on my GF-P8 to do this in FSUIPC with the LED activated by GFDisplay (as long as the offset is x01). As long as I have the button held in, the LED is lit. As soon as the button iss released, IVAP sets the offset back to x00 and GFDisplay extinguishes the LED; perfectly correct according to the programming I have set up.

What I would like is for the LED to slow flash for a second or two after the button is released (just as a reminder), but can't see any way to do this in the current version of GFDisplay. If it's not in there, any chance you can add this to the suggestions list for the next version?

[Pete Dowson]

Is there a way in GFDisplay to do timed display activations?

No, there are no timer facilities in there at present.

What I would like is for the LED to slow flash for a second or two after the button is released (just as a reminder), but can't see any way to do this in the current version of GFDisplay. If it's not in there, any chance you can add this to the suggestions list for the next version?

Hmmm. Yes, I'll think about how to do that. You want a time associated with an action, effectively splitting in, in this case, into two actions --

button off = slow flash, set timer

timer expired = indicator/display off

???

That's a bit complex to weave into the design philosophy I adopted.

If it's only for flashing (for instance) then how about some flashing variations instead, like

Slow flash for N secs then off

Slow flash for N secs then on steady

Fast flash ditto, ditto

Steady for N secs then off (not really a flash but still)

If that will do the job it will be easier to plug into the existing program. What do you think?

Regards,

Pete

[Murray Crane]

Hmmm. Yes, I'll think about how to do that. You want a time associated with an action, effectively splitting in, in this case, into two actions --

button off = slow flash, set timer

timer expired = indicator/display off

Basically, yes, but...

That's a bit complex to weave into the design philosophy I adopted.

If it's only for flashing (for instance) then how about some flashing variations instead, like

Slow flash for N secs then off

Slow flash for N secs then on steady

Fast flash ditto, ditto

Steady for N secs then off (not really a flash but still)

If that will do the job it will be easier to plug into the existing program. What do you think?

That would be even better (and is pretty much exactly what I am after). The IVAP IDENT offset functionality makes the P8 button act as a non-locking push-to-make, the moment the button is released the offset is (re)set to x00, making reminder indications difficult. Your proposed solutions would be perfect for me; slow flash while the offset is x01 (button press), and leave it flashing for N seconds after the offset returns to x00, then turn the indicator off altogether.

This is kind of what GFConfig does when the gear is assigned to a T8 switch: LED on steady when gear is down and locked, slow flash while gear is in motion, off when gear is retracted. Thanks in advance of the release that understand this.

[Pete Dowson]

This is kind of what GFConfig does when you assign gear to a T8 switch: LED on steady when gear is down and locked, slow flash while gear is in motion, off when gear is retracted.

Well, that isn't really comparable, and it can be done now in GFdisplay, because there are definable events for each of those changes, i.e. the value in the gear position variables. In my example for the gear LEDs on the GF-LGT unit does similar, excepting of course it uses RED for motion, not flashing.

Flashing is also used on an MCP for VOR/LOC when it's engaged but not yet acquired, and GS too -- except there's no GS LED on the GF MCP, so you'd have to make use of the APP LED instead.

Flashing "for a time" rather than until an event occurs is different. I'll need to add code for that.

Thanks in advance of the release that understand this.

It's on my list. I'll see when I can fit it in. Hopefully within the next two weeks.

Regards,

Pete

[Pete Dowson]

Version 1.10 of GFdisplay, on its way to you and the usual websites now, supports options for delayed indicator 'off' actions and the extra timed flashing options I mentioned. Please see the recent Changes notice near the top of this Forum.

Regards,

Pete

[Murray Crane]

Pete,

Hate having to dig up an "old" topic, but...

I'm having a problem with the new timed flash functionality.

I have the following code snippet in my GFDisplay.ini

[GFP8.0]
Needs=E B
B=8
L6=X7B93 U8 !=0 Fs5off;IVAP/SB3 IDENT active - Slow flash for 5 seconds

With IVAP not running, this code works perfectly (press the L6 button, the LED above slow flashes for 5 seconds then goes off - having said that, I didn't try it a second/third time just to be sure. Expect a further edit/post when I get home tonight). Unfortunately, if IVAP is running (so that the X7B93 offset is also being read/written by IVAP) the LED just isn't working correctly: a single flash on the first button press, then nothing on subsequent presses.

This leads me to suspect that the problem is inside IVAP but, to aid my debugging/aportioning blame, can I confirm that GFDisplay subsequently ignores the content of X7B93 and the 5 second flash will continue regardless once triggered?

Also, I don't suppose you (or anyone else out there in FSUIPC/GF programming land) have a debugging tool that is capable of monitoring the content of specified offset(s) in real time? I tried using the offset monitoring tool from the SDK (FSInterr?), but that wasn't immediate enough for testing/debugging this issue (least ways, not how I assumed it was supposed to be used - if it's capable of this, guidance would be most appreciated). Ideally, what I want to achieve is monitoring X7B93 in real time.

[Pete Dowson]

This leads me to suspect that the problem is inside IVAP but, to aid my debugging/aportioning blame, can I confirm that GFDisplay subsequently ignores the content of X7B93 and the 5 second flash will continue regardless once triggered?

No, that isn't the case. GFdisplay has to be able to respond logically to changes in the values -- how else can it deal with them. As soon as the value changes, the action caused by the previous change ceases and the logic is re-scanned.

As the release notes said "These all apply only when, without the flash/delay option added, the display would have been enabled/lit." Maybe I should have said "while" rather than "when", but I did think it was clear.

Also, I don't suppose you (or anyone else out there in FSUIPC/GF programming land) have a debugging tool that is capable of monitoring the content of specified offset(s) in real time?

Up to four offsets can be monitored in a number of formats using the FSUIPC Monitoring facility (see Logging page, right-hand side). You can check the Advdisplay option to have these shown in the normal FS message window, or run AdvDisplay and have it elsewhere.

Regards

Pete

[Murray Crane]

No, that isn't the case. GFdisplay has to be able to respond logically to changes in the values -- how else can it deal with them. As soon as the value changes, the action caused by the previous change ceases and the logic is re-scanned.

As the release notes said "These all apply only when, without the flash/delay option added, the display would have been enabled/lit." Maybe I should have said "while" rather than "when", but I did think it was clear.

In which case, mea culpa and I'll RTFM properly next time, promise :)

Up to four offsets can be monitored in a number of formats using the FSUIPC Monitoring facility (see Logging page, right-hand side). You can check the Advdisplay option to have these shown in the normal FS message window, or run AdvDisplay and have it elsewhere.

Didn't know that... shame I worked out how to do what I wanted well enough in FSInterrogate.

It definitely appears like something screwy is going on in IVAP, but now I know thath GFDisplay is only doing what I told it to, it does explain what I am seeing the light doing.

Thanks for all the help Pete, no doubt I'll be back later with more daft questions... :)

[Pete Dowson]

In which case, mea culpa and I'll RTFM properly next time, promise :)

Sorry, I wasn't intending to tell you off. Possibly you want it to work the way you suggest? i.e. if there's something which should hapen for n seconds after an event, that it should happen for those n seconds no matter what similar or counter events follow in that time?

If this is really a need I can think about how to accommodate it, but it does make things a little ambiguous about what should happen about these intervening changes. Should they be ignored, or have a result which is queued until the n seconds are up, or what? It does get rather complicated as you can perhaps see.

Regards

Pete

[Murray Crane]

Sorry, I wasn't intending to tell you off.

To quote Mr. Winner, "Calm down dear..." :D Not to worry; I had (a) not made the initial request as clear as I should (more on which in a moment), and (b) misunderstood the documentation entirely.

Possibly you want it to work the way you suggest? i.e. if there's something which should hapen for n seconds after an event, that it should happen for those n seconds no matter what similar or counter events follow in that time?

Precisely, but I have subsequently realised that the best place to "fix" this will likely be at source, inside IVAP and/or SB3 (don't fly on VATSIM myself, but others do...) Once the IVAO forums are running again (down at time of writing) I'll be requesting this as a feature (given cockpit builders are the only ones affected by this offset...)

[Pete Dowson]

Precisely, but I have subsequently realised that the best place to "fix" this will likely be at source, inside IVAP and/or SB3 (don't fly on VATSIM myself, but others do...) Once the IVAO forums are running again (down at time of writing) I'll be requesting this as a feature (given cockpit builders are the only ones affected by this offset...)

Okaybut if you do subsequently find that, probably optionally, the delayed display options should postpone actions resulting from value changes, let me know. I'm sure it could be accommodated.

Regards,

Pete