Damage to a ship or land unit, say via pinpoint bombing, doesn't
damage loaded planes and land units.
Damage to a sector, say via strategic bombing, doesn't damage ships
there, but it does damage planes, even when loaded on a land unit (but
not when loaded on a ship), and land units, even when loaded on a land
unit or a ship.
This makes no sense. Sector damage spills over to land units that way
since Chainsaw 3 added them, and to planes since 4.0.9.
Change sectdamage() not to damage land units and planes loaded on
ships or land units.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Relations state is relatively bulky: it's a big chunk of struct
natstr, and adds 200 bytes per country to xdump nat.
Relations change rarely. Rewriting it to disk on every nation update
and retransmitting it in every xdump nat is wasteful.
To avoid this waste, move relations state to its own struct relatstr.
This is of course an xdump compatibility break. We're not maintaining
xdump compatibility in this release.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
New struct relatstr is basically empty so far. The next commit will
move relations state from struct natstr to struct relatstr.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Reject state is relatively bulky: it's a big chunk of struct natstr,
and adds almost 200 bytes per country to xdump nat.
Reject state changes rarely. Rewriting it to disk on every nation
update and retransmitting it in every xdump nat is wasteful.
To avoid this waste, move reject state to its own struct rejectstr.
This is of course an xdump compatibility break. We're not maintaining
xdump compatibility in this release.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
New struct rejectstr is basically empty so far. The next commit will
move reject state from struct natstr to struct rejectstr.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Contact state is relatively bulky: it's a big chunk of struct natstr,
and adds almost 200 bytes per country to xdump nat for deities.
Contact changes rarely. Since we avoid unnecessary updates, it
doesn't change at all unless option HIDDEN is enabled. Rewriting it
to disk on every nation update and retransmitting it in every deity
xdump nat is wasteful.
To avoid this waste, move contact state to its own struct contactstr.
This is of course an xdump compatibility break. We're not maintaining
xdump compatibility in this release.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
New struct contactstr is basically empty so far. The next commit will
move contact state from struct natstr to struct contactstr.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
A country must always be in contact of itself when option HIDDEN is
enabled. The code ensures this by establishing contact whenever a
player logs in, in init_nats(). This is not the proper place. Game
state should be initialized in empfile's oninit() callback, in this
case nat_oninit(). Do that, and drop the putcontact() from
init_nats().
Note that option LOSE_CONTACT only affects contact to other countries:
agecontact() doesn't age the country's contact to itself.
Use the opportunity to initialize contact so that getcontact() works
even when HIDDEN is disabled. Just cleanup, it isn't actually called
then.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
We maintain a few sector invariants in sct_prewrite(). Since the
update bypasses sct_prewrite(), it needs to maintain them itself. The
two should be consistent.
sct_prewrite() resets work percentage of owned sectors to 100% when
there are no civilians. The update's populace() resets it for unowned
sectors as well, if they have military.
Change sct_prewrite() to reset sct_work = 100 regardless of owner.
Also change sct_oninit() to initialize sct_work = 100, so it doesn't
change on first write. Update tests/smoke/fairland.xdump for the same
reason.
The massive test output differences are all due to sct_work.
Inconsistencies with the update remain. They will be fixed next.
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>
SAIL has issues:
* Sail orders are executed at the update. Crafty players can use them
to get around the update window.
* The route is fixed at command time. You can't let the update find
the best route, like it does for distribution.
* The info pages documenting it amount to almost 100 non-blank lines
formatted. They claim you can follow friendly ships. This is
wrong. They also show incorrect follow syntax. Unlikely to be the
only errors.
* Few players use it. Makes it a nice hidey-hole for bugs. Here are
two nice ones:
- If follow's second argument is negative, the code attempts to
follow an uninitialized ship. Could well be a remote hole.
- If ship #1 follows #2 follows #3 follows #2, the update goes into
an infinite loop.
* It's more than 500 lines of rather crufty code nobody wants to
touch. Thanks to a big effort in Empire 2, it shares some code with
the navigation command. It still duplicates other navigation code.
The sharing complicates fixing the bugs demonstrated by
navi-march-test.
Reviewing, fixing and testing this mess isn't worth the opportunity
cost. Remove it instead. Drop commands follow, mquota, sail and
unsail. Drop ship selectors mquota, path, follow.
struct shpstr shrinks some more, on my system from 160 to 120 bytes.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The autonavigation feature has issues:
* Autonavigation orders are executed at the update. Crafty players
can use them to get around the update window.
* Usability is poor:
- The order command is overly complex, not least because it can do
five different things: clear, suspend, resume, declare route, set
cargo levels.
- Unlike every other command involving movement, order does not let
you specify routes, only destination sectors.
- Setting cargo levels can silently swap start and end point of a
circular route, because "this keeps the load_it() procedure
happy". Maybe it does, but it surely keeps players confused.
- Setting "start" cargo levels actually sets the "end" levels, and
vice versa. Has always been broken that way.
- Predicting what exactly autonavigation will do at the update isn't
easy.
* The info pages documenting it amount to almost 400 non-blank lines
formatted. They claim only merchant ships can be given orders.
This is wrong. Unlikely to be the only error.
* Few players use it, and its workings at the update a fairly opaque.
Makes it a nice hidey-hole for bugs. Here are two:
- Unlike the scuttle command, autonavigation happily scuttles trade
ships while they're on the trading block.
- Unlike the load command, autonavigation can load in friendly and
allied sectors.
* It's more than 700 lines of rather crufty code nobody wants to
touch. Thanks to a big effort in Empire 2, it shares code with the
navigation command. It still duplicates load code. The sharing
complicates fixing the bugs demonstrated by navi-march-test.
Reviewing, fixing and testing this mess isn't worth the opportunity
cost. Remove it instead. Drop commands order, qorder and sorder.
Drop ship selectors xstart, xend, ystart, yend, cargostart, cargoend,
amtstart, amtend, autonav.
xdump ship sheds almost half its columns. struct shpstr shrinks, on
my system from 200 to 160 bytes.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When a player moves more than 1023 sectors in a single navigate
command, we overrun the buffer holding the path taken. Remote hole,
but it requires a ship that can go that far, and even a ship with
speed 1000 would need a tech level well in excess of 1000 for that.
Thus, the hole is purely theoretical for even remotely sane game
configurations.
First known version with the flaw is 4.0.0.
Fix by going back the older behavior: don't print the total path
taken, but do print what the path finder does. Context diff of an
example:
[0:634] Command : nav 3 6,0
Flagship is od oil derrick (#3)
+Using path 'n'
h =
k . .
j d
<67.2:67.2: 6,0> h
od oil derrick (#3) stopped at 6,0
-Path taken: n
This is how march works.
Removes the only use of shp_nav_one_sector()'s unusual return value 2.
Return 1 instead.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Cuts size of export files in test suite by a factor of four. Not a
big deal for disk usage, as export files compress very well, and disk
space is cheap anyway. Export files are simply easier to work with
when they aren't full of redundant crap.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Now covered in tests/bridgefall. Damage perturbed, because deleting
the bridges from the setup makes defend() roll fewer dice.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Sector 0,2 takes a lot of damage. When it gets shot to deity, the
rest of the test can be upset. Avoid by putting more civilians there.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Copying the ship copies the ship to follow. When the source ship
doesn't follow a ship, the target ship is made to follow the source.
Screwed up since Chainsaw added the means to copy a ship. Fix it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Setup uses edit to build units. Stupid idea, because that misses unit
initialization normally done by build, directly or via
unit_wipe_orders(). Use build instead.
Changes test output harmlessly: ship xbuilt, ybuilt go from 0,0 to the
building sector, ship#0's builder goes from 98 to 0, all ships'
cargostart and cargoend go from 0 to -1, jhb range from 0 to 35, and
land unit retreat percentage from 0 to 42.
Setup no longer needs country 98. Drop it.
Setup no longer copies 2,0 to 0,0 messing up its distribution center.
Harmless.
Setup doesn't need POGO's tech level anymore, so don't set it to 400.
Nukes are now built at their required tech level. Also harmless.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Let deities build in any sector. If the deity's tech level is too
low, use the required tech level instead. Don't require or use
materials, work or money. Bridge spans still require support.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Moving the telegram files away isn't enough, we also have to reset
nat_tgms. actofgod/setup-POGO does it already, but fire/setup-POGO
doesn't. Do it in begin_test instead, right where the telegram files
are moved away.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
TREATIES has issues:
* Treaties can cover attack, assault, paradrop, board, lboard, fire,
build (s|p|l|n) and enlist, but not bomb, launch, torpedo and
enlistment centers.
* Usability is very poor. While a treaty is in effect, every player
action that violates a treaty condition triggers a prompt like this:
This action is in contravention of treaty #0 (with Curmudgeon)
Do you wish to go ahead anyway? [yn]
If you decline, the action is not executed. If you accept, it is.
In both cases, your decision is reported in the news.
You cannot get rid of these prompts until the treaty expires.
* Virtually nobody uses them.
* Virtually unused code is buggy code. There is at least one race
condition: multifire() reads the firing sector, ship or land unit
before the treaty prompt, and writes it back after, triggering a
generation oops. Any updates made by other threads while trechk()
waits for input are wiped out, triggering a seqno mismatch oops.
* The treaty prompts could confuse smart clients that aren't prepared
for them. WinACE isn't, but is reported to work anyway at least
common usage. Ron Koenderink (the WinACE maintainer) suspects there
could be a few situations where it will fail.
This feature is not earning its keep. Remove it. Drop command
treaty, consider treaty, offer treaty, xdump treaty, reject treaties.
Output of accept changed, obviously.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Two bugs. First, multifire() checks the condition only for surface
ships, not for submarines. Second, multifire() neglects to write back
the ship after retreating it. The player is told the ship retreats,
but it actually stays where it is.
Broken since retreat was added in Chainsaw. Previous fixes (commit
8065fe8, v4.3.1 and commit de2651e, v4.3.19) "fixed" only the
bulletin.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
It's not firing, yet.
While there, trim an unwanted blank line before reporting the first
sector ready.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
This was a lame attempt at limiting the ripple effect of adding /
removing commands. Better means are now available, so drop it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Changed xdump output is too painful to review. final.xdump should
still catch changes that are visible only in xdump.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Tests need repeatable pseudorandom numbers to yield repeatable
results. We seed the pseudorandom number generator with a fixed value
(emp_server -R) to make it produce the same sequence of numbers every
time. But whenever code exercised by a test is changed to consume
fewer or more of them, all subsequent users get different numbers
regardless. The ensuing test result changes are extremely tedious to
review.
To address this problem, reseed the PRNG with the count of commands
right before executing a command when running_test_suite is on. This
way, the effect of perturbing the PRN sequence lasts only until the
next command.
Note that the next command could be another player's. Doesn't matter.
Adding or removing commands now upsets the PRN sequence even for
commands that don't consume PRNs. The next commit will take care of
that.
Perturbs test results across the board. Hopefully, that'll happen
much less frequently now.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
To make setup scripting more similar to test scripting. Also permits
use of countries other than POGO there, but that isn't necessary right
now.
Setup scripts renamed from init_script to setup-POGO.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The other test output files have fixed names, and having just one with
a name that varies with the test name complicates things with no gain.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Commit 37ff377 stripped trailing white space in test output, except
for journal.log, where it stripped it only from player output. This
misses the space preceeding player empty output, and doesn't cover
equally annoying trailing white space elsewhere, such as the space
preceeding empty input and trailing white space in prompts. Testing
the latter could be marginally useful, but let's keep things simple,
and strip all trailing white space for now.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
