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

SimObject Display Engine [released]

Messages
611
Country
switzerland
As already mentioned in an other thread , I am working on a module that allows scenery designers to add some "brains" into their scenery object. As the name of the module implies, this is for display purposes, i.e. how and when an object should be shown in the sim. This is done by means of conditions which can be date based (seasonal, month, time of day) or user triggered via an in-game selection menu.
The user can trigger custom animations or control visibility of the object. Moreover, the user can switch through a series of models during runtime also by triggers.
It is also possible to set a "proximity switch" on an object to control its visibility and/or animation (e.g. for automatic hangar door opening).

I'm trying to keep the set of instructions to be used by the developer simple and generic, so you can come up with creative implementations.

The implementation on the developer side will be done through simple XML-files describing the behaviour of the objects, similar to what you are used to do now to place scenery objects, but with those new "condition tags". See the attachment for an example of such an XML file.

I have made a quick and dirty demonstration video to show you the current functionality. I will add more features as time progresses. The next idea I want to implement is wind dependency (direction and velocity). See video description for a walkthrough of the course of actions.
VIDEO

If you have any suggestions of features you want to have concerning the display of your objects in FSX/P3D, feel free to share your ideas :)

Regards,
Jeff
 

Attachments

  • XML_2.png
    XML_2.png
    33.1 KB · Views: 1,641
Last edited:
Messages
444
Country
unitedkingdom
That's very interesting, highly anticipated by me at least :)

what about an animation trigger based on the user's proximity to the scenery object (**edit: just saw the proximity trigger..lol**) or an animation trigger when a user is located at a specific area in the sim (i.e. trigger display when Alt=0, and stop display when Alt>0)
 
Last edited:
Messages
105
Can you nest or group triggers? That could be useful for more complex stuff, such as ground crew or APIS with actual information
 
Messages
611
Country
switzerland
Regarding nested logic or more complex chaining of conditions: In the current state, the module only supports simple on-off, cycle and trigger states. To be able to really have complex control, I would have to implement "finite state machines", which have to be defined by the developer with some sort of scripting language...that's what fsdreamteam's couatl engine can offer I think using Python.

That's currently beyond the scope of my module. I may put some thoughts into that matter once all this "simple" stuff works, but I can't promise anything in this direction as of now. It will be a big challenge to do this to offer a generic platform for all kinds of implementations.
 
Messages
240
Country
switzerland
Regarding nested logic or more complex chaining of conditions: In the current state, the module only supports simple on-off, cycle and trigger states. To be able to really have complex control, I would have to implement "finite state machines", which have to be defined by the developer with some sort of scripting language...that's what fsdreamteam's couatl engine can offer I think using Python.

That's more or less what we do.

We did something similar to your approach in 2005, before FSX was released, we had a XML file controlling objects and their conditions, and was working in FS9 too, just using direct in-memory hacks instead of Simconnect.

After using it for years, it was fairly obvious that with such triggers you end up wanting more flexibility, and only a true scripting language would give you that.

So, we started writing our custom Python interpreter in 2008, when we designed our XPOI product, which needed a way more complex logic, because it needed to access the internet, made date queries on remote web servers, presenting a complex UI, etc. The whole XPOI program logic was written entirely in Python.

Then, we started developing GSX, so we had to improve the script capabilities a lot, so we now have pathfinding routines, finite state machines, custom animation players, custom vehicle movers based on IK to overcome default vehicles behaviors, and even an astronomical calculator...also, we can use the whole wxWindows GUI from FSX. The whole GSX is also written 100% in Python.

Note that we don't just wrap Simconnect, but we also use the Panel interface, the GPS interface, many FSX undocumented API calls, the wx GUI and the OpenAL sound library, all handled in a coherent language, regardless of what the low-level routines do.

Right now, we use scripts for basically everything, latest sceneries even use self-modifying code to do on-the-fly patches and multi-seasonal code for objects or, for example, to have the objects have different material properties if they are run under Prepar3D V2.
 
Messages
611
Country
switzerland
Umberto, thanks for explaining a bit the inner workings of your engine. Impressive list of features I must say. Of course it's impossible to do something like GSX with the API offered by SimConnect ;)
I am aiming for designers, who desire simple switching of their objects without having to code in a scripting language.

Quick update on the progress:

