Given and argument like tests/xdump, the script looks for
tests/xdump/.git, tests/.git, /.git. The last one is wrong. Make it
look for ./.git then.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Ship, plane, land unit and nuke types require lcms and hcms to build.
Planes also require military, and nukes also require oil and rads.
These build materials are exposed as ship-chr, plane-chr, land-chr,
nuke-chr selectors l_build, h_build, crew, o_build, r_build.
We want to optionally support more build materials in the future. To
help clients prepare for that, provide selectors for all other item
types. Use CA_DUMP_ONLY to keep them out of configuration tables
until they actually work.
Rename selector crew to m_build for consistency. This is an xdump
compatibility break. We could easily add m_build and deprecate crew
to provide the customary grace period for such breaks. However, more
xdump changes are coming down the pipe, and for some of them providing
a grace period wouldn't be as easy. Ron Koenderink assures us WinACE
doesn't need a grace period. So don't bother with maintaining xdump
compatibility in this release.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
CA_DUMP_ONLY selectors are like CA_DUMP_NONE, except the xdump command
still has them. This will permit adding selectors for conditional
selector and xdump command forward compatibility without also adding
them to configuration tables.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
struct castr ca_flag NSC_EXTRA was introduced in commit 3e5c064
(v4.2.18) to permit selectors that aren't in xdump.
Flag NSC_CONST was introduced in commit 445dfec, and put to use in
commit d8422ca (both v4.3.0) to protect certain table elements that
should not be changed in customized tables.
Both flags apply only to xdump, not to other uses of struct castr,
such as conditionals.
Combining NSC_EXTRA | NSC_CONST makes no sense.
I'll shortly need a way to keep selectors out of configuration tables
for conditional selector and xdump command forward compatibility.
Doing it as a third flag would add more nonsensical combinations.
Convert the flags to a separate enum ca_dump instead:
neither -> CA_DUMP
NSC_CONST -> CA_DUMP_CONST
NSC_EXTRA -> CA_DUMP_NONE
Bonus: unlike the flags it replaces, ca_dump is not visible in xdump.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Commit 9989c5b (v4.2.14) switched item storage from unsigned short to
short, but missed a type cast in the offset computation for
distribution and delivery selectors. Offset computation was factored
out into NSC_IELT() in commit 4366c5a (v4.2.15). Correct it there.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
bombcomm[] used to contain the commodities that can be p-bombed. In
BSD Empire 1.1, it contained I_SHELL, I_GUN, I_MILIT, I_PETROL, I_OIL,
I_RAD. In Chainsaw, it contained either everything or everything but
I_BAR, depending on option preprocessor symbol SUPER_BARS. When
Empire 2 replaced the compile time variable SUPER_BARS by the run time
variable opt_SUPER_BARS, bombcomm[] became a redundant indirection.
Eliminate it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
comm_bomb() first lists commodities that can be bombed and are
present, then prompts for the one to bomb. If the player selects a
bomb-proof one, it rejects it, lists the bombable ones, and prompts
again. This can only happen when option SUPER_BARS is enabled, and
the player selects bars. Looks like this:
Bomb what? (ship, plane, land unit, efficiency, commodities) c
some civilians
some military
commodity to bomb? b
You can't bomb bars of gold!
Bombable: civilians, military, shells, guns, petrol, iron ore, dust (gold), food, oil, light products, heavy products, uncompensated workers, radioactive materials
commodity to bomb?
The list is of marginal value. It was more useful back when
comm_bomb() didn't list commodities before prompting (BSD Empire 1.1).
It's also illegible. Drop it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Commit 612ec62 (v4.3.31) made plane crew and cargo spread the plague.
This requires looking for crew in build materials. Awkward if we ever
permit non-military crew.
Simply drop the "has crew" condition. If a plane's cargo can spread
it, then servicing and refueling the plane can spread it, too.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
tran_plane() computes a plane's weight from its materials. It
hardcodes lcm weight 1, hcm weight 2, and military weight 0. Use
ichr[].i_lbs instead, which is 1 in the stock game for all three
materials.
While there, support arbitrary materials, even though they aren't yet
possible, just to avoid unnecessary assumptions on possible build
materials.
Since the stock game's planes use fewer military than hcms, they
become up to 15% lighter, except for zep, which becomes 10% heavier.
Missiles use no military and become 20-33% lighter.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Building nukes makes you rate *lower* on the power chart, because the
power factor ignores nukes. Fix that.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Items, ships, planes and land units all contribute to the power
factor, which determines position on the power chart.
Items are worth
amount * item value * (0.5 + nation tech level / 1000.0)
The item values aren't quite right: producing stuff can *hurt* your
position on the power chart. Food, uw and rads are worth nothng.
Reduce the value of oil, and give rads the same value as oil. Tweak
value of iron and oil products so that production's power change is
roughly zero around p.e. 0.9 (tech 110), except for construction
materials, where it's zero at p.e. 0.5 (tech 0). Construction
materials become less valuable, shells, guns and petrol become more
valuable. Increase value of bars to roughly match the other changes.
It may still be too low. Halve the value of civilians, and give the
other half to uw. Results:
old new change
civ 100 50 / 2
mil 100 100
shell 80 125 * 1.5625
gun 400 950 * 2.375
pet 2 7 * 3.5
iron 10 10
dust 200 200
bar 1000 2500 * 2.5
food 0 0
oil 100 50 / 2
lcm 100 20 / 5
hcm 200 40 / 5
uw 0 50 new
rad 0 50 new
Ships, planes and land units are worth
base value * effic/100.0 * (0.5 + unit tech level / 1000.0)
For ships and land units, the base value is
lcm/5.0 + hcm/5.0
Build cost is ignored, but lcms are valued twice as much "loose" ones
(before this commit). Therefore, building stuff can change your
position on the power chart in both directions, depending on the type
of build.
For planes, the base value is
20 * (0.5 + nation tech level / 1000.0)
Build cost and materials are ignored, and tech is squared. This
is plainly absurd.
Unify to
(power value of money and materials to build) * effic/100.0
This formula is chosen so that building stuff doesn't change your
power factor. Bonus: it doesn't assume anything about possible build
materials.
For ships and land units, factoring in build cost overcompensates the
discounted value of construction materials more often than not.
Noteworthy changes for the stock game:
ship type old new change
ss slave ship 20 5.8 * 0.29 largest decrease
cs cargo ship 20 7.8 * 0.39
ts trade ship 60 25.5 * 0.42
frg frigate 12 7.8 * 0.65
bb battleship 24 21.8 * 0.91
cal light carrier 22 30.4 * 1.38
can nuc carrier 30 84.6 * 2.82 largest increase
land unit type old new change
hat hvy artillery 12 9.6 * 0.8 largest decrease
linf light infantry 2.4 3.32 * 1.38
cav cavalry 3 5.4 * 1.8
inf infantry 3 5.4 * 1.8
lar lt armor 3 6.4 * 2.13
com commando 3 15.4 * 5.13
eng engineer 3 30.4 * 10.13
meng mech engineer 3 45.4 * 15.13 largest increase
For planes, the power value change depends on the type. Below a
certain nation tech level, planes of this type become more valuable,
above less.
For the stock game, planes costing at most $1000 become less valuable
at any nation tech level that can build them, and planes costing at
least $1800 become more valuable at any practical tech level,
i.e. under 400. Noteworthy planes:
plane type new
sam Sea Sparrow 2.1 least valuable
f2 P-51 Mustang 4.34
lb TBD-1 Devastator 5.92
jf1 F-4 Phantom 10.6
tr C-56 Lodestar 10.78
jt C-141 Starlifter 15.86
jhb B-52 Strato-Fortress 33.54
ss KH-7 spysat 41.2 most valuable
The old value is a flat 12 at nation tech level 100, 15 at tech level
250, and 18 at tech level 400.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
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>
Actual abilities of ships, planes and land units depend almost
completely on the individual unit's tech, not the nation's tech. The
power factor should reflect that.
The power value of a unit is of the form
base value * (20 + nation's tech level) / 500
Change it to
base value * (20 + unit's tech level) / 500
Note that a plane's base value still depends on the nation's tech
level. This commit merely makes the absurdity stand out a bit more.
To be fixed later.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
In the old times, power didn't consider tech at all. Chainsaw's
option NEWPOWER (mandatory since v4.2.14, on by default before)
changed this dramatically: the power factor gets multiplied by
max(1, tech) / 500.
In the early game, small absolute tech differences yield large power
factor differences. For instance, if country A has tech level 10, and
B has 5, then A gets a factor two boost.
As the game progresses, tech differences between viable countries tend
to grow, but only slowly. The influence on power diminishes. For
instance, if C has tech level 270 and D has 240 (quite a respectable
tech lead), then C gets a modest 1.125x boost over D.
Change the factor to (20 + tech) / 500. Now A's advantage is only
1.2, and C's is 1.115.
You might think that's rather low. However, tech is not power unless
you project it, and then it manifests itself as sectors, population
and other stuff power counts.
The same tech term occurs in plane power, except with just tech
instead of max(1, tech) . Change it there as well, for consistency.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
If option RES_POP is enabled, the power factor is multiplied by a
"research factor" of 1.0 + maxpop / 10000.0, where maxpop is the
maximum population of a mine sector.
Back when this code was written (Chainsaw 3), all sectors had the same
population limit, so using a mine sector was as good as any. Since
then, it has become configurable, and the stock game has both sector
types with lower (mountains, plains) and with higher (cities)
population limits.
Space for people is worth considering for power, but multiplying total
power by a fudge factor based on the most common sector type's maximum
population is silly. Drop it.
Adjusting each sector's value for maximum population would make more
sense, with and without RES_POP. Perhaps later.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Item power value is basically number of items times the item power
weight. For some item types, we add up the item numbers, then apply
the weight. For lcms and hcms, we apply the weight, then add up the
weighted numbers.
Adopt the latter method for all types: change addtopow() to tally the
power value for all types instead of just lcms and hcms, and drop
gen_power()'s item power value computation.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Use a single array member instead of multiple scalar members. Only
the array elements that replace scalar members are can be non-zero for
now.
This is a first step to permitting more build materials.
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>
Notable gaps in its coverage are fallout, most of guerrilla, delivery,
distribution, ALL_BLEED and LOSE_CONTACT.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Add edit u keys 'A' for plague stage, and 'b' for plague time.
Admittedly unobvious, but at least they match edit s keys 'a' and 'b'.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Exercise version, show and xdump, except for xdump of game state.
The xdump part is mostly factored out of tests/smoke.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
One-way sorties (fly, recon and sweep) reject mountain destinations
with a "Nowhere to land" message. However, planes can land there just
fine when they return to base (bomb, drop, paradrop, missions).
Already inconsistent in BSD Empire 1.1.
Fix the inconsistency by changing pln_where_to_land() to permit only
helicopters to land in mountains, and pln_airbase_ok() to permit only
helicopters and missiles to take off there, i.e. reject fixed-wing
aircraft.
The flying commands now reject fixed-wing planes based in mountains
with an "is in a mountain and can't take off" message.
Commands flying to a mountain now select only helicopters and silently
ignore the rest, exactly like they select only VTOL planes for flying
to a non-airfield. If no planes can be selected, the command fails
with a "No planes could be equipped" message. This is admittedly less
clear than the "Nowhere to land" message we got before.
Missions now ignore fixed-wing planes based in mountains, exactly like
they ignore non-VTOL planes outside airfields. This may make players
wonder why the fixed-wing VTOL planes they transported up that
mountain don't obey missions. Missions are always quiet unless they
execute.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The two "while it is carrying a nuclear weapon" messages lack
newlines. Add them. Screwed up in commit a269cdd, v4.3.23.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When bombing land units, the bombers get a chance to spot spies. They
can target one even when it wasn't spotted. This makes no sense.
Screwed up when spy units were added in 4.0.0. Hide them completely.
They can still be killed via collateral damage.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
This reverts commit 9b33a4c598.
Parameter only_count was introduced so would_abandon() could use
unitsatxy(), but that was a flawed idea, fixed in the previous commit.
No callers passing non-zero remain, so get rid of it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
sct_prewrite() makes an owned sector revert to the deity when there
are no civilians, military or own land units.
would_abandon() tries to predict that, but gets it wrong: it ignores
land units that evade spy detection or are loaded on ships, and it
fails to ignore land units loaded on land units marching out.
Broken in commit 7c1b166, v4.3.33. Fix by counting manually rather
than with unitsatxy().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Set the application name to "Empire" to support Empire-specific
customization of readline. Use in .inputrc looks like this:
$if Empire
set bell-style audible
set history-size 500
else
set bell-style visible
$endif
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Make -H take an argument. Default it to ~/.empire_history, except in
-r restricted mode, where history is off unless you specify -H.
That's because restricted mode restricts the player's access to the
local system, and that includes the history file. If you want to
grant access to a history file, you have to do so explicitly.
Thanks to the previous commit, there is no need to suppress saving to
~/.empire_history in the test suite.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Readline is for interactive use. For non-interactive use, it merely
complicates things. Case in point: it slows down "make check" by almost
10% for me.
Interactive use should always involve a TTY, so use readline only when
standard input is a TTY. This supresses readline in "make check".
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
We truncate the user's home directory name to 1000 characters when
constructing the history file name. Use fnameat() to fix that.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
AX_LIB_READLINE tries to cope with systems where readline lacks
history support, or lacks headers, or needs headers included in
unorthodox ways. It puts six HAVE_ macros into config.h, and its
usage example takes 24 lines of code just to include two headers.
Way too complicated for my taste. Replace with new MY_LIB_READLINE,
which succeeds only when you have a sane readline, and then defines
*one* macro: HAVE_LIBREADLINE.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Two out of three callers want an extra newline. Letting the callers
do that is simpler, especially now that readline added another case to
prompt().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
If recv_input() can't stuff the whole line into @inbuf, it leaves its
tail in @input_from_rl. If send_input() then empties @inbuf, the next
iteration will select @input_fd for reading instead of @sock for
writing, because @inbuf is empty. Since @has_rl_input is still set,
recv_input() will do nothing, and the client hangs.
Fix as follows. Factor ring_from_rl() out of recv_input(). Also call
it in send_input() to refill @inbuf from @input_from_rl.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Document readline in more detail in man/empire.6.
Make @history_file local to main().
main() silently truncates the home directory name to 1000 characters
when constructing the history file name; mark FIXME.
Set @rl_already_prompted just once.
Write history file on unsuccessful exit, too.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Readline provides fancy command line editing such as <Arrow Up> for
previous commands and CTRL+A to jump to the beginning of the line.
This patch does not add any completion on <tab> key, a TODO, if you
will.
A new command line flag, -H, turns on saving the history to disk.
This may have security implications on shared computers, as all
commands are saved as-is. Thus "change re 1234" would be logged
directly to the file.
Signed-off-by: Martin Haukeli <martin.haukeli@gmail.com>
Rebase on top of preparatory work, fix a few bugs, and tidy up:
* Update the standalone client build, too.
* Fix the Windows build.
* Keep command line options sorted case-insensitively.
* Error out when $HOME is unset and getpwuid() fails, just like we do
for $LOGNAME.
* Give @input_from_rl, @has_rl_input static linkage.
* @has_rl_input is a flag, not a counter, set and test it accordingly.
* Save all input in history, not just commands. Martin's attempt to
recognize commands works only as long as the server sends prompts
faster than the user sends input. Drop that part, and update commit
message accordingly.
* Fix recv_input() not to truncate value of strlen() to int, and to
use memmove() for updating @input_from_rl in place.
* Clean up whitespace in a few places.
* Tweak commit message.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
We need to copy input to @auxfp to implement command line option -2,
and pass it to save_input() to enable protection against a rogue
server exploiting redirection and execute. We currently do this right
when input enters the ring buffer, in recv_input().
Calling save_input() before sending input to the server is sloppy: it
can make the client accept "future" redirections and executes.
Delay save_input() until after input is sent. For simplicity, delay
copying to @auxfp as well.
This is actually pretty close to how things worked before commit
8b7d0b9 (v4.3.11).
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
