Sign in to follow this  
rhumbaflappy

Reading wind direction

Recommended Posts

Hi,we talked a lot of wind variables but I have one odd problem. I know wind direction variable is c74 but I only used it in TransformCall() intruction. Now I need to read this variable in IfVarRange() instruction but whatever limits I put, it is not what I need. So let's say, I need to show an object when wind is blowing from hdg 000-090, what this instruction should look like? IfVarRange( :Skip c74 0 90 ) doesn't work, I tried also IfVarRange( :Skip c74 0x00 0xff ) but nothing again. Any ideas?Many thanks and best regards,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

I would expect it to be degrees indeed, but I never tried it with an IfVarRange. Can it be, that just like the TransformCall, that you need to place the object twice before it works?

Share this post


Link to post
Share on other sites

Hi Arno!I assume so; I placed two objects there but still no success. I am now wondering why in TransformCall() the object rotates as wind directon changes but if I properly substitute TransformCall() with IfVarRange() the object does not show. So it seems that ranges there are something not known. This reminds me also on entering ADF value, where for 388kHz, I had to put IfVarRange( :xy 7bc 0904 0904 ). And I do not se the connection between 904 and 388.Thanks for help. Best regards,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

Share this post


Link to post
Share on other sites

That 904 doesn't surprise me at all. 388h is 904 in decimal form, so that makes sense. I don't know if for the wind direction the same holds, but you can try to put the h for hexadecimal behind it....

Share this post


Link to post
Share on other sites

Hi guysThe behaviour of the NDB variable is because NDB frequencies are coded internally as a BCD (Binary Coded Decimal) value. So, when used with IfVarRange, which expects normal decimal values for the min and max arguments unless type casting is used, the easiest way to write an NDB frequency of, say, 324 is as 0x324 - which will perform the necessary conversion.Other FS variables also have other unusual internal values: for example VOR/ILS frequencies are coded as channel numbers in the range 0-199 (the channels are at .05 mHz intervals, from 108.00 mHz to 117.95 mHz).The wind direction variable is probably stored in 'pseudodegrees', which is the normal way of handling angles internally in FS2. These are unsigned 8/16/32/48-bit integers (different integer sizes are used in different situations) with the full range of the variable representing 0-360 degrees, and thus an 'overflow' value simply wraps correctly in angular terms. As C74 appears to be a 16-bit variable, which would make its range is 0x0000 (0 degrees) to 0xFFFF (just under 360 degrees - 360 degrees would actually be 0x10000, but wraps back to 0x0000). To check for 0-90 degrees you probably need to write IfVarRange( C74 0x0000 0x4000 ) - but I haven't tried this for myself, so good luck!CheersGerrish

Share this post


Link to post
Share on other sites

Hi Goran and all...I know you're all more-skilled at code writing (than myself), but sometimes (speaking for myself :-)) the simple things escape me because I'm concentrating on the math or technique instead of the simple 'program flow', i.e. it's easy to overlook placing a necessary call in the code stream just before drawing/painting the object which you want to be responsive to the 'IfVar' wind direction change? Even a Dummy RotatedCall (Oops, there that word again) often works.J.R.

Share this post


Link to post
Share on other sites

Hi all.As usual, things can get complicated.Area( B N42:37:42.00 W088:35:58.80 22 ); IfVarRange( : 0C74 0 16384 ) PerspectiveCall( :_PlaceObject ) ShadowCall( :_PlaceObject ) Jump( : );;:_PlaceObject; RefPoint( rel :_PlaceObjectFail 0.25 N42:37:42.00 W088:35:58.80 V1= 800 V2= 2 ) TransformCall( :_DrawObject 0 0 0 0 0000 0 0000 0 0C74 ); RefPoint( rel :_PlaceObjectFail 0.001953125 N42:37:42.20 W088:35:59.00 V1= 800 V2= 1 ) TransformCall( :_DrawObject 0 0 0 0 0000 0 0000 0 0C74 ); RotatedCall( :_PlaceObjectFail 0 0 0 ) ; dummycall;;:_PlaceObjectFail Return; ....... etc ..........This will display the object if the wind is between 0 and 90 degrees. When you leave the range of 0-90 it stops displaying... ...but re-enter the range ( 0-90 ), and it won't redisplay. Wind direction is between 0-65535 ( 16 bit ). I don't know why the object won't redisplay when re-entering the range. Other than that, it works fine.Edited======I found if I exit the v1 range of the object, change the wind back to within the direction range, then re-enter the visual range, the object will redisplay correctly.So the only problem would be if the wind direction were to change while you are within the visual range ( v1 ). If you keep the v1 reasonably small, there shouldn't be a problem. My above example creates a cube about 1x1 meter. The second object is a repeat of the first, slightly offset and tiny, to satisfy the #2 object Arno discovered we need. I added a dummycall ( not even sure if it is needed ). I set v1 to 800... but I'm not sure if the scale factor affects v1 ( I don't think it does ).So... this should be workable.Dick

