Add check to ensure a country by that name does not exist.
Ensure the length is not too long. Note this is a change
behaviour for edit and change commands which used to silently
truncate long names. Enforce that a country name can not have
control characters in it. Ensure that a country name is not
blank or just spaces.
The Chainsaw 3 feature to let you load/unload to a specific amount
through a negative amount argument created loopholes: it let you load
your ships in friendly sectors with the unload command, and unload
friendly ships with the load command. Likewise for land units, with
allied instead of friendly, of course.
Empire 4.0.0 fixed that for the case of loading a land unit from an
allied sector. Get rid of that check, and fix it for good in
load_comm_ok().
The game generally doesn't let you give away civilians. But the check
in load_comm_ok() for that compared the sector old owner to the player
instead of the ship's or land unit's owner, which is incorrect for
foreign ships or land units. Fix that.
Also make fix the message there not to assume that the civilians are
owned by the player. This can't currently happen, but will when these
commands support use by deities properly.
This is for consistency with load and unload.
Before, you could use lunload for allied land units and lload in
allied sectors, but the command failed when stuff was loaded in allied
sectors. Doing that with lload no longer fails the command, because
the check that does that in load_comm_land() is now masked by the new
checks in lload(). Note that loading with lunload still fails the
command; that inconsistency will be removed in a later commit.
load_plane_land() already refused to load planes from foreign sectors.
This commit makes that check redundant, so remove it. Functional
change: lload now refuses to load foreign planes silently, unless both
land unit and plane were named by number. This is consistent with
load.
load and unload work on foreign ships only when their argument
explicitely names them, i.e. you have to ask for them by number. When
any other syntax is used, load() ignores foreign ships. This makes
sense. Change lload() to work just like that.
The check for ship owner's relations to the player was backward: it
checked the player's relations to the ship's owner instead. Abusable:
you could load and unload any ship by declaring friendly to its owner.
Broken since Chainsaw let you load and unload friendly ships.
The check for land unit owner's relations to the player was similarly
backward, similarly abusable, and also broken since day one.
lload and lunload checked sector owner's relations to the land unit's
owner instead of to the player. Harmless, because the two must be the
same to reach the check.
The contents of the line was partly useless (repetition of the command
argument) and partly misleading (modification time of the formatted
info file, ifndef _WIN32).
Land units were erroneously charged the much lower raw path cost,
except when attacking high-mobility terrain (mountains). Broken in
commit 2673a258, v4.3.6.
Conditions comparing strings behaved rather erratically: while wing=m
was smartly interpreted as wing='m' (because m is ambiguous as plane
selector), wing=e was not so smartly interpreted as wing=effic
(because e unambiguously identifies effic; this was then rejected due
to incompatible types), and wing=g was even less smartly interpreted
as wing=group.
Address this by a redesign of the identifier resolution rules in
nstr_comp(): If the condition contains just one identifier, it names a
selector. If it contains two, try to intepret either as selector or,
if the other can be interpreted as selector, as value for that.
String selectors accept any identifier as value, numeric selectors
only the ones listed in their table.
Interpret both identifiers as selectors only if their types are
compatible (makes rpath=gu work for ships) and their tables, if any,
match (makes type=spy work for land units).
If more than one interpretation makes sense, drop any value
interpretations of identifiers that are unabbreviated selector names,
and selector interpretations of those that are not (makes wing=w work
for planes).
Change nstr_match_val() to accept any identifier as value for a string
selector. Replace nstr_mkselval() by nstr_resolve_val(), to resolve
string values in addition to symbolic ones. Remove resolution to
string from nstr_resolve_id(), drop its last parameter. Remove unused
nstr_string_ok(). New nstr_is_name_of_ca(), nstr_ca_comparable().
Examples for conditions that are now interpreted differently:
condition old interpretation new interpretation
wing=g wing=group wing='g'
w=g wing=group rejected as ambiguous (1)
w=e wing=effic (2) wing='e'
(1) because both wing='g' and 'w'=group make sense
(2) rejected as incomparable later on
Change nstr_mkselval() to generate values with promoted types only,
and replace nstr_coerce_val() by new and simpler nstr_optype() in
nstr_comp().
Replace the only remaining use of nstr_coerce_val() in surv() by
nstr_promote(), and remove nstr_coerce_val().
This loses one half of the unimplemented sketch of coercions to
NSC_STRING. Drop the other half from nstr_exec_val().
getsect() can fail here only when the coordinates are invalid. The
first check uses coordinates from a successful sarg_xy(), so they
can't be invalid. The second check uses coordinates of an object to
be put on the mission. If these are invalid, game state is corrupt,
and failing the mission command doesn't improve the situation a bit.
Before, the escort mission didn't support an op-area, and planes on
escort mission escorted anywhere. Change mission() to define the
op-area for escort missions as well. Show it in mission() and
show_mission(). Check it in find_escorts().
Land unit reactions are overly complex because we have two different
concepts controlling them: reaction radius (set with lrange) and
reserve mission (set with mission). You need to deal with both to set
up or query reactions.
Commit 8d0e1af5 "fixed" this by making reserve missions meaningless.
The previous commit made reserve missions meaningful again: they
support an op-area now. This brought back the problem of having to
deal with two separate commands to accomplish one thing.
Fix this for good by removing non-mission land unit reaction
alltogether. The only feature we lose by that is the ability to order
land units to react until the order is explicitely cancelled. That's
because missions are implicitely cleared by many commands and events,
while non-mission reaction wasn't. Closes#858121 and #858122.
Remove the non-mission reaction case from att_reacting_units().
Don't limit reserve missions to the land unit's reaction radius: make
lnd_reaction_range() return the type's maximum radius instead of
lnd_rad_max.
The reaction radius is now useless. Remove the lrange command, and
struct lndstr member lnd_rad_max along with its selector react.
Remove land command's column rd. Make ldump show column react as
zero. Deprecate edit key 'P' in dounit(), and don't show it in
pr_land().
Before, they always reacted to their maximum range, and the op-area
was unused. Change mission() to define the op-area for reserve
missions as well. Remove the special-case for showing reserve
missions from mission() and show_mission(). New lnd_reaction_range()
factored out of att_reacting_units(). Use it in oprange() to cover
reserve missions. Pass the mission as separate parameter to oprange()
for now, because miss() doesn't set it in the object until later.
The mission command limits op area radius to the possible range.
That's okay, as it doesn't actually restrict possible op areas. When
the mission is executed, it was limited again. Don't do that; remove
the limiting code from build_mission_list_type() and show_mission().
The removed limiting had no effect, except when the range shrunk.
Then limiting reduced the op area more than necessary. For instance,
consider an object O with initial range 3 on a mission around M with
range 3:
- - - y - - -
- - z y - -
- - z x y - -
- O x x M -
- - z x y - -
- - z y - -
- - - y - - -
Initially, all sectors not marked - are in range and in the op area.
If the range drops to two, sectors marked O, x and z are still in
range of O. But only the x are still in range of M. The O and z got
excluded.
Range can currently shrink when plane range is reduced (range
command), or a ship, plane or land unit somehow loses tech (deity
intervention).
Land units on reserve missions used to pay only half the usual
mobility for combat. This bonus was commented out in the code in
4.0.0, but not in info. Remove it from both.
In that case, make copied the sources.mk from $srcdir, but unless it
existed already, the peculiar workings of VPATH did us in: make
searched for the target, found it in $srcdir, and the dependency
became circular.
Fix by keeping sources.mk in $srcdir always. We can build it there,
because its contents depends only on git state, not on anything in the
build tree. This avoids the need to copy sources.mk alltogether.
When a ship is shelled, retreat condition 'i' (injured) applies. When
there's no return fire, 'h' (helpless) applies as well. Ships
retreated twice in that case. Fix that.
