Topic: Tribes/World file structure

Since our engine no longer cares whether a unit belongs to a tribe or the world, should we reflect this in our Lua directory structure?

This is what it currently looks like (entries in bold have hard-coded locations):

• tribes

  • buildings
  • economy_profiles
  • immovables
  • initialization
    • atlanteans
      • starting_conditions
      • init.lua
      • ...
    • barbarians
    • ...
  • scripting
    • help
  • ships
  • wares
  • workers

• world

  • critters
  • immovables
  • pics
  • resources
  • terrains
  • init.lua
  • map_generation.lua

I am proposing the following file structure:

• units
  • buildings
  • critters
  • economy_profiles
  • immovables (both from world and tribes)
  • initialization
    • atlanteans
      • starting_conditions
      • init.lua
      • ...
    • barbarians
    • ...
    • editor
      • pics
      • init.lua
  • resources
  • scripting
    • help (shift the editor help here too from data/scripting?)
    • map_generation.lua
  • ships
  • terrains
  • wares
  • workers

This change would also affect our textdomains, but since the world textdomain (465 words) is small compared to the tribes (3984 words, with Amazons soon to be added), I'm not that worried about it.

Busy indexing nil values

Top

Quote

+1 for merging amazons first.

I just had another idea - we could split up the textdomains into buildings/wares/workers/immovables etc. Would that be helpful?

Busy indexing nil values

Top

Quote

Since our engine no longer cares whether a unit belongs to a tribe or the world, should we reflect this in our Lua directory structure?

While I'm not really opposed to changing the directory like this, we do care about whether a unit is tribe or world. Or rather, we will start caring again when add-ons are implemented. The reason for this is that new terrains, resources, critters etc must be available to map designers, so the choice is made prior to launching the editor, stored in the map file, and enforced when starting a game on the map. New buildings, wares, workers, tribes etc are ignored when launching the editor – they are chosen by the player every time he starts a new game, and this choice is stored only in savegames. So there is a certain distinction between units that belong to the world and those that don't. In my opinion this important restriction would be more intuitive to add-on designers if we keep distinguishing between world and tribes in the datadir.

Top

Quote

GunChleoc wrote:

How are you planning to deal with immovables in the add-on system, since they can be tribe or world?

I have not gotten around to updating the branch for the new dynamic loading code yet, but I think I will hardcode that ResourceDescrs can be created only from official scripts and from world add-ons, WareDescrs only from official scripts and from tribe add-ons, and so on. Attempting to create e.g. a new terrain from a tribe add-on would then throw a GameDataError. Immovables would be definable from both world and tribe add-ons depending on the scripter's choice whether they should be tribe-specific or available to map designers as well. (If the designer makes a poor choice, e.g. defining a new crop field type in a world add-on or a non-tribe-creatable rock in a tribe add-on, we can just tell them so while reviewing the add-on.)

Top

Quote