Project

General

Profile

Feature #809471

unreachableprotects should be specified at unit/ruleset level instead of only at server option level

Added by Lexxie L 8 months ago. Updated 4 months ago.

Status:
Closed
Priority:
Normal
Category:
General
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Currently it is not possible to make a unit type unreachable yet unable to protect a whole stack, without getting rid of unreachableprotects from the entire game (game-wide as a server option.)

Unreachable can be OP exploitative in some conditions. Making a server option for it was a first step toward limiting exploits, but it throws away the ability completely for ALL game situations. As a server option only, it "fixes" things by completely removing it from EVERY aspect of the entire game.

A ruleset that is finer tuned and finer balanced may realistically portray units in different ways.
It may wish Submarines to be Unreachable by Air units, to represent they can submerge. But of course it does not want Submarines to be a magic stack-protector for an entire stack of ships. Other examples where you would want unreachable_protects ALWAYS OFF would be things like Satellites, Hot Air Balloons, Cargo Planes, AWACS, Bombers, etc.

However, the same ruleset may also have units and mechanics where it wants unreachableprotects. It is a very important tactical mechanic for representing inaccessibility and protection. Unreachable Protection is a legitimate and important tactical mechanic for some types of units.

Suggested solution:
1. Server option unreachableprotects continues to control globally if OFF.
2. If ON, individual units may have override flags for disabling unreachableprotects

This should be a simple change that solves huge tactical mechanical problems in rulesets. Right now we are forced to choose between two extremes / too much one way or too much another way.

This would allow a much improved ability to tune unit mechanics, tactics, and dynamics, over a notorious issue that is constantly putting ruleset designers into unsolvable paradoxes.

History

#1 Updated by S.C. L. 8 months ago

I can't assign this to myself, but I've started work on this.

Is there a defined behavior for unit_attack_all_at_tile_result() when the given tile contains no units? It's a minor edge case, but it does affect some of the code.

#2 Updated by S.C. L. 8 months ago

Done. It's PR#17 on github.

Some notes:
  • The aforementioned unit_attack_all_at_tile_result() now returns ATT_UNREACHABLE when called against an empty tile (instead of ATT_OK). If this is relevant at all, I can make another patch for that.
  • The helptext for the new unit type flag is displayed regardless of unreachableprotects and doesn't mention the server setting. This might lead some people to think that other unreachable units do protect in a situation where unreachableprotects is globally off. I'm not sure how likely and how much of an issue this is.

#3 Updated by S.C. L. 7 months ago

Forgot to update ruledit files.

Also, this should probably be an Issue, not a Task.

#4 Updated by Marko Lindqvist 5 months ago

  • Tracker changed from Task to Feature
  • Category set to General
  • Status changed from New to In Progress
  • Target version set to 3.1.0

#5 Updated by Marko Lindqvist 5 months ago

I haven't looked at the contents of the patch yet, but you could help the process by preparing it a bit:

Can you combine the patches in to one and to have a commit message for it that:
- Has first line in imperative (e.g. "Add NeverProtects unit type flag")
- Has longer explanation on later lines if needed
- Has a reference to this ticket (e.g. "See hrm Feature #809471")

If I get a patch prepared that way I can easily push it with using you as the --author so you get it in your name.

#6 Updated by Marko Lindqvist 5 months ago

- As a single commit
- Minor formatting fix
- Escaped "'" in data/ruledit/comments.txt

#8 Updated by Marko Lindqvist 5 months ago

  • Status changed from Resolved to In Progress

This assumes attack to be otherwise possible when unit_attack_unit_at_tile_result() return ATT_UNREACHABLE. In reality unit_attack_unit_at_tile() returns ATT_UNREACHABLE also when attack is prevented by both unreachability and some tile nativity issue. We should not allow attack when there's also tile nativity issue.

#9 Updated by Marko Lindqvist 5 months ago

- Make sure there's no other reasons attack is not permitted than unreachability, before allowing it
- Return ATT_OK for empty tile like before this patch
- Indentation correction

#10 Updated by Marko Lindqvist 4 months ago

  • Status changed from Resolved to Closed
  • Assignee set to Marko Lindqvist

Also available in: Atom PDF