Supported Variables/Conditions
  1. Conditional Visibility
    • Month of Year (JAN-DEC)
    • Time Of Day (DAWN, DAY, DUSK, NIGHT)
    • Precipitation (NONE, RAIN, SNOW)
    • Wind Direction [degrees] (0-359)
    • Wind Velocity [kts]
    • (Meteo.) Visibility [m]
    • Air Temperature [°C]
    You can specify a range or a single value in which the object is to be shown in FSX.
    NEW: You can connect all those conditions with arbitrary boolean logic defined in the xml (AND, OR, NOT). I have implemented a parser that reads your logic and handles it during runtime.:D
  2. NEW: Variable-driven Rotation
    • Wind Direction: Turn your object into the wind.
    • User Aircraft Position: Point your object towards the user aircraft. This is available in 2D (heading only) or 3D (heading and pitch)

Coming soon:
  • Conditional Visibility: Separation Planes (e.g. for PAPI lights)

Regards,
Jeff
 
Last edited:
Messages
757
Country
netherlands
Supported Variables/Conditions
  1. Conditional Visibility
    • Month of Year (JAN-DEC)


  1. Maybe you should also include day of the year - for synchronisation with FSX seasons.

    Coming soon:
    • Conditional Visibility: Separation Planes (e.g. for PAPI lights)

    Regards,
    Jeff

    I imagine that will be a b*tch to program :) I briefly considered it, but evetually decided against it for the time being. I am not much of a fan of 3D relative position calculations, even if you approximate the geo coordinates to a rectangle.
    Plus, that should be relative of the camera position, not airplane position - another hurdle.
 
Messages
611
Country
switzerland
Thanks Peter for the inputs.
Day of year should be easy to include.
Haha, and yes, separation plane is tricky to calculate. I'm still thinking of a way to make a simple parametrization for the end user. Didn't think of the camera position yet. Hmm, let's see :rolleyes:
I think simplifying the calculations to a rectangular plane around the object's coordinates is a good approximation for the small distances normally used in and around an airport.

-Jeff
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
The separation plane would be very useful to do things like dynamic docking systems. But from coding point of view it can be hard indeed.

Maybe alternatively providing a variables like azimuth and elevation to the object and a distance to object would be easier?
 
Messages
757
Country
netherlands
The separation plane would be very useful to do things like dynamic docking systems. But from coding point of view it can be hard indeed.

Maybe alternatively providing a variables like azimuth and elevation to the object and a distance to object would be easier?

Docking systems would work better with azimuth and distance - after all, the laser guiding ones work like that anyway. The ones that work with parallax are even easier - it's all just modelling.

PAPI is going to be tricky though.
 
Messages
111
Country
austria
VERY, VERY, VERY APPRECIATED!!!

Would be great to have such functionality for our sceneries.
As I have seen on your screenshot of the XML code, it seems that it will work only with simobjects and not with library objects, so it should also accept GUID for conditional placement of objects like the following code taken from orbx, which are already using such technology for their sceneries with the DynPlacement.dll

Code:
<DynPlacement.Document>
   <Object>
        <AltAGL>0</AltAGL>
        <GUID>{712651b0-197b-48c5-b093-4b823ff922fe}</GUID>
        <Condition>MONTH_OF_YEAR GREATER_OR_EQUAL 4 AND MONTH OF YEAR LESS_OR_EQUAL 10</Condition>
        <Lat>46.830753259</Lat>
        <Lon>16.272731930</Lon>
        <Heading>34.71</Heading>
    </Object>
</DynPlacement.Document>
Regards,
Heinrich
 
Messages
611
Country
switzerland
Servus Heinrich,
Can you confirm that the DynPlacement.dll module does the switching during runtime? I'm not aware of a SimConnect API function that can inject/remove GUID-referenced models into the sim.:confused: SimObjects do have the SimTitle property, which has to be provided to the API function.
--

Meanwhile, I got the separation plane working. The hard part was to calculate the eye position of the user aircraft. So now you can specify if you want the aircraft reference point or the eye position to be used for the separation plane check.

Regarding docking systems: To provide parameters like distance, azimuth and elevation to the object is feasible. The only problem I see with the current implementation, that it is based on switching of entire models. So for every distance step, you need to create a separate model. Of course you can have one static housing and only make several variants of the distance indication bar, which are shown according to the variable. I haven't tested if this wouldn't strain the sim too much (creating and replacing objects all the time).

Regards,
Jeff
 
Messages
111
Country
austria
Hi Jeff,
In fact that all orbx scenery objects are ordinary library objects, the DynPlacement.dll is switching during runtime of FSX or ORBX.

I attached all the text strings found in the dll. Maybe you can find some helpful information inside. :stirthepo

Regards,
Heinrich
 

Attachments

  • DynPlacement1.txt
    21.1 KB · Views: 1,244
