Page MenuHomeWildfire Games

clean up structure vision
ClosedPublic

Authored by Nescio on Oct 15 2020, 3:57 PM.

Details

Reviewers
Freagarach
Group Reviewers
Restricted Owners Package(Owns No Changed Paths)
Commits
rP24163: Clean up structure vision.
Summary

Currently template_structure.xml defines a <Vision> of 40. However, most structures define different values. Furthermore, many of the structures in the other/ folder, which inherit directly from template_structure.xml, have a <Vision> of 4 (perhaps because one tile is 4×4?), which is roughly the attack range of a melee unit.
This patch:

  • changes template_structure.xml vision to 1.
  • inserts a vision of 40 in those files that used to inherit it.
  • purges the vision of those other/ structures (this does not alter gameplay balance)
  • removes 1 vision lines that are now unnecessary in other structures (outpost, palisades, walls, monument, pillar, arch)

A vision of 1 means the structure can't see its surroundings, but can be selected (unlike fields, which have 0 vision); this seems more generic than the arbitrary value of 40.

  • [EDIT] Changed 1 to 4, because players are unable to see capture points or set rally points with a vision of 1 (spotted by @Freagarach).

See also D2505/rP23934 and D3016/rP24104.

Test Plan

Check for correctness and completeness.

Event Timeline

Nescio created this revision.Oct 15 2020, 3:57 PM
Owners added a subscriber: Restricted Owners Package.Oct 15 2020, 3:57 PM
Nescio added inline comments.Oct 15 2020, 4:00 PM
binaries/data/mods/public/simulation/templates/other/bridge_hele.xml
26–28

Bridges are neither buildable nor capturable nor player-owned, therefore it doesn't need vision.

binaries/data/mods/public/simulation/templates/other/bridge_wooden.xml
26–28

idem

Successful build - Chance fights ever on the side of the prudent.

builderr-release-macos.txt
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libgraphics.a(precompiled.o) has no symbols

Link to build: https://jenkins.wildfiregames.com/job/macos-differential/1649/display/redirect

Nescio requested review of this revision.Oct 15 2020, 4:15 PM

Those other/ structures are neither buildable nor garrisonable, therefore it shouldn't matter.
As for the rest (palisades etc.), those already have a vision of 1, hence no change effectively.

But still, a vision of 1 with the knowledge we have now is a bug. So I'd say change all so they have at least a vision of 2.

Nescio updated this revision to Diff 13669.Oct 28 2020, 9:31 AM
Nescio edited the summary of this revision. (Show Details)

(the advantage of this patch is one needs to change only the number in a single file)

Successful build - Chance fights ever on the side of the prudent.

builderr-release-macos.txt
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libsimulation2.a(precompiled.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libengine.a(precompiled.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libatlas.a(precompiled.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libgui.a(precompiled.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/liblowlevel.a(dbghelp.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/liblowlevel.a(file_stats.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/liblowlevel.a(vfs_path.o) has no symbols

Link to build: https://jenkins.wildfiregames.com/job/macos-differential/1679/display/redirect

Some more testing reveals that in _some_ cases 2 also has the same limitation as 1. You can make it 3 (probably always correct) or 4 (seems logical with the tilesize).

Nescio updated this revision to Diff 13670.Oct 28 2020, 8:06 PM
Nescio edited the summary of this revision. (Show Details)

Some more testing reveals that in _some_ cases 2 also has the same limitation

Any idea why? It's a bit annoying the minimum vision range is apparently 4.

No clue, sorry ^^'

Some more testing reveals that in _some_ cases 2 also has the same limitation

Any idea why? It's a bit annoying the minimum vision range is apparently 4.

I think the explanation is that we compute LOS on a 'per-tile' basis, but representing a tile as a point/vertex. With tiles being 4 meters-wide, a vision range of 1 doesn't guarantee that you'll actually light up a vertex, thus giving an effective range of 0.

I suppose the simplest fix is to always reveal at least the 4 vertices making a tile around the given point.

Nescio added a comment.Wed, Nov 4, 7:19 PM

Yes, I can understand that, but what I don't really get is why health appears to be treated differently than capture points.
Anyway, this patch changes the vision of those that have 1 to 4.

Freagarach added a comment.EditedThu, Nov 5, 6:42 AM

Probably because the entity ends up being miraged, in which case the health bar is shown (albeit not updated) and the capture bar is not shown.

Freagarach accepted this revision.Thu, Nov 5, 6:53 AM
  • Compleat.
  • Correct, cleans up nicely.
This revision is now accepted and ready to land.Thu, Nov 5, 6:53 AM
This revision was automatically updated to reflect the committed changes.