Reading wind direction

[Guest gorchi]

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

[rhumbaflappy 113]

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

[arno 1]

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

[rhumbaflappy 113]

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

[Guest luissa]

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

[arno 1]

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

[rhumbaflappy 113]

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