Expand visibility controls for objectives

[applenick]

Expand visibility controls for objectives

This PR was inspired by a set of changes @Pablete1234 provided from his previous work back on the old PGM. Introduced are several new attributes that can be used when defining objectives in XML. These new show flags allow map authors to precisely control where and how objectives are displayed within a match. For example, you'll now be able to hide if a wool is shown on the scoreboard, or if a core broadcasts messages or not. This will hopefully provide mapmakers with greater flexibility to customize the user experience per-map.

Show Flags

attribute	description	value
show-messages	Broadcast messages related to objective	true/false
show-effects	Play sounds, fireworks, and effects	true/false
show-info	Display objective under commands (/match)	true/false
show-sidebar	Display objective on scoreboard	true/false
stats	Whether objective counts as a win condition	true/false

The existing show attribute will now function as the default value for all the above flags, which is still by default true.

These show flags work for the following objective types:

• Cores
• Monuments
• Wools
• Flags
• Control Points

XML Syntax

<!-- Hide a wool from the scoreboard -->
<wool show-sidebar="false" team="blue" color="purple">
    <block location="-1,75,97"/>
</wool>

<!-- Hide core break/leak broadcast messages -->
<core show-messages="false" team="red" region="red-core"/>

<!-- Prevent control point from playing sounds / fireworks -->
<control-point show-effects="false" name="Center" capture-time="20s"/>

<!-- Hide a monument from /match and the scoreboard (combining multiple show flags) -->
<destroyable show-info="false" show-sidebar="false" owner="red" region="red-monument"/>

<!-- Define using `show` to set a default value, then overriding a single type (effects) -->
<core show="false" show-effects="true" team="red" region="red-core"/>

Feedback

As per usual, these changes have been tested and should all work as intended. If you have any suggestions/requests let me know and I'd be glad to look further into it 👍

Signed-off-by: applenick applenick@users.noreply.github.com

[KingOfSquares]

Looking at XML parsing in general the ShowOptions class could probably just be a Set parsed in XMLUtils? I like the simplicity of the implementation though, so if you decide to keep it as-is I have a couple of suggestions.

[Electroid]

Looks great. Requested a few minor changes

[Electroid]

I think this should just be a top-level enum.

public enum ObjectiveOption {
   SHOW_MESSAGES("show-messages")
   // ...
}

Parsing code should exist exclusively in XMLUtils.

[applenick]

Parsing code should exist exclusively in XMLUtils.

@Electroid How should the implementation be handled for moving parsing to XMLUtils. Should ObjectiveOption be moved as well so we can reference it directly and have the method be something like:

public static Set<ObjectiveOption> parseObjectiveOptions(Element el, boolean def) {
// ...
}

Or were you thinking of a more generic parsing method? I feel like since this is a pretty specific use case it's better off residing inside of ObjectiveOptions, similar to how we already have a KitParser or ControlPointParser. If you want I can extract the static parse method to a separate ObjectiveOptionParser class, but seems unnecessary.

Any suggestions would be appreciated 👍

[Pablete1234]

I think this should just be a top-level enum.

The thing is "ShowOptions" is not an enum, it's a set of show flags. and it makes sense for them to be wrapped rather than having to pass around an ImmutableSet<ObjectiveOption>

Also, i have one major issue with naming it "objective option" and that is that it's an over-generalization, this is specifically for "show-*" toggles, not for any random boolean you want to put on an objective, otherwise we'd shove half of the objective xml into here

Maybe we can have it be called ShowOption if you want to avoid confusion with actual flag objectives

[Electroid]

LGTM for now, improvement is good enough.

[Pablete1234]

ObjectiveOption / ObjectiveOptions / hasOption are too generic of a name. What is "option" supposed to mean, anything you put on the xml is an "option" (the region? the material? the owning team?) but that isn't what this is about.

These are show-flags, makes sense @Electroid don't wanna call them "flags" for the confusion with the Flag objective but this needs to represent what it's about