P3D v4 Daytime Only Visibility Condition

[=rk=]

Can someone offer the proper syntax to make the intended condition render? I copied one of the seasonal visibility conditions and attempted to insert a time frame, between 8 am and 5 pm, based on what Arno had posted here. Below is what I's come up with so far. I removed the word "ZULU" on the basis I wanted the condition to apply to local time and not universal time. The parts appear as expected for the seasonal visibility conditions, the intention is to have the parts appear in day time only, P3D v4.4.

  <PartInfo>
    <Name>daylight_visible</Name>
    <Visibility>
      <Parameter>
        <Code>
          (E:TIME OF DAY, number) 8:00 &gt;= (E:TIME OF DAY, number) 17:00 &lt;= and if{ 1 } els{ 0 }
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>

 

[Deleted member 1281]

Mais Monsieur! That's not the way time of day operates if IRC. Try

<Code>(E:Time of Day, enum) 1 ==</Code>

 

[=rk=]

Thank you so very much for the observation. I searched through the modeldef.xml, using "time" as the term. the search uncovered a visibility condition for a clock gauge needle and I knew I'd found my code snippet.

 

[mole_man99]

Just trying to do similar. I want an object to appear at Dawn day and dusk only. I am clueless how the write the code for it. Is it even possible? Any helpers?

 

[GaryGB]

https://www.fsdeveloper.com/forum/threads/daytime-only-visibility-condition.445222/post-821233

Just trying to do similar. I want an object to appear at Dawn day and dusk only. I am clueless how the write the code for it. Is it even possible? Any helpers?

Hi Graeme:

With regard to Arno's post on this topic in his Blog:

https://www.scenerydesign.org/2017/07/prepar3d-v4-visibility-conditions-for-scenery/


IIUC, one can add additional new entries to the (basic) default RTM ModelDef.XML file, but whether they can be custom needs to be tested.

One might wonder if there is a master list of variables allowed and syntax required to implement them ...somewhere in the SDK docs ?


Apparently Time Of Day and Seasonal conditional display can be implemented within P3D (...and FSX ?) MDLs.


[EDITED]

FYI: An option for implementing P3D conditional display by Material Scripting via a Lua script is documented here:

https://www.prepar3d.com/SDKv4/sdk/...ing/modeling_materials.html#MaterialScripting


I (also) found it interesting to see that conditional display can be added to a P3D MDL via an AttachPoint:

https://www.prepar3d.com/SDKv4/sdk/modeling/3ds_max/tools/3ds_max_tools_overview.html#The Attach Tool


IIUC, when 'Attach to selected geometry' is implemented, display of Materials via an AttachPoint is incidental to their being mapped to geometry, and visibility does not individually control Materials per se, but rather by controlling whether geometry is displayed.

The SDK doc states:

"Because the actual geometry of attach points disappears, the tool will not allow a user to create an attach point out of an LOD."

However, the SDK doc 'also' states:

"If the attach point is linked to an LOD, it will only show up in the simulation when that LOD is being rendered. In order to make an attach point persistent throughout all LODs, link the attach point to the root node of the scene."

https://translate.google.com/transl...ahrometrix.de/viewtopic.php?t=102&prev=search

Google Translated from: http://forum.bahrometrix.de/viewtopic.php?t=102

Contributed by Christian » Mon 21st May 2018, 23:00

Forum: http://forum.bahrometrix.de/viewtopic.php?t=102

Post #: 2296&sid=58ae4ffb2b82ee473ee8bc1d420bab3a


In the P3DV3 and P3DV4 models can be provided directly in the 3-D software in the Attach Point Tool with a "Visibility".

To do this you modify the modeldef.xml and can then, for example, directly export an MDL file from Gmax / 3dsm.

I'm curious if the Seasonal 3D MDLs are being directly attached as Library objects, or if an attached Effect (*.Fx) calls the Library objects.

If an attached Effect (*.Fx) calls the Library objects, IIUC, one may be able to use the (many) EffectParameters for conditional display:

http://www.prepar3d.com/SDKv4/sdk/world/scenery/scenery_overview.html#AttachedObject

http://www.prepar3d.com/SDKv4/sdk/modeling/special_effects/special_effects_overview.html

http://www.prepar3d.com/SDKv4/sdk/modeling/special_effects/special_effects_overview.html#Step 1: Create an XML File for the Effect


