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>
makelost() overwrites an existing entry for the same thing, else
creates a new one. It calls findlost() to find existing entries.
findlost() means to look up by coordinates if it's looking for a
sector entry, and by ID if it's looking for a ship, plane, land unit
or nuke entry. It actually does both for sectors. Since callers pass
zero ID for sectors, sector entries always match, so at most one gets
created, and additional ones overwrite it.
Broken since the lost table was introduced in 4.0.7. Fix the flawed
comparison in findlost().
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>
"torped" comes from symbol table retreat_flags. Visible in output of
edit, retreat, lretreat and xdump. Tolerable in edit, but player
commands like retreat should really use proper words.
Fixing it in retreat_flags changes xdump output, thus risks breaking
clients. Do it anyway, since no known client recognizes this
particular symbol value.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
It sets the new type, then falls through to setting tech if the new
type requires more than the plane currently has. Two problems with
that:
* If we fall through, the plane is invalid: it has less tech than
required. Its only use before it gets overwritten is pln_set_tech()
calling pln_range_max() to find out whether the range is limited.
Passes a negative number to log(). Not fatal, but pln_set_tech()'s
range adjustment is unlikely to work.
* If we don't fall through, the range may still need adjustment,
either up (to keep it unlimited if the new type has more range), or
down (to keep it within the new type's shorter range).
Screwed up when the key was added in commit 6b0b6f17. Fix by
adjusting tech first, then setting the type, then adjusting the range.
The latter relies on pln_set_tech() coping with ranges exceeding the
type's maximum, which it does.
Change the other type edits similarly for consistency.
When a type edit triggers a tech change, the tech change is now
silent.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Demonstrate bugs: doesn't always preserve unlimited range, and doesn't
always cut range back to maximum.
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>
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>
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>
Copying the sector copies its distribution center. When the source
sector has none, the target sector is made to distribute to the
source. Unexpected. Zap the distribution center then.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
final.xdump changes, because setup no longer copies 3,-1 to 1,-1,
messing up its distribution center. 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>
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>
Units owned by POGO are not in use. Giving a unit to POGO destroys
it. The opposite doesn't work, however: the unit prewrite hooks give
it right back to POGO, because efficiency is below the minimum. Make
it work by also increasing efficiency to minimum.
Note that you can't use this to create a unit that doesn't already
exist in the respective file. That's because edit's second argument
selects from existing objects only.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
print_plane() ends its output with '\t' instead of '\n'. Next is a
prompt, which supplies the missing newline (see pr_id()).
Ugly, clean up.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Accept general <SECTS|SHIPS|PLANES|LANDS|NATS> argument instead of
just <SECT|SHIP|PLANE|LAND|NAT>.
edit with <KEY> <VALUE>... arguments applies the arguments to all
selected objects. Without such arguments, edit lets you edit the
selected objects interactively one after the other.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Interactive edit prints the edited object, then reads player input.
If it gets key and value, it applies them to the object, and repeats.
If it gets nothing, it prints the edited object again, and stops.
Remove this last print, because it's not really useful. The object is
commonly the same after reading input as before. Except when a nation
gets updated while "edit c" is waiting for input: then the second
print actually reflects the updates. Has always been that way.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Print a message describing the actual change for keys 't' (nat_tgms)
and 's' (nat_status). The message is necessary to give the deity a
chance to catch unexpected changes, e.g. a player reading telegrams
just before the deity edits nat_tgms.
Send a bulletin to the country for key 's'.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Print "FOO of CNAME (#CNUM)" instead of just "FOO". Print "unchanged"
instead of "changed from X to X" on no-op.
Send a bulletin to the country and report news when appropriate.
Affected keys:
key struct member before after notes
-------------------------------------------
n nat_cnam -- BN 1
r nat_pnam -- B- 2
b nat_btu -- BN 3
m nat_reserve BN BN
c nat_xcap,ycap -- B-
o nat_xorg,yorg -- B-
u nat_timeused -- BN
M nat_money B- BN
Notes:
1. Reports N_NAME_CHNG rather than N_AIDS/N_HURTS.
2. Message improved to accurately reflect string truncation.
3. Greengrocers' apostrophe in message fixed.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Print "Technology" instead of "Tech". Print "FOO of CNAME (#CNUM)"
instead of just "FOO". Print "unchanged" instead of "changed from X
to X" on no-op.
Send a bulletin to the unit owner and report news on change.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Print a message (always), send a bulletin to the unit owner and report
news (sometimes).
The message is necessary to give the deity a chance to catch
unexpected changes, e.g. a player spending mobility right before the
deity edits it. Watching out for such changes is especially important
with non-interactive edit.
Affected keys:
cmd key struct member action
----------------------------------
edit s L shp_x,y B-
E shp_effic BN
M shp_mobil BN
F shp_fleet B-
T shp_tech BN
a shp_pstage --
b shp_ptime --
R shp_rpath B-
edit p l pln_x,y B-
e pln_effic BN
m pln_mobil BN
w pln_wing B-
t pln_tech BN
r pln_range B-
edit u L lnd_x,y B-
e lnd_effic BN
M lnd_mobil BN
a lnd_army B-
t lnd_tech BN
F lnd_harden BN
Z lnd_retreat B-
R lnd_rpath B-
The two characters in column action show whether the command sends a
bulletin (B) or not (-), and whether it reports news (N) or not (-).
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Print a message, send bulletin to owner. Affects ship key 'W', land
unit key 'W', and plane key 'f'. The message is necessary to give the
deity a chance to catch unexpected changes, e.g. a player modifying
retreat conditions right before the deity edits them. Watching out
for such changes is especially important with non-interactive edit.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
