Wind direction...

[Nemesis6]

Well, I found this script thing below:

_pos = [0,0,0]
windpos = [0,0]

drop ["cl_basic", "", "Billboard", 1,1, _pos, [0,0,0],1, 1, 1, 1, [3], [[0,0,0,0]], [0,0,0],0, 0.00, "", "windspeed.sqs", ""]
~1.1
_dx = (windpos select 0)
_dy = (windpos select 1)

_angle = atan (_dx /_dy)
_dist = sqrt(_dx^2 + _dy^2)

player sidechat format ["dx: %1 , dy: %2 ,Angle: %3, Windspeed (m/s): %4",_dx,_dy,_angle,_dist

I don't really need this for anything, just curious... Anyway, does anyone know how to possibly "fix" the above script, or come up with a better way to determine wind speed?

[RujiK]

Where did you get this script? It would be easier to view the whole script instead of just a portion.

The colors are all set to 0 so you wouldnt be able to see anything, meaning this script would be totally pointless. I dont think this script is even worth messing with.

The rest of it looks like the guy didnt even bother testing his numbers, just made them all random.

[General Barron]

Hmm... what is wrong with the above script? I just want to know what you think needs to be "fixed".

What the script is doing is dropping a particle, which is then blown by the wind. The script then compares the particle's starting position to its ending position to determine what direction the wind blew it, and at what speed.

You could then take this windspeed value and do something else with it in other scripts, like messing with the velocities of aircraft or bullets. But this script doesn't do any of that; it just finds the windspeed (with the above errors).

The only thing that I can think of off the top of my head is that the delay should be 1 second, not 1.1. Also, I'm not entirely sure if this particle would EXACTLY match the speed of the wind, which the script is assuming. I would have to play around with some volume and mass combinations before I could make that call.

[macguba]

AFAIK creating an drop particle - invisible or otherwise - and checking how it gets on is the only way of determining wind velocity.

Nobody writes a delay of 1.1 instead of 1 by accident.   I suggest that this is the result of experiment.

[Raptorsaurus]

Also, if the parameters that dictate how a particle reacts to wind are set correctly (weight, volume & rubbing). You can make the particle move exactly with the wind (direction and speed).  I made a simillar script, but I used a parachute placed at very high elevation.  The problem with that script is that the parachute does not move at the same speed as the wind, also, since it is at a high elevation the wind may not be the same as on the ground (depending on how sophisticated the OFP Game engine is regarding wind).  But with the "weather parachute" method, the caluclating is less complex... speed _weatherpara will yield speed.  getDir _weatherpara will yield wind dir.

[General Barron]

Ah, I forgot about the 'rubbing' parameter. It looks like it is set to full, so the particle should go exactly with the wind.

The reason I said it should be 1 instead of 1.1 is because the script calculates the velocity as though there was only 1 second between when the particle was created and when it disappeared:

Code: [Select]

velocity  = distance travelled / time elapsed
distance travelled = sqrt (_dx^2 + _dy^2)
time elapsed = 1.1
velocity = sqrt (_dx^2 + _dy^2) / 1.1But in the script, velocity (_dist) is NOT divided by anything (i.e. it is only divided by one).

On second thought (as I type this), the values for _dx and _dy are returned by a different script (run from the dropped particle with a delay of 1 second). So in fact the delay in the script could be anything and it would still work. I stand corrected.

@Raptorsaurus

The parachute idea is brilliant! It is much, much cleaner than dealing with drops... I definately like it. But assuming the parachute's speed is proportional to the wind, then couldn't you just multiply it by a constant to get the true windspeed? I suppose I could do some experimenting, finding the "true" windspeed with this script, and comparing it to the speed of the parachute.

One quick Q though: is there a "ceiling" on how high you can place the parachute? Unless you can place it at essentially infinite height, then eventually the chute will hit the ground...

[Raptorsaurus]

In my script I put the parachute at 3000 M, then every 10 seconds it is reset at 3000 M.  I also setpos it directly above the area where wind info is desired (just in case OFP wind varies across the island.  The parachute will have persistent existance as long as it does not hit the ground.  I will dig in my archive (this weekend when I have more time) for the script and post it in the editor depot.

Yes, I imagine one could figure out a constant to add to adjust for the true wind speed.  Maybe use the drop particle mehtod along side the parachute method to find the difference, that should give the constant.

One other drawback of the parachute method is that the parachute direction does not change instantly with wind direction change (there is a delay).  But since even the U.S. National Weather Service determines wind direction from taking an average over time (from a wind vane), one can make a runing average of the parachute direction for average wind direction.

[Terox]

just a quickie on this

Code: [Select]

_count = 0

#START
~1
hint format ["%1 = loops\n\n%2 = script runtime", _count,_time]
goto "START"

the values for loop _count and script runtime start to differ over even a short period of time, say several minutes

i didnt check into this further, might be down to system clock, might be the millisecond of time used to run the hint and goto commamds


just thought you may find the info useful

[Raptorsaurus]

Ok, here is a little demo mission for a script using a parachute as a wind detector.  There are also two functions used for geting true movement direction and horizontal speed.

General B. maybe you can play around with it and find the constant to adjust for the difference between the parachute speed and true wind speed.

P.S.  Terox, what does your post have to do with wind direction? ;D
I think you must have meant to put that under a different topic.

Oh, nevermind Terox.  You are refering to the ~1 delay versus the ~1.1 delay (sorry).  Personally, when I want a precise delay I use:

Code: [Select]

_reftime = _time
@ _time - _reftime >= XInstead of:

Code: [Select]

~ X