== Moving map ==
The information about "The hidden map" is very enthusiastic but somewhat lacking and even wrong. Result is that "The Hidden Map" stays hidden or at least hard to find.
# Add the URL for the moving map:<br />http://localhost:8080/gui/map/
# Remove this sentence: '''Click on "Equipment" and select "Map (opens in browser)"''' since this simply does not work.<br /> The map is accessible from the URL only on all the 3.2.0 or 3.0.0 installs I've tried, whether on Linux or Win 7.
--[[User:Jarl Arntzen|Jarl Arntzen]] ([[User talk:Jarl Arntzen|talk]]) 13:33, 19 October 2014 (UTC)

== Can't jump to Heading Level 3 on mobile ==

The links to the level 3 headlines do not work in the mobile template.<br />

Tapping the link does not jump to any headline at all. I suggest linking the headline "DEVELOPMENT NEWS" so at least, it's possible to navigate by tapping that one.
The long term solution would of course be to allow linking to level 3 headlines directly, also on mobile.
Cheers.
--[[User:Jarl Arntzen|Jarl Arntzen]] ([[User talk:Jarl Arntzen|talk]]) 13:43, 19 October 2014 (UTC)

Talk:FlightGear Newsletter September 2014

2014-10-19T13:33:24Z

Jarl Arntzen: /* Moving map */

Talk:FlightGear Newsletter September 2014

2014-10-19T13:31:01Z

Jarl Arntzen: /* Moving map */

Talk:FlightGear Newsletter September 2014

2014-10-19T13:28:35Z

Jarl Arntzen: /* Moving map */

== Moving map ==
The information about "The hidden map" is very enthusiastic but somewhat lacking and even wrong. Result is that "The Hidden Map" stays hidden or at least hard to find.
# Add how to activate the moving map:<br />Start FG with: '''<code>fgfs --httpd=8080</code>'''
# Add the URL for the moving map:<br />http://localhost:8080/gui/map/
# Remove this sentence: '''Click on "Equipment" and select "Map (opens in browser)"''' since this simply does not work.<br /> The map is accessible from the URL only on all the 3.2.0 or 3.0.0 installs I've tried, whether on Linux or Win 7

Talk:FlightGear Newsletter September 2014

2014-10-19T13:25:44Z

Jarl Arntzen: The hidden map, need actual info about config and URL

== Moving map ==
The information about "The hidden map" is very enthusiastic but somewhat lacking and even wrong. Result is that "The Hidden Map" stays hidden or at least hard to find.
# Add how to activate the moving map:<br />Start FG with: '''fgfs --httpd=8080'''
# Add the URL for the moving map:<br />http://localhost:8080/gui/map/
# Remove this sentence: '''Click on "Equipment" and select "Map (opens in browser)"''' since this simply does not work.<br /> The map is accessible from the URL only on all the 3.2.0 or 3.0.0 installs I've tried, whether on Linux or Win 7

FGCamera

2014-08-12T10:28:44Z

Jarl Arntzen: /* Added forum thread for easier reference */

