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

Multiple conditions

Messages
374
Country
italy
Hi guys,
calvert at least! I've been able to model my 3d approach lighting system and I used the svisibility module to tweak my light in order to let them appear in low visibility conditions. I've also tweaked the asm in order to get the ligths on during night, dusk and dawn. This is the code:

Code:
IFMSK CHECK_TOD1, 031Ah, 01h
	JUMP ShowLightsFila1
	CHECK_TOD1:
	IFIN1 NoLightFila1, tod, 2, 4
	ShowLightsFila1:
	SEPARATION_PLANE PrimaFila, 0, 0, 32768, -29049225
		IFIN1 PrimaFilaLight1, 033bh, 0, 1000  ; 0-1 km
			BGL_LIGHT LIGHT_NAV, -0.010, 3.488, 893.659, 20, 0.60, 0.40, 0FFFFFFFFh, 0.000000, 0.000000, 1.000000 ; source poly num = 10
		  BGL_JUMP_32 PrimaFila
		PrimaFilaLight1 label BGLCODE
		IFIN1 PrimaFilaLight2, 033bh, 1000, 3000  ; 1-3 km	
			BGL_LIGHT LIGHT_NAV, -0.010, 3.488, 893.659, 20, 0.60, 0.40, 0FF999999h, 0.000000, 0.000000, 1.000000 ; source poly num = 10
		  BGL_JUMP_32 PrimaFila
		PrimaFilaLight2 label BGLCODE	
			BGL_LIGHT LIGHT_NAV, -0.010, 3.488, 893.659, 20, 0.60, 0.40, 0FF555555h, 0.000000, 0.000000, 1.000000 ; source poly num = 10
	PrimaFila label word	
NoLightFila1: ;label word

The problem is that the condition which write on USRVR5 doesn't work during day, I mean is turn on the lights only at night/dusk.
What I would get is turn on the lightswith the following conditions:

Dawn, dusk, night AND when the visibility is low (means use the IFMSK CHECK_TOD1, 031Ah, 01h condition).
What's wrong with my code?
 
Hi,

Your code looks fine to me, as far as I can see it should already do both.
 
It used to be... also for me the code is fine but for some reason sometimes doesn't work, btw I will keep testing. Concerning the separation plane calculed, in my case the RWY is aligned with Y axis. If I would put a light visible only from the opposite side (hdg 14) have I to take the vector component as minus?

Code:
	SEPARATION_PLANE PrimaFila, 0, 0, 32768, -3276800
		BGL_LIGHT LIGHT_NAV, 0.000, 3.488, 0.000, 20, 0.60, 0.40, 0FFD4CE86h, 0.000000, 0.000000, 1.000000 ; source poly num = 1
	PrimaFila label word
 
Hello,

I have not experimented with visibility tweaks yet (AFAIK the method mentioned only works with FS9? I am even considering learning C and writing my own module for FSX, hehe... of course, knowing C would be beneficial also elsewhere, not just for my scenery)

Anyways at a very brief look, your code looks good to me as well. Have you tried isolating it into two separate conditions instead of embedding two into one.

i.e.

IF visibility THEN light
IF tod THEN light

instead of

IF visibility THEN jump to light ELSE IF tod THEN jump to light

I hope you understand what I mean.


Regarding separation planes:

if you want to make separation plane active from another site, you have to turn the whole vector around, with first three parameters, the last parameters denotes that you have to be further-than-this-from-refpoint in direction of vector. I can explain this in person and with help of a blackboard well, not too good with words. I will try picture, in 2D setting ISO 3D setting.

The VectorPoint denotes where the Separation Plane vector ends. This instance, it is at (-20525, -25545) coordinates.
The vector length (size) is always 32768 (either by convention, or because of programming constraints. I am not sure.)

The last parameter denotes distance of actual separation plane from the reference point. Here, you can see three options:

-If negative, separation plane will move away from refpoint in direction opposite to defining vector. Any distance along vector "higher" than negative value will then fit the condition, as denoted in green area, also red and blue.

-If zero, the plane will be positioned directly in the refpoint. Anything in red or blue areas will trigger the condition.

-If positive, the plane will be positioned outward along the vector to the distance defined. Anything in the blue area will trigger condition.


I am told that distance compared corresponds by 32768 units = 1m.
In this picture, NegativeValue is -11 312, PositiveValue is 15 815.
 

Attachments

  • separation plane.jpg
    separation plane.jpg
    172.7 KB · Views: 518
Thank you for the answers guys, I fixed my asm code and the lights appears correctly.
 
So if I understand correctly you did a module which writes the usrv5 the visibility and in you asm you make the condition according to this? Very interesting.

Regarding the separation plane. It's indeed complicated.
In our current project (Budapest) there is two runways. Basically for every lightsource we need to create separation planes, which is a tedious job. I did some excel macro to make our live easier. The result is that making a full scale approach light takes less than 2 minutes.
The method:

