• 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.

Sequential "Events"

G

gadgets

Resource contributor
Messages
9,388
Country
ca-britishcolumbia
Hi, Jeffrey. I came across SODE quite by accident a couple of days ago. On the surface, at least, it appears to offer a solution to my current dilemma of not being able to offer AFLT (Airfield Lights Toolbox) custom lights for P3D - since P3D ignores animation and visibility code in scenery objects.

If you are not familiar with AFLT, it is fully described on my website http://stuff4fs.com under Applications.
There is, however, one aspect of AFLT that it appears SODE could not currently support. That is, sequentially blinking lights ("running rabbit"). This is not a limiting factor for AFLT implementation via SODE since I could add a VISC block that processes the TICK18 timer the same way as I do for FS9 and FSX. (AFLT writes the .bgl code "on the fly".) But, it occurs to me that SODE processing sequential events may have other applications, and such a capability would also simplify my implementation of AFLT.

What I have in mind is the user specifying in the XML the number of events in the sequence (perhaps restricted to a power of two which simplifies the implementation), the standard duration of each event, and the event number. For example 32:3:14, meaning a cycle of 32 events, each activated for 3 ticks and, for that particular object, the event being the 14th in the sequence. (In AFLT, I also add a "seed number" to avoid synchronism between running rabbit arrays.) Alternately, the second item could be milliseconds, letting SODE "do the math".

If this is of interest to you, I'd be happy to share my sequencing algorithms which should be directly useful.

Don
 
Hi Don

Thanks for you input.
I think, the best method to implement sequences such as running rabits is a VISC block within the model. Moving the logic into the model and having SODE provide a variable is the way to go.
I am just progressing in the way SODE is handling animations with internal, object-bound animation counters. This is necessary for my (still experimental) jetway engine.
This local animation counter could then used in the VISC section similar to TICK18. Of course, that counter can be customized (period, delays -> random delays).
Unfortunately, I screwed up the code I have written in December by mistake and have to start over again now...

I will let you know when there's something productive to show.

-Jeff
 
Could you use the model visibility to hide and show each light on a timer? Or would that degrade performance? ...or is that was visc is?
 
VISC is a mdl riff section where all the visibility conditions for parts of the object are defined.
You basically attach different timer based visibility conditions to a corresponding lamp. I am pretty confident that this works, Don actually managed to do this with the TICK18 timer.
Using SODE, I plan to provide a customizable timer.

As for performance: I am using custom c++ timers to drive my own jetway and haven't seen performance issues yet. I used a custom DLL simconnect client and it is far more fluid than with a EXE based client.
 
Thanks for the response, Jeffery, and nz255 for your interest. AFLT currently implements this algorithm in BGL code and supports up to 32 sequential flashers in a line. Suggesting Jeffery implement something similar in SODE was for my convenience and, potentially, to minimize memory utilization, the alternative to which is is to rewrite this code as a VISC entry - which is what I will do.

To answer your question about performance, nz255, as you might expect, it depends on the number of strobes and your computing power. The code needs to be executed for each individual light - whether implemented as VISC in the model itself or in SODE. Currently, I have running rabbits on up to three runawys (2 ODALS , 1 MALSR) for a total of 26 strobes. I don't see any significant impact - but then I do have a relatively modern system. None of my AFLT users have reported an unacceptable impact.

Don
 
You must log in or register to reply here.
Back
Top