BTW: Example *.X-file code for conditional (dis-)play-ing of a sound Effect (*.Fx) via an AttachPoint on a MDL was posted by Christian Bahr here:

https://www.fsdeveloper.com/forum/threads/sound-effects.424400/post-799906

[END_EDIT]

Whether AttachPoint Effect (*.Fx) Library Object display is less FPS efficient than methods cited above which are implemented via MCX Hierarchy Editor ...merits testing.


https://www.google.com/search?source=hp&ei=FLTEXJWDLYW0tQW4l4T4DA&q=site:www.fsdeveloper.com+rhumbaflappy+effect+season&btnK=Google+Search&oq=site:www.fsdeveloper.com+rhumbaflappy+effect+season&gs_l=psy-ab.3...1732.36062..36715...0.0..0.226.2533.31j1j1......0....2j1..gws-wiz.....0.85-dhRLqUxs

GaryGB

 

[=rk=]

I found it interesting to see that conditional display can be added to a P3D MDL via an AttachPoint:

I find it interesting that you post on this thread at all. You must do it either as an olive branch, or as a provocation, which would qualify as trolling. Surely it must be your steadfast desire to spread knowledge, despite any consequences that would entail and if this were to be the case, it's reasonable to expect the post to be somewhat knowledgeable.
FYI, translated links are extremely difficult to extract, in order to review the unedited page and it's associated links. If you actually researched those links and went straight to the source, you would see that 29Palms informs exactly how the software works, by switching file extension and there is nothing mentioned about an attach point.

"The basic concept is a program that activates and deactivates files by changing the file extension."
https://shop.29palms.de/home/17-customizable-scenery-configurator-pro.html

Going back to Christians post on the Bahrometrix page, using the exact link you provided above, we see that there are two sentences, related only by proximity.

The Scenery Configurator LITE is used only in the FSX for switching the seasonal buildings / objects. In the P3DV3 and P3DV4 models can be provided directly in the 3-D software in the Attach Point Tool with a "Visibility"

.

So, Christian is talking about the Scenery Configurator and he is also talking about the "Attach Point Tool." These are two distinct procedures, one provides conditional display of textures using the P3D v4 model material attributes, this is the technique I employed and I did not use any attach point. I used specific texture files, that the software did, or did not render, based on parameters defined in the modeldef.xml file. I manually edited the modeldef.xml to define my intended visibility condition, then I hard coded that visibility condition into the model, by compiling it through MCX.
I suggest the translational quality of the Google algorithm, may have allowed you to believe Christian was saying, "models can be provided directly into P3Dv4," while in actuality, he was saying, "in P3Dv4 models can be provided with the ability." Above and beyond all else, Christian was referring to the Scenery Configurator in relation to FSX. This thread, and the question you replied to, are specific to P3Dv4.

To be absolutely clear, the Attach Point Tool, is a 3ds Max script. It works only in that particular 3d software and it only uses legacy software that is also accessed by other software, like MCX. It performs no functions in 3ds Max, that can't be performed other ways.

The Attach tool included in this SDK is a MAXScript plug-in that allows you to attach special effects, library objects, visibility conditions, and set active mouse rectangles for use with virtual cockpits, to your 3D models. It also allows you to create landable platforms, remove crash boxes from parts of your model and attach beacons or other simulation driven objects to your models.

http://www.prepar3d.com/SDKv3/LearningCenter/modeling/using_modeling_tools.html#The Attach Tool

Since the remainder of the post goes down the rabbit hole of a non existent, 3d model-attachment/scenery enhancement tool, it seems more provocative, than informative, to me.

Just trying to do similar. I want an object to appear at Dawn day and dusk only. I am clueless how the write the code for it. Is it even possible? Any helpers?

Well, myself and others have confirmed that Arno's code works, I consider that fact to be a pretty good clue. I believe your goal is theoretically possible, but the exact terms to define the dawn and dusk values aren't readily known. If I could make a suggestion, it would be to adapt my solution to a range of time that defines, roughly, both dawn and dusk and then have two identical models, one of which appears at either interval.
If that were not exact enough, the only other course I can suggest is to search the modeldef.xml for either of those terms. I have searched very thoroughly for a published list of P3D v4 conditional material visibility variables. If you're feeling adventurous, you might try substituting the effect visibility terms into the code for material visibility. There's a table of them, just below the section of the SDK that describes the Attach Point Tool.

 

