Tests need repeatable pseudo-random numbers to yield repeatable
results. Commit 73f1ac8 (v4.3.33) reseeds the PRNG with the count of
commands right before executing a command when running_test_suite is
on. This doesn't help the update: whenever update code exercised by a
test is changed to consume fewer or more PRNs, all subsequent users
get different numbers regardless. The ensuing test result changes are
extremely tedious to review.
To address this problem, reseed the PRNG in the update's two most
important loops with the iteration count when running_test_suite.
This way, the effect of perturbing the PRN sequence lasts only until
the next iteration.
There are many more loops, but reseeding in all of them seems
impractical.
Perturbs test results across the board. Hopefully, that'll happen
less frequently now.
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>
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>
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>
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>
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>
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>
When the player aborts the command at the movement prompt, we write
back stale ships or land units, triggering a generation oops. Any
updates made by other threads meanwhile are wiped out, triggering a
seqno mismatch oops.
Broken in commit 24000b4, v4.3.33. Fix by restoring the lost
shp_nav_stay_behind() and lnd_mar_stay_behind() calls.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When the player declines to abandon a sector, we write back stale land
units, triggering a generation oops. Any updates made by other
threads meanwhile are wiped out, triggering a seqno mismatch oops.
The culprit is lnd_abandon_askyn(): when the player declines, it
returns without calling check_sect_ok(), check_land_ok(). Broken in
commit 7c1b166, v4.3.33. Fix it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
recvclient() calls ef_make_stale() only when it does actual I/O, via
io_output() and io_input(). Missed in commit 2fa5f652, v4.3.24. Call
it directly when it doesn't do actual I/O.
This makes navi-march-test expose a bug in march: when the player
declines to abandon a sector, we write back stale land units,
triggering a generation oops.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
MALLOC_CHECK_=3 makes glibc check for memory allocation programming
errors. It's the factory default, but set it anyway just in case
someone disabled it for speed.
Non-zero MALLOC_PERTURB_ makes glibc wipe memory value on allocation
and deallocation. The actual value determines the bit pattern. Set
it to the value of environment variable EMPIRE_CHECK_MALLOC_PERTURB or
else a pseudo-random number, and record it in sandbox/malloc-perturb.
See mallopt(3) for more information.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When the player aborts the command at the movement prompt, or declines
to abandon a sector, unit_move() returns without freeing the list.
Found with valgrind. Broken in commit 24000b4 and commit 7c1b166,
both v4.3.33.
Free the list on these returns, too.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Telling the player his torpedo "slams into land" can give a clue on
the direction to the target. No good when the target is out of range,
because we shouldn't tell the player more than that then.
Screwed up in 4.2.2. Fix by checking range before line of sight.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
This partly reverts a change made in Empire 2.3 to tell a submarine's
opponent only that he's dealing with a "sub" instead of the
submarine's UID and type. Hiding submarines is done by prsub().
Uses:
* Command torpedo: defender depth charges or torpedoes an attacking
submarine
If you can attack a submarine reactively, you should be able to
attack it actively, too. But that requires its UID. Reveal it
again, but keep the type hidden.
* Command fire: defender fires back at a submarine using its deck gun
Submarines need to surface to fire deck guns, so they shouldn't be
treated any different than surface ships. Revert Empire 2.3's
change entirely there, i.e. defender learns type as well as UID.
* Command torpedo: attacking submarine hits its target
Keep the submarine hidden.
* Commands torpedo and fire: attacking ship hits a submarine
The attacker passed the UID as command argument, so it doesn't
matter whether we print it or not. Printing it is simpler to code,
so do that.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Mission is cleared only when firing at a target that is out of range.
Screwed up when missions were added in Chainsaw. Always clear it when
firing. Matches torpedo.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The cost is meant to be proportional to efficiency / 100, but the code
truncates the fraction to zero. Broken in Empire 2.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Group retreat still doesn't work, because when boar() passes a sunk
ship to retreat_ship(), its owner has been reset to POGO already.
This makes it impossible to find the group to retreat. Instead, it
attempts to retreat ships that sank in the same sector with group
retreat orders and with the same fleet letter assigned. If any exist,
shp_may_nav() oopses, and prevents actual retreat of these ghosts.
The other retreat conditions don't have this problem, because they
call putship(), which resets the owner, only after retreat_ship().
Making boar() work the same is not practical. Instead, add an owner
parameter to retreat_ship(), and for symmetry also to retreat_land().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
This reverts commit c3a839934f.
The commit message's claim that the code never actually retreats
ghosts is wrong: boar() does.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Conflicts:
src/lib/subs/retreat.c
The root cause is in put_combat(): after it sinks the ship, it calls
att_get_combat(), which treats a combat object with a dead ship as an
error, tells the attacker "not in the same sector!", and "recovers" by
putting the combat object into an error state. Too hard for me to fix
right now, so put in a FIXME comment.
The error state trips up retreat. boar() uses the victim's ship
number in the combat object to find the ship it may have to retreat.
Putting the combat object into an error state sets this number to
zero. If that ship exists, and isn't owned by the attacker, and has
RET_BOARDED set, it retreats. Oops. Broken when Empire 2 factored
out common combat code.
Fix by saving the ship number while it's still valid.
This uncovers the next bug: we now pass a dead ship to retreat_ship().
Oopses since commit f743f37. Its commit message says "Harmless, but
avoid it anyway." Going to revert.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
It's only printed for ships. Looks misplaced when it's followed by
"sunk" or other damage reports.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
With offensive support but no defensive support, there's no empty line
separating the support table from the text that follows. Fix that.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Instead of listing all the ships or land units ordered, just print how
many got ordered, and describe the order, like this:
[0:640] Command : retr 2/3 bg itb
2 ships ordered to retreat along path bg when injured, torpedoed, bombed
[0:640] Command : retr 2 h
1 ship ordered not to retreat
fleetadd doesn't list the ships it reassigns, either. On the other
hand, stop lists the sectors it stops. Perhaps it should be gagged,
too.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
It's redundant; retreat path 'h' cancels orders just fine. Document
that instead. 'c' still works, and I don't plan to break it as long
as it doesn't get in the way, which seems unlikely.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Optional arguments can save typing. Mandatory arguments are more
easily discoverable: just run the command and answer its prompts.
Empire traditionally uses optional arguments only for expert features.
Consider mission:
[0:640] Command : mission
Ship, plane or land unit (p,sh,la)? s
ship(s)? 0
Mission (int, sup, osup, dsup, esc, res, air, query, clear)? int
operations point? .
frg frigate Early Bird(#0) on an interdiction mission, centered on 21,-3, radius 0
1 ship
Compare retreat:
[0:638] Command : retreat
ship(s)? 0
shp# ship type x,y fl path as flt? flags
0 frg frigate 21,-3
1 ship
Arguments are not discoverable this way.
Change retreat to work like mission: make the second argument
mandatory, and if it's 'q', show retreat orders, else treat it as path
and ask for conditions:
[0:637] Command : retreat
ship(s)? 0
Retreat path, or q to query? jj
Retreat conditions ('?' to list available ones)? i
shp# ship type x,y fl path as flt? flags
0 frg frigate 21,-3 jj i
1 ship
To reduce smart client and script breakage, keep retreat with one
argument working as before, but print a deprecation warning.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Has no effect now. Before the recent rewrite of automatic retreat, it
could be used to trigger group retreat while staying put.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