We place all bgl lights in gmax. The scene Y axis is oriented in runway heading. The lights are exported with asm keep option. The asm is opened the bgl light section is copied to the excel. I run the macro. The macro extracts from all BGL light the Y position. It sorts the lights (every row is one light source) in ascending. Than the macro ask for the heading of the runway and from which side should it be visible. The macro starts to create the separation planes. It makes groups +1/-1 meter Y distance from each other are grouped into one separation plane, and of course the vector value is used (multiplied by 32738). The label of the code is continous, at the beginning the macro ask from which label number it shall start the labeling. The code gets assembled in 1 second. It can be copied and pasted to the asm file.
With this method the approach lights rows are illuminated only when you are front of the respective row. Exactly the same way as the default runway.
 
Hi Tsgucci,
I didn't write a module, I've just use the one posted by Piopawlu some years ago. It's a simply DLL that need to be placed in "fs2004\modules\" folder and with ad .ini file you can configure it's behavior.
 
So if I understand correctly you did a module which writes the usrv5 the visibility and in you asm you make the condition according to this? Very interesting.

piopawlu (IIRC) wrote the module for FS9. As you may know, usrv5 is not accessible in FSX anymore, but I believe I will have a SimConnect solution ready within days. The info is available to SimConnect client.
Of course, when I finish it, I will be happy to let you use it, after all, you guys are the inspiration with your free sceneries.

Regarding the separation plane. It's indeed complicated.
In our current project (Budapest) there is two runways. Basically for every lightsource we need to create separation planes, which is a tedious job. I did some excel macro to make our live easier. The result is that making a full scale approach light takes less than 2 minutes.
The method:

We place all bgl lights in gmax. The scene Y axis is oriented in runway heading. The lights are exported with asm keep option. The asm is opened the bgl light section is copied to the excel. I run the macro. The macro extracts from all BGL light the Y position. It sorts the lights (every row is one light source) in ascending. Than the macro ask for the heading of the runway and from which side should it be visible. The macro starts to create the separation planes. It makes groups +1/-1 meter Y distance from each other are grouped into one separation plane, and of course the vector value is used (multiplied by 32738). The label of the code is continous, at the beginning the macro ask from which label number it shall start the labeling. The code gets assembled in 1 second. It can be copied and pasted to the asm file.
With this method the approach lights rows are illuminated only when you are front of the respective row. Exactly the same way as the default runway.

Elegant. Reminds me of this graphic
 

Attachments

  • timespent.jpg
    timespent.jpg
    58.8 KB · Views: 607
Yes I'm also waiting a lot for the simconnect solution. I hope you or Arno can provide it with source code. So later it can be used for almost everything.


The picture rocks! It is exactly like this. If you are interested in the excel macro, let me know, I can share it.
 
Not yet, but thank you. Later we can share our efforts :)

I don't know what Arno is doing for now, but definitely I will be happy to provide module, source and instructions.
I can also give you right now a solution to place an object (without visibility condition), I do not know whether the colleague who offered to you to write the copyprotection has reached an agreement with you yet. I suppose it should be possible to reach a registry from within the module with RegQueryValue or something similar.
edit: that will obviously not work in FS9 though.
 
Last edited:
Thank you.

Unfortunately they could not help me. They can do the frame of the program but they are also unaware of the simconnect thing.
 
Thank you.

Unfortunately they could not help me. They can do the frame of the program but they are also unaware of the simconnect thing.

I will see what can be done.
Unfortunately you will have to find a different way to protect your FS9 version (and Xplane if you decide to do that)
 
Hi,

I am also testing with SimConnect. Got placement of objects working as a test, next step is to try to trigger animations. Once I got that figured out, I plan to turn this test application into a general framework.

Instead of each scenery using their own module or application, I think it would be better to have one general framework that each developer can configure for his project with some configuration file. That configuration should tell where objects should be placed, what checks to (e.g. license check) and other special conditions for display.

Back to me testing :)
 
I can't do it all yet, but thats my vision :)

Send from my phone using Tapatalk, so excuse the short sentences and possible typos
 
I can already read and write files with my module, so that is good and should not make a problem.

I like modularity of C programming I make a .cpp file to get a visibility from sent metar and it behaves just like that :) I guess that is good for collaboration, so for starters, don't bother with parsing METAR for visibility, I can send you .cpp file. Although you are much more experienced programmer, so it might actually make more harm than good. :)

(well if I can even get my decoder to run, that is)
 
Hi Arno,

Could you please be so kind and share with us the scenery object placement example? The source I mean. I would like to do also some tests.

Thank you!
 
Hi,

It's just the example from the sdk. I used the c# sample. All I changed is call my own test object instead of the dc-3.

Send from my phone using Tapatalk, so excuse the short sentences and possible typos
 
Hmm... I could not find such an example. Can you tell me where it is? I'm blind :) Maybe a screenshot? Thanks
 
Back
Top