[low prio] Dry/wet yardmap tiles

[sprunk]

The request is to accomodate this kind of "age of" style shipyard, where one specific edge of the building has to be on dry land and one on water.

As far as I can tell building masks apply to the whole unit so could not be used. gadget:AllowUnitCreation and gadget:AllowCommand can implement arbitrary placement rules but the UI doesn't reflect them.

Yardmap characters that say "this has to be in water" and "this has to be dry" sound like a good choice, especially since there's precedent all the way back from TA ('w' used to mean water; currently it is the same as 'o' but it is still recognized as valid).

[WatchTheFort]

How do you handle the tiles in the middle that can be either wet or dry?

[sprunk]

o

[marcushutchings]

So 'w' is water-only, 'o' is water or land. That leaves and 'x' and 'f', what are those for?

[sprunk]

Below is a table of the status quo. (As a side note I should put this up as documentation somewhere.)

letter	Spring/Recoil	TA
o	unbuildable, unpathable, universal	unbuildable, unpathable, land
y	buildable, pathable, universal	buildable, pathable, land
w		unbuildable, unpathable, water
Y		buildable, pathable, water
c	buildable iff active, pathable iff active, universal	buildable iff active, pathable iff active, land
C		buildable iff active, pathable iff active, water
g	o + geothermal	o + geothermal
G		w + geothermal
f		feature, idk what other traits
x		i don't believe x was a thing
i	unbuildable iff active, unpathable iff active, universal
j	g + stackability
s	o + stackability
b	buildable, unpathable, universal
h	first char only: high-resolution yardmap

Looking at it, it looks like there are many independent yard traits one could want and our yardmap characters encode some limited and arbitrary subset of those:

• applies when dry?
• applies when wet?
• buildable if active?
• pathable if active?
• buildable if inactive?
• pathable if inactive?
• stackable?
• geo?

Adding a bunch of water letters would still be nice but perhaps this requires some deeper thought. Maybe check what Supcom did?

[WatchTheFort]

How many combinatoric combinations are going to be required? If more binary attributes are added, it may be better to have each yardmap square be a block of letters, rather than a single one, and use a dedicated separator to distinguish squares.

[sprunk]

I think at that point we wouldn't bother with these opaque letters and just make a new format. For example engine would expose constants:

YARD.PATHABLE_IF_ACTIVE = 1
YARD.BUILDABLE_IF_ACTIVE = 2
YARD.PATHABLE_IF_INACTIVE = 4
YARD.STACKABLE = 8
YARD.GEOTHERMAL = 16
YARD.WATER = 32
...

YARD.OPEN_IF_ACTIVE = PATHABLE_IF_ACTIVE + BUILDABLE_IF_ACTIVE
YARD.PATHABLE = PATHABLE_IF_ACTIVE + PATHABLE_IF_INACTIVE
YARD.BLOCKED = UNPATHABLE + UNBUILDABLE (= BLOCKED_IF_ACTIVE + BLOCKED_IF_INACTIVE)
YARD.UNIVERSAL = WATER + LAND
...

and then games would be able to do

local o = YARD.BLOCKED
local j = YARD.STACKABLE + YARD.BLOCKED + YARD.GEOTHERMAL
yardmap = { o, j, o, ... }

or maybe even

yardmap_chars = { -- perhaps globally and not per-unitdef, with default set to current if missing
  o = YARD.BLOCKED,
  y = YARD.OPEN,
  φ = YARD.STACKABLE + YARD.OPEN_IF_ACTIVE + YARD.WATER,
  ѭ = YARD.GEO + YARD.PATHABLE_IF_ACTIVE + YARD.BUILDABLE_IF_INACTIVE + YARD.LAND,
}
yardmap = "ooѭo φoφo yoooooo",

[Beherith]

I dunno how helpful it is to use wierd unicodes for this. I would much prefer a space-based, multiline format for adding characters, or even a proper lua array would be saner to parse.

Backwards def-wise similarity (especially character level) is actively discouraged.

yardmap = {YARD.BLOCKED, YARD.STACKABLE + YARD.OPEN_IF_ACTIVE + YARD.WATER, ...},

[sprunk]

Strings have the important benefit of being pseudographical/visual.

Your example is the same as one of mine though.

[Beherith]

I understand the intuition behind strings, but at this point it quickly becomes and arcane, nonstandard hack. Anyone could still unitdefs post from a string.

[Beherith]

And coming from me, who doesn't mind arcane shit, its probably a bad sign.

[sprunk]

Anyone could still unitdefs post from a string.

Yes, but would anybody not do that? String is the most convenient (regardless of whether it's parsed by engine or unitdefs_post). And mature games using the convenient option would be nice because newbie devs learn by looking at what mature games do.