On 08.08.2011 11:31, thorsten.i.r...@jyu.fi wrote:
> It seems that there's then something I don't understand about the
> structure of the runtime-loadable modules - I was under the impression
> that all the stuff in the subdirectory is loaded upon request, but it
> seems that this hasn't been the case for me. Any ideas?

Well, there is one difference which you're probably not aware of. It has 
nothing to do with the run-time loading - it's a difference between the 
_individual_ Nasal files in fgdata/Nasal and files belonging to a common 
Nasal _module in general (no matter whether loaded at run-time or loaded 
at start-up using a "<nasal>" tag).

The individual Nasal files in fgdata/Nasal have an own namespace _each_. 
The namespace get's the name of the Nasal file itself. So if you have a 
"gui.nas" in the directory, then you can reference a symbol "foo" using 
"gui.foo".

Nasal modules also have a single namespace. But all files belonging to 
the module share this _single_ namespace. The name of their namespace is 
made from its directory (for the run-time loadable modules), or from the 
specific tag given below the <nasal> XML element, which are often used 
for a/c specific modules (e.g. <nasal><ufo>...</ufo></nasal> creates the 
ufo Nasal namespace in ufo-set.xml).

So each Nasal file in your "local_weather" module now shares the same 
namespace - which is "local_weather". When I moved your local weather 
files to an own Nasal module, it'd have been necessary to replace all 
"weather_tiles.XXX" and "compat_layer.YYYY" references to 
"local_weather.XXXX" or "local_weather.YYYY" references. Instead, to 
make life easier, I just added
   compat_layer = local_weather;
   weather_tiles = local_weather;
   ...
lines to your "compat_layer.nas" file. This creates aliases (variables 
really), so the old style references still work. You could do the same 
for the new Nasal file, i.e. add an
   cloud_definitions = local_weather;
But it would be cleaner to avoid the cheating altogether and just use 
"local_weather.*" references now.

Hope this explains how the module namespaces work.

cheers,
Thorsten

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to