The Land xx class: Difference between revisions

Revision as of 12:34, 30 May 2018

A great deal of angst, frustration and misunderstandings surround would be map makers using animated buildings on their maps.

The very first, and very infamous misunderstanding is that your animated building opens doors when you place it in the game editor, but simply does not work when you bake it into a map (wrp).

For this magic to happen, you must have class land_nameOfP3d and model = NameOfp3d;

It is that simple.

class house_f; // almost always 
class land_my_great_building: house_f
{
    model=\some\location\my_great_building.p3d;
    ..... the rest doesn't matter
};

Note that you can have land classes for other p3d class 'types', and they are optional. But if you wish to use the unique and very special properties of class=house, you must have a land_xx to go with it.

It is that simple.

And for these animations to happen at all either in the in-game editor or otherwise, your p3d has to have it's geolod property set to class=house as a minimum. There are other, less used, animation class types, such as 'housesimulated' and 'fuelstation' but you are on pretty firm ground using class=house if you expect doors to open.

It is that simple.

A land_xx trigger list of all objects used on the map that *need* land classes to operate correctly is automatically baked into that wrp by pboProject. (Geolod class=house is the prime candidate, but there are other much less used class= types that pboProject also takes care of.)

if doors (eg) still won't open, then you don't have that land_xx class in any config.cfgVehicles in the game.

Under those circumstances, it's up to you to create one.

@@ Line 1: / Line 1: @@
 {{DISPLAYTITLE:The Land_''xx'' class}}
-Note: Time marches on. This document is obsolete BUT it still describes accurately WHY you have no icons or doors not opening in maps. PboProject now does all this transparently.
-if you STILL have un-opening doors etc, then there is NO class land_NameOfP3d  in any pbo, It's up to you, to provide one. Read how to below.
-----
-{{warning | A corrupted named property definition of  '''class<nowiki>=</nowiki>house''' in a models GEO LOD, can also cause '''land class not found''' - verify via Eliteness or ObjectBuilder in the source/MLOD p3d}}
 A great deal of angst, frustration and misunderstandings surround would be map makers using animated buildings on their maps.
@@ Line 36: / Line 29: @@
 ----
-Architecturally, and indeed, in the engine itself, the class name for an animated building is of no consequence. It can be named anything and will 'work'. This is sometimes encountered in arma2 where bis have used a different bis binarise to the one released to the community. For the community, bis binarise is not so kind to you. It has a primitive search facility that '''insists'''
+A land_xx trigger list of all objects used on the map that *need* land classes to operate correctly is automatically baked into that wrp by pboProject. (Geolod class=house is the prime candidate, but there are other much less used class= types that pboProject also takes care of.)
- nameOfp3d = class land_nameofP3d.
-And for this magic to happen, bis binarise must be able to locate the config.cpp where this land_xx is declared.
-When porting arma2 assets, whether genuine bis product, or other people's:
-*there may not be a corresponding land_xx. It was never coded. Or (much much much more likely)
-*you haven't told bis binarise where to look.
-pboProject from Mikero looks at the wrp that bis binarise produces, and checks whether or not '''every''' p3d with class=house has a corresponding land_xx.
-If some are missing you have several choices
-*remove or at least change the geolod property to something else using dep3d.exe. If you don't want animations or the p3d was wrongly classed.
-*use wingrep to locate where the config.cpp is on your p:\drive and tell pboProject about it. (so that bis binarise can go sniffing)
-*create your own land_xx class in your own config for those land_classes that genuinely do not exist.
-'''Hunting for land_xx:'''
-Because of the clever way config architecture works, the relevant land_xx can be \any\where  on the p: drive.
-Ordinarily, this is closely associated with the nameofP3d. Eg  \my\elephant.p3d ''probably'' has a \my\config.cpp  where the land_elephant class is declared. This isn't always the case and notably on large projects where a single config for a mass of p3d's could (and generally is) located \nearly\any\where.
-Bis binarise spends a large part of it's processing time locating it.
-By default, PboProject automatically 'guesses' which paths bis binarise must look in. It does a reasonable job but can never be perfect. The one thing it cannot do is tell binarise to look every\where. because your P drive is filled with crud and will crash binarise instantly (with you none the wiser).
+if doors (eg) still won't open, then you don't have that land_xx class in any config.cfgVehicles in the game.
-Secondly, it might not be immediately obvious, but due to land_NameOfP3d MUST = NameOf.p3d, there can only ever be one, single, unique instance of both this p3d, and, it's class name ''in the entire game''.
-You need to ensure that you have fully extracted every possible pbo that could contain your land_xx class before you create your own.
+Under those circumstances, it's up to you to create one.
 See also: [[Building Land Classes]]

The Land xx class: Difference between revisions

Revision as of 12:34, 30 May 2018

Navigation menu

Search