HostedRedmine.com has moved to the Planio platform. All logins and passwords remained the same. All users will be able to login and use Redmine just as before. Read more...
unreachableprotects should be specified at unit/ruleset level instead of only at server option level
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.
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.
#2 Updated by Alina L. over 3 years ago
- File 0001-Added-NeverProtects-unit-type-flag.patch 0001-Added-NeverProtects-unit-type-flag.patch added
Done. It's PR#17 on github.Some notes:
- The aforementioned
ATT_UNREACHABLEwhen 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
unreachableprotectsand doesn't mention the server setting. This might lead some people to think that other unreachable units do protect in a situation where
unreachableprotectsis globally off. I'm not sure how likely and how much of an issue this is.
#5 Updated by Marko Lindqvist about 3 years 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.
#8 Updated by Marko Lindqvist about 3 years 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 about 3 years ago
- File 0003-Add-unit-type-flag-NeverProtects.patch 0003-Add-unit-type-flag-NeverProtects.patch added
- Status changed from In Progress to Resolved
- 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