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.Nov 4 2020, 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.EditedNov 5 2020, 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.Nov 5 2020, 6:53 AM
  • Compleat.
  • Correct, cleans up nicely.
This revision is now accepted and ready to land.Nov 5 2020, 6:53 AM
This revision was automatically updated to reflect the committed changes.