{{#ev:youtube|DMZB7QXpR9I|400|right|FGCamera v1.0 in action}}
FGCamera is an alternative FlightGear view system that adds features similar to „EZdok Camera Addon“ for Flight Simulator X. FGCamera is written in Nasal.

'''Currently available features:'''
* 4 camera types:
** Virtual cockpit,
** Aircraft (look-at),
** Aircraft (look-from),
** World (look-from);
* Arbitrary number of preset views;
* Smooth/discrete transition between the views of the same camera type.

== Download link / Installation ==
{{ WIP }}

== User Interface ==
[[File: Fgcamera menu item.jpg|thumb]]

Graphical user interface is used to create and manage camera views. FGCamera dialogs can be launched using menubar item ''View/FGCamera (experimental)''.

Currently, there are three functional dialogs:
* Main,
* Camera creation,
* Current camera settings.

=== Main Dialog ===
[[File: Fgcamera main dialog.jpg|thumb]]

* "Options" button opens FGCamera's global settings dialog. This dialog is currently non functional.
* "Create new camera..." button opens new camera creation dialog.
*The list of cameras shows all the camera views that are created for the currently selected aircraft. Each camera view has its own index. The active view (currently selected view) is marked by square brackets.
* The active view can be renamed using input box below the list of cameras.
* Buttons "U" and "D" are used to rearrange camera views.
* "Delete" button removes the active camera.
* "Save" button saves all the cameras data to disk.
* "Close" closes the dialog (changes will not be saved to disk).

=== Camera Creation Dialog ===
[[File: Fgcamera new camera dialog.jpg|thumb]]

* "Camera type" popup list is used to select camera type. Supported types:
** cockpit,
** aircraft (look at),
** aircraft (look from),
** world (look from);
* "Create" – creates new camera view and selects it as an active camera.
* "Cancel" – closes the dialog.

=== "Current camera settings" Dialog ===
[[File: Fgcamera camera settings dialog.jpg|thumb]]

* FOV – field of view;
* View movement – group of inputs that controls view movement between preset views:
** Transition time – time to move camera from current position to preset position.
* View adjustment – group of inputs that controls view adjustment behaviour:
** Linear velocity – translational velocity of camera in meters per second,
** Angular velocity – angular velocity of camera in degrees per second.
** Lowpass filter – "smoothness" of the camera movement.
* Mouse look – group of inputs that controls mouse look behaviour:
** Mouse sensitivity – self explanatory,
** Lowpass filter – "smoothness" of the camera movement.
* "Apply" saves current camera position (does not write to disk).
* "Cancel" – closes the dialog (current camera position will not be saved).

== Controls ==
{{ WIP }}

== Current status (Jul 2014) ==
'''Objective'''<br />
Three FlightGear views registered using default view manager (throught view.nas): {{progressbar|50}}
# FGCamera cockpit view.
# FGCamera aircraft view.
# FGCamera world view.

'''Features'''<br />
FGCamera cockpit view:
# Arbitrary number of preset views. {{progressbar|50}}
# Manual camera rotations and translations. {{progressbar|70}}
# Smooth/discrete transition between preset views. {{progressbar|50}}
# Dynamic view movement. {{progressbar|20}}
# Random camera movement (effects). {{progressbar|40}}

FGCamera aircraft view:
# Arbitrary number of preset views. {{progressbar|50}}
# Manual camera rotations and translations. {{progressbar|60}}
# Smooth/discrete transition between preset views. {{progressbar|50}}
# Random camera movement (effects). {{progressbar|40}}

FGCamera world view:
# Arbitrary number of preset views. {{progressbar|90}}
# Manual camera rotations and translations. {{progressbar|50}}
# Smooth/discrete transition between preset views. {{progressbar|70}}

== Gallery ==
{{#ev:youtube|Ow30k9WJSeI}}

In-flight preview (camera enabled/disabled several times using keyboard):

{{#ev:youtube|JfHf1OG7-TQ}}

Added basic dynamic head movement:

{{#ev:youtube|cJEg5nWm4gw}}

Flight in turbulence:

{{#ev:youtube|kyMfg9g8sV8}}

First release. Pre-configured for Piper Cub.

{{#ev:youtube|YsXa6ZWNU3o}}

Preview of headtracker inputs handling.

{{#ev:youtube|iRPAAnjYmkI}}

Improved random camera movement:

{{#ev:youtube|BlH7AgUFC5M}}

Using random camera effects to trigger sound effects:

{{#ev:youtube|x-JPzLox-gI}}

== POV hat binding example ==
<syntaxhighlight lang="xml">

<axis>
<number>
<mac>7</mac>
<unix>7</unix>
<windows>6</windows>
</number>
<desc>View Direction</desc>
<binding>
<command>property-scale</command>
<property>/data/hat-H</property>
<factor type="double">-1.0</factor>
</binding>
<binding>
<command>nasal</command>
<script>
<![CDATA[
var hat_H = getprop("/data/hat-H");
fgcamera.point.adjust("h", hat_H);
]]>
</script>
</binding>
</axis>

<axis>
<number>
<mac>8</mac>
<unix>8</unix>
<windows>7</windows>
</number>
<desc>View Elevation</desc>
<binding>
<command>property-scale</command>
<property>/data/hat-V</property>
<factor type="double">1.0</factor>
</binding>
<binding>
<command>nasal</command>
<script>
<![CDATA[
var hat_V = getprop("/data/hat-V");
fgcamera.point.adjust("p", hat_V);

]]>
</script>
</binding>
</axis>
</syntaxhighlight>

== Used TrackIR and PPJoy (virtual joystick) combination ==
<syntaxhighlight lang="xml">
<?xml version="1.0"?>

<PropertyList>
<axis n="0">
<desc>6DOFYaw</desc>
<tolerance>0.00001</tolerance>
<binding>
<command>property-scale</command>
<property>/sim/TrackIR/heading-deg</property>
<factor type="double">-180.0</factor>
</binding>
</axis>

<axis n="1">
<desc>6DOFPitch</desc>
<tolerance>0.00001</tolerance>
<binding>
<command>property-scale</command>
<property>/sim/TrackIR/pitch-deg</property>
<factor type="double">-100.0</factor>
</binding>
</axis>

<axis n="2">
<desc>6DOFRoll</desc>
<tolerance>0.00001</tolerance>
<binding>
<command>property-scale</command>
<property>/sim/TrackIR/roll-deg</property>
<factor type="double">-100.0</factor>
</binding>
</axis>

<axis n="3">
<desc>6DOFX</desc>
<tolerance>0.00001</tolerance>
<binding>
<command>property-scale</command>
<property>/sim/TrackIR/x-m</property>
<factor type="double">-0.5</factor>
</binding>
</axis>

<axis n="4">
<desc>6DOFY</desc>
<tolerance>0.00001</tolerance>
<binding>
<command>property-scale</command>
<property>/sim/TrackIR/y-m</property>
<factor type="double">0.5</factor>
</binding>
</axis>

<axis n="5">
<desc>6DOFZ</desc>
<tolerance>0.00001</tolerance>
<binding>
<command>property-scale</command>
<property>/sim/TrackIR/z-m</property>
<factor type="double">0.5</factor>
</binding>
</axis>

</PropertyList>


</syntaxhighlight>

== Installation ==
Download: https://drive.google.com/folderview?id=0B7ZpQgmbsSZGcTZ4SWQxa0FIUEU&usp=drive_web

# Put "fgcamera" folder into "../FlightGear/data/Nasal/";
# Set "fgcamera_cfg.xml" as flightgear's config (use advanced settings of fgrun);
# Copy contents of "/Cub" folder into "../FlightGear/data/Aircraft/Cub/". (Make copies of original files before overwriting).

Number keys 1, 2, 3, 4, 5 selects cameras. Key 8 toggles FGcamera on/off. Arrow keys and PageUp/PageDown keys moves camera.

'''NOTAM to People using keyboard to fly (with or without mouse):''' throttle keys aren't working with the camera.

[http://forum.flightgear.org/viewtopic.php?f=6&t=21685&start=30 FGCamera forum thread]

[[Category:Recording]]
[[Category:Nasal]]
[[Category:FlightGear add-ons]]

Talk:North American P-51 Mustang

2014-08-11T13:59:24Z

Jarl Arntzen: Is there a working download link?

Congratulations!<br />
This is a really good looking and very detailed aircraft. Though it's unusable on not close to high-end systems. It's cutting FG's frame rate to 10 to 15 fps where it normally has more than 30. Even worse, it not even has a downgraded version in AI/Aircraft. If some other pilot shows up on MP with the p51d my FG suffers from the worst lags ever, making it completely unusable.
$ du -hs Aircraft/p51d/
1.1G Aircraft/p51d/
What the frell!? FG is a simulator which renders the scene in real-time not an animated 3D movie which has 25 times the time to calculate rendering. I am not able to comment on the fdm. Even though it might be good, any fdm goes bad at that frame rate.<br />
[[User:Flughund|Flughund]] ([[User talk:Flughund|talk]]) 12:32, 10 August 2014 (UTC)

:Calm down! Hal V. Engel made several announcements about the heaviness of this aircraft. And compared with other aircraft like 777, computer perfomance is even equal.
:Compared with commercial sims like X-Plane and FSFX vertice numbers and details are even in a similar range. Nethertheless, some optimations is always appreciated.
:What are your computer specs?
--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 15:24, 10 August 2014 (UTC)

:: Hi Heiko, thanks for the reply.
:: Don't worry, I am way too lazy to be really upset, just expressed my disappointment of not being able to fly the p51d anymore and that it kills the MP fun when another pilot shows up with it. Specs of my system can be found [http://beggabaur.onpw.de/wiki/index.php?title=FG_backtraces#System_info here]. Anything but up to date, I know, though I am certain there are many FG users with an even less powerful one.
:: I can see why people do want eye-candy, however wouldn't it be possible to preserve the old version? Btw, comparing it to other overdone models or even other sims is not something I count as a criterion. I am not a 3D modeler so I am not really able to make suggestions on how to improve the model. But is it really necessary to model every single tiny detail? Like little holes in the fuselage or the interior of the gear housing. Most of those details can be done by a good texture.
:: But don't mind users with lower spec systems, they'll find a way. I've looked closer at the situation and decided to use the old version of the Mustang as an AI model and switch to another cool, powerful taildragger for flying.
::[[User:Flughund|Flughund]] ([[User talk:Flughund|talk]]) 16:55, 10 August 2014 (UTC)

:: Hello
:: So it looks like we have a volunteer to create an AI version of the exterior model or am I mistaken? If users want things to get better they need to do more than complain. After all I have put literally 10's of thousands of hours of work into this aircraft. There have only been a few who have volunteered to help and most of them didn't do anything at all (other than waist my time). Literally the only things in the current model that were produced by a volunteer are the rudder pedals and related linkage. New rudder pedals will be made sometime soon based on factory blue prints (the existing ones are not very accurate) and I expect this to take perhaps 10 to 12 hours to do. So volunteers are responsible for literally less than 0.1% of this aircraft.

:: The new exterior model only affected my frame rates by about 5% compared to the old external model but I am running modern high end hardware but with the eye candy near max and I am still seeing frames rates > 55FPS and it often locks onto vsync, which is 60FPS, on a 2560x1600 display (IE. the resolution significantly increases the GPU load compared to a more normal monitor size) at high LOD airports. I am also using the 8Kx8K textures rather then the default 2Kx2K textures. So this is a worst case setup.

:: A suggestion that might help out. How old is the version are you running? The last version I pushed had texture sizes defaulted to 2Kx2K which should work on most hardware. This setup was pushed only a few days ago so there is a significant possibility that you are using a version that predates this change. Earlier versions have only 8Kx8K textures and these would definitely cripple older/lower end hardware even if, as is the case with your hardware/drivers, the 8k textures are supported. The latest version is setup to allow you to change texture resolution/size although this does require you to do some manual file copying. This is to allow users to adjust texture size to their hardware capabilities both high and low end. You can choose 1K, 2K, 4K or 8K textures for both the livery and the effects textures - if you have 1K, 2K, 4K and 8K directories in the Models/Livery and Models/Effects/Textures directories you are using the 2K textures. I have found that using the same resolution for both the effects textures and the livery textures seems to perform better on my hardware and look cleaner (IE. crisper details). I have also found that even on my high end hardware that there is a noticeable increase in frame rate going from 8K to 4K textures but not going to lower resolution textures. But again this is on very high end hardware so I would expect lower end hardware to show an even bigger frame rate hit with the large textures. Lower end/older hardware might benefit from going all the way down to the 1K level but I don't have any way to test this. However I did make it possible for users to select these lower resolution textures.

:: The number of vertices in the exterior model is significantly higher than the old model at around 100K (the old one is about 15K) but compared to the scenery (which can have millions of vertices) this is a relatively small number. From what I have read the 777 is slow on very high end hardware were as the frame rate hit of the P-51D on high end hardware is relatively small compared to the old exterior model. So it is definitely "lighter" than the 777 or the Extra 500 but there is definitely older/lower end hardware that it not up to the job of running the new P-51D. I don't know were the cutoff line is since I don't have a bunch of old hardware laying around to do testing on. Also various versions of this have been in git for sometime now and one responsibility of users is to do testing well before the release date. If this feedback had happened months ago there might have been time to test some things to see where the bottle neck is on low end hardware and make some adjustments. At this late hour this will not be possible before the 3.2 release which is days away. I am not saying that this can not be made to run better on lower end system only that it takes some effort and time to do that and this includes some effort from those with lower end hardware to help figure out what the issues are and to test fixes. This is an on going issue in the FG community - IE. users with low end hardware complaining about performance but being unwilling to help resolve the issues. Not saying that this applies to you and perhaps you are an exception to the rule.

:: As to your system hardware. It is not even close to being "not close to high-end systems" although in it day it was "close to a high end system" and I think clearly stating that it is very old and by modern standards very low end is in order. This is lower end hardware than I had 10 years ago so it definitely has it's limitations and may not be up to handling higher end models like the P-51D. My older hardware would only run the FG v2.4 P-51D with the eye candy turned down significantly at around 25FPS when running FG 2.4 with scenery 1.0 and a 1600x1200 monitor. This is just barely useable IMO. Going from scenery 1.0 to 2.0 had a significant frame rate hit on my high end system and I shutter to think what it would have done to my old system.

:: Aircraft devs (and the scenery devs as well) are caught between a rock and a hard place on this because one group of users is always complaining about aircraft (scenery) not being detailed/accurate enough and those with lower end hardware are always complaining that the high end aircraft (scenery) don't run well on their systems. Basically users can have either detailed accurate models or models that run well on older/lower end hardware but having both is very difficult, at best, if not impossible. After all none of us have magical powers and I can't just will your graphics card to have more CUDA cores. Again there are likely some optimizations that can be done to the new P-51D to make it run on a wider range of hardware and I suspect that your hardware is very close to the line between can and can't be made to work OK.

:: On the other hand eventually you and other users with low end/old hardware will be replacing their systems and almost anything purchased to replace it, as long as it has at least a mid level graphics card, should run the P-51D nicely but perhaps not the 777 or Extra 500 and perhaps not with full eye candy. Over time fewer and fewer users will have low end/older hardware and this is a major consideration for aircraft devs. In fact at some point my hardware is likely to be considered old/low end so this is a cycle we all go through and at some point all of us need to do hardware upgrades even if we don't want to.

:: Should I do a bunch of work to create something that works on low end/old hardware but is really not a big improvement over the existing models and that will eventually need to be redone or should I look to the future and make something that will hold up over a longer time frame and will run nicely on mid (IE. $100 graphics card) to high end current hardware? After all I have over 600 hours into the new exterior model and it is still a work in progress (meaning it needs a lot of work to be "complete") - why would I do that much work to produce something that is not a big upgrade to the existing models? I started working on the new exterior model about 10 months ago so I will likely have 1 1/2 years into this effort before I consider it to be "done" and I have averaged close to 20 hours per week on this. This is a huge undertaking that I don't want to repeat anytime soon. In fact I think the current external model will hold up well for several decades and will likely out live me.

:: Also I work for a software company and the software I work on is based on certain minimum hardware and system specs. If the users hardware does not meet that minimum spec and they call in with an issue they are told to upgrade their hardware and system software as the first step in the support process. That minimum spec is way newer and higher end than your hardware so expecting to run current high end software (which is more or less what the new P-51D is) on your hardware is not a realistic expectation and most commercial software companies support people would basically LOL and then tell you to upgrade your hardware if such a request is made.

:: The wheel well details are only about 1% to 2% of the total vertices of the exterior model. These are all low poly models (some of these models are a few as 12 vertices for example). The same thing is true for what holes exist in the exterior. These are at most a few hundred vertices total and are well under 1% of the vertices in the model. So these things will have almost no impact on frame rate.

:: As has been pointed out on the forums many times there is nothing stopping users with low end hardware from using older lighter models like the 3.0 P-51D model which will run just fine on FG 3.2 or FG 2.4 or anything i between. Just download it from the 3.0 aircraft page and install it in place of the new one. You can do this going all the way back to 2.4 aircraft if you need to. "however wouldn't it be possible to preserve the old version" yes it has been preserved just get it from the right location and install it as has been pointed on the forum MANY MANY times. But maintaining the old version in place beside the new work is something I will not do as it significantly increases the maintenance overhead for no reason and in the process slows down the rate at which improvements can be made.

:: If you are limited to running very old hardware (for what ever reason) then you should be aware that you may have to run older software that is suited to that hardware. That applies to many things in addition to FlightGear aircraft. From a flying point of view there is very little difference between the 3.0 version and the 3.2 version of the P-51D since the FDM, systems and cockpit are almost exactly the same although all of these have had some, mostly minor, changes for 3.2. After all the upgrade project is aimed at the exterior model. Future plans do include significant upgrades to the cockpit to make it more accurate (probably about the same LOD however) since the current cockpit models are more or less eye balled from photos rather than being based on factory blue prints and are not very accurate. I would also be interested in how the 3.0 version runs on your hardware since it appears that you have not run the older versions based on you comments. IE. is the older version really 2 to 3 times as fast on your hardware?

:: If you are actually interested in helping out let me know and we will figure how to make that possible. Even if it is just to be a "low end system" tester something that FG needs way more of in general if low end systems are going to be supported going forward. After all we can't fix the issues with low end systems if the people with these systems refuse to help with diagnostics and testing.

:: Also I experienced a lot of issues with the Blender to ac3d exporter and one of these has to do with parented objects not being correctly exported (IE. the export moved and rotated these objects in what appeared to be random ways). As a result, currently, the objects involved in the livery stuff are not correctly parented. I know that this has some performance implications. I would like to figure out a good way to fix this but so far have not been able to locate the information needed to do this is a way that is not a huge amount of work (to redo work that I already did). This could have a significant impact on users with low end systems but on my system it seems to impact how long it takes to start up the sim and how long it takes to switch liveries. There is a rumor that the solution to this issue was talked about on the dev list but I have not been able to locate this information. If anyone knows how to solve this issue please let me know.

--[[User:Hvengel|Hvengel]] ([[User talk:hvengel|talk]])

:::Hi, sorry, but you are falling in the same trap the 777 modeller did, although one order of magnitude lower. I'm not saying your work isn't great (or the 777), I'm saying it's not ok for ''realtime'' rendering, while it would be a killer asset on a CG movie set, or in a 3d-printing shop. You've so far fallen in the huge texture trap while they fell into overly heavy vertex counts and "over modelled details that never end up visible" trap.

:::'''8kX8k''' textures are '''overkill''', unless they are a proper '''texture atlas''' and the whole model uses just that one texture. Keep in mind that that texture will be uncompressed (since the .dds format is effectively banned), then mipmapped (which makes it use 1.5x system/video memory than the original uncompressed texture) and it's a waste of system and video ram, not to mention the time spent on CPU to generate the mipmaps, which will cause huge freezes to any system when your aircraft joins any MP session.

::: Before anyone comments, yes the global water depth-map is 16kX8k, but that was necessary to have proper detail, and it's only one texture used by any "Ocean" tile in the world. And now with Stuart's changes to the materials handling, splitting it into 4 textures becomes possible and worth investigating.

:::OSG has its builtin LOD/Decimation, any individual "feature" that would be rasterized to less than 8px (default, could be set to an arbitrary size) will be culled away. Everybody's whining for LOD, but they forget one essential thing, LOD comes at a cost (roughly speaking 1.5x increase in memory usage, both system and video, so if your model is already 'heavy', LOD won't help, it will actually make things worse; either that or thrashing as you load LODs individually if you went that route).

:::There are a few very "cheap" and effective strategies to optimize your model. Biggest wins come from merging all "static" meshes into one, and using one single texture sheet (so called atlas) for the whole model (except of course transparent parts/textures that need to be separate) . Then clean up your textures, don't leave alpha channels in opaque textures (causes unneeded overdraw and depth testing, not to mention weird culling/transparency bugs; I'm talking about the diffuse texture, not the additional ones assigned/used by effects). Then you can look into optimizing vertex/tri count, and there you can start with removing faces that will never be seen. Then you can look into detail optimizing, like what features are easier and cheaper to do via a texture+normalmap vs. what can be modeled. It's all smoke and mirrors, and the fewer resources your result needs the better, even if that means that it's no longer 100% accurate (irrespective of what GPU it ends up on)

:::BTW, minimal system requirements for fg are an OpenGL2.1/GLSL1.2 capable card, period. That's what it needs to run, until further notice (a port to OpenGL3.1+ will have to be done sooner or later). That means a generation 8xxx nVidia card or the ATI equivalent (I'm not even going to discuss the IGP solutions as they're not worth it). They're by far not current cards, but they can and should handle it very well, if things are properly optimized. (Would it interest you if I told you I can run trees and random buildings at density 2.9 on an 8800GT with minimal framerate impact? Oh yeah, with dense 'grass' generated nearby too? This requires minimal changes to the source, but its not really prime-time ready yet)

:::Please note that above I'm talking about 'optimization', and not about simplified/featureless models/textures/etc. for "low end specs". What you're doing with a "modern" GPU is simply offsetting the rather huge unoptimized part with raw "power", and that's not ok any way you look at it. (And yes, this optimization will help the higher end GPUs too, as they will be able to cram even more stuff in the scene, or do some extra interesting things without choking). And frankly, the fact that FG can't run at a steady vsync-locked 60fps on that system, would ring lots of alarm bells if I were you.

:::As to the issue with parenting in blender. You have to reset your objects origins and make them all have a 0 offset to the parent. '''Shift+c''' to reset 3d cursor to scene origin (0,0,0). Select the parent -> '''Object''' -> '''Transform''' ->'''Origin to 3d Cursor'''. Then with the parent still selected-> '''Shift + g''' -> '''Children''' (to select all children objects). '''Alt+p''' -> '''Clear parent and keep transform''' (to clear the "wrong" parent relationship), then keeping all the children selected '''Object''' -> '''Transform''' -> '''Origin to 3d Cursor'''. Then with the children still selected, '''shift select''' the parent, '''ctrl + p''' -> '''Object''' (to reparent them).
:::'''Do not''' parent '''glass''' and/or other '''transparent objects''' to the main parent. Also if using '''different effects''' on different objects, those with the different effect '''cannot be''' parented to the main parent (they will have their effect '''overwritten''' by the parent's)
:::[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 01:51, 11 August 2014 (UTC)

:::P.S. The Extra500 is a very special case, and its performance issues have nothing to do with a detailed model on old hardware (like some would like you to think), but there the nasal beast rears its ugly head and starts biting ;) (it runs just as bad with a cube replacing the 3d-model)

Hm... looks like the download link does not work...
--[[User:Jarl Arntzen|Jarl Arntzen]] ([[User talk:Jarl Arntzen|talk]]) 13:59, 11 August 2014 (UTC)

Talk:FlightGear Newsletter December 2013

2014-01-06T21:41:57Z

Jarl Arntzen: Cleaning up formatting

Hello, I'm translating the newsletter and I have a doubt with the concepts "stub" and "skeleton" used in "Wizard-based Aircraft Creation" section, are these used as C++ concepts?. Thanks.

Mmmm, I think "Usability Improvements" subtitle must be deleted or this is not in the right place.

{{unsigned|07:03, 5 January 2014‎|Wallkon}}

: Hi,
: you were correct about "Usability Improvements". I've removed that heading.
: I don't know about the concepts, best to ask Hooray, the author of that section. In general, "stub" refers to a (short) example/draft that needs to be further extended before it can be used. "Skeleton" probably refers to a simple (file/folder) structure, consisting of the essential parts to make an aircraft fly in FlightGear.
: Cheers, [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 13:47, 5 January 2014 (UTC)
: PS: Please sign messages on wiki talk pages with <nowiki>~~~~</nowiki>

::: Hi Wallkon, first of thank you -once again- for doing this, translating the newsletter is really appreciated, and we really need more contributors like you !
::: Regarding the terms you mentioned, Gijs is actually right. A [https://en.wikipedia.org/wiki/Skeleton_(computer_programming) skeleton] is basically a "template" that can be filled in and parameterized, a [https://en.wikipedia.org/wiki/Method_stub stub] is a placeholder that waits to be adopted and extended by others. So this is not really about C++ or Nasal, these are just words to indicate that something only just got started and needs to be extended to be useful (stubs) or that something is just a generic template that is not specific to a particular use-case, i.e. needs to be customized. HTH & Thanks again for all your contributions here! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:42, 5 January 2014 (UTC)

Hello, could you tell me what is the meaning of cc: in the following sentence "Just cc: me if you do". I guess this is related to "carbon copy" used in e-mails, but I am not sure.

Thanks in advance. [[User:Wallkon|Wallkon]] ([[User talk:Wallkon|talk]]) 18:45, 6 January 2014 (UTC)

== Small headline issue ==

May I humbly request that the level-2 headline

'''<nowiki>== Wizard-based Aircraft Creation ==
</nowiki>'''

Is changed to a level-3 headline

'''<nowiki>=== Wizard-based Aircraft Creation ===</nowiki>'''

At least on mobile it currently seems like '''Wizard-based Aircraft Creation''' is a whole separate category, which doesn't reside under '''Development news''' at all and that the following level-3 headlines actually reside under '''Wizard-based Aircraft Creation''' not '''Development news''' as they really are.

Confusing on mobile.

Kind regards
[[User:Jarl Arntzen|Jarl Arntzen]] ([[User talk:Jarl Arntzen|talk]]) 21:38, 6 January 2014 (UTC)

Talk:FlightGear Newsletter December 2013

2014-01-06T21:38:29Z

Jarl Arntzen: /* Small headline issue */ new section

Hello, I'm translating the newsletter and I have a doubt with the concepts "stub" and "skeleton" used in "Wizard-based Aircraft Creation" section, are these used as C++ concepts?. Thanks.

Mmmm, I think "Usability Improvements" subtitle must be deleted or this is not in the right place.

{{unsigned|07:03, 5 January 2014‎|Wallkon}}

: Hi,
: you were correct about "Usability Improvements". I've removed that heading.
: I don't know about the concepts, best to ask Hooray, the author of that section. In general, "stub" refers to a (short) example/draft that needs to be further extended before it can be used. "Skeleton" probably refers to a simple (file/folder) structure, consisting of the essential parts to make an aircraft fly in FlightGear.
: Cheers, [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 13:47, 5 January 2014 (UTC)
: PS: Please sign messages on wiki talk pages with <nowiki>~~~~</nowiki>

::: Hi Wallkon, first of thank you -once again- for doing this, translating the newsletter is really appreciated, and we really need more contributors like you !
::: Regarding the terms you mentioned, Gijs is actually right. A [https://en.wikipedia.org/wiki/Skeleton_(computer_programming) skeleton] is basically a "template" that can be filled in and parameterized, a [https://en.wikipedia.org/wiki/Method_stub stub] is a placeholder that waits to be adopted and extended by others. So this is not really about C++ or Nasal, these are just words to indicate that something only just got started and needs to be extended to be useful (stubs) or that something is just a generic template that is not specific to a particular use-case, i.e. needs to be customized. HTH & Thanks again for all your contributions here! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:42, 5 January 2014 (UTC)

Hello, could you tell me what is the meaning of cc: in the following sentence "Just cc: me if you do". I guess this is related to "carbon copy" used in e-mails, but I am not sure.

Thanks in advance. [[User:Wallkon|Wallkon]] ([[User talk:Wallkon|talk]]) 18:45, 6 January 2014 (UTC)

== Small headline issue ==

May I humbly request that the level-2 headline
== Wizard-based Aircraft Creation ==

Is changed to a level-3 headline
=== Wizard-based Aircraft Creation ===

At least on mobile it makes it seem like "Wizard-based Aircraft Creation" is a whole separate category, which doesn't reside under "Development news" at all and that the following level-3 headlines actually reside under "Wizard-based Aircraft Creation" not "Development news" as they really are.

Confusing on mobile.

Kind regards
[[User:Jarl Arntzen|Jarl Arntzen]] ([[User talk:Jarl Arntzen|talk]]) 21:38, 6 January 2014 (UTC)

Talk:FlightGear Newsletter January 2013

2013-02-16T14:05:19Z

Jarl Arntzen: Question about the availability of procedural textures

I'm a little puzzled about a slight difference between the newsletter content and the Changelog:

===== The January newsletter says: =====
"The texturing procedure is easily configurable via materials.xml and combined with regional texturing allows for a much improved experience for low-level flights or helicopter trips away from airfields. ''Note that this feature will not be available for the 2.10 release, as it requires still some testing.''"

===== The 2.10 Changelog says: =====
"High resolution close-up texturing effects with up to 10 cm detail resolution and dynamically added bumpmap for low-level flight and better depth perception."

What's correct?
I know I can just download and test this but in case it doesn't work on my computer I'd like to know if it's really supposed to work so I can file a bug, if needed.

--[[User:Jarl Arntzen|Jarl Arntzen]] 14:05, 16 February 2013 (UTC)

Talk:FlightGear Newsletter January 2013

2013-02-16T14:04:15Z

Jarl Arntzen: Question about the availability of procedural textures

I'm a little puzzled about a slight difference between the newsletter content and the Changelog:

===== The January newsletter says: =====
"The texturing procedure is easily configurable via materials.xml and combined with regional texturing allows for a much improved experience for low-level flights or helicopter trips away from airfields.
''Note that this feature will not be available for the 2.10 release, as it requires still some testing.''"

===== The 2.10 Changelog says: =====
"High resolution close-up texturing effects with up to 10 cm detail resolution and dynamically added bumpmap for low-level flight and better depth perception."

What's correct?
I know I can just download and test this but in case it doesn't work on my computer I'd like to know if it's really supposed to work so I can file a bug, if needed.

--[[User:Jarl Arntzen|Jarl Arntzen]] 14:04, 16 February 2013 (UTC)

Howto talk:Multi-computing FlightGear

2013-02-08T23:16:41Z

Jarl Arntzen: Created page with "Wow. I just got some old computers from work. I'll put them to use and try this as soon as possible. <br /> --~~~~"

Wow. I just got some old computers from work. I'll put them to use and try this as soon as possible.
<br />
--[[User:Jarl Arntzen|Jarl Arntzen]] 23:16, 8 February 2013 (UTC)

Scripted Compilation on Linux Debian/Ubuntu

2013-02-03T17:50:41Z

Jarl Arntzen: /* Clarification about ability to build only part of the system.*/

==Description==
The following script takes care of downloading and compiling FlightGear from the git repositories with just one command execution for both 32-bit and 64-bit Debian based systems (Debian, Ubuntu). Pre-existing installed version (if any) of FlightGear are not touched at all since the script builds and installs everything under the directory in which it is launched. You can choose between building all or only specific tools and applications. For redhat-based systems (Fedora, CentOS) you may want to check out [[CentOS]].

Necessary packages are installed via the apt-get system while libraries not included in the repositories are downloaded and compiled on the fly (i.e. [[Plib]], [[Simgear]] and [[OSG]]).

For Hints on Using a RPM based distribution like CentOS, please see [[CentOS]]

=== Disk Space Requirements ===
As of 02/2013, this script will by at least require 24-30 gb of disk space, note that this includes the downloaded source trees and the build files, but also the fgdata checkout (which accounts approx. for 50% of the whole thing).

=== List of compiled programs ===
The script is able to download and compile:
* FlightGear (And all the data needed to use it)
* [[Fgrun]]
* [[FGCOM]]
* [[FGComGui]]
* [[FGo!]]
* [[FGX]]
* [[Atlas]]
* [[Terrasync]]
* [[FlightGear HLA support (High Level Architecture) | OpenRTI]]

==== Updated list of programs compilation status ====
Keeping in mind that this script compiles bleeding edge software versions, using latest debian derivered distros, it can happen that the program that was successfully compiling last week, today does not.<BR/>
This is a list of what does and does not compile as much updated as possible.<BR>
Date: 19 November 2012
* FlightGear ... OK
* [[Fgrun]] ... OK
* [[FGCOM]] ... OK
* [[FGComGui]] ... OK
* [[FGo!]] ... OK
* [[FGX]] ... OK
* [[Atlas]] ... COMPILATION ERROR
* [[Terrasync]] ... OK
* [[FlightGear HLA support (High Level Architecture) | OpenRTI]] ... OK

== Download ==
You can download the script here:
* Primary site: [http://www.gitorious.org/fg/fgmeta/blobs/raw/master/download_and_compile.sh download_and_compile.sh]
* Mirror: [http://assistenza.larasrl.net/brisa/fgfs/download_and_compile.sh download_and_compile.sh]

The script is maintained in the FlightGear main repository. Remember to update this script whenever a new FlightGear version is released, so that you'll be able to download the latest stable revision.

There is also another option for building FlightGear and all its dependencies in an automated fashion, please refer to: http://geoffmclane.com/fg/fgfs-052.htm

== Instructions ==
To run download_and_compile.sh, just save it in a directory called for example: ~/fgfs
then execute it (no need to execute it as root).

Here is for example a sequence of commands to get the script:
<pre>
mkdir ~/fgfs
cd ~/fgfs
wget http://www.gitorious.org/fg/fgmeta/blobs/raw/master/download_and_compile.sh
chmod 755 download_and_compile.sh
</pre>

You have two options now: build the latest ''stable'' FlightGear release or build the ''current development'' version (bleeding edge).

=== Build the latest stable FlightGear release ===
When executing the script, use the "-s" option to build the latest stable release:
<pre>
sh download_and_compile.sh -s
</pre>

=== Build the current FlightGear development version ===
When executing the script without any option, the latest development version is built.

'''Warning''': The development version changes on an almost daily basis. It provides the latest features, but is not always guaranteed to work reliably. If you're unfamiliar with software testing, you may prefer to use the latest stable release.

<pre>
sh download_and_compile.sh
</pre>

Once the script is finished, you will successfully get Flightgear and Fgrun installed in the ~/fgfs directory.

=== Launching FlightGear ===
To run your new git installation of FlightGear you have to launch the ''run_fgfs.sh'' command under the same folder, for example:
<pre>
cd ~/fgfs
sh run_fgfs.sh
</pre>

=== Launching Fgrun ===
[[File:fgrun-page2.jpg|thumb|right]]
For many users it's more comfortable having FlightGear launched by the graphical utility Fgrun which is installed as well in the same folder. You have to launch the ''run_fgrun.sh'' command, for example:
<pre>
cd ~/fgfs
sh run_fgrun.sh
</pre>

=== Launching Fgo! ===
[[File:Fgo01.jpg|thumb|left]]
This is a graphical utility written in [[python]], You have to launch the ''run_fgo.sh'' command, for example:
<pre>
cd ~/fgfs
sh run_fgo.sh
</pre>
Remember that the first time you run it, you have to go to preferences and set the binary and fgdata path (Do no set the working directory, you don't need it).

== Additional programs ==
If you wish to get all the other programs, you need to launch the script adding the "ALL" option to the command line:
<pre>
sh download_and_compile.sh ALL
</pre>
This, will also install FGCOM, FGComGui and Atlas

=== Launching FGCOM ===
FGCOM is the system used by FlightGear to simulate radio communications between users. Launch it using the ''run_fgcom.sh'' command:
<pre>
cd ~/fgfs
sh run_fgcom.sh -cs
</pre>

=== Launching FGComGui ===
FgComGui is a GUI wrapper to launch fgcom.
<pre>
cd ~/fgfs
sh run_fgcomgui.sh
</pre>

=== Launching Atlas ===
[[File:Atlas.jpg|thumb]]
Atlas provides a map for FlightGear, use it launching: ''run_atlas.sh''
<pre>
cd ~/fgfs
sh run_atlas.sh
</pre>

=== Launching Terrasync ===
Your FlightGear compilation comes with the Terrasync program too, so if you want to use it:
<pre>
cd ~/fgfs
sh run_terrasync.sh -S -p 5500 -d /folder/with/sceneries
</pre>
Where: ''/folder/with/sceneries'' is the folder containing the sceneries data.

Then launch fgfs with the '''--fg-scenery=/folder/with/sceneries --atlas=socket,out,5,localhost,5500,udp''' option

== Troubleshooting ==

=== Compilation errors ===
Here we are, no fear, if you wish to use programs from the cvs/svn/git repositories, you might face compilation errors that will prevent you to have a working copy of one or more of the programs provided by this script. What can be the causes that prevent us from successfully compiling? As far as I know those:
# Software developers introduce a new functionality with a new piece of code that prevents the compilation under your architecture, this can happen working with cvs/svn/git sources.
# The program refuses to compile because of a divergence in the libraries on which it depends. For example FlightGear might not compile because OSG has been modified, while OSG itself compiles fine, FG won't.
# One or more repositories are down and you can't get the library you need. (Both from cvs/svn/git or apt-get)

There is a simple solution to the above errors: wait and relaunch the script after some time (hours or days), if software developers repair or synchronize their code with the newly updated libraries (which generally happens eventually), your FlightGear will compile fine as if the previous error never took place.

Sometimes it happens that the script fails to compile only fgrun, fgcom or atlas, if you then see the run_fgfs.sh file it means that FlightGear installation was successful and you can safely run it.

== Options ==
The script by default (without any option) will only compile FlightGear and Fgrun. To make it compile all, you need to launch the script with the ''ALL'' parameter. i.e.:
<pre>
sh download_and_compile.sh ALL
</pre>

=== Compiling only one program ===
If you wish to recompile only one of the programs you can launch the script with one of the following parameters:
* PLIB (to compile and install only plib)
* OSG (to compile and install only OpenSceneGraph)
* SIMGEAR (to compile and install only Simgear)
* FGFS (to compile and install only FlightGear)
* DATA (to download / update only data files for FlightGear)
* FGRUN (to compile and install only Fgrun)
* FGO (to compile and install only Fgo!)
* FGCOM (to compile and install only Fgcom)
* FGCOMGUI (to compile and install only FgComGui)
* ATLAS (to compile and install only Atlas)

=== Fast updating ===
There is a second parameter ''UPDATE'' that allows you to just update your installation. i.e.:
This will only update FGFS
<pre>
sh download_and_compile.sh FGFS UPDATE
</pre>

=== Compiling last stable versions (Experimental) ===
Even if the script fetches data and sources from bleeding edge developers repositories (which sometimes do not compile), you can still force the script to download latest known versions of the software that were compiling successfully by adding the -s option.
<pre>
sh download_and_compile.sh -s
</pre>

How does it work? Inside the script there is a small list with latest known versions of successfully compiling revisions, it will download from svn/git those specific revisions, which have been found able to compile together.<BR/>
Warning: If you run this option inside a folder where you previously compiled fgfs, it will probably fail to compile, you better run the script with this option inside an empty folder or a folder whith the same fgfs version compiled previously.

=== Advanced options ===
* Skip download of packages using '''-p n''' option
* Skip compilation of programs using '''-c n''' option
* Skip retrieving software updates using '''-d n''' option
* Skip reconfigure (make clean) using '''-r n''' option

For example, if you are a developer and wish to quickly recompile and reinstall only your own modifications for FlightGear do this:
<pre>
sh download_and_compile.sh -p n -d n -r n FGFS
</pre>

this will only recompile modifications and reinstall them.

=== Multicore Acceleration ===
Using the option '''-j x''' (where x is the number of your CPU-Cores you wish to assign to the job) will speed up the whole compilation process considerably.

== Disk usage ==
Having both compiled program, source code, and data from git requires some hard disk space: It will take something like 13 GB of space.
If you don't have a fast machine, it will require several hours of compilation time.

[[nl:Compileren met een Script op Linux Debian/Ubuntu]]

Talk:Procedural texturing

2013-02-03T12:28:49Z

Jarl Arntzen: Question about how to test out autumn colors. What's the procedure?

BTW: How can we test out the autumn colors? Does it require custom scenery? I can not really see any settings for it in the UI. Does it take any parameters at run-time at all? Or is the time of year set at startup? I'd really like to test it out and maybe make some kind of promotional video.
<br />
[[User:Jarl Arntzen|Jarl Arntzen]] 12:28, 3 February 2013 (UTC)

I'd just like to say: Fantastic terrain images at the bottom of the page! I'm still failing to install TerraGear, but one day... :)<br />
[[User:Jarl Arntzen|Jarl Arntzen]] 18:15, 5 January 2013 (EST)

Talk:Procedural texturing

2013-01-05T23:15:59Z

Jarl Arntzen: Positive comment... :)

I'd just like to say: Fantastic terrain images at the bottom of the page! I'm still failing to install TerraGear, but one day... :)
[[User:Jarl Arntzen|Jarl Arntzen]] 18:15, 5 January 2013 (EST)