Messages
757
Country
netherlands
Servus Heinrich,
Can you confirm that the DynPlacement.dll module does the switching during runtime? I'm not aware of a SimConnect API function that can inject/remove GUID-referenced models into the sim.:confused: SimObjects do have the SimTitle property, which has to be provided to the API function.

Same here, don't know about it. Maybe check - if ORBX uses some library management software of their own making, it just might be able to populate simobjects.cfg with simobject definitions where title is the same as library guid.

Meanwhile, I got the separation plane working. The hard part was to calculate the eye position of the user aircraft. So now you can specify if you want the aircraft reference point or the eye position to be used for the separation plane check.

Good progress! Eventually I guess I will have to delve in it myself :D

Regarding docking systems: To provide parameters like distance, azimuth and elevation to the object is feasible. The only problem I see with the current implementation, that it is based on switching of entire models. So for every distance step, you need to create a separate model. Of course you can have one static housing and only make several variants of the distance indication bar, which are shown according to the variable. I haven't tested if this wouldn't strain the sim too much (creating and replacing objects all the time).

Regards,
Jeff

As long as FSX is concerned, I only have one word for you. Animations ;)

Then for P3Dv2 I guess direct drawing would work even better, but this solution would lock you out of FSX and first generation P3D.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
Regarding docking systems: To provide parameters like distance, azimuth and elevation to the object is feasible. The only problem I see with the current implementation, that it is based on switching of entire models. So for every distance step, you need to create a separate model. Of course you can have one static housing and only make several variants of the distance indication bar, which are shown according to the variable. I haven't tested if this wouldn't strain the sim too much (creating and replacing objects all the time).

Maybe we don't have to use many different models. Once a object is placed through simconnect you can use the visibility conditions in the mdl as well, just like aircraft do. So part of the logic can probably go in the mdl.

I have been testing this for wind rotation, once the object is placed through simconnect it is perfectly possible to make an animation that rotates it with the wind. The placement module doesn't have to do that, all it needs to do is place the object.

So if there are some good variables available, the same approach could work for a docking system.
 
Messages
757
Country
netherlands
Maybe we don't have to use many different models. Once a object is placed through simconnect you can use the visibility conditions in the mdl as well, just like aircraft do. So part of the logic can probably go in the mdl.

I have been testing this for wind rotation, once the object is placed through simconnect it is perfectly possible to make an animation that rotates it with the wind. The placement module doesn't have to do that, all it needs to do is place the object.

So if there are some good variables available, the same approach could work for a docking system.

You can make any variable you should ever think of needing, Arno ;)
 
Messages
611
Country
switzerland
premek, thanks for the hint concerning the use of GUID. So after all, it is still a simobject, just referencing the model from a library rather than directly. I'll leave it to the developer, what approach he/she uses. In the end, you have to provide a SimTitle anyway.

Arno, the idea of putting some logic into the object works very nicely. For very dynamic objects, which display states have to be changed/updated frequently, this is the way to go. In my test with a custom PAPI, the creation and removal of the model depending on the separation plane is sometimes too slow to keep up with the refresh rate (sim frame) of the internal routine that checks for the condition. By moving that simple on-off logic into the model (VISC), it is now placed once as you suggested, and the switching is now super-responsive:D I will try to implement a demonstration docking system using this method later.

I have attached an example how to set up a 4-Unit PAPI. There is one tiny mdl called "SODE PAPI Light" that basically is two squares with a halo texture on it (red/white).
You place four of these to the location of your static PAPI model, set the heading and the angles for each of them and that's it! No more vector calculations! The engine handles that for you. All calculations all relative to the heading and angles set in the xml. So you can use that light over and over again.
As for the real-world PAPI, the eye-position is used for the check instead of the aircraft reference point as it is used now. Terms like Minimum Eye Height over Threshold (MEHT) will be of importance now.
Furthermore, you are now able to group objects together, that share common conditions. In the attached example, I have set a general visibility trigger on the PAPI lights. You can manually turn them off and on again through the pop-up text-menu (no more frequency dialing for Pilot controlled lighting!).
With the same idea, you can turn them on automatically with certain conditions (visibility, time, whatever is supported by the engine).

Some progress was also made on controlling animations directly by setting the keyframe value. At the moment, you can incrementally control the animation via the pop-up text menu. Maybe I should make another demo video for that...

Thanks for the interest and regards,
Jeff
 

Attachments

  • TestPAPI_CODE.png
    TestPAPI_CODE.png
    54.7 KB · Views: 1,038
Last edited:
Top