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

Hi guys!Sorry I am bit to late with replies, I completely forgot about this post and I stuck in LandClass :)Anyway regarding second object as I have tested it, it is only important that it has C74 variable. Usually on my airports we have one windsock and one anemometer so these are two completely different objects but both using C74 variables and they work very nice.Rhumba, You said that at some distance (v1) object rotates, at larger distance it not. Can You please tell me, what v1 You used and what approximately distance was? I used V1=10000m and at 40m away the object (my two test boxes) stopped rotating which I found rather annoying feature...Gerrish, many thanks for Your BCD explanation!Thanks a lot guys, when I will come home I will try to find something usefull for that box.Best regards,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

Share this post


Link to post
Share on other sites

Hi Goran.I think you misunderstood my use of the v1. v1 is the far distance at which the object will first appear.I found that the IfVar condition would not re-trigger the display if the wind changed direction out of the 0-90 range, then back into this direction range.If you are in the visual distance, you can see the object swing with wind redirection 0-90, and if it exceeds 90, the object disappears... and that's OK, as that is how I coded it. But when the wind swings back to the 0-90 range, it won't reappear. This is a bug in the sim.The cure is that if the object has disappeared, then you fly ( or slew ) outside the v1 range, then change wind direction to within the 0-90 directional range, then re-enter visual range, the object re-appears as it should.===============My point then is that v1 should be as small as possible to minimize the effects of this bug. A 1 meter cube is virtually invisible at 800 meters... in fact I could have made it 400, as a cube on the ground would be very hard to see at that distance.If the 2 rotating objects are not very close to one another, they might cease interacting together as your visual distance closes on the objects and then the rotating object bug re-appears ( of needing 2 objects for rotation to work ). I don't know how close these objects really need to be, or if they all will stop funtioning as we get too close. Maybe we're blocking the wind. :-lol That's why I liked the idea of a tiny clone, as small as a grain of sand, to be very close to the original object. It's virtually invisible, and it still fulfills the need for 2 objects.This is all very annoying. And wind controlled objects are plagued with these bugs.Dick

Share this post


Link to post
Share on other sites

Hi Dick,I did some tests as well and I don't think you found a new wind bug here.I used two simple objects that had the IfVarRange command just after the Area command to let them dissapear when the wind direction was wrong. When I placed those two I noticed that after I switched the wind they did not dissapear/reappear (it happened only once and after that they didn't respond anymore). I haven't tested if going out of the v1 range fixes this, but I guess it is the same as you found.But after that I placed on extra object, a windsock in this case that rotates to the wind all the time. This object also uses C74 of course. Now the objects appear and dissapear all the time without problems. So I don't think the v1 range is a real problem (I didn't use a small range for example). It is just the same problem as before. There always needs to be another object that uses C74 visible...

Share this post


Link to post
Share on other sites

Hi Arno.You're right. That's a very good find.I'm attaching some code that places a cube that rotates with the wind, and will disappear if the wind is between 91-359 degrees... and will reappear if the wind is between 0-90.It has 2 Area structures. The second is a clone of the first, scaled very tiny and placed very near the first object... but this sand-like cube never disappears and always rotates with the wind direction... and cures the problems I had with the large cube not reappearing when the wind switches back into the direction range.So one of the objects must aways be visible and rotating with the wind direction, then the other may be altered by the IfVar() condition.Dick

Share this post


Link to post
Share on other sites

Dear Scenery Designers,It is curious that I see this post here giving the fact that I has been working independently on a similar problem. I did not visit the forum during the last week as I have been extremely busy in finallizing the Madeira Islands scenery (the work of Jose and I during this last year or so).In Madeira there is a Lead-In-Light approaching system to runway 05 consisting on a sequence of 17 neon flashes in a curve along the shore. Given the fact that the runway has an heading of 45 degrees, we wanted this lighting system to work only with winds coming from 315 clockwise up to 135 degrees.These angular values (when local winds = global winds) correspond to C74 contents as follows:315 degrees = 0xD975135 degrees = 0x5975We are quite sure as we used a SCASM macro that places the contents of any variable on the screen. Therefore we used the following line to skip the elaborated approaching system just after the Area():IfVarRange( :return C74 0xD975 0x5975 )Note that D975 in 16 bit integer representation is a negative number (corresponding to - 45 ) and 5975 is a positive one. So 0xD975 is smaller than 0x5975 and the range checking has sense! I only thought about this, 2 days ago and I was completely convinced that there was a bug in IfVarRange() but I never claimed it. Even now, the working of the so commom test like:Area( ... )IfVarRange( : 346 %12 5 ) ;check complexitysurprises me. For example if I change it to:Area( ... )IfVarRange( :yes 346 0 %12 ) ;check complexityJump( : ):yesit has a strange behaviour.Anyway, there is another problem with the "wind" variables. The problem is, as it has been referred here in the past, that there should be at least 2 accesses to the wind variables (in different Areas) for them to respond as expected. In our Madeira scenery we had windsocks, moving wind generators, flags, etc, but if we were looking to the Lead-In-Light system at certain angles it would not respond to the wind. We should look into a direction where one of these "other wind objects" were in sight.So we forced an access to the wind variables independently of the viewing direction with an Indirect Refpoint using the special macro flagsini.api . Here is the final code for our wind dependent LEAD-IN-LIGHT system:;macro( ../macros/showvar.scm 0 0 C74 0 0 )macro( ../macros/flagsini.api )Area( 5 r 224.7 [1241 + 2034] 25 )PerspectiveCall( :pcall )RotatedCall( :return 0 0 0 ) ; to avoid autogen exclusionJump( : ):pcallRefPoint( 2 :return 1 d 0 0 E= 0 v1= 20000 V2= 1800)SetScaleX( :return 0 0 13 )IfVarRange( :return C74 0xD975 0x5975 )The flagsini.api is:Area( 5 d 0 0 255 )dwx( 3a 1e 0 0 0 1BA0 )SetScale( : 0 0 1 )IfVarAnd( : C76 0000 )EndAKind Regards, Luishttp://www.ptsim.com/en/madeira/madeira.htm

Share this post


Link to post
Share on other sites

Hi Luis,Good to see that you have reached about the same conclusions. I think you flagsini macro is interesting, but might indeed be better then placing dummy objects, because I have also found that at least two of such objects must be visible on the screen (thus not only there in the scenery) before it works correct.I will give it a try in my scenery as well...

Share this post


Link to post
Share on other sites

Hi all.Indeed, the wind variable seems treated as a 16 bit signed integer.That creates some problems. What if you want an object to display from 90* to 270*. Scasm can't handle that because you are now going from a positive to a negative value. The solution would be to split the range checking at 180*...Area( B N42:37:42.00 W088:35:58.80 22 ); IfVarRange( : 0346 2 5 ) IfVarRange( :_TestNegative 0C74 [ [ 90 / 360 ] * 65536 ] [ [ 179.9999 / 360 ] * 65536 ] ) PerspectiveCall( :_PlaceObject ) ShadowCall( :_PlaceObject ) Jump( : );:_TestNegative IfVarRange( : 0C74 [ [ 180 / 360 ] * 65536 ] [ [ 270 / 360 ] * 65536 ] ) PerspectiveCall( :_PlaceObject ) ShadowCall( :_PlaceObject ) Jump( : );;:_PlaceObject... and so on....The fail of the first wind check takes you to the negative values check. Works good for me.========================================In addition to Luis' solution for a second object, you could create a tiny rotating ground poly, which could sit under the main rotating object. I'm attaching some code that will display a wind rotating cube in the range from 90* to 270*, and has this tiny ground poly for the second object.Dick

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