From: D-NXKT <D_...@ya...> - 2012-02-25 21:36:55
|
Hello, in a recent posting I claimed that the windturbines are heading out of the wind and not into it. After a deeper investigation I found out that this is only true for the north- south direction. In contrast to this the heading in the east-west direction is correct. The reason is a wrong orientation of the windturbines in the *.stg files. Most of the placed windturbines have a orientation of 180 instead of 0 (e.g. e010n50/e012n50/3154746.stg:OBJECT_SHARED Models/Power/windturbine.xml 12.6544444 50.9219444 298 180)! To make them work properly the orientation has to be changed to 0! Due to the enormous number of windturbines in the scenery this should be done automatically. Best Regards D-NXKT |
From: D-NXKT <D_...@ya...> - 2012-02-27 21:06:53
|
Hello, just checked the orientation of the windturbine.ac and windsock.ac (windsock is working correct) with blender: windsock in +y |---- | | --- windturbine in -y | |-| | | | | -- That's correct, because the windsock faces out of the wind and the turbine into the wind. The animation of both in the xml-Files is absolute identical. --> both are working properly if they have the same orientation (I assume windsock has 0; haven't checked that)! But there is still this issue with smoke. Smoke is drifting for ALL wind directions into the wind. Maybe this is another story because it is related to the particlesystem: ... <program> <fluid>air</fluid> <gravity>true</gravity> <wind>true</wind> </program> </particlesystem> But at the moment I don't know where the "drift" is made in the code. Best Regards D-NXKT |
From: Curtis O. <cur...@gm...> - 2012-02-28 00:28:18
|
Interesting -- if smoke is also going the wrong way, maybe a bug was recently introduced with wind/environment? On Mon, Feb 27, 2012 at 3:09 PM, D-NXKT wrote: > Hello, > > just checked the orientation of the windturbine.ac and windsock.ac(windsock > is working correct) with blender: > windsock in +y > |---- > | > | > --- > windturbine in -y > > | > |-| > | | > | > | > -- > That's correct, because the windsock faces out of the wind and the turbine > into the wind. > The animation of both in the xml-Files is absolute identical. > --> both are working properly if they have the same orientation (I assume > windsock has 0; haven't checked that)! > > But there is still this issue with smoke. Smoke is drifting for ALL wind > directions into the wind. Maybe this is another story because it is > related to > the particlesystem: > ... <program> > <fluid>air</fluid> > <gravity>true</gravity> > <wind>true</wind> > </program> > </particlesystem> > But at the moment I don't know where the "drift" is made in the code. > > Best Regards > D-NXKT > > > > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org |
From: Stuart B. <stu...@gm...> - 2012-02-28 09:11:51
|
On Tue, Feb 28, 2012 at 12:27 AM, Curtis Olson wrote: > Interesting -- if smoke is also going the wrong way, maybe a bug was > recently introduced with wind/environment? I recall a big change to a lot of vector classes quite a while ago, possible changing from SGVec3f to osg::vec3f? The created a couple of regressions, IIRC ridge lift worked on the wrong slopes. So it's possible that this bug has been present for some time. -Stuart |
From: Torsten D. <To...@t3...> - 2012-02-28 10:44:35
|
Am 28.02.2012 10:11, schrieb Stuart Buchanan: > On Tue, Feb 28, 2012 at 12:27 AM, Curtis Olson wrote: >> Interesting -- if smoke is also going the wrong way, maybe a bug was >> recently introduced with wind/environment? > > I recall a big change to a lot of vector classes quite a while ago, > possible changing > from SGVec3f to osg::vec3f? > > The created a couple of regressions, IIRC ridge lift worked on the > wrong slopes. > So it's possible that this bug has been present for some time. I just checked a few turbines in the Netherlands around EHAM - they all look good to me. Is there any specific example or area to check? Torsten |
From: Gijs de R. <gij...@ho...> - 2012-02-28 11:10:33
|
> I just checked a few turbines in the Netherlands around EHAM - they all > look good to me. Is there any specific example or area to check? AFAIK all windturbines I orignally submitted with 0 degrees orientation, until Jon told me to set it to 180 (and elevation to -9999); I think Jon set them all (757 in NL) to 180... I do remember having some issues with flag animations for the Aviodrome model, back in October. But I cannot recall whether it was a reversed animation on my side, or a reversed windsock direction. Gijs |
From: D-NXKT <D_...@ya...> - 2012-02-28 21:04:57
|
Argh! And I thought this issue would be fixed within a few minutes! < just checked a few turbines in the Netherlands around EHAM - they all <look good to me. Is there any specific example or area to check? < <Torsten Ok, I went to the Netherlands, too. Inspected the next windturbine I could find .... and it was correct!?!?! After friends affirmed that I'm not drunk or a little bit "out of order" I decided to do it more systematic: Scenery_TerraSync/Objects/e000n50> grep windturbine */* > e005n51.txt And the result is: a lot of windturbines with orientation 0 and a lot of with 180! Picked this two: 1.) e004n51/3023736.stg:OBJECT_SHARED Models/Power/windturbine.xml 4.17551 51.92114 0 0 2.) e005n51/3040067.stg:OBJECT_SHARED Models/Power/windturbine.xml 5.9733333 51.0483333 69 180 Grabbed the ufo .... (Btw: is the orientation of scenery stuff visible in the property browser?) And the winner is: ........ 1. This is the evidence! The next question is how we should proceed. a) fixing this issue in the assumption that the smoke issue is decoupled from windturbines b) first looking into the smoke issue and then fixing both A fast solution would be prefered. I can't see windturbine anymore at the moment! Best Regards D-NXKT |
From: Curtis O. <cur...@gm...> - 2012-02-28 21:15:29
|
Certainly it would seem like all the wind turbines would need to share the same alignment for them to all point correctly into the wind. The windturbine uses wind-from-heading-deg which should be correct, but also includes a -90 degree offset and reverses the sense of rotation -- perhaps to address the choice axis about which to rotate? <property>/environment/wind-from-heading-deg</property> <offset-deg>-90</offset-deg> <factor>-1</factor> The smoke is particle system based and thus uses a slightly different mechanism -- is the smoke really still reversed? The steam off the catapult on the Vinson is correct. Wind heading is typically the direction the wind is coming from, not the direction it is blowing to. Curt. On Tue, Feb 28, 2012 at 3:05 PM, D-NXKT <D_...@ya...> wrote: > ** > > Argh! > > > > And I thought this issue would be fixed within a few minutes! > > > > < just checked a few turbines in the Netherlands around EHAM - they all > > <look good to me. Is there any specific example or area to check? > > < > > <Torsten > > Ok, I went to the Netherlands, too. Inspected the next windturbine I could find .... and it was correct!?!?! > > After friends affirmed that I'm not drunk or a little bit "out of order" I decided to do it more systematic: > > Scenery_TerraSync/Objects/e000n50> grep windturbine */* > e005n51.txt > > And the result is: a lot of windturbines with orientation 0 and a lot of with 180! > > Picked this two: > > 1.) e004n51/3023736.stg:OBJECT_SHARED Models/Power/windturbine.xml 4.17551 > 51.92114 0 0 > > > > 2.) e005n51/3040067.stg:OBJECT_SHARED Models/Power/windturbine.xml > 5.9733333 51.0483333 69 180 > > > > Grabbed the ufo .... > > (Btw: is the orientation of scenery stuff visible in the property browser?) > > > > And the winner is: ........ 1. > > > > This is the evidence! > > > > The next question is how we should proceed. > > a) fixing this issue in the assumption that the smoke issue is decoupled > from windturbines > > b) first looking into the smoke issue and then fixing both > > > > A fast solution would be prefered. I can't see windturbine anymore at the > moment! > > > > Best Regards > > D-NXKT > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org |
From: Torsten D. <To...@t3...> - 2012-02-29 10:42:44
|
Looks like we have two bugs here: 1. wind turbines with mixed orientations. These should be fixed in the database. If the correct orientation in the stg file is zero. 1a. wind turbine orientation and rotation/spin speed is bound to /environment/wind-from-heading-deg and /environment/wind-speed-kt which represent current wind at the FDM position. This should probably change to ground wind. The same is true for the windsock, btw. 2. Particles attached to "local" move against the wind on the northern hemisphere. Note: Particles attached to "world" (aircraft) behave correctly and move downwind. On southern latitudes, particles attached to "local" also move correctly downwind. This seems to be a bug. IIRC, there was a fix for contrails moving into the wind some time ago - maybe this is somehow related. Torsten Am 28.02.2012 22:15, schrieb Curtis Olson: > Certainly it would seem like all the wind turbines would need to share > the same alignment for them to all point correctly into the wind. > > The windturbine uses wind-from-heading-deg which should be correct, but > also includes a -90 degree offset and reverses the sense of rotation -- > perhaps to address the choice axis about which to rotate? > > <property>/environment/wind-from-heading-deg</property> > <offset-deg>-90</offset-deg> > <factor>-1</factor> > > The smoke is particle system based and thus uses a slightly different > mechanism -- is the smoke really still reversed? The steam off the > catapult on the Vinson is correct. Wind heading is typically the > direction the wind is coming from, not the direction it is blowing to. > > Curt. > > > On Tue, Feb 28, 2012 at 3:05 PM, D-NXKT <D_...@ya... > <mailto:D_...@ya...>> wrote: > > __ > > Argh! > > And I thought this issue would be fixed within a few minutes! > > < just checked a few turbines in the Netherlands around EHAM - they all > > <look good to me. Is there any specific example or area to check? > > < > > <Torsten > > Ok, I went to the Netherlands, too. Inspected the next windturbine I could find .... and it was correct!?!?! > > After friends affirmed that I'm not drunk or a little bit"out of order" I decided to do it more systematic: > > Scenery_TerraSync/Objects/e000n50> grep windturbine */*> e005n51.txt > > And the result is: a lot of windturbines with orientation 0 and a lot of with 180! > > Picked this two: > > 1.) e004n51/3023736.stg:OBJECT_SHARED Models/Power/windturbine.xml > 4.17551 51.92114 0 0 > > 2.) e005n51/3040067.stg:OBJECT_SHARED Models/Power/windturbine.xml > 5.9733333 51.0483333 69 180 > > Grabbed the ufo .... > > (Btw: is the orientation of scenery stuff visible in the property > browser?) > > And the winner is: ........ 1. > > This is the evidence! > > The next question is how we should proceed. > > a) fixing this issue in the assumption that the smoke issue is > decoupled from windturbines > > b) first looking into the smoke issue and then fixing both > > A fast solution would be prefered. I can't see windturbine anymore > at the moment! > > Best Regards > > D-NXKT > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > <mailto:Fli...@li...> > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > > -- > Curtis Olson: > http://www.atiak.com - http://aem.umn.edu/~uav/ > http://www.flightgear.org - http://gallinazo.flightgear.org > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Erik H. <er...@eh...> - 2012-02-29 12:05:26
|
On Wed, 2012-02-29 at 11:43 +0100, Torsten Dreyer wrote: > Looks like we have two bugs here: > 1. wind turbines with mixed orientations. These should be fixed in the > database. If the correct orientation in the stg file is zero. I was wondering, shouldn't all wind turbines share the same configuration file? Erik |
From: Torsten D. <To...@t3...> - 2012-02-29 13:24:03
|
Am 29.02.2012 13:05, schrieb Erik Hofman: > On Wed, 2012-02-29 at 11:43 +0100, Torsten Dreyer wrote: >> Looks like we have two bugs here: >> 1. wind turbines with mixed orientations. These should be fixed in the >> database. If the correct orientation in the stg file is zero. > > I was wondering, shouldn't all wind turbines share the same > configuration file? They do, the mentioned rotation is specified in the *.stg file (last data column). Torsten |
From: TDO B. <tdo...@ho...> - 2012-02-29 15:33:30
|
I also suspect that the speed of wind turbines is not just directly proportional to wind speed. As far as I know, the speed is generally regulated either by increasing the turbine load or by changing the blade pitch, to avoid them getting damaged in high wind. In extreme gusty gales they are probably stopped with the blades feathered. It would be nice to see one or two turbines randomly stopped for maintenance in a wind farm. Alessandro > Date: Wed, 29 Feb 2012 14:24:56 +0100 > From: To...@t3... > To: fli...@li... > Subject: Re: [Flightgear-devel] Windturbines facing in wrong wind direction > > Am 29.02.2012 13:05, schrieb Erik Hofman: > > On Wed, 2012-02-29 at 11:43 +0100, Torsten Dreyer wrote: > >> Looks like we have two bugs here: > >> 1. wind turbines with mixed orientations. These should be fixed in the > >> database. If the correct orientation in the stg file is zero. > > > > I was wondering, shouldn't all wind turbines share the same > > configuration file? > > They do, the mentioned rotation is specified in the *.stg file (last > data column). > > Torsten > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Arnt K. <ar...@c2...> - 2012-03-05 09:58:59
|
On Wed, 29 Feb 2012 15:33:20 +0000, TDO wrote in message <DUB...@ph...l>: > > I also suspect that the speed of wind turbines is not just directly > proportional to wind speed. As far as I know, the speed is generally > regulated either by increasing the turbine load or by changing the > blade pitch, to avoid them getting damaged in high wind. In extreme > gusty gales they are probably stopped with the blades feathered. ..some are "turned off" by yawing the mill head "out of the wind" until the blade chords face the wind. > It would be nice to see one or two turbines randomly stopped for > maintenance in a wind farm. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. |
From: Olivier <ac...@ya...> - 2012-02-29 16:59:33
|
> I was wondering, shouldn't all wind turbines share the same > configuration file? They do. But their heading declaration (as an object position) in the db (which is later generated as a STG file may be different, just like any other object. It depends on the guy who submitted it. That's why their orientation should be, IMHO, independant from the orientation they have been set in the DB. They have to face the wind, that's "all". Olivier |
From: Gijs de R. <gij...@ho...> - 2012-02-29 17:07:11
|
Whatever you do to fix it, please note that there is more than one windturbine model ;) E.g. this one I created recently: http://scenemodels.flightgear.org/modeledit.php?id=2418 IIRC it has the same animation setup, just different numbers. |
From: Jon S. <li...@st...> - 2012-02-29 22:00:40
|
On 29/02/12 17:06, Gijs de Rooy wrote: > Whatever you do to fix it, please note that there is more than one > windturbine model ;) > E.g. this one I created recently: > http://scenemodels.flightgear.org/modeledit.php?id=2418 > > IIRC it has the same animation setup, just different numbers. It seems there was some weirdness in the db: landcover=> select count(*),ob_heading from fgs_objects where ob_model=33 group by ob_heading; count | ob_heading -------+------------ 1 | 200.00 2 | 210.00 1 | 230.00 1 | 240.00 789 | 180.00 24262 | 0.00 (6 rows) So I've updated it, and we now have: landcover=> select count(*),ob_heading from fgs_objects where ob_model=33 group by ob_heading; count | ob_heading -------+------------ 25056 | 0.00 (1 row) I'll do the same for model 2418 - then once everything is consistent we can see if any changes need to be made (they certainly used to work properly). -- Jon Stockill li...@st... |
From: D-NXKT <D_...@ya...> - 2012-02-28 22:11:19
|
>The smoke is particle system based and thus uses a slightly different >mechanism -- is the smoke really still reversed? The steam off the >catapult on the Vinson is correct. Wind heading is typically the direction >the wind is coming from, not the direction it is blowing to.> >Curt. Yup! Tested with release 2.6.0 at KSFO. Wind from 90° with 30kn. Fly direction San Fransisco. Behind the arena are a few chimneys. The smoke drifts to the bay! Use the dragonfly. You can fly with no groundspeed besides the chimneys and watch the weird scenario! Best Regards D-NXKT |
From: Emilian H. <emi...@gm...> - 2012-02-29 10:18:46
|
On Tuesday 28 February 2012 23:14:18 D-NXKT wrote: > >The smoke is particle system based and thus uses a slightly different > >mechanism -- is the smoke really still reversed? The steam off the > >catapult on the Vinson is correct. Wind heading is typically the direction > >the wind is coming from, not the direction it is blowing to.> > > >Curt. > Yup! > Tested with release 2.6.0 at KSFO. Wind from 90° with 30kn. > Fly direction San Fransisco. Behind the arena are a few chimneys. > The smoke drifts to the bay! Use the dragonfly. You can fly with no groundspeed besides the chimneys and watch the weird scenario! > > Best Regards > D-NXKT That's due to the particle system on those chimneys (Models/Industrial/generic_chimney_01.xml) having: <attach>local</attach> instead of: <attach>world</attach> Also while invetigating this I found the smoke.png texture these are referencing as missing from the terrrasync Models/Industrial folder. That makes the smoke look square/ugly. |
From: jean p. <jea...@wa...> - 2012-03-01 23:29:57
|
Hi, happy ati user :) I'm affected from quite some time by the bug 385: http://code.google.com/p/flightgear-bugs/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone&groupby=&sort=&id=385#makechanges It appear in my setup that adding a radar section in the intrumentation.xml (or any name called by the <instrumentation> field in the -set.xml file) solve the bug, for all the planes tested (b1900d, bo105, iar80, super constellation etc...) <radar> <name>wxradar</name> <number>0</number> </radar> - is there some clue why the radar can have such an impact? - is it possible to add the radar section to the aircrafts in the base package affected by the bug, or do we have to buy nvidia again? jano |
From: ThorstenB <br...@gm...> - 2012-03-02 07:53:42
|
On 02.03.2012 00:29, jean pellotier wrote: > http://code.google.com/p/flightgear-bugs/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone&groupby=&sort=&id=385#makechanges > > It appear in my setup that adding a radar section in the > intrumentation.xml (or any name called by the<instrumentation> field in > the -set.xml file) solve the bug, for all the planes tested (b1900d, > bo105, iar80, super constellation etc...) > > <radar> > <name>wxradar</name> > <number>0</number> > </radar> > > - is there some clue why the radar can have such an impact? > > - is it possible to add the radar section to the aircrafts in the base > package affected by the bug, or do we have to buy nvidia again? See my comments at bug #385: For some people, removing the "<instrumentation>" section from aircraft "fixes" the issue (or renaming it, which is effectively the same). Otherwise, adding even more stuff to the section, such as the radar also seems to help. This could be a timing issue, since people seeing the issue obviously need to speed up or slow down the phase of initial aircraft loading. We already know that FG doesn't receive a Window resize event when the issue happens. But we don't know why this only happens with the ATI, only with their driver versions 11.5 and above, and only on Windows. One hope is that using a newer OSG library might fix the issue. The latest OSG release is still 3.0.1, but there have been a number of fixes to OSG, including the modules handling GraphicsWindows since. So, it'd be interesting if someone seeing the issue tested FG the latest OSG trunk version. If this doesn't help, then it really takes someone using a debugger and investigate what's happening to the resize event. In any case, randomly adding or removing stuff to aircraft files isn't a solution. Of course, it's ok for anyone to change things locally as a work-around, but nothing acceptable for FG in general. cheers, Thorsten |
From: Robert <do...@go...> - 2012-03-03 02:28:47
|
2012/3/2 ThorstenB <br...@gm...> > But we don't know why this only happens with the ATI, > only with their driver versions 11.5 and above, and only on Windows. > Thorsten, this bug is also present on Linux (in my case), and I think I have read in the google bug-reports that OSX is affected, too. cheers, Robert |
From: ThorstenB <br...@gm...> - 2012-03-03 22:12:33
|
Am 03.03.2012 03:28, schrieb Robert: > 2012/3/2 ThorstenB <br...@gm... <mailto:br...@gm...>> > But we don't know why this only happens with the ATI, > only with their driver versions 11.5 and above, and only on Windows. > > Thorsten, this bug is also present on Linux (in my case), and I think I > have read in the google bug-reports that OSX is affected, too. Never heard anyone reporting the issue for Linux. Indeed, there was a related bug for Mac (#356), but that was reported to be fixed with OSG 3.0.1, only leaving an "ugly effect" (whatever that is). Anyway, anyone reproducing the issue and capable of compiling FG 2.7.0/Git could help by providing the terminal output when running a debug patch, see #385, comment 41 for details: http://code.google.com/p/flightgear-bugs/issues/detail?id=385#c41 cheers, Thorsten |
From: jean p. <jea...@wa...> - 2012-03-03 23:09:07
|
Le 03/03/2012 23:12, ThorstenB a écrit : > Am 03.03.2012 03:28, schrieb Robert: >> 2012/3/2 ThorstenB<br...@gm...<mailto:br...@gm...>> >> But we don't know why this only happens with the ATI, >> only with their driver versions 11.5 and above, and only on Windows. >> >> Thorsten, this bug is also present on Linux (in my case), and I think I >> have read in the google bug-reports that OSX is affected, too. > Never heard anyone reporting the issue for Linux. Indeed, there was a > related bug for Mac (#356), but that was reported to be fixed with OSG > 3.0.1, only leaving an "ugly effect" (whatever that is). > > Anyway, anyone reproducing the issue and capable of compiling FG > 2.7.0/Git could help by providing the terminal output when running a > debug patch, see #385, comment 41 for details: > http://code.google.com/p/flightgear-bugs/issues/detail?id=385#c41 > > cheers, > Thorsten > Hi, thanks for the patch, as I am on linux and affected by the bug (and the one complaining the most), I guess i will try it, BTW, whitch OSG version do i have to use? last devel version is ok? cheers jano |
From: ThorstenB <br...@gm...> - 2012-03-04 09:52:06
|
Am 04.03.2012 00:09, schrieb jean pellotier: > BTW, whitch OSG version do i have to use? > > last devel version is ok? Any version that reproduces the issue for you. If it still occurs with OSG trunk, then that's also interesting. If it wasn't, well, then you have a solution ;-). But I already have a suspicion on a timing/sequence issue inside FG itself, so OSG probably won't matter. cheers, Thorsten |
From: Martin S. <Mar...@mg...> - 2012-02-26 12:49:01
|
D-NXKT wrote: > After a deeper investigation I found out that this is only true for the north- > south direction. In contrast to this the heading in the east-west direction is > correct. > The reason is a wrong orientation of the windturbines in the *.stg files. Most > of the placed windturbines have a orientation of 180 instead of 0 (e.g. > e010n50/e012n50/3154746.stg:OBJECT_SHARED Models/Power/windturbine.xml > 12.6544444 50.9219444 298 180)! > To make them work properly the orientation has to be changed to 0! > Due to the enormous number of windturbines in the scenery this should be done > automatically. If anybody verifies and tells me the ID of the affected model in Scenemodels, I'd fix the orientation of all of them - that's just a very simple one-liner in SQL, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |