Imagine a dat file which (likewise SHIII harbors) only contains a node skeleton that all the lighthouse parts will be attached to; one node for the rocky base, one for the ligthouse building, one for the lens/lamp, etc.
All these parts will be stored in an external library file and linked to the "skeletal" dat file through eqp files customized for each lighthouse. If need be, we can switch those parts on/off by date, using the usual Start and EndDate settings.
The same dat file can be shared by different lighthouse models set as "proxy clones", i.e. copies of a unit that use the same dat, zon, sim etc. files as their parent unit, but have customized cfg, eqp and sns files. If you have ever messed with SHIV or SH5, you will understand instantly what I am talking about, otherwise you will undesrtand when I send you the files.
What will be different from a lighthouse to the other, will be its unique eqp file, and the model parts that by mean of each eqp file will be linked to the common skeleton.
Let's talk about the vertical position of each lighthouse now. Onshore lighthouses will be placed directly on the land surface, and they wont pose any problem. As for offshore lighthouses, they are placed on the seabed, and we risk them to be totally submerged if the sea bottom is too deep at the desired position, or to stand too high if the is the sea bottom is too shallow. What I can do for overcoming the problem, is making the rocky base a bit higher than expectedly needed. If we notice that a lighthouse lays too low/high on the water surface, I will move the lighthouse together with the relative rock model a bit up/down using Wings3D. This method applies to unique lighthouses which are to be found in a single location on the map. For generic lighthouses the process will be similar, but since they will share the same 3D models, we wont be allowed to play with model coordinates, because what will be okay in a certain location, wont be possibly acceptable in another location. What we can do, is linking those models to customized skeletal dat files whose equipment linking nodes will have different heights, i.e. instead of moving up and down model coordinates, we will move up and down the posiotion of nodes that those models will be attached to.
In both cases, terrain editing will be desiderable and possibly needed if the diffrence between RL depths and in-game depths will be too high.
Answering your question about the CollisionableObject vs StaticObject controller: yes, as I stated before, after intensive testing in SH5 I can confirm that the latter can be placed on unit equipments as well as on terrain objects with no side effects that I know of. I have not tried placing it directly on an unit, but I guess it would work too.
The similarity of the two controllers is that they both make objects that they are attached to collisionable. End of the similarities. Beside the visible mesh, a CollisionableObject controller requires a collision mesh to work. No collision spheres nor damage boxes are involved. It is much simpler to use, but it won't cause objects to take damage from collisions, bullets or nearby explosions. That's why it is called static: it makes 3D objects as solid as a rock and, as a side note, there are some oddities related with its usage:
http://www.subsim.com/radioroom/show...postcount=3372
http://www.subsim.com/radioroom/show...22&postcount=4
LOL
