Vamos a ver...
Yo quería tener los LIN (sobretodo) y algún que otro objeto (VOR, LLZ,...puede que alguna instalación ILS) haciendo uso del library (me parecía cómodo y "elegante") y tan sólo sustituyendo la parte visible (objeto 3D)
1.) Teniendo en cuenta que los objetos-3D: VOR, LLZ, antena ILS-GS son
atrezzo... ¿para qué demonios liarme tanto?... me explico.
Ese tipo de objetos-3D que "actúan" como radio-ayudas pertenecen a la carpeta NAVAIDS...una carpeta especial! Las frecuencias de las radio-ayudas, su orientación, su rango... todo eso va en el apt.dat de X-Plane... es "interno".
Los objetos -VISIBLES- para estas antenas se generan desde lo que hay en la carpeta NAVAIDS. Las sentencias REGION_DEFINE sólo afectan al 3D VISIBLE (objeto con vértices, caras, aristas y textura)... NO! a lo que viene dictado por el apt.dat (las frecuencias y demás características de la radio-ayuda de turno)
Parece que el REGION_DEFINE no afecta a los objetos involucrados en la carpeta NAVAIDS... de tal forma que
no limito un VOR o un LLZ a una zona concreta... ese objeto sustituiría a todos sus correspondientes en TODOS LOS AEROPUERTOS del mundo.
SOLUCIÓN:
anular el OBJ creado por X-Plane mediante una
sustitución con un OBJ vacío (mi OBJ-vacío NO ESTÁ en la carpeta NAVAIDS por lo que es susceptible de la instrucción REGION_DEFINE)... por contra... SITUAMOS -con WED- el OBJ -visible- que nos interese desde NUESTRA carpeta de objetos (o desde otra librería si así lo consideramos) personalizados con el modelo que consideremos oportuno en la posición donde esté el OBJ-vacío... que es la misma posición donde ANTES el X-Plane* te colocaba su antena o lo que fuera.
EXPORT lib/airport/NAVAIDS/ILS.obj objetos/ILS/LLZ/none.obj
EXPORT lib/airport/NAVAIDS/VOR.obj objetos/ILS/LLZ/none.obj
*Leyendo el library de X-Plane ("Resources/default scenery/sim objects/library.txt") vemos que hay una parte llamada PRIVATE que consta de (oh sorpresa!):
# NAVAIDS
EXPORT lib/airport/NAVAIDS/ILS.obj NAVAIDS/ILS.obj
EXPORT lib/airport/NAVAIDS/Marker1.obj NAVAIDS/Marker1.obj
EXPORT lib/airport/NAVAIDS/Marker2.obj NAVAIDS/Marker2.obj
EXPORT lib/airport/NAVAIDS/glideslope.obj NAVAIDS/glideslope.obj
EXPORT lib/airport/NAVAIDS/NDB_1.obj NAVAIDS/NDB_1.obj
EXPORT lib/airport/NAVAIDS/NDB_2.obj NAVAIDS/NDB_2.obj
EXPORT lib/airport/NAVAIDS/NDB_3.obj NAVAIDS/NDB_3.obj
EXPORT lib/airport/NAVAIDS/VOR.obj NAVAIDS/VOR.obj
Sobra decir que tales OBJ no se muestran en el WED (¿cambiando PRIVATE por PUBLIC?
) y son los que no son afectados por la regionalización.
2.) Olvidad todo lo anterior. Las líneas... un mundo aparte.
Definidas por el apt.dat de X-Plane. No son afectadas por el REGION_DEFINE. De tal forma que cualquier cambio/sustitución (a través de un library) en un tipo de línea afecta a todas las de todos los aeropuertos.
PROS: usar lineas propias (si se quiere, claro) o librerías externas
CONTRAS: no se renderizan en el WED (sí en el OverlayEditor) de tal forma que diseñas "a ciegas". Todas las líneas aparecen en el programa de color verde.
El WED es muy cómodo para diseñar... coges una línea amarilla, si quieres le pones luces verdes, azules, ambar... y voilà! Todo bien pintadito en la pantalla.
Para usar lineas personalizadas (propias o de alguna librería externa)... AHORA que tengo TODO el aeropuerto con sus líneas dispuestas y ordenaditas... debería "dibujar" encima/ como una referencia las líneas custom (que aparecen renderizadas en verde en WED) y luego eliminar u ocultar las que creé -lineas normales- con WED.
Y con las luces de líneas qué hacemos?... con esos STR. En el fondo son una llamada a un OBJ al que se le ordena una repetición. Aquí lo veo algo mas claro (veré si REGION_DEFINE funciona y me ahorro volver a dibujar).
Saludos
