[PATCH] Bugfix and balance walls / siege

[elexis]

Walls are one of the greatest remaining imbalances in alpha 19 due to multiple bugs and imbalances:

Before the attack:

• Walls can be built very fast r17312
• The number of wall turrets is not limited by area ("min-distance"),

During the attack:

• Walls are instantanously repaired and without any resource costs #3707
• Pathfinder of the attacker yielding unexpected paths in mazes of obstructions
• Wall turrets having more range than every other unit
• Attackers fail at dealing enough damage
  • Regular champs are not (and shouldn't be) useful in attacking walls
  • Elephants die too quickly
  • Ranged siege doesn't deal enough damage and is destroyed by wall-turrets

After the attack:

• Walls don't decay in disconnected territory #3340

---

#3707 and #3340 should be fixed individually. The other issues (besides pathfinding) can be addressed in this ticket. Not everything must be fixed for a20, but it should become more reasonable.

---

See also from: ​https://wildfiregames.com/forum/index.php?/topic/20621-good-players-usually-say-no-walls-in-the-multiplayer-lobby/&do=findComment&comment=314820

[elexis]

Two alpha 19 replays of games that took extremely long due to the pattern described above.

[fatherbushido]

(wrong comment)

[fatherbushido]

There is inheritance from template_structure_defense

    <Hack>15.0</Hack>
    <Pierce>25.0</Pierce>
    <Crush>3.0</Crush>

So with r17312, walls have 33% more crush armour compared as a19 balancing, HP is a bit decreased but for many civs, HP is hardcoded in their own templates (gauls, brits, romans iirc).

[sanderd17]

How about trying to enforce the connectedness of walls.

• Wall pieces should always have 2 towers
  • The health of a wall piece could be defined to be the minimum of both towers.
  • Wall pieces don't have to be constructed, but appear automatically when the two towers are build (it rises together with the slowest tower).
  • When damage is dealt to a wall-piece, that damage is distributed over both connected towers (either divided over the two, or the two get the full damage)
  • When one of the towers collapses, the wall piece also collapses (since its health also reaches 0)

• Towers preferably are connected to two wall pieces.
  • When a wall tower has no wall pieces connected, it should lose health

This would enlarge the easiness to attack a wall: attacking a wall piece would automatically take out 2 towers and 3 wall pieces. The towers could be made more expensive, and the wall pieces even cheaper (you can't delete the towers as that would remove your wall). And overall, I guess it would cause walls to be used as walls, and not just to spam towers.

[fatherbushido]

Sanderd17 idea sounds very good. Does it fix #3789 in the same move ?

[bb]

As discussed some time ago on IRC, the wall tower spam can be solved by making the mindistance a maxdensity component (maxdistance is done in same way here). Also killed a TODO in the wall buildingplacement.

[fatherbushido]

@bb: L150 L151 it should be template.BuildRestrictions.Density instead of template.BuildRestrictions.Distance

[fatherbushido]

I tested the patch. I observed that : When building a set of walls with close tower after queuing some walls i can't build anymore (the red stuff) but if i finish the set then i can build starting from the last towers. (a bit confused description).

[bb]

If I understand correctly, this problem is caused by the effect that the towers in the same drag (during same build order) does not effect each others red stuff (cant build model during placement). Though you cannot build the towers, its just same lack of red stuff.

Solving this issue is kinda a pita, time consuming for pc (already notice the tooltip lagg when placing walls to close) and leading to some strange decisions by the pc (i.o. which tower to skipp and which not, only saying closest tower to start point or most towers won't kill out all cases, so we get a hard time placing walls) I do not know if/how we need to fix this issue.

Attached rebased patch.

[bb]

rebased

[mimo]

Can you explain how is the density computed ? and what's the meaning of your 3 parameters Distance, MinEntity and MaxEntity ? From the IRC discussion you are referring, my understanding was that this could be a new restriction for walls and wallTowers, and not to replace the current distance requirements. But maybe the previous distance requirement is still a subset of your new ones, but some explanations would help.

In any case, if that's restricted to walls and wallTowers, that's not a problem for the AI which does not yet build them, but if it's a new criteria used for other structures, you should also modify public/simulation/ai/petra/mapModule.js where the build requirements are implemented lines 87 to 106.

[bb]

Replying to mimo:

Can you explain how is the density computed ? and what's the meaning of your 3 parameters Distance, MinEntity and MaxEntity ?

MinEntity is the minimum number of Entity's (of a specified class) which should be in range ("Distance" is this range) in order to be able to build the building. When we say MinEntity = 1 we have the old maxDistance component, as a density of 1 in a range is just a maxDistance. MaxEntity is parallel from this: the maximum number of ents (of class) in range ("Distance") on building, so a number of 0 gets us the old minDistance component.

From the IRC discussion you are referring, my understanding was that this could be a new restriction for walls and wallTowers, and not to replace the current distance requirements. But maybe the previous distance requirement is still a subset of your new ones, but some explanations would help.

It's my pleasure to explain :), see the above, the old Distance checks have become useless as its a subset indeed. The only (unused) functionality (which is not in the new system) from the old system would be to add two ranges with different Distance. So a MinDistance and a MaxDistance. If we want such a thing in the new system we need to make it a "zeroOrMore" thing to allow different ranges, not sure if that is needed. (hope this is not too vague)

In any case, if that's restricted to walls and wallTowers, that's not a problem for the AI which does not yet build them, but if it's a new criteria used for other structures, you should also modify public/simulation/ai/petra/mapModule.js where the build requirements are implemented lines 87 to 106.

Thx, cc, towers etc. will have a look on this.

[bb]

added ai support for the changed component, still a TODO in it, not sure if that is vital (as it won't happen too often). The new case in map-module.js changes in L144.

[elexis]

In 18288:

Wall placement cleanup. Somewhat based on patch by bb, refs #3811.

Early return instead of a big if-statement.
Inline r, targetX, targetZ, towerX and towerZ.
Rename s to spacing.
Remove unneeded else keywords.
Eliminate deprecated for-each.
Use let instead of var.
Quote object keys.
++i instead of i++.
Some newlines.

[elexis]

Rebased, removed committed stylefix hunks and bad hunk from GUIInterface. Still contains stylefixes which should be done separately as they draw attention when reading the patch.

[fatherbushido]

see r18502 for gate

[Itms]

Move tickets from the review queue to the rfc one.

[bb]

Partial splitted of cleanup from previous patch (partial in order to prevent mega-patches)

[FeXoR]

Applying ​http://trac.wildfiregames.com/attachment/ticket/3811/t3811_buildingDensity_5.diff throws: ERROR: RelaxNGValidator: Validation error: structures/brit_wooden_tower:1: Expecting an element PlacementType, got nothing ERROR: RelaxNGValidator: Validation error: structures/brit_wooden_tower:1: Invalid sequence in interleave ERROR: RelaxNGValidator: Validation error: structures/brit_wooden_tower:1: Element BuildRestrictions failed to validate content ERROR: RelaxNGValidator: Validation failed for '(null)' ER That happens when a map is loaded (Sometimes only when a builder is selected). Some templates may have been forgotten.

After that more errors occurr and the game is unplayable (actually the GUI will be entirely broken in some cases).

[elexis]

another example of walling that might be considered abusive IMO

[elexis]

Another example of walling that might be considered abusive IMO. The entire game was a 2 hour stalemate. No progress was achievable.