EnvironmentalDataProbe

[gadgets]

Jeffery, EnvironmentalDataProbe requires a ClientList. The on-line documentation calls for a list of SimObject names separated by semi-colons. Can this also be a Group Name (which, in my case, would comprise the same list of models)?

Don

 

[gadgets]

Further to my question above, would it be possible to extend the EnvironmentalDataProbe to include actual time-of-day, e.g. 1425 - either local time or Zulu? AFLT currently includes simulation of airport operating hours (the implementation of which is fairly complex). It would be good not to have to include that (identical) overhead in every VISC block - of which there could be hundreds.

Also, an enhancement that should be broadly useful and that would obviate what I'm asking for above. Currently, (while I stand to be corrected) it appears one can specify multiple conditions and apply the result to a group. What would be very useful is for multiple condition logic to be able to access any available simulation variable (probably via the EnvironmentalDataProbe) and, using the current set of operators, to create one or more custom variables accessible by SimObjects/Groups .

My wish-list for today.

Don

 

[12bPilot]

I will check the code if I can use the group name in the client list. For now, you need to provide the SimObject name.
The inclusion of actual time of day is on the list.
For the last question, what would you want to do with the custom variables? Control visibility of the object, or parts thereof?

 

[12bPilot]

Okay, the probe needs a proper SimObject name. I checked the possibility of using a group name but that would require quite some code, because internally, SODE handles every object as a single instance and the group info is not really needed during runtime (only during xml parsing at start-up). So I won't change the mechanism for now.

 

[gadgets]

the probe needs a proper SimObject name. I checked the possibility of using a group name but that would require quite some code, because internally, SODE handles every object as a single instance and the group info is not really needed during runtime (only during xml parsing at start-up). So I won't change the mechanism for now.

Thanks for checking. In my case, the ClientList will include virtually ever object (several hundred of them). Is "ALL" a possibility?

The inclusion of actual time of day is on the list.

Thanks. I noticed this yesterday when I was scouring the forum looking for a solution to a problem I was experiencing (now fixed).

For the last question, what would you want to do with the custom variables? Control visibility of the object, or parts thereof?

In my experience, users of my applications always want to do more than I intended the app to do. So, I was simply suggesting a mechanism allowing the user to access any variable(s) would enhance the attractiveness of SODE and avoid a continual series of requests for you to expand the scope of EDP. All I need (at this point) is time-of-day (HH:MM).

Good progress with AFLT implementation. Yesterday, I managed to display every custom light - including both those in AFLT arrays and those placed in the airport (e.g., by ADE) using SODE. No blinking or conditional display yet, but given a few days ....

Don

 

[12bPilot]

I have found a way to let the XML parser to do the work (figuring out the underlying SimObjects from a group name). So the group name will be a valid entry in the client list in the next release
Wow, hundreds of objects? Any issues so far with that (performance wise)? There's another thread which reported appearance issues with a larger number of grouped objects...I'd still rather build clusters of objects into one mdl and let SODE manipulate only that very one.

Congrats on your progress, I hope it all falls into place as desired!

 

[gadgets]

I have found a way to let the XML parser to do the work (figuring out the underlying SimObjects from a group name). So the group name will be a valid entry in the client list in the next release

Any chance time-of-day (HH;MM) could also be in the next release, please? How far off is it?

Wow, hundreds of objects? Any issues so far with that (performance wise)?

Too early to tell. SODE isn't doing anything yet but displaying static objects. However, you can see why I'm interested in efficiency. I'll let you know.

I'd still rather build clusters of objects into one mdl and let SODE manipulate only that very one.

That would be nice, but I don't know how it could be accomplished. These objects are individually placed - some using other object placement tools such as ADE, and are scattered all over the airport. The separation could be as much as two miles (or more). About half use separation planes.

Don
.

 

[gadgets]

Just did a quick test on SODE's impact on FSP in FSX. Without custom lights, FPS ~50. With custom lights controlled using .bgl commands (AFLT's normal mode), FPS ~ 38. SODE static display of custom lights, FPS ~ 30. It will be interesting to see what happens when the EDP is running and separation planes are in use. Anything you can do to minimize this impact will be helpful

Don

 

[gadgets]

Jeffery, just so you don't do anything you wouldn't have otherwise done, I am very disappointed to report that it appears the only elements of SODE that I will be able to use for AFLT is static display and separation planes. This is because I misunderstood how conditional visibility works.

I had assumed that conditional visibility (driven by EDP and PCD) used the same concept as Separation Planes, i.e., an on/off flag that was accessible from the VISC block. However, having just implemented the EDP, I find that it suppresses the display of the entire model. (I hadn't noticed that note in the documentation previously.)

I'm wondering if you could optionally map conditional visibility to one or more flags (probably in the VELOCITY BODY Y variable) rather than suppressing the entire model. This would also eliminate the need for an EDP client list.

My difficulty is that at the medium-sized airport I'm using for test purposes (my CYYJ) there are nearly 600 individual lights. (At a large airport, there could be in excess of a thousand.) While I could separate the lights (effects) from the models, this would mean an additional 600 models to be displayed with the associated impact on FPS.

(See what I mean by users always wanting more than the developer plans to provide?

Don

 

[12bPilot]

I'm right now adding local/zulu time into SODE.
Performance: Well, that's what I've expected. That's way I'm advertising to put as much stuff into one mdl as possible. Separation planes will decrease fps even further I'm afraid.
For the airport lighting scenario, I would try the texture/mipmap based approach as suggested somewhere else here in the forum. Using that, the directional dependency of the lights is set by the actual polygon, no separation plane needed. And all those litte light polygons can be combined into a single mdl.

 

[gadgets]

That's way I'm advertising to put as much stuff into one mdl as possible.

While that approach seems quite appropriate if designing lights for a particular airport, I don't see how it would apply to a program like AFLT which allows lighting configurations of the users design to be created using standard models. Also, my goal is not to design a new application but, rather, to extend an existing application to overcome limitations of P3D. I'm sure LM will come to its senses about these deficiencies and provide alternate means so, I suspect whatever I have to do, it will be temporary.

try the texture/mipmap based approach .. the directional dependency of the lights is set by the actual polygon, no separation plane needed

While that may be adequate for runway end "split" lights and other front/back applications, it wouldn't seem to be able to handle cut-offs at other than 90 degrees or angular visible ranges of less than 180 degrees. All my lights other than omnis and "splits" have adjustable horizontal and vertical visible range capability. I see no alternative to separation planes. That being said, I do plan to test the texture/mipmap approach to extend the visible range of things like PAPI's

Basically, all I'm looking for - other than local time of day - is for SODE to spawn the models and to tell me via flags what the light state should be. The visibility and animation blocks of my models - created on the fly - handle what actually gets displayed by reference to those flags. So, I have no need for many of the "frills" of SODE. That's why I've asked for an alternate, flag-based implementation of part visibility and, from my experience with separation planes a few moments ago, I'd also like the same thing there - though I may be able to overcome the cutrrent issues by adding a couple more attachpoints.

Don