mappings.lua

local dungeon_styles= {
	{
		-- tower of hera
		-- palette = 'dungeon.tower_of_hera.1';
		tier_introduction = 3,
		tileset = 'dungeon.tower_of_hera',
		floor = {
			scope = 'room',
			{
				high = { 'floor.a.12.high', 'floor.a.6.high' },
				low = { 'floor.a.13.low.' },
				p = 0.75,
			},
			{
				high = { 'floor.b.12.high', },
				low = { 'floor.a.13.low', },
				p = 0.25,
			},
		},
		wall_pillars = {
			scope = 'room',
			{
				socket = { 'pillar.4', },
				socketless = { 'pillar.4.socketless' },
			}
		},
		drapes = {
			scope = 'room',
			{ nil },
		statues = {
			scope = 'room',
			{ 'statue.1', p = 0.25 },
			{ 'statue.2'},
		},
		wall_statues = {
			scope = 'room',
			{ 'wall_statue.6' },
		},
		barrier = {
			scope = 'dungeon',
			{ 'barrier.1' },
		},
		hole = {
			scope = 'room',
			{ 'hole' },	
		}
		big_barrier = {
			scope = 'dungeon',	
			{ 'big_barrier.3' },
		},
		stage = {
			scope = 'dungeon',
			{ 'stage.1' },
		},
		entrance = {
			scope = 'dungeon',
			{ 'entrance.1' },
		},
		entrance_statue = {
			scope = 'dungeon',
			{ 'entrance_statue.4' },
		},
		music = {
			scope = 'dungeon',
			{ 'dungeon_light' },
		},
		destructibles = {
      			pot = 'entities/vase',
        		stone1 = 'entities/stone_white',
        		stone2 = 'entities/stone_black',
		},
	},
},

• Is there any chance that you'd want to change one of the attributes from being selected per room to being selected per dungeon or vice versa? In that case I suggest that the scope prefix is replaced with a property (room.floor = { ... } -> floor = { scope = 'room', ... }). It does get a bit more verbose that way, so I'm not sure if that flexibility is worth its price.
• Do you think styles and candidates will be referred to directly by name in configuration files like this? If not, the names could be omitted (local dungeon_styles = { 1 = { ... } } -> local dungeon_styles = { { ... } } and room.floor = { a = { ... } } -> room.floor = { { ... } }).

I have some other ideas as well, but I'll have to come back to those later.

Right now I am aiming to procedually create all the dungeons in alltp and that does not require the extra versatility but I see no reason to not prepare for more custom dungeon styles by allowing the scope to be defined as you suggest. I also do not see any reason to not remove names of candidates.

A syntactic question: If we name scope, can we still omit the names of the candidates in the same table?

• I think the preferred patten is a combination of key-value properties and a list of unnamed items:

  { scope = 'room', { ... }, { ... }, },
  

• Are distances even required for displacement? East-tiles, for instance, could be east-center aligned.

• p-values should be named as such. p could default to 1.0.

• Destructibles don't have any candidates. Is this deliberate?

• I don't mind nil, but I think it's better use to have it in place of a patternid rather than an entire set of candidates. That way you could have p-values for tile omissions.

Updated:

• p-values named p
• removed names for candidates
• nil now in table

I'm not sure how we should work with destructibles since the candidates would be entities rather than tiles in a tileset.

Can tiles be aligned as you describe? It is not an attribute which can be set for a tile in the tileset.

Is there any chance you want to left-align an east oriented tile? In that case I believe an alignment property or coordinates are needed.

I can't think of any such case.

I think we are ready to start implementing this. I've pushed a new tileset (dungeon.tower_of_hera) to the 0.4_gfx branch in my fork. I have not pushed any updated mappings.lua since i'm not sure what will break by doing so. Better to just lift the code from this gist.

Gist above updated to fit tileset better.

Made a pull request to develop with the new tileset but without mappings.lua

Somehow my comment about displacement yesterday got lost, but I managed to recover it from an old tab. Here goes:

The only information that's needed for positioning relative to the placeholder is the sizes of the placeholder and candidate tile pair as well as the direction of one of them. In the case of an east-oriented candidate: positionTopLeft(candidate) = positionTopLeft(placeholder) + vectorTopLeftToMiddleRight(placeholder) - vectorTopLeftToMiddleRight(candidate). If the placeholder and candidate have the same size, the top left corners will overlap. If the candidate is smaller it will be pushed to the right and centered within the placeholder.

No rush with destructibles.

Edit: Fixed math.

Then we need not declare displacements. Updating

How's floor supposed to be interpreted? For each room (or dungeon, depending on scope), choose a candidate. For each room (always, independent of scope), choose a high and a low floor from this candidate? In that case, maybe the floors of most styles should be dungeon scoped? Or is there a better interpretation?