commands: Rename the command functions Command functions are traditionally named like the command shortened to four characters. When this name collides with a keyword or library function, we abbreviate more: brea(), rea(). A few are unabbreviated, e.g. execute(). A few have different names, e.g. explain(), not list(). Commit 23726b379 (v4.3.0) suppressed a GCC warning about carg() colliding with its built-in function. Ron Koenderink reported Microsoft Visual Studio 2019 fails to link: "_carg already defined in ucrtd.lib(ucrtbased.dll)". Time to clean this up: rename the functions to c_FOO(), where FOO is the unabbreviated name of the command. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
buy: Fix bogus error when lot gets reused at the last prompt When the lot being bid for goes away and gets reused while the player is at the prompt for the destination sector, comm.com_amount gets stale. We use it before we detect the change and fail the command This can lead to a misleading ""You don't have that much to spend!" error. Messed up when the code was fixed to deal with lot changes in 4.0.2. Fix by checking for lot change earlier. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
buy: Don't continue when lot changes while asking for bid When the lot being bid for changes while the player is at the "How much" prompt, we report "Commodity #%d has changed!", and continue with the changed lot. If continuing is okay, we should keep quiet. We did that until commit 40b11c098 "Fix buy not to wipe out concurrent updates", v4.3.27. Okay when only the lot's price changed. However, the lot could have gone away, or even be reused for something else. Failing the command seems safest for the player, so do that. It's how we use the check_FOO_ok() elsewhere. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
work: Don't let embarked engineers work Engineers can work even when loaded on a ship or land unit. They happily raise sea sector efficiency. That's just wrong. It's questionable even on land, because unloading need not be possible. Has been that way since the command was added in Empire 2. Add the missing check. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
neweff production work: Fix crash for sea sector The work required for building sea sectors is zero in sect.config. When a deity runs neweff or production on a sea sector, e.g. with "neweff *", buildeff() divides by zero. Same when a player or deity runs work with an engineer in a sea sector. Broken in commit 2ffd7b948 "config: Make work to build sectors configurable", v4.4.0 Fix buildeff() to avoid the division. Change the required work to 100 in sect.config for good measure. Cover deity use of neweff and production in tests/update. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
config: Increase mountain process efficiency from 75% to 100% Each point of gold resource is worth 5d. Except for mountains, where it's just 3.75d. This is because a mountain's process efficiency is only 75%. Has been that way since Empire 3 made mountains mine gold. This is actually a needless complication: a sector with 75% process efficiency produces just like one with 100% process efficiency and 75% of the resource. Increase mountain process efficiency to 100%. Deities may want to compensate by adjusting mountains' gold resources. 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: Give a few helpers internal linkage External use of prod_materials_cost(), prod_resource_limit() went away in commit 4a714a37d "production: Use update code instead of duplicating it", v4.4.0. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
arm: Rework "cannot carry nukes" test for robustness We reject satellites, ABMs, anti-ship missiles, and SAMs. That's enumerating badness. More robust replacement: accept only bomber, tactical, cargo, except for anti-ship missiles. Throw in PLN_LAUNCHED sanity checking while there. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
ef_verify: Reject invalid plane flag combinations Any plane may have capabilities VTOL, helo, light. Capability missile requires VTOL. Anti-ballistic missiles have capabilities missile, SDI. Anti-satellite missiles have capabilities missile, satellite. Surface-to-air missiles have capabilities missile, intercept. Anti-ship missiles have capabilities missile, marine, and may have tactical. Surface-to-surface missiles have capability missile, and may have tactical. Satellites have capability satellite, and may have spy, image. Ordinary planes may have capabilities bomber, tactical, intercept, cargo, spy, image, ASW, para, escort, mine, sweep. Capability para requires cargo; see para(). Only "missile requires VTOL" is enforced. Enforce the rest. Excluding P_O when asking for P_N is now redundant. Drop that from msl_abm_intercept(). Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
launch interception: Drop support for ABM, a-sat consuming shells Their impact on the target does not depend on shell load (it sometimes did for a-sats until commit cf960a573 "Make anti-sat launch consistent with interception", v4.3.23). The shell use is logistical busy-work, and economically irrelevant. Remove it. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
config: Change asat not to consume shells The asat's impact on the target does not depend on its shell load (it sometimes did until commit cf960a573 "Make anti-sat launch consistent with interception", v4.3.23). The shell use is logistical busy-work, and economically irrelevant. Remove it. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
mission: Don't permit SAMs on escort missions The mission code doesn't treat SAMs specially: they take off, fly out, maybe fight, fly home, and land. Landing triggers the oops in pln_put1(). Letting SAMs escort makes no sense. Fix the mission command to reject them. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>