Timers, Max Times in Minutes, when to recycle?

#1
Hey all,

I want to do these cool little mini popup message things that are misc fictional popups. I wish to use a single timer that runs on minutes. It occurred to me that two things might happen.

1. The timer might start to bottleneck the memory (massive number being produced and starts to pull down memory and frame rates in the sim
and...
2. How much time should a timer time time if a timer was timing time?
3. How would you 'loop' time? I know this is a sacred bit of information for only groundhogs, but surely we know how to do this? Modulo? How would you write a modulo for looping time? (And would a groundhog show up at my door wearing a black suit and sunglasses?)

What I'm trying to do is similar to those popup things in the CRT screens in the movie 2001 a Space Odyssee, like in the Pan Am shuttle.
 
#4
I reset my loop easily. Running an experimental loop at 500 clicks of enum. Working smoothly with 2 popups in the loop system.

I'll put an over-ride on it to block out the system for those that might find it agitating.

This is my loop system;

Code:
     <!-- Start timer and increment when both battery and avionics are ON -->
    <Element>
       <Select>
        <Value>
        (A:Avionics Master Switch,bool) (A:Electrical Master Battery,bool) and (L:RANDOM POPUP OVERRIDE,bool) 0 == and
        if{ (L:3307RANDOM POPUP Time,enum) ++ (>L:3307RANDOM POPUP Time,enum) }
        </Value>
       </Select>
    </Element>

     <!-- Stop timer after 20 seconds -->
    <Element>
       <Select>
        <Value>
                            (L:3307RANDOM POPUP Time,enum) 500 > if{ 0 (>L:3307RANDOM POPUP Time,enum) }
        </Value>
       </Select>
    </Element>
This is my popup windows...

Code:
    <Element>
        <Visible> 200 250 (L:3307RANDOM POPUP Time,enum) rng </Visible>
                               <Position X="444" Y="222"/>
        <Image Name="2K1ASO_M1.bmp" ImageSizes="300,300" Bright="Yes">
        </Image>
    </Element>
    <Element>
        <Visible> 450 499 (L:3307RANDOM POPUP Time,enum) rng </Visible>
                               <Position X="700" Y="222"/>
        <Image Name="2K1ASO_M2.bmp" ImageSizes="300,300" Bright="Yes">
        </Image>
    </Element>
Working nicely...
 
#6
The big blue square 'Battery Level' alert popup is what I am talking about. I would stagger these into random locations on the panels, probably only on the two side screens, not over Instrumentation (center screen). They show for a short moment then hide. What I would like to do is have them 'appear' and after their time runs up, they animate downwards (Shift) and then their visibility terminates.

By the way, I got some really cool 'full side' sliding animations to work. What I would LOVE to do is to have 'Mouse Drag' screen commands bring about each page of screens in the PFD and System screens. To include the GPS would be nice. Something similar to Apple iPad and the newest Garmin screens where you slide your finger sideways over the screen to turn pages. That would be the ultimate....


2018-8-4_1-33-50-502.jpg
 

Heretic

Resource contributor
#7
From a user perspective, I would curse the daylights out of the manufacturer of the aircraft if I had to drag everything onto the screen. Your hands belong on the controls all the time unless necessary (think driving), and if you have to take them off to do something, a simple tap or press has to suffice.


Is the cyclic timer reset intentional?
If not, your code needs to look like this:

Code:
(A:Avionics Master Switch,bool) (A:Electrical Master Battery,bool) and (L:RANDOM POPUP OVERRIDE,bool) 0 == and (L:3307RANDOM POPUP Time,enum) 500 &lt; and
        if{ (L:3307RANDOM POPUP Time,enum) ++ (>L:3307RANDOM POPUP Time,enum) }
This will prevent it from starting over after 500 update cycles.
 
#8
It was the WiFi and mail icons that jumped out at me. A Syros driver gets to text and check email while flying. Maybe the panel is still in development.

Nice looking flying wing though.

What are the rudder pedals for?
 
Last edited:
#9
It was the WiFi and mail icons that jumped out at me. A Syros driver gets to text and check email while flying. Maybe the panel is still in development.

Nice looking flying wing though.

What are the rudder pedals for?

The letters (email) icon is actually messages from the system. I have a message page that pops up when you tap on that. WiFi might get deleted. I am still working on that. It was supposed to be a system that picks up COMMs. I have COMMs on a headphone icon now. Made more sense.

Rudder pedals work the Yaw thrusters, which are like spoiler plates that slide up and down in the rear of the lifting body. They act like a rudder and are angled to cause a deflection and rotation on the Yaw axis. You can also turn the joysticks and that gives you Yaw control as well. Similar to the B2 flying wing. They use clamshell type spoiler yaw effectors near the wingtips.

Then it has a spoiler plate that drops down in the back by the tail wheel, identical to the Gotha flying wing.
2018-7-4_16-17-45-579.jpg


The aileron thruster pods can aim upwards for maximum STOL take-offs. The idea is a bush plane concept. All electric. Could be petrol or turbine as well. This one has colored one way plexi. Auto industry is trying to get this.


2017-6-16_20-34-48-508.jpg


Early screenshot, fixed gear version, thruster pods in max STOL take-off angle.
 
#11
Each time I read your posts I think you should write your gauges in C or C++. Many things, including timers, are so easy to do, so much easier than in XML, which is absolutely not a programming language.
I know your products, I bought some of them and I know the gauges you develop are advanced ones, sometimes complex. I am convinced they would be easier to develop in C.
 

Heretic

Resource contributor
#12
Each time I read your posts I think you should write your gauges in C or C++. Many things, including timers, are so easy to do, so much easier than in XML, which is absolutely not a programming language.
I know your products, I bought some of them and I know the gauges you develop are advanced ones, sometimes complex. I am convinced they would be easier to develop in C.
The only advantage of developing in C++ is that it runs at framerate and not 18.2 Hz max.
What Bill wants to do (and more) is perfectly possible in XML, although interaction beyond standard EventIDs requires bridging to SimConnect via XMLTools.

Oh, and reloading an XML gauge is as simple as reloading the aircraft, which is a HUGE time saver. ;)
 
