Latest Posts

Topic: Tribes/World file structure

GunChleoc
Avatar
Topic Opener
Joined: 2013-10-07, 15:56
Posts: 3324
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2020-10-27, 07:50

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
hessenfarmer
Avatar
Joined: 2014-12-11, 23:16
Posts: 2646
Ranking
One Elder of Players
Location: Bavaria
Posted at: 2020-10-27, 09:07

No objections but only after amazons have been merged, please.


Top Quote
GunChleoc
Avatar
Topic Opener
Joined: 2013-10-07, 15:56
Posts: 3324
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2020-10-27, 10:12

+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
hessenfarmer
Avatar
Joined: 2014-12-11, 23:16
Posts: 2646
Ranking
One Elder of Players
Location: Bavaria
Posted at: 2020-10-27, 10:16

GunChleoc wrote:

+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?

Well, I believe the biggest issue is to keep consistency in translations over different textdomains. In the big tribes domain it is easy to filter in transifex to see the translation style, which is not always consistent with the Glossary. So basically a bigger domain is better then a smaller one in practical use.


Top Quote
Nordfriese
Avatar
Joined: 2017-01-17, 18:07
Posts: 1929
OS: Debian Testing
Version: Latest master
Ranking
One Elder of Players
Location: 0x55555d3a34c0
Posted at: 2020-10-27, 20:03

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
Avatar
Topic Opener
Joined: 2013-10-07, 15:56
Posts: 3324
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2020-10-28, 10:36

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

Let's keep the file structure as it is for now.


Busy indexing nil values

Top Quote
Nordfriese
Avatar
Joined: 2017-01-17, 18:07
Posts: 1929
OS: Debian Testing
Version: Latest master
Ranking
One Elder of Players
Location: 0x55555d3a34c0
Posted at: 2020-10-28, 11:43

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
GunChleoc
Avatar
Topic Opener
Joined: 2013-10-07, 15:56
Posts: 3324
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2020-10-28, 18:30

Sounds like a plan face-smile.png


Busy indexing nil values

Top Quote