FlightGear Newsletter September 2010: Difference between revisions

Jump to navigation Jump to search

FlightGear Newsletter September 2010 (view source)

Revision as of 19:27, 30 September 2010

89 bytes removed ,  30 September 2010
m
Final fixes before lock. Will have a closer look tomorrow, running out of time ;)
m (Final fixes before lock. Will have a closer look tomorrow, running out of time ;))
Line 3: Line 3:
''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''
''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''


== FlightGear events ==
== Development news ==
== Development news ==
===Local Weather v0.85===
===Local Weather v0.85===
The [http://www.phy.duke.edu/~trenk/files/local_weather_fgfs2.0.0_v0.85.tgz version 0.85] (also on GIT) of the [[A local weather system|Local Weather package]] is out - with new cloud types and textures and most importantly a significant performance gain over previous versions. There is a new menu to allow the user at runtime to specify cloud visual ranges, so that the impact on framerate can be adjusted to the situation.
The [http://www.phy.duke.edu/~trenk/files/local_weather_fgfs2.0.0_v0.85.tgz version 0.85] (also on GIT) of the [[A local weather system|Local Weather package]] is out - with new cloud types and textures and most importantly a significant performance gain over previous versions. There is a new menu to allow the user at runtime to specify cloud visual ranges, so that the impact on framerate can be adjusted to the situation.
Line 51: Line 49:
With careful choice of options and locations frame rates can be kept at a reasonable level. Analysis has shown that the tall pole in the tent is the code which measures Altitude Above Ground Level. This is known to be  code that is heavy on framerate and which is used extensively in the AI code. It might be possible to get a cheaper, simpler version of this function which would improve the impact on framerate. Hopefully, this will be the next stage of development.
With careful choice of options and locations frame rates can be kept at a reasonable level. Analysis has shown that the tall pole in the tent is the code which measures Altitude Above Ground Level. This is known to be  code that is heavy on framerate and which is used extensively in the AI code. It might be possible to get a cheaper, simpler version of this function which would improve the impact on framerate. Hopefully, this will be the next stage of development.


Further development of the Wingman concept will allow formations to break and reform as shown in this video[http://www.youtube.com/watch?v=dBcKET9h5E8]. Subject to further testing and tuning this code should be available in Gitorious by early October.  
Further development of the Wingman concept will allow formations to break and reform as shown in [http://www.youtube.com/watch?v=dBcKET9h5E8 this video]. Subject to further testing and tuning this code should be available in Gitorious by early October.  


[[File:FlightPlan_Generator1.png|thumb|270px|A taxi-script example]]
[[File:FlightPlan_Generator1.png|thumb|270px|A taxi-script example]]
Line 60: Line 58:
When the waypoint is finished, it can be exported to an XML code which then can be used in an AI Scenario.
When the waypoint is finished, it can be exported to an XML code which then can be used in an AI Scenario.


The AI FlightPlan Generator can be found here: [http://bit.ly/FlightPlanGenerator]
The AI FlightPlan Generator can be found at [http://bit.ly/FlightPlanGenerator this link].


<gallery>
<gallery>
Line 74: Line 72:


===Bump-Spec-Reflection shader===
===Bump-Spec-Reflection shader===
Based on Vivian Meazza's reflection shader and the bumpmap shader, Frederic Bouvier created a new shader, which merge both shader effects together.
Based on Vivian Meazza's reflection shader and the bumpmap shader, Frederic Bouvier created a new shader, which merge both shader effects together.
That means that we can have now bumpy surfaces which has reflections. The specular effect can be also controlled so that will gives us effects which has been used in commercial sims like MSFS since a while.
That means that we can have now bumpy surfaces which has reflections. The specular effect can be also controlled so that will gives us effects which has been used in commercial sims like MSFS since a while.


===Improvements on the Urban Shader===
===Improvements on the Urban Shader===
The urban shader has been improved as well- building sides are now vertical. Thanks to Stuart for this improvement!
The urban shader has been improved as well- building sides are now vertical. Thanks to Stuart for this improvement!


Line 101: Line 97:


=== JSBSim, and Matlab ===
=== JSBSim, and Matlab ===
Brian Mills and Agostino De Marco have been working at preparing a new release of a Matlab SFunction that wraps JSBSim.
Brian Mills and Agostino De Marco have been working at preparing a new release of a Matlab SFunction that wraps JSBSim.


Line 127: Line 122:


==Nasal syntax highlighting file for Notepad++ users ==
==Nasal syntax highlighting file for Notepad++ users ==
Forum member c.harms has created a syntax highlighting file for Notepad++ users, please check out [http://flightgear.org/forums/viewtopic.php?p=92127#p92127 the topic] to download the file and for installation instructions.


Forum member c.harms has created a syntax highlighting file for Notepad++ users, please check out http://flightgear.org/forums/viewtopic.php?f=30&t=9260&p=95391#p92127 to download the file and for installation instructions.
== Nasal for newbies: OOP ==
OOP is all about creating "things" (i.e. a cloud) with "actions" (transform,draw,update) (or "messages").
Where a class (or hash in Nasal) is the "template" for a "thing" containing a number of member fields.
So the class only describes the "layout" or properties of objects that can be created. To actually use a class, it has to be "instantiated" which means creating an object using a specific "template class" (or even several different classes).
These member fields can be variables (e.g. lat, lon, alt) or functions (setAlt, setPos).
And the actual instance (cloud[n] in the property tree) of such a thing is then called an "object".
Functions that work with instance specific state are called "methods", they may refer to instance specific state using a "self reference" (me) in Nasal, that ensures that access to a field or method is using the right instance specific data.
In OOP, internal state is managed by wrapping everything in a class using accessor functions for modifying and getting internal values.
So internal state would in turn only be modified by an abstract interface: class "methods", instead of directly accessing class-internal fields.
This provides a way for managing access to a member variable (field), such an abstract interface is also useful for keeping logics private, and internal. For example, the name of a variable "altitude" can be easily changed internally to "altitude_ft", without having to rename all users of the class - simply because all other code will refer to the methods providing access to the field.
For example, instead of doing something like cloud.lat=10.22; cloud.lon=43.22; you would have a method accepting lat/lon variables: cloud.setPos(lat, lon);
That means that the actual variables containing the values for lat/lon are not exposed or used outside the actual object. This is called encapsulation and provides you with a way to manage state and ensure that internal state is valid at all times, because other code may only use the external interface.
This allows you for example to simply rename a class variable, without having to change any of the code that uses the object, because other code only uses class methods.
Another important thing in OOP is separation of concerns, i.e. you don't want to end up with huge bloated "super classes" that manage all sorts of different state, but instead use different classes where appropriate to split code into abstract "modules" with well defined responsibilities.
So, one of the very first steps to convert procedural code to OOP code would be to group your code into a number of logical "classes" (e.g. cloud, cloud field ).
Classes may be composed of other classes, i.e. a "cloud field" class would in turn contain "cloud" classes.
This is then called "composition".
Another way is inheritance, where a type may inherit properties (fields:variables and methods) from a "parent" class. Imagine it like taking a "template" for the class and then saying "make a new class using this template".
Inheritance has the added advantage of providing a means to customize class behavior without having to modify the actual class, because all member fields can be parametrized.
For example, a "cumulus" cloud class could be derived from the "cloud" class, just by parametrizing it (different cloud model, different texture, different transformations), without touching anything in the actual "cloud" class.
This is basically how OOP may be understood: things are classified according to "is a" or "has a" relationship.
Of course, one may still use objects like conventional variables for passing and returning parameters.
== New software tools ==
== FlightGear addons and mods ==
== In the hangar ==
== In the hangar ==
===BAe-146===
===BAe-146===
Line 194: Line 149:
===Historic Nike Hercules Missile Sites===
===Historic Nike Hercules Missile Sites===
[[File:nike missile site3.png|thumb|One of 3 Sites.]]
[[File:nike missile site3.png|thumb|One of 3 Sites.]]
Jack Mermod has begun modeling Historical Nike Hercules Missile Sites. They will all be in the Bay Area. These Sites were the last stand of defense in the event of a Soviet Bombing. You can still find evidence of these sites today, and they are a important part of history. Each Site has a helipad, in hopes of attracting helicopter pilots to come and explore the sights. So far there are 3 sites that have been made and placed into flightgear, and the plan is to make 12. The sites will hopefully be available through terrasync soon, but for now you can [http://www.flightgear.org/forums/viewtopic.php?f=5&t=9521 watch this forum topic] to see updates for the sites and download them.
Jack Mermod has begun modeling Historical Nike Hercules Missile Sites. They will all be in the Bay Area. These sites were the last stand of defense in the event of a Soviet Bombing. You can still find evidence of these sites today, and they are a important part of history. Each site has a helipad, in hopes of attracting helicopter pilots to come and explore the sights. So far there are 3 sites that have been made and placed into FlightGear, and the plan is to make 12. The sites will hopefully be available through terrasync soon, but for now you can [http://www.flightgear.org/forums/viewtopic.php?f=5&t=9521 watch this forum topic] to see updates for the sites and download them.


===UK Football Stadiums===
===UK football stadiums===
[[File:Emiratesstadium.jpg|thumb|Emirates Stadium in Flightgear]]
[[File:Emiratesstadium.jpg|thumb|Emirates Stadium in Flightgear]]
Andyramone has completed and submitted three football stadiums to the scenery database. These include Carrow Road (Norwich), Emirates Stadium (Arsenal) and Stamford Bridge (Chelsea.) Portman Road (Ipswich) and White Hart Lane (Tottenham) are complete and will be submitted to the scenery database this month. The project will continue later this year with more London stadiums including Wembley on the to do list.  
Andyramone has completed and submitted three football stadiums to the scenery database. These include Carrow Road (Norwich), Emirates Stadium (Arsenal) and Stamford Bridge (Chelsea.) Portman Road (Ipswich) and White Hart Lane (Tottenham) are complete and will be submitted to the scenery database this month. The project will continue later this year with more London stadiums including Wembley on the to do list.  
Line 235: Line 190:
Image:PoolbegPP-01.jpg|Poolbeg Power Station (Dublin) in progress
Image:PoolbegPP-01.jpg|Poolbeg Power Station (Dublin) in progress
</gallery>
</gallery>
===Estonia kicked off===
Alexander Raldugin started modeling the cities and airports of Tallinn and Tartu, Estenia in northeastern Europe. Most models include night lighting. Buildings are available from the regular places.


[[File:VadoLigureHarbor.jpg|thumb|Vado Ligure Container Ship Terminal]]
[[File:VadoLigureHarbor.jpg|thumb|Vado Ligure Container Ship Terminal]]
===Harbors===
===Harbors===
Harbors, with their huge cranes and long peers, may be as well noticeable landmarks for VFR flying. Scighera is presently working on the model of Vado Ligure Harbor, having completed the Container unloading pier.
Harbors, with their huge cranes and long peers, may be as well noticeable landmarks for VFR flying. Scighera is presently working on the model of Vado Ligure Harbor, having completed the Container unloading pier.
Line 249: Line 206:
</gallery>
</gallery>


===Moveable Helipads===
===Moveable helipads===
[[File:Moveable helipads.jpg|200px|thumb|right|Moveable-helipads in FGFS can be controlled in many ways. It is a feature which commercial sims like MSFS or X-Plane don't have yet.]]
[[File:Moveable helipads.jpg|200px|thumb|right|Moveable-helipads in FGFS can be controlled in many ways. It is a feature which commercial sims like MSFS or X-Plane don't have yet.]]
[[User:HHS|HHS]] is working on moveable helipads, also known as dollys.
[[User:HHS|HHS]] is working on moveable helipads, also known as dollys.
Line 261: Line 218:


Theoretically with this a physically accurate working [[Howto: Implement pushback|pushback]] over mp, independant of the aircraft's FDM and settings, would be possible. First experiments have been quite successful, but need further investigations.
Theoretically with this a physically accurate working [[Howto: Implement pushback|pushback]] over mp, independant of the aircraft's FDM and settings, would be possible. First experiments have been quite successful, but need further investigations.
== Nasal for newbies: OOP ==
OOP is all about creating "things" (i.e. a cloud) with "actions" (transform,draw,update) (or "messages").
Where a class (or hash in Nasal) is the "template" for a "thing" containing a number of member fields.
So the class only describes the "layout" or properties of objects that can be created. To actually use a class, it has to be "instantiated" which means creating an object using a specific "template class" (or even several different classes).
These member fields can be variables (e.g. lat, lon, alt) or functions (setAlt, setPos).
And the actual instance (cloud[n] in the property tree) of such a thing is then called an "object".
Functions that work with instance specific state are called "methods", they may refer to instance specific state using a "self reference" (me) in Nasal, that ensures that access to a field or method is using the right instance specific data.
In OOP, internal state is managed by wrapping everything in a class using accessor functions for modifying and getting internal values.
So internal state would in turn only be modified by an abstract interface: class "methods", instead of directly accessing class-internal fields.
This provides a way for managing access to a member variable (field), such an abstract interface is also useful for keeping logics private, and internal. For example, the name of a variable "altitude" can be easily changed internally to "altitude_ft", without having to rename all users of the class - simply because all other code will refer to the methods providing access to the field.
For example, instead of doing something like cloud.lat=10.22; cloud.lon=43.22; you would have a method accepting lat/lon variables: cloud.setPos(lat, lon);
That means that the actual variables containing the values for lat/lon are not exposed or used outside the actual object. This is called encapsulation and provides you with a way to manage state and ensure that internal state is valid at all times, because other code may only use the external interface.
This allows you for example to simply rename a class variable, without having to change any of the code that uses the object, because other code only uses class methods.
Another important thing in OOP is separation of concerns, i.e. you don't want to end up with huge bloated "super classes" that manage all sorts of different state, but instead use different classes where appropriate to split code into abstract "modules" with well defined responsibilities.
So, one of the very first steps to convert procedural code to OOP code would be to group your code into a number of logical "classes" (e.g. cloud, cloud field ).
Classes may be composed of other classes, i.e. a "cloud field" class would in turn contain "cloud" classes.
This is then called "composition".
Another way is inheritance, where a type may inherit properties (fields:variables and methods) from a "parent" class. Imagine it like taking a "template" for the class and then saying "make a new class using this template".
Inheritance has the added advantage of providing a means to customize class behavior without having to modify the actual class, because all member fields can be parametrized.
For example, a "cumulus" cloud class could be derived from the "cloud" class, just by parametrizing it (different cloud model, different texture, different transformations), without touching anything in the actual "cloud" class.
This is basically how OOP may be understood: things are classified according to "is a" or "has a" relationship.
Of course, one may still use objects like conventional variables for passing and returning parameters.


== Video of the month ==
== Video of the month ==
Line 266: Line 260:


[[File:Clip0437_0002.jpg]] [[File:Clip0437_0001.jpg]]
[[File:Clip0437_0002.jpg]] [[File:Clip0437_0001.jpg]]
== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==


== Suggested flights ==
== Suggested flights ==
Line 282: Line 271:


The islands will be available through the download center with the next major scenery release, but for now, fire up [[TerraSync]] and your favorite VFR aircraft and have a blast.
The islands will be available through the download center with the next major scenery release, but for now, fire up [[TerraSync]] and your favorite VFR aircraft and have a blast.
== Aircraft reviews ==


== Wiki updates ==
== Wiki updates ==
Line 304: Line 291:


=== Forum news ===
=== Forum news ===
 
Thanks to moderator Gijs, we have now a new sub forum for all issues related to building FlightGear from source. Hopefully, this will make it easier for new users (and developers!) to get support for compiling FlightGear. So if you are having problems building FlightGear from source, please check out http://flightgear.org/forums/viewforum.php?f=45
Thanks to Gijs, we have now a new sub forum for all issues related to building FlightGear from source. Hopefully, this will make it easier for new users (and developers!) to get support for compiling FlightGear. So if you are having problems building FlightGear from source, please check out http://flightgear.org/forums/viewforum.php?f=45


=== New Spanish-Latin American FG community website ===
=== New Spanish-Latin American FG community website ===
NiTuS and El Flauta have created ''[http://www.vivefg.org| Vive FG!]'' (translation: Live FG!), a new version of the Spanish-Latin American FG community website. Powered by Joomla!, it's now much more dynamic and clearer than the previous one, including many FG tutorials about aircraft, scenery and FG-itself-related ''how-to'', as well as additional aircraft and sceneries created by the community, and much more. We encourage everyone to come in, regardless the language you speak!
NiTuS and El Flauta have created ''[http://www.vivefg.org| Vive FG!]'' (translation: Live FG!), a new version of the Spanish-Latin American FG community website. Powered by Joomla!, it's now much more dynamic and clearer than the previous one, including many FG tutorials about aircraft, scenery and FG-itself-related ''how-to'', as well as additional aircraft and sceneries created by the community, and much more. We encourage everyone to come in, regardless the language you speak!


=== Multiplayer ===
=== FGCom server down ===
=== Virtual airlines ===
The [[FGCom]] server is temporarily down. Please refer to [http://flightgear.org/forums/viewtopic.php?f=10&t=9651 this forum topic] for the latest news.


== Useful links ==
== And finally ... ==
== And finally ... ==
Next [http://www.fsweekend.com/ FSWeekend] event takes place November 6 & 7th 2010. Mark this date in your calendar and expect an outstanding presentation of FlightGear's features at [[Lelystad_Airport|Lelystad's airport]].
=== Contributing ===
=== Contributing ===
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.  
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.  
Line 332: Line 314:


So all users are invited to help us progress further with our preparations for GSoC 2011. If you have any questions or other feedback, please use the forum to [http://flightgear.org/forums/viewforum.php?f=38 get in touch].
So all users are invited to help us progress further with our preparations for GSoC 2011. If you have any questions or other feedback, please use the forum to [http://flightgear.org/forums/viewforum.php?f=38 get in touch].
=== Did you know ===


[[Category:FlightGear Newsletter|2010 09]]
[[Category:FlightGear Newsletter|2010 09]]
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/24313"

Navigation menu