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

Wind Speed and Heading

Well Dick. Thanks!

You put me right on track there. It was the clue about the no animation code in your earlier post :)

Tick18 just has to be there, not even used for it not work work.

After all that, I have decided that the scenery installed will give the choice to the user of animated static flags or non animated wind affected flags :)
 
Hi Nick.

You should also be able to code the ASM by just reading the 0c74h variable, and directing the code to a different model...

If you were to make 8 different MDLs, orientated to 45*, 90*, 135*, 180*,....
combine the code and link using a group of IFIN1 conditions to point to the right model for the wind range?

A bit complicated, but that might allow animation for each different model.

Haven't tried it, but it might work.

Dick
 
rhumbaflappy said:
You should also be able to code the ASM by just reading the 0c74h variable, and directing the code to a different model...

If you were to make 8 different MDLs, orientated to 45*, 90*, 135*, 180*,....
combine the code and link using a group of IFIN1 conditions to point to the right model for the wind range?

A bit complicated, but that might allow animation for each different model.

Haven't tried it, but it might work.

From the discussions I had with Nick about this problem a long time ago, I thought this what exacatly what he was trying to do anyway. Using MDLTweaker to restrict each model to a certain wind heading and speed and then combine all the different objects.
 
Yes, but that did not appear to work originally.

I am going to look at that later this week.
 
Hi Nick.

Part of the problems with this idea is that the different RIFF code areas don't seem to use conditional branching.

It might prove better to use different BGLs for each wind range.

Dick
 
Hi Dick,

rhumbaflappy said:
Part of the problems with this idea is that the different RIFF code areas don't seem to use conditional branching.

It might prove better to use different BGLs for each wind range.

That was indeed sort of what Nick and I worked out when we discussed this some time ago. Especially because Nick does not really like playing with the ASM code :D, we planned to use MDLTweaker and make a collection of MDL files, each showing the windsock for a certain wind heading and wind speed combination.

The only trick would then be how to place them all in an easy way (you don't want to place dozens of MDL files again and again). Maybe attaching them one into one object (using the GMax script for example) is a good solution for that. But this is something we hadn't looked into yet.
 
Placing them is not a problem. It is easy to create a XML file to do this. This is in fact what I had done.

I am going to try a simple N E S W Animation and see if it now works if there is a hidden object in the way that Dick gave an example. I can see no reason why this would not work.

btw... for your reference, the windspeed variable is indeed in kts.

Cheers,
 
One more thing.

The heading however, is not stored 0 - 360. It is stored 0 - 65535

I have compiled the list as you can see on the other section for this.
 
Hi Arno & Nick.

I think with XML, it's pretty easy to use "cut and paste" and the Replace function of NotePad to place dozens of objects at the same location. And with Gmax, you should be able to make different MDLs fairly quickly by rotating them within that program... just an idea.

Dick
 
Hi guys,
sorry for reopening the thema again but using BiasXYZ as proposed by Dick doesn't seem to work at my computer. I get this kind of Error:
Parsing document: oblak1.XML

ERROR C2033: XML Parse Error (line, column, error)

ERROR: 7, 44, Element content is invalid according to the DTD/Schema.
Expecting: LibraryObject, Effect, Trigger, Windsock, AttachedObject, GenericBuilding.

ERROR: Schema errors detected, compilation failed!

Parse complete!
I guess this is something with XSD file (mine is from 18.11.2003) so where can I find the newest one?
 
Hi Goran,

Mine is from 20.01.2004, so I guess you can best redownload the BGLComp SDK from MS.
 
Okay Arno, thanks! That was definitely the source of XML compile problem :)
Now for the wind direction variable problem. I want to create a cloud that would be visible only when wind blows from certain direction. I have created gmax poly, tested it and it works okay. The tricky part is the code, which should be wind direction sensitive. So the code is:
Code:
oblak1_top label BGLCODE
texture_riff_start_oblak1	label	word
    db  'T','E','X','T'   
    dd  texture_riff_end_oblak1 - $ - 4  
    TEXTURE_LIST_BEGIN
    TEXTURE_DEF TEXTURE_BUILDING    , <255,255,255,252>, 1225.970871, "CLOUDA.BMP"	; 0
    TEXTURE_LIST_END
    BGL_RETURN
texture_riff_end_oblak1 label word       


material_riff_start_oblak1	label	word
    db  'M','A','T','E'   
    dd  material_riff_end_oblak1 - $ - 4  
    MATERIAL_LIST_BEGIN
    MATERIAL_DEF 1.000000,1.000000,1.000000,0.988235,  0.392157,0.392157,0.392157,  0.000000,0.000000,0.000000,  0.000000,0.000000,0.000000,  0.000000 ; 0
    MATERIAL_LIST_END
    BGL_RETURN
material_riff_end_oblak1 label word       


vertex_riff_start_oblak1	label	word
    db  'V','E','R','T'   
    dd  vertex_riff_end_oblak1 - $ - 4  
    VERTEX_LIST_BEGIN
    VERTEX_DEF  -500.000031,-1500.000122,    0.000000,   0.000000, 0.000000,-1.000000,   0.000500,0.000500 ;   0 part=  1 prim=2000
    VERTEX_DEF  -500.000031, 1500.000122,    0.000000,   0.000000, 0.000000,-1.000000,   0.000500,0.999500 ;   1 part=  1 prim=2000
    VERTEX_DEF   500.000031,-1500.000122,    0.000000,   0.000000, 0.000000,-1.000000,   0.999500,0.000500 ;   2 part=  1 prim=2000
    VERTEX_DEF   500.000031, 1500.000122,    0.000000,   0.000000, 0.000000,-1.000000,   0.999500,0.999500 ;   3 part=  1 prim=2000
    VERTEX_LIST_END
    BGL_RETURN
vertex_riff_end_oblak1 label word       


bgl_riff_start_oblak1	label	BGLCODE
    db	'B','G','L',' '
    dd	bgl_riff_end_oblak1 - $ - 4
LOD_0_oblak1	label	BGLCODE

; Alpha
oblak1_Alpha label BGLCODE
	 IFIN1 WindExit, 0c74h, 00001d, 32767d ;rotate with the wind...  
	 	BGL_CALL_32 oblak1_MasterScale_1a
	 	
WindExit label BGLCODE
    BGL_END
    BGL_RETURN

oblak1_MasterScale_1a label BGLCODE
    SPRITE_VICALL oblak1_MasterScale_1, 0, 0, 0, 0, 0, 0, 0, 1, 0
    BGL_RETURN


oblak1_MasterScale_1 label BGLCODE
    MATERIAL 0,0 ; <255,255,255,252> CLOUDA.BMP;;;
    DRAW_TRI_BEGIN 0, 4
    DRAW_TRI    1,   3,   0 ; poly=1 part=1 (double sided)
    DRAW_TRI    1,   0,   3 ; poly=1 part=1
    DRAW_TRI    2,   0,   3 ; poly=2 part=1 (double sided)
    DRAW_TRI    2,   3,   0 ; poly=2 part=1
    DRAW_TRI_END
    BGL_RETURN


bgl_riff_end_oblak1	label	BGLCODE

I am now testing and restaring FS for about 2 hours without success. If the limits in the condition
Code:
IFIN1 WindExit, 0c74h, 00001d, 32767d
are from 0000d to 32767d, the cloud appears. If I change the second condition from 0001d to 32767d, the cloud is there, no mather wind direction is. If the upper limit is raised above 32767d, there is no cloud! Same if I raise the lower limit from 0000d to 0001d. I also tried hex values, from 0000h to FFFFh, its' just the same :confused: Now I am starting to ask myself if this variable has some special values... Does anybody has any experience with the use as above? I have only experience in TransformCall() from SCASM, where it works with known limitations...
Oh and yes, I created two objects, one tiny and one normal in the same BGL:

Code:
<?xml version="1.0" encoding="ISO-8859-1"?>
<FSData version="9.0" xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:noNamespaceSchemaLocation="bglcomp.xsd">

	<SceneryObject lat="46 37.69" lon="016 10.70" alt="0" pitch="0" bank="0" heading="0" altitudeIsAgl="FALSE" imageComplexity="SPARSE">
		<BiasXYZ biasX="1" biasY="-1" biasZ="1" />
		<LibraryObject name="559D75DD4481E070F104CB8D08537DB9" scale="0.0001" />
	</SceneryObject>

	<SceneryObject lat="46 37.69" lon="016 10.70" alt="1500" pitch="0" bank="0" heading="0" altitudeIsAgl="FALSE" imageComplexity="SPARSE">
		<LibraryObject name="559D75DD4481E070F104CB8D08537DB9" scale="1.0" />
	</SceneryObject>
	<ModelData name="559D75DD4481E070F104CB8D08537DB9" sourceFile="oblak1.mdl" />
</FSData>

Thanks in advance!
Best regards,
 
Last edited:
Hi Goran,

I have read some time ago a post in the avsim scenery forum about the use of the wind direction variable for the SCASM IfVarRange.
Someone found out, that if your sector contains the 180° mark, you have to split up the checks to work correctly...(example, I did a landing direction T, which checks for winds from 135° to 215°, so in between there is that 180° value...)
So I translated that into BGLC code and it works perfectly in FS!

Here a quick tutorial:

specify the bounds of your check-sector
in my example, it was 135°-215° (semi-circle)
now, transform the degree value into the 16bit-integer range:
(angle in degrees * 65535 ) / 360

135° -> 24576
180° -> 32767 (it's a good approximation..I use 32768 for values >180°)
315° -> 57344

do some coding...
Code:
   .
   .
   .
;###### CHECK WIND DIR: if wind is within bounds, draw the T, else do nothing #####
;###### 135 - 179 degrees ######
IFIN1 chk_next180, global_winds_surface_direction, [COLOR=Red]24576[/COLOR], 32767
BGL_CALL_32 drawT            ; draw the object
BGL_JUMP_32 doNothing       ; go to the end...
;###### 180 - 315 degrees ######
chk_next180 label BGLCODE
IFIN1 doNothing, global_winds_surface_direction, 32768, [COLOR=Orange]57344[/COLOR]
BGL_CALL_32 drawT

doNothing label BGLCODE
    BGL_END
    BGL_RETURN

;###### draw the landing T #######
drawT label BGLCODE
    MATERIAL 0,0 ; <255,255,255,255> LSZT_MISC2.BMP;;;
    DRAW_TRI_BEGIN 0, 56
    DRAW_TRI   27,  30,  28 ; poly=1 part=1
    DRAW_TRI   27,  29,  30 ; poly=2 part=1
    DRAW_TRI   29,  26,  30 ; poly=3 part=1
     .
     .
     .

I had to change the checks a bit, cause I had some more checks in my landing T code, but the above is the basic wind check code.
I hope that works, I haven#t tested it, but it should do the job :scratchch

Jeff

EDIT: Oh yeah, I believe you heard this several times already, but I always go nuts about this one: you have to place at least 2 objects that read wind variables.
 
Last edited:
Hi Jeffrey!
Many thanks, it works now more or less as it should. Definitelly is the main trick heading division where one must take care to enter proper high value for the first part and lower value for the second part.
I said it works more or less as it should; yes I still have a problem. This little cloud is blinking like crazy... Any ideas why guys? I am attaching both asm files + bitmap + xml file if anybody would care to take a look...

Best regards,
 

Attachments

Back
Top