Quote:
|
Originally Posted by Anvart
I would like, that you have made a correct hierarchical tree of the interconnected objects for the best understanding of communications between objects ...
Example:
pic.1. Druck_LM1 is material (name of material - Type8) and cannot be root node ...
Common_Druck.tga is base bitmap for Druck_LM1 material ...
Gato_CR_LM1_LightMap.tga is lightmap for Druck_LM1 ...
...
And terminology... for example Controller (Type 10), Controller Parameters (Type 6)...
And many other things ...
|
The tree is as correct as it can be.
I won't put materials under the nodes they are used by, because a material is often used by more nodes on the same level. I want to keep the tree as clean as possible, and not have a material added to multiple parents... I've tried your suggestion a couple of weeks ago, and when viewing for instance the Gato interior, this became a huge mess.
There are other ways to show relationships (and I have some things planned), like navigable id's. So, for nodes that reference materials, you'll get a list of id's on the right that you can click. You'll have to trust me on this for now and see for yourself when I release it.
As far as terminology, this is debatable. I think some terminology used in the community was bad, and decided to use some new. 'Controller' is a bit non-descriptive if you ask me, but that's just me. I don't know, maybe if others complain to me as well
Quote:
|
Originally Posted by Seeadler
Good job 
Is it possible to read also the harbour.dat files in a correct way so that one can change the harbour model tiles with new models? |
Harbor_kit.dat is read without problems... Also, all files under \Terrain\Locations are read, and chunk type 11 (Placement) is editable.