show: Drop Windows-specific fmttime2822() code fmttime2822() works around Windows strftime() lacking %z and %T. This is no longer the case, although MinGW still warns about %T. Replace %T by the %H:%M:%S, and drop the work-around. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
config: Make product work independently configurable The work required for a product is traditionally the amount of raw materials, plus 1 for resource usage, or 1 if using neither. Make it independently configurable instead, via new product selector bwork, backed by new struct pchrstr member p_bwork. Keep the required work exactly the same in the default configuration. 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>
Update copyright notice Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
New macro ARRAY_SIZE() Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Update copyright notice Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Update copyright notice Signed-off-by: Markus Armbruster <armbru@redhat.com>
Spelling corrections Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Fix up a few identifier references in comments Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
show: Clean up long vs. int in fmttime2822() for Windows fmttime2822() prints long with format %d, and passes long to abs(). Harmless, because both int and long are 32 bits in the Windows API. Clean it up anyway. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Update copyright notice Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
config: Generalize infrastructure build materials storage Infrastructure requires lcms and hcms to build. The build materials are exposed as infrastructure columns lcms, hcms (struct sctintrins members in_lcms, in_hcms). They are per point of efficiency. In contrast, sector and unit build materials are defined for 100%. We want to define build materials for 100% now, for flexibility and consistency, and we want to optionally support more build materials in the future. Replace members in_lcms and in_hcms by array in_mat[], and provide selectors l_build and h_build. Additionally provide selectors for all other item types, with value zero, to help clients prepare for future additional materials. Use CA_DUMP_ONLY to keep them out of configuration tables until they actually work. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
config: Define infra build cost and mobility use per 100% Infrastructure build cost is defined by infra column dcost (struct sctintrins member in_dcost). It's the cost per point of efficiency. In contrast, sector and unit build cost is defined for 100%, by sect-chr, ship-chr, plane-chr, land-chr, nuke-chr column cost. Switch to build cost per 100%, for flexibility and consistency: replace struct sctintrins member in_dcost by in_cost, and selector dcost by cost. With cost values that aren't multiple of 100, the build cost may have to be rounded. Do this exactly like we round sector build cost: the amount is limited to money * 100 / cost rounded down, but the money charged is actual amount * money / 100 rounded randomly. Do the same for mobility use: replace struct sctintrins member in_mcost by in_bmobil, and selector mcost by bmobil, with similar rounding. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
show: Show infra costs in the same format as sector build costs Use similar column headings, and show cost for 100% instead of 1%. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Include "file.h" where it's needed Several headers define macros that use ef_ptr() without including "file.h". Fix that. Drop redundant inclusions elsewhere. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
collect: Derive collection value from power value The collection value of a sector is sector value = sector type value * (sector efficiency + 100) + sum of item values item value = item type value * amount The sector and item type values are configurable. The item type collect values aren't too far off the power values: uid mnem pow val pow/val 0 "c" 50 1 50 1 "m" 100 0 inf 2 "s" 125 5 25 3 "g" 950 60 15.8 4 "p" 7 4 1.75 5 "i" 10 2 5 6 "d" 200 20 10 7 "b" 2500 280 8.9 8 "f" 0 0 NaN 9 "o" 50 8 6.25 10 "l" 20 2 10 11 "h" 40 4 10 12 "u" 50 1 50 13 "r" 50 150 0.33 The power value is very roughly ten times the collect value, except for civilians and uw it's 50, for rads its 0.33, and military are free to collect. The latter two make no sense. Replace the item type collect value by the power value / 50 for people, and by the power value / 10 for everything else. This makes collecting military, shells, guns and uw more expensive, and petrol, bars, iron, oil and rads cheaper. The sector type values are basically arbitrary. For instance, an iron mine costs five times as much as a wilderness, but a third of an uranium mine, regardless of actual resource contents. Replace this by different arbitrary values: sector value = (item value of materials necessary to build it + build cost) * efficiency / 100 + sector type maximum population + sum of item values Some sector types become cheaper, some more expensive. Drop sect-chr and item selector value. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
config: Make work to build sectors configurable Traditionally, building up 100% takes 100 work. Make the work to build configurable, via new sect-chr selector bwork, backed by new struct dchrstr member d_bwork. Keep the required work exactly the same for now. Tearing down sectors remains four times easier than building. Clients that hardcode sector build work need to be updated. Easy, since build work is now exposed in xdump. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
config: Generalize sector build materials storage Sectors require lcms and hcms to build. The build materials are exposed as sect-chr columns lcms, hcms (struct dchrstr members d_lcms, d_hcms). They are per point per point of efficiency. In contrast, unit build materials are defined for 100%. We want to define build materials for 100% now, for flexibility and consistency, and we want to optionally support more build materials in the future. Replace d_lcms and d_hcms by array member d_mat[], and replace selectors lcms and hcms by selectors l_build and h_build. This is an xdump compatibility break. To provide the customary grace period, we'd have to make selectors lcms and hcms virtual instead, with value l_build / 100 and h_build / 100 rounded up, and deprecate them. Deities would have to avoid l_build and h_build values that aren't multiples of 100 for this to work fully. But we're not bothering with maintaining xdump compatibility in this release. Provide selectors for all other item types, to help clients prepare for future additional materials. Use CA_DUMP_ONLY to keep them out of configuration tables until they actually work. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
config: Define sector build cost per 100% instead of 1% Sector build cost is defined by sect-chr column build (struct dchrstr member d_build). It's the cost per point of efficiency. In contrast, unit build cost is defined for 100%, by ship-chr, plane-chr, land-chr, nuke-chr column cost. Switch sectors to cost per 100%, for flexibility and consistency: replace struct dchrstr member d_build by d_cost, and replace selector build by selector cost. Naming it cost for consistency with units is possible only because the previous commit made the name available. This is an xdump compatibility break. To provide the customary grace period, we'd have to make selector build virtual instead, with value bcost / 100 rounded up, and deprecate it. Deities would have to avoid bcost values that aren't multiples of 100 for this to work fully. But we're not bothering with maintaining xdump compatibility in this release. With bcost values that aren't multiple of 100, the cost of sector building may have to be rounded. On the one hand, the cost of sector demolition has always been rounded up. On the other hand, the cost of producing stuff is rounded randomly. For now, round up, because rounding randomly would affect subsequent random rounding, and upset the smoke test. Fortunately, show se b already shows build costs per 100%, since commit 48ff096, v4.3.23. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
config: Add sect-chr flags, replace cost by flag "deity" Give sector types capability flags (dchrstr member d_flags), like ship, plane, land unit and nuke types have. Member d_cost is effectively a flag since the previous commit. Replace it by capability flag "deity". This is an xdump compatibility break. To provide the customary grace period, we'd have make selector cost virtual instead, and deprecate it. But we're not bothering with maintaining xdump compatibility in this release. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
designate: Drop support for designate costing money Chainsaw 3 added the designate cost along with extra build cost and materials, and used both to make fortresses expensive. Unlike build cost and materials, the cost to designate didn't pass the test of time: it was set to zero in Empire 2. Get rid of it. sect-chr selector cost and struct dchrstr member d_cost have to stay, because they're still used to configure whether a sector may be designated by players (see commit 8d792e1). Signed-off-by: Markus Armbruster <armbru@pond.sub.org>