World
Wide Guide | Knowledge Bank
| Kukushkin's Notebook |
Design Fundamentals
World
Wide Guide | Knowledge Bank
| Kukushkin's Notebook |
Design Fundamentals
FS5 allows more than one scenery to be active in
a given area. While each scenery alone normally works very well, their
co-operation often produces problems. Such problems are called scenery conflicts.
They can occur between different add-on sceneries, as well as between an
add-on scenery and the default scenery. Resolving them often becomes a headache
for the user. However, the scenery can be designed in a way that would avoid
such conflicts or make resolving them very easy. The easiest and the most
natural way for the user to help himself in case of a scenery conflict is
to change the order of layers in the scenery library. The scenery must allow
him to do this.
The most common conflicts are:
Conflicts with the synth scenery mostly occur when the scenery does not define its own synth tiles, but relies on the default scenery of FS5 or some other scenery instead. Both ground elevation and type differ in different versions of FS5. Also, there are many add-on sceneries that redefine the synth scenery for a large area and thus can cause conflicts too. If the scenery defines its own synth tiles, at least under its objects, it becomes much less vulnerable to conflicts with the synth scenery and also allows the user to resolve such conflicts. More details on this can be found in "How to design 2D landscapes".
Duplicate navaids are navaids that have the same frequency and are so close to each other that they both could be received from the same location. If such a frequency is tuned in, a database error occurs. Duplicate navaid conflicts often occur with the CD-ROM scenery of FS5.1CD, which contains many navaids, but can also be caused by add-on IFR sceneries as well. For this reason, it is impossible to predict which navaids are already present in the installation of FS5 the user possesses. This makes it impossible to define only those navaids that are not already present in other sceneries. The scenery should include either no navaids at all, or all navaids in the area covered. Conflicts between navaids are normally resolved using exclusion files, as described later in this section. Also, it is a good idea to place all navaids, including location markers, into a separate BGL file, thus giving the user the opportunity to remove them if they cause problems.
Duplicate objects appear when more than one scenery has a certain object. Most problems here are caused by duplicate runways, but other objects can theoretically also be duplicated. As with navaids, it is impossible to predict which objects are already present in the user installation of FS5, so the only solution is to disable objects from other sceneries using exclusion files.
FS5 cannot handle more than one dynamic scenery at the same time. This means it is impossible to add more dynamic scenery objects to an area that already has some dynamic scenery. However, the user may want to replace the dynamic scenery with his own or some other scenery, and should be allowed to do so. The dynamic scenery cannot be disabled using exclusion files, so the only solution is to put it into a separate BGL file. The user can then erase this file, if needed. Dynamic sceneries for different areas should be put into different files in order to allow replacing them in certain areas without affecting the rest.
The documentation supplied with the scenery should describe which files are to remove and why. Existing tools make development of dynamic scenery easy enough to be done by non-scenery designers, and figuring out how to remove existing dynamic scenery would most likely be the most difficult problem for them.
The main means of resolving scenery conflicts are exclusion files. Besides the coordinates of the exclusion area, each exclusion file has a 'flags' field that specifies which objects should be excluded. Different bits in flags allow exclusion of visual scenery, VOR/ILS, NDBs and ATIS messages. Other data, such as LandMe, location markers or synth scenery, cannot be excluded. The bit 0 (value 01h), when set, enables the exclusion of the visual scenery. It is performed by ignoring Area()blocks from lower priority scenery layers with center coordinates inside the exclusion area. The exclusion mechanism does not look inside Area()-blocks. For example, an Area()-block with the center outside the exclusion area can contain a RefPoint and an object inside the exclusion area. The exclusion mechanism would not prevent such an object from being drawn. However, in most cases exclusion of Area()s works very well. its additional bonus is memory freed from excluded Area()blocks.
Bits 1,2,3 (values 02h, 04h, 08h) control exclusion of VOR/ILS, NDBs resp. ATIS messages. These objects from lower priority scenery layers are ignored when their coordinates happen to be inside the exclusion area.
It is possible to combine multiple bits by simply adding or ORing corresponding values. For example, the value 0Eh (02h+04h+08h) can be used to exclude VOR/ILS, NDBs and ATIS messages without affecting the visual scenery. The scenery should exclude only information it really replaces or makes obsolete. For instance, a VFR-only scenery should not exclude any navaids, and a navaid-only scenery should not exclude any visual scenery.
The size of the exclusion area should be equal to the size of the area actually covered by the scenery, as opposed to the area specified in the scenery header, which is normally larger. Otherwise, objects from neighboring sceneries could disappear - another kind of a scenery conflict.
Because exclusion files only disable scenery in layers with lower priority, they allow the user to resolve conflicts in a very natural way - by adjusting layers in the scenery library. A scenery with a higher priority would disable underlying scenery with a lower priority, which is exactly what most users would expect it to do. Exclusion files can be generated by scenery compilers or other programs. Some programs for generating exclusion file, like AREAINCL, do not allow specifying the 'flags' parameter or explicit values for the exclusion areas. Their main purpose is to help novice users and they are not flexible enough to be used by a scenery designer.
The documentation supplied with the scenery should mention that the scenery already has exclusion files in order to prevent power users from building them. Also, the user might want to delete them if he prefers the scenery to be combined with underlying sceneries instead of replacing them.
Theoretically, some scenery conflicts cannot be resolved by redefining the synth scenery or using exclusion files. For example, there is no way to remove elevated surfaces. In such cases, the user can help himself only by disabling offending sceneries. However, such cases are extremely unlikely. Most unresolvable scenery conflicts are caused by a poor programming which prevents using the scenery library to resolve them.