Share this post


Link to post
Share on other sites

Hi guysWhy on earth this stuff with multiple RefPoint's and TransformCall's and a 'dummy' RotatedCall into the bargain - have I missed something here, won't a simple 'normal' structure work? (Or did the original object have a problem with Autogen exclusion - that problem doesn't usually occur with normal 3D objects, only with certain features like runways, taxiways, old-style roads etc. where MS have coded the Autogen exclusion algorithm incorrectly).The key to getting the object to appear and disappear correctly in response to the wind direction may be to move the IfVarRange check inside the :_PlaceObject subroutine so that it becomes part of the object placed onto the display stack and gets re-evaluated more frequently. With IfVarRange where it is in Dick's suggested code, I think it may only get evaluated when the whole Area block goes in and out of range - hence the strange behaviour you are reporting Dick.So now the code will be something like

Area( B N42:37:42.00 W088:35:58.80 22 );PerspectiveCall( :_PlaceObject )ShadowCall( :_PlaceObject )Jump( : ):_PlaceObjectIfVarRange( :_PlaceObjectFail 0C74 0 0x4000 )RefPoint( rel :_PlaceObjectFail 0.25 N42:37:42.00 W088:35:58.80 V1= 800 V2= 2 )TransformCall( :_DrawObject 0 0 0 0 0000 0 0000 0 0C74 ):_PlaceObjectFailReturn:_DrawObject; ....... etc ..........ReturnEndA

CheersGerrish

Share this post


Link to post
Share on other sites

Why on earth this stuff with multiple RefPoint's and TransformCall's and a 'dummy' RotatedCall into the bargain - have I missed something here, won't a simple 'normal' structure work?That's just what I thought, I haven't tested it, but this seems much to complicated for me and it makes no sense I think...I haven't had the time yet to do some tests, but I will try to do some. This is getting interesting :).

Share this post


Link to post
Share on other sites

Hi Goran and Arno.The code simply means we can place the "IfVarRange( : 0C74 0 16384 )" right after the Area declaration. If the wind direction isn't in the range, then the code exits the Area structure ( : ) and nothing is drawn.The other code is simply the drawing of 2 objects that rotate with the wind... one displayed as normal and the other scaled to a tiny size ( same object, but invisible to the naked eye ). That 2nd object fulfills the need for 2 objects in the same general location for wind-rotating objects, in order for them to display correctly... No need to hide the second object... just make it very small.The Dummycall is probably not needed... but leftover code from another experiment. :(So what I've done is declare the Area structure, set the condition for a wind direction range between 0-90, then call the drawing routines for a wind-rotated object. Then the object rotates, but only displayed if between 0-90 degrees.More code could be added to display the object as stationary if between 91-359 degrees, if that's what is desired.Dick

Share this post


Link to post
Share on other sites

Humm, explained that way it makes sense again :D.I remember that I tried that two RefPoint solution once for a windsock, but then it didn't work correct. Would be interesting to try it again.

Share this post


Link to post
Share on other sites

Hi Arno.RefPoint( rel :_PlaceObjectFail 0.001953125 N42:37:42.20 W088:35:59.00 V1= 800 V2= 1 )TransformCall( :_DrawObject 0 0 0 0 0000 0 0000 0 0C74 )Note the scale of the second object ( 0.001953125 )! I wish I could remember why I chose that scale. :( The .25 scale of the object ( a cube ) was about 1 meter... so the tiny cube must be about 0.5 millimeters! A grain of small sand. But it satisfies the need for a 2nd object. Dick

Share this post


Link to post
Share on other sites

If I remember correctly, you were hiding it somewhere for the reason you selected the scale.

Share this post


Link to post
Share on other sites

:)Yes I chose a tiny scale so I would hide it visually... right out in the open! But I can't remember why I chose that exact scale number. It shouldn't make much difference, as long as it is too small to see.Also, I don't believe the 2nd object needs to be a copy of the first, but could be a much simpler object to prevent any FPS loss.=============I just searched the forum for "0.001953125", and came up with:http://forums.avsim.com/dcboard.php?az=sho...ing_type=searchFrom that post, I realized I was using a scale of 002000000h ( hex ) in BGLC code.. so it was just a convienient tiny-scaled number.Dick

Share this post


Link to post
Share on other sites

Humm, about the second object. I think it must be a copy of the first one. For the windsock for example it was necesairy that both of them used the variable for the wind direction. In your example that variable is not in the actual object code, so maybe this double object thing is not needed at all then.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this