[Deleted member 1281]

Just trying to do similar. I want an object to appear at Dawn day and dusk only. I am clueless how the write the code for it. Is it even possible? Any helpers?

Maybe I am misunderstanding something in the discussion here. Why don't we just look up the SDk, take note of what it says, namely,

TIME OF DAY
General time of day:
1 = Day
2 = Dusk/Dawn
3 = Night
Enum

and then we write a vis condition, perhaps thus:

<PartInfo>
<Name>show object at dawn and dusk only</Name>   
<Visibility><Parameter><Code>
    (E:Time of Day, enum) 2 ==
</Code></Parameter></Visibility>
</PartInfo>

... and that should be all there is to it, no?

P.S. I'd be very surprised if a term like "(E:TIME OF DAY, number) 17:00 &lt;=" would count as well-formed. I may be mistaken, of course. Can find no such instance of it in my original FSX modeldef, either.
Edit, as expected, the expression "17:00" causes the FSX gauge checker to flag it as an error.

 

[=rk=]

Maybe I am misunderstanding something in the discussion here.

You are. The disconnect is not your understanding of how time works, the disconnect applies to the application of the variables that define time, into the appropriate code snippet. Arno has already provided us the correct code syntax, this has been proven to me conclusively in testing, all that must be done is to insert the proper variable terms. You may want to sit down before you read the next section, depending upon how well your physiology deals with surprise.

I'd be very surprised if a term like "(E:TIME OF DAY, number) 17:00 &lt;=" would count as well-formed.

This is actually very, very close the the actual working code. Consider, "(e:time of day, number)" fully resolves when the decimal values are removed. After all, the term defines an integer. Please, be kind enough to link your quotes. I did not find the time of day definition that you quoted above. If I were able to, I might be able to explain to you why "enum" does not represent the term "number," in this code syntax. My suspicion is that you are linking code terms for gauge syntax, which is not to say, those same terms won't work, but their source and intent would have to be quantified, in relation to conditional material visibility code. I am speculating that a technician reverse engineered the code, of which you quoted terms and then wrote his own code into the model file to mimic the original and apply the changes we intend. Since he saw no reason to call number "enum," he didn't. Again, this is only a guess. Finally, you may notice my statement about "ZULU." There are actually several ways that the time/date format can be resolved, the code must include one of those terms and I needed the one that applied to local time.

I've already discovered the exact code and terms I needed for my intended render state. I wrongfully assumed the screen shot, showing both render states and included clock, would prove I'd done so. Since I had to develop that code independently of any posts on this thread, I do not feel obliged to share the exact code segment, it's not something we hashed out together. Additionally, it is to be included in a commercial release.

Can find no such instance of it in my original FSX modeldef, either.

I searched through the modeldef.xml, using "time" as the term.

I am inclined to encourage others to make their own discoveries, I feel I've left a very clear trail of bread crumbs and I remain attentive and responsive to follow up inquiries.

 

[Deleted member 1281]

Well, admittedly I am always assuming that the FSX SDK is the holy writ, but since (I now realize) we are talking p3d 4 that may clearly be wrong. If so, apologies; indeed, there may be new and undocumented stuff . That said, the p3d 4 sdk has this for E:time of day. Actually, there is a significant change (the value for dawn). Still, no mention of hour intervals. Also, in Arno's doc I can find no reference to E:time of day.

P3D V4 SDK:
General time of day:
0 = Dawn
1 = Day
2 = Dusk
3 = Night

Link: http://www.prepar3d.com/SDKv4/sdk/references/variables/environment_variables.html

Happy to let this rest, however.

 

[=rk=]

Correct about e: time of day, in Arno's post He was using a seasonal term. However, if you use the term, "time" and search the default P3dV4 modeldef.xml, included with the SDK, you will get returns. Combining those terms, with Arno's code, derived the visibility condition depicted. Admittedly, dawn and dusk might have been more appropriate terms to define when sunglasses are to be visible, however, there is nothing about a model or SimObject that was anticipated to change state at those times, apparently, so there is no visibility condition in the modeldef.xml, using those terms. There is however, syntax defining clock visibility.

 

[mole_man99]

Maybe I am misunderstanding something in the discussion here. Why don't we just look up the SDk, take note of what it says, namely,