#13
Each time I read your posts I think you should write your gauges in C or C++. Many things, including timers, are so easy to do, so much easier than in XML, which is absolutely not a programming language.
I know your products, I bought some of them and I know the gauges you develop are advanced ones, sometimes complex. I am convinced they would be easier to develop in C.
Thanks for that, Eric.

I wonder how hard it would be to make something in C++.
 
#14
The only advantage of developing in C++ is that it runs at framerate and not 18.2 Hz max.
What Bill wants to do (and more) is perfectly possible in XML, although interaction beyond standard EventIDs requires bridging to SimConnect via XMLTools.

Oh, and reloading an XML gauge is as simple as reloading the aircraft, which is a HUGE time saver. ;)
No, this is not the only advantage. C/C++ gives you easy access to all the Windows API, including timer management and much more... In my opinion, C/C++ makes the code much easier to debug. Maybe it is because I hate XML for coding, but I still wonder how you guys can debug such complex gauges, you are heroes from my point of view :D

I agree that reloading the aircraft makes the XML reload easy and fast, but compiling a gauge DLL is quite fast as well. Even when you have complex code, the compiler just regenerates the modified code and it is very fast.
Anyway, I don't want to convince you that C/C++ is better than XML, each of us has its own expertise, I just wanted to say some things would be easier in C/C++ ;)
 
#15
Thanks for that, Eric.

I wonder how hard it would be to make something in C++.
If you know nothing about C/C++, I can understand how difficult it would be for you to learn it. As I learnt it for work, it was easy for me to use it for gauge coding and this is why I believe it is better than XML. but as I said above, each of us has its own area of expertise. If you feel comfortable with XML and you can achieve what you want to do, then keep going :)
 
#17
It is too long to read to the end, just I agree with Umberto. I think he is too "radical", but I agree to say that XML is good because it allowed a huge number of people who don't know any programming language to develop their own gauges, this is great. It made gauge development accessible to anyone who takes the time to understand this XML notation, which is not so complex. So this is perfect for "freeware gauges", or "low end" gauges, I agree with this.
But when it comes to "complex" gauges, such as an advanced autopilot, a fly-by-wire system or worse, a full Flight Management System (FMS) with a Navigraph database, XML is not the right choice. Maybe some XML gurus can do it, but I am sure it would be hard to code and even harder to maintain.
This is why I think Lionheart should learn C or C++. He develops advanced gauges that have a very professional look and advanced features, I am sure they would be coded more easily in C or C++ and, more important, I am sure he would be able to do even better gauges, it would release his development power. This is just my personal opinion :)
 
#18
Hey Lionheart

you should check out the dragon flight sdgau papers, that will give you an idea on how it all works with C/C++ and flightsim but bare in mind, that was written for people who have a good grasp of programming. here is a snippet of my timer in one of my gauges for a project I am working on. I can also send data too and from XML when needed so I can utilize the ease of XML with the power of C/C++.

http://prntscr.com/kfbhob

the timer bits are as follows:
time_t timer; - this accesses the time header file (lets me use time)
int max time = 15*60; lets me set a maximum time
double mins = difftime(timer, maxTime); lets me compare the current timer with my max time and saves that to mins which I can use for my conditions.

Daniel
 

Heretic

Resource contributor
#19
No, this is not the only advantage. C/C++ gives you easy access to all the Windows API, including timer management and much more... In my opinion, C/C++ makes the code much easier to debug. Maybe it is because I hate XML for coding, but I still wonder how you guys can debug such complex gauges, you are heroes from my point of view :D

I agree that reloading the aircraft makes the XML reload easy and fast, but compiling a gauge DLL is quite fast as well. Even when you have complex code, the compiler just regenerates the modified code and it is very fast.
Anyway, I don't want to convince you that C/C++ is better than XML, each of us has its own expertise, I just wanted to say some things would be easier in C/C++ ;)
Timers are very easy to implement in XML.

Code:
(A:Absolute Time, seconds) (L:Absolute Time Temp, number) - 1 &gt;=
if{
<!-- Do something here -->

(A:Absolute Time, seconds) (>L:Absolute Time Temp, number) 
}
Precision may not be perfect, but it does what it does down to intervals of 1/18.2 seconds. I use it all the time.
 

n4gix

Resource contributor
#20
Don't forget the usefulness of the modulo!
Code:
<!--  === Universal Timer ===

With this universal code it's very simple to control not only the length of the cycle but the frequency of the
blink itself:
Pseudocode:<Visble>(P:Absolute time,seconds) "seed" % "blink lapse" > !</Visible>
The seed parameter is the total length of the blinking cycle. For example, if you want something to blink on every
second, you use 1, if you want it blink every half a second, use 0.5 , every two seconds, 2 ,etc.

For each seed, you can determine how long would be the duration of both the visible and invisible part.
Then:
(P:Absolute time,seconds) 1 % 0.5 > !
this will make the visible and invisible parts of half a second both.
(P:Absolute time,seconds) 1 % 0.7 > !
this will make the visible part 70% of the cycle (0.7 secs) and invisible parts of 30 % (0.3 secs).
(P:Absolute time,seconds) 0.5 % 0.25 > !
this will make the visible and invisible parts a quarter of second both.
You can invert the cycle by removing the "!" char.
-->
 
Top