* new textures for EarthView ( https://forum.flightgear.org/viewtopic.php?f=5&t=29780&p=289106#p289106 )
* change location of earthview textures to Models/Astro/Textures/*
* change pale_blue_aug_??.png world tiles to Textures/world_??.png
* change clouds_??.png to Textures/clouds_??.png
* change corresponding xml accordingly
Looking back, it seems this typo was maybe present in
the 'initial commit'. In a quick local search I found
it present in a 2007 version 1.0.0 of fgdata ;=))
I guess not many use the xml <name> in any significant way!
I only stumbled across it using a perl script to verify
the input and output chunks match... when writing a
generic script...
Needs a lot of testing, but aircraft can be installed / changed and
location adjusted from within the sim. After some number of times the
sim will crash.
This enables using the http repository instead of the svn repository
for terrasync.
Fall back to svn by setting prop:/sim/terrasync/http-server to an empty string
Emesary is a simple and efficient class based interobject communcation system to allow decoupled disparate parts of a system to function together without knowing about each. It allows decoupling and removal of dependencies by using notifications to cause actions or to query values.
Emesary is all about decoupling and removing dependecies, and improving the structure of code. Using Emesary you can more easily define the what rather than the how. By using what is essential an event driven system it is easy to add or remove modules, and also for extra modules to be inserted that the rest of the aircraft knows nothing about (e.g. FGCamera or the Walker).
see: http://chateau-logic.com/content/emesary-nasal-implementation-flightgear
Emesary Multiplayer Bridge
--------------------------
There is also support for transmitting messages over MP which allows models to communicate with each other in a decoupled method using notifications. What happens is that bridged messags simply arrive at the Receive method of recipients in other models on other running instances without the need to do anything special.
see: http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear
AN/SPN-46 ACLS
--------------
The AN/SPN-46 is an ACLS implementation using Emesary. ACLS is the Navy's version of ILS.
The carriers have all been modified to have an AN/SPN-46 transmitter. The F-14 will be revised shortly to support this; for the F-14 it is a non-breaking change as the F-14 currently uses the TACAN channel and does it's own ACLS calculations. When the F-14 is revised it will mean that when approaching any carrier it is not necessary to retune the TACAN to get ACLS.
The AN/SPN-46 and ARA-63 (receiver) implementations both support the use of channels; but for the moment this is preset to use channel 2.
---------------------------------------------------------------------------
Emesary is a simple and efficient class based interobject communcation system to allow decoupled disparate parts of a system to function together without knowing about each. It allows decoupling and removal of dependencies by using notifications to cause actions or to query values.
Emesary is all about decoupling and removing dependecies, and improving the structure of code. Using Emesary you can more easily define the what rather than the how. By using what is essential an event driven system it is easy to add or remove modules, and also for extra modules to be inserted that the rest of the aircraft knows nothing about (e.g. FGCamera or the Walker).
see: http://chateau-logic.com/content/emesary-nasal-implementation-flightgear
The AN/SPN-46 is an ACLS implementation using Emesary. ACLS is the Navy's version of ILS.
---------------------------------------------------------------------------
There is also support for transmitting messages over MP which allows models to communicate with each other in a decoupled method using notifications. What happens is that bridged messags simply arrive at the Receive method of recipients in other models on other running instances without the need to do anything special.
This links together the generic MFD and the NavDisplay; it allows a fairly easy method to add a Map page to an MFD device.
----------------------
See: http://wiki.flightgear.org/Canvas_MFD_Framework
----------------------
Instantiate parameters:
1. pfd_device (instance of PFD_Device)
2. instrument display ident (e.g. mfd-map, or mfd-map-left mfd-map-right for multiple displays) - used to map to the property tree
3. layer_id: main layer in the SVG
4. nd_group_ident : group (usually within the main layer) to place the NavDisplay
5. [optional] switches - used to connect the property tree to the nav display. see the canvas nav display.
To add a canvas nav display page simply do
me.some_page = PFD_NavDisplay.new(me.PFD,"Situation", "mpcd-sit", "ID", "jtids_main");
This is for all of the files restored in edb2c9 and 5453fb. The new files have
been restored to their state at commit f739a7, the commit prior to the purging
of the Models directories.
This is for all of the files restored in edb2c9. The new files have been
restored to their state at commit f739a7, the commit prior to the purging of the
Models directories.
This follows from the thread:
http://thread.gmane.org/gmane.games.flightgear.devel/81852/focus=81859
All the $FG_ROOT/Models/* files found using a grep command in both FGData and
FGAddon and now missing in FGData were restored to their state at commit f739a7,
the commit prior to the purging of the Models directories. The command used
was:
grep -rI "Models/3ds\|Models/Agriculture\|Models/StreetFurniture\|Models/Structures\|Models/Sport\|Models/Power\|Models/Misc\|Models/Aircraft\|Models/Airport\|Models/Boundaries\|Models/Communications\|Models/Fauna\|Models/Military\|Models/Transport\|Models/Trees\|Models/Industrial\|Models/Residential"
