I just noticed that the mWind member in the ScoringInfoV01 structure is a TelemVect3 structure. How is this supposed to be interpreted? Generally these triplets are directional, but why would wind have a Z direction, and why would you need to do maths to calculate the actual wind speed? Or am I missing something here? EDIT: After some tests, the wind triplet values are all zero. I guess that is why wind has no in-game effect, it's not enabled yet, right?
The latest info I read about this was that, as you say, wind is not enabled. Considering it is a feature that will be important to take into account when preparing a setup it will for sure be assesed in the release notes of the build when it gets in the game. Enviado desde mi GT-I9505 usando Tapatalk 2
Was your car under AI by any chance? Most of the values in the telem struct are zero when the car is under AI control. Normally when testing a plugin I let the AI run around the track and then when it gets on a straight I turn AI off and then I at least see all the values in the telem struct update until the driverless car hits the wall.
My car was in the pits, but I did run quite a number of AI on track. Wind is not in the telemetry data though, it's in the session-related data along with temperature, rain density, etc. Regardless, it's a bit weird that it is reported using X/Y/Z oriented data...
The car speed is measured in x,y,z, so air speed measured/stored the same way makes it easy to find the relative speed for aero effects etc. If Z (or Y, always get confused between other progs and rF) is always 0 that's fine. Still makes more sense than storing X and Y separately.
I agree that a moving object, like a car, would make sense to report in three directions. For wind though, I guess it's a wind sensor which is stationary, so an angle in degrees or radians, and a speed in meters per second would be much simpler imo. (Particularly since that is the way you configure it in the weather file, albeit somewhat simplified when it comes to direction) Anyway, let's see what the x/y/z values will be used for once wind is enabled.
Velocity is a vector. Three components would be needed in order to fully define it. Maybe z direction will not be used later. Who knows... It will depend on how they transform the input provided when defining weather which is static to real time where it should be dynamic the same as weather. I dealt a little bit with wind theory in the past when I was working designing heliostats for solar thermal power where wind is the critical load in terms of the strength you need to provide to them to avoid a disaster at plant level. I would love to see a variable wind in the game where you could feel the gusts introduced by random variables as well as speed direction variations. This would also include small variations in Z direction which would greatly affect downforce. I guess that the geometry of the track will have to be disregarded since it would be much more complicated and probably heavily affect performance. I dont thing it is such a big deal however... Enviado desde mi GT-I9505 usando Tapatalk 2
It may seem simpler from the point of view of how we generally define wind (usually the direction it's coming from, and the speed/strength), but you could say the same for a car. You don't drive down the road and say, "it's ok, I'm not speeding - I'm currently travelling at 17.6m/s N, 8.4m/s E, pretty much level." You have an inherent direction (the one in front of you) and a speed. And really you could deal with all moving objects in a game the same way. Even if you want to use cartesian measures for a car and polar for a wind, you can still make them interact. As much as anything else, by just using x,y,z (even if Z is always zero, or close to it) you've got a single object that captures the wind data which is the same type of object as the car is using. If the cars used polar, you'd probably use polar for the wind as well to keep things easy. So I probably wouldn't read too much into it - the game is already dealing with x,y,z values, and quite a few of them, so using x,y,z to define the wind is just a logical choice. Spaskis... variable gusts, channels, pressure points, upstreams, all dependent on track geometry... you'll give the guys at ISI nightmares
I hear what you are saying. It's just that I'm the kind of developer who likes to keep an API clean and simple unless it needs to be complicated. (like for a flight simulator that definitely wants all three components) Anyway, I realize that the API representation won't change, so let's instead hope that wind gets activated in the game soon. And yeah, I'd love to see wind gusts too.