TIME OF DAY
General time of day:
1 = Day
2 = Dusk/Dawn
3 = Night
Enum

and then we write a vis condition, perhaps thus:

<PartInfo>
<Name>show object at dawn and dusk only</Name>  
<Visibility><Parameter><Code>
    (E:Time of Day, enum) 2 ==
</Code></Parameter></Visibility>
</PartInfo>

... and that should be all there is to it, no?

Think that is what I am after. You can't get more than one variable into a code? So I would need two objects, one that shows at day and one that shows at dawn/dusk

 

[GaryGB]

Hi Graeme:

I believe most of use here would welcome seeing further replies posted by Manfred Jahn (mjahn) in this thread; hopefully he may do so.


While we await a possible reply, I'll offer an observation based on Effect (*.Fx) placement code criteria that, IIUC, still applies to AttachPoint methods.

One might wonder if AttachPoint code for conditional visibility is to be used twice for (2) different Time Of Day variables as with EffectParam code:

https://www.fsdeveloper.com/forum/threads/effect-doenst-disappear-at-day.437992/post-751208


Some 'gotchas' when working with EffectParam variables:

https://www.fsdeveloper.com/forum/threads/effects-conditions-day-night.435870/post-731877


PS: See the edits in my post above:

https://www.fsdeveloper.com/forum/threads/daytime-only-visibility-condition.445222/post-821238

Hope this info might prove helpful in testing worked examples to sort out how *.X-file coding for conditional visibility is to be used,

GaryGB

 

[=rk=]

The thread is a specific question about P3Dv4 conditional material visibility, as described by a post by Arno and applied through the modeldef.xml. It's been answered, conclusively.

I believe most of use here would welcome seeing further replies posted by Manfred Jahn (mjahn) in this thread; hopefully he may do so.

You'd probably want to provide him more encouragement than a puerile desire to read absolutely anything he might have to write about a question that has already been solved.

 

[Deleted member 1281]

Sorry, couldn't help it ... against my better judgment I just downloaded the 4.5 SDK and ran a text search on the modeldef. I was unable to find any occurrence of "time of day" as used in your example, any occurrence of a string like "17:00", which surely is ill-formed in itself and not a "number" by any stretch of the imagination and certainly not to be accompanied by a numerical comparison operator, and nothing of the kind is supported by the current SDK documentation as quoted above, with a link.

 

[GaryGB]

Hi Manfred:

[EDITED]

I'm rather new to this aspect of working with the innards of *.X-file 3D-related XML coding, but over the years since FSX was released, IIRC, in forum threads, folks like yourself, Henk Schuitemaker, Lazarus, Jeffrey Stähli (aka "12bpilot") et al have made reference to the 'default' MdlDef.xml needing code to be added to it ...for support of certain FS features not otherwise available for ex: aircraft or scenery content.

[END_EDIT]

This has led me to infer that RTM / SP2 SDK MdlDef.xml has only a 'basic' feature set, and we may need to add code to it.

Furthermore, this implies adding such code is compatible with both XtoMDL and FSX / P3D run time rendering engines.

I'm curious if:

* Code that is added can only be certain types from a feature set provided by the SDK

...or if:

* It is possible to add to MdlDef.xml, 'custom' code not documented in the SDK ...that is actually compatible with FS ?


Thanks for any additional insights you may be able to share with us about this aspect of work with MdlDef.xml.


GaryGB

 

[=rk=]

Hmm, not sure why you downloaded the V4.5 SDK or what your troubles are with a text search in the modeldef.xml. I can't really hint much more, Manfred, without showing you exactly what I did. I already stated, quite clearly, that the code syntax I used required an integer. It was not "17:00," the actual term was the "17."

nothing of the kind is supported by the current SDK documentation as quoted above, with a link.

In this regard, I disagree with you. Arno's code example is, in my interpretation, "of the kind" and it's functionality encouraged me to attempt a very real requirement for my commercial project, I made the working push back tugs for a soon to be released addon, I'm not the developer. From that working example, I simply substituted the terms we just located together.

 

[=rk=]

Repeated attempts to correct a message that did not fully post were unsuccessful. Oddly, it looked fine in edit mode. I finally copy/pasted the edit version to get it in this post, below.




Try to make good use of these code snippets. I'd thought it was rather easy to decipher them, but I guess there was a small measure of skill involved. I have attached a copy of my modeldef.xml included with the P3D v4.4 SDK, please use this copy to verify my operations.

Please open the modeldef.xml using notepad and search the term, "time." Continue to click the "find next" button, until you come to this entry:

<Code>(E:LOCAL TIME, hour) 12 % 10 *</Code>

There is your code format, it has the regional numerator, "local," so now we know both "zulu" and "local" are options for defining time intervals. I hope you can see, as I did, that "17:00" won't work, but "17" will. The code I posted above will work perfectly if you remove both instances of ":00".

 

[Deleted member 1281]

Guys, let me clear this up with Rick first, okay?

<Code>(E:LOCAL TIME, hour) 12 % 10 *</Code> I can find in the 4.5 modeldef as well and I have no trouble with it. What I am worried about (and so, with all due respect, should you) is taking this as a master pattern for a wholly different calculation using a) a different variable, b) different units, c) different operators, d) different value ranges.

But, as instructed, I will "remove the ':00'" in your original code (that's not a "decimal value" btw) and use the expression (E:TIME OF DAY, number) 8 &gt;= (correct so far?)

Evaluating this expression in sim (FSX) and successively selecting day, dusk, night, and dawn environments, I get the followng readouts in season spring :

local time 1400; Time of Day=1; greater or equal to 8? No.
local time 2000; Time of Day=2; greater or equal to 8? No.
local time 0000; Time of Day=3; greater or equal to 8? No.
local time 0550; Time of Day=0 (! slight conflict here between SDK docs); greater or equal to 8? No.

In other words, the Time of Day value range being restricted to 0..3, any comparison with values 8 or 17 is pretty much redundant because it's never greater than 8 and alway less than 17. The Boolean result of your final 'and' operator will always come out as FALSE, which can't be what you are after.

Can we agree on this?

 

[Deleted member 1281]

@Moleman

Think that is what I am after. You can't get more than one variable into a code? So I would need two objects, one that shows at day and one that shows at dawn/dusk

You can use as many variables as you want, but yes, if your object has two types of appearance, one for day and one for night, say, then you would actually design two objects and show them based on mutually exclusive visibility conditions.

In your case the two vis conditions should work out as (slightly deviating from my earlier suggestion):

<PartInfo>
<Name>show object at dawn and dusk only</Name> 
<Visibility><Parameter><Code>
    (E:Time of Day, enum) 0 == (E:Time of Day, enum) 2 == or
</Code></Parameter></Visibility>
</PartInfo>

<PartInfo>
<Name>show object at day and night only</Name> 
<Visibility><Parameter><Code>
    (E:Time of Day, enum) 1 == (E:Time of Day, enum) 3 == or
</Code></Parameter></Visibility>
</PartInfo>

 

[Deleted member 1281]

Hi Manfred:
I'm rather new to this aspect of working with the innards of *.X-file 3D-related XML coding, but over the years since FSX was released, IIRC, in forum threads, folks like yourself, Henk Schuitemaker, Lazarus et al have made reference to MdlDef.xml needing code to be added to it ...for support of certain FS features not otherwise available for ex: aircraft.
This has led me to infer that RTM / SP2 SDK MdlDef.xml has only a 'basic' feature set, and we may need to add code to it.
Furthermore, this implies adding such code is compatible with both XtoMDL and FSX / P3D run time rendering engines.
I'm curious if:
* Code that is added can only be certain types from a feature set provided by the SDK
...or if:
* It is possible to add to MdlDef.xml, 'custom' code not documented in the SDK ...that is actually compatible with FS ?
Thanks for any additional insights you may be able to share with us about this aspect of work with MdlDef.xml.
GaryGB

Gary, quite right, each SDK supplies you with a long modeldef.xml file that lists a huge number of animation, mouse, and visibility logic code needed for designing FS models, both aircraft and scenery objects.

And yes, for your own projects you create your own code, or adapt, refine, or modify existing code. That said, the rules for adding a part or visibility condition to the modeldef file are incredibly strict - even the tiniest typo can junk your code and sometimes the whole modeldef file. In other words, you never work on it without keeping a backup.

That said, there are known errors in the SDK manual, and sometimes there are undocumented features that you can only explore by trial and error (usually error it must be said!). Indeed, that's why I am so interested in helping to clear up the current issue here.