Custom games may want to tweak how items contribute to the power
factor, in particular when products are also customized. Add ichrstr
member i_power and item selector power for that.
"info power" doesn't reflect this change, yet. It'll be updated in
the next commit.
The current item power values are problematic. This will be addressed
later.
For straightforward configurations, reasonable item power values could
perhaps be derived from the configuration automatically. However,
this is surprisingly hard in the general case: since producing things
should not decrease power, the efficiency of processing products into
other products needs to be considered, and estimating these
efficiencies can be difficult.
Deities can create multiple products making the same item, or multiple
sector types with the same product, but different process efficiency
(sect-chr selector peffic). Providing differently efficient ways to
make the same item can be reasonable when the sector types involved
have different terrain. To average them, you'd need to know the map.
The stock game has one example: gold mines produce dust with 100%
process efficiency, mountains produce it with 75%. Mountains are
normally rare enough not to matter.
Level p.e. (product selectors nlmin, nllag) may have to be considered.
In the stock game, level p.e. variations are minor, because it reaches
0.9 pretty quickly. In games where it doesn't, you might have to
increase the power value of the product.
Resources (sect selectors min, gold, fert, ocontent, uran) and
resource depletion (product selectors nrndx and nrdep) further
complicate things: you might want to increase the power value of
products depending on unusually scarce resources, but you can't know
what's scarce without understanding the map.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The work required for build and repairs is traditionally a function of
build materials: 20 + lcm + 2*hcm for ships, planes and land units,
and (lcm + 2*hcm + oil + rad)/5 for nukes. Make it independently
configurable instead, via new ship-chr, plane-chr, land-chr, nuke-chr
selector bwork, backed by new struct mchrstr member m_bwork, struct
plchrstr member pl_bwork, struct lchrstr member l_bwork, struct
nchrstr member n_bwork. Keep the required work exactly the same for
now.
Clients that compute work from materials need to be updated. Easy,
since build work is now exposed in xdump.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The code needs it first so it can store field values into the object
right away. Save the values instead, and store them when the row is
complete.
The improvement is hardly worth the trouble by itself, but it'll
simplify supporting keys consisting of multiple fields, like sector
xloc, yloc or realm cnum, realm, so we can omit rows in those tables,
too.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
We currently require all rows to be present for tables item, sect-chr,
infrastructure, sect, realm.
The first three make sense: the code hard-codes indexes for them, and
malfunctions when entries are blank, so we want to make it hard to
leave any blank by accident.
The last two don't: blank sectors and realms work fine. There, the
restriction is arbitrary. Drop it.
Sectors and realms still can't be omitted "in the middle" (can do that
only with an ID selector), but that's coming soon.
See also commit 4a4ec91.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Each part of a split table needs to supply rows for the same objects.
We currently require each part to name its objects explicitly, with an
object ID field, and don't support splitting tables that don't have
such IDs. These restrictions became arbitrary when commit 4e23c45
implemented checking each partial table supplies the same rows. Relax
them.
Affects tables sect, news, lost, realm, game, infrastructure.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
