A Cleaner Rewards Section

[Nesseley]

Feature request

Short description Right now rewards are nice, but it could be better. When using the cmd: option you will get a really messy config that is hard to work trough.

Implementation details Exmaples:

Now:

    rewards:
      waves:
        every:
          '2': random(nothing, nothing, cmd:/cmi kit Påfyll1 <player>, cmd:/cmi kit
            Påfyll2 <player>, cmd:/cmi kit JK32 <player>, cmd:/cmi kit JK32 <player>,
            cmd:/cmi kit JK32 <player>, cmd:/cmi kit JK48 <player>, cmd:/cmi kit JK16
            <player>, cmd:/cmi kit JK16 <player>)
        after:
          '10': all(random(cmd:/cmi kit Påfyll2 <player>, cmd:/cmi kit Påfyll2 <player>,
            cmd:/cmi kit Påfyll2 <player>, cmd:/cmi kit Boss3 <player>, cmd:/cmi kit
            Boss2 <player>), all(cmd:/lp user <player> permission set mobarena.arenas.slagmarken3
            true))

After:

    rewards:
      waves:
        every:
          '2': 
            - random:
              - nothing
              - nothing
              - cmd:/cmi kit Påfyll1 <player>
              - cmd:/cmi kit Påfyll2 <player>
              - cmd:/cmi kit JK32 <player>
              - cmd:/cmi kit JK32 <player>
              - cmd:/cmi kit JK32 <player>
              - cmd:/cmi kit JK48 <player>
              - cmd:/cmi kit JK16 <player>
              - cmd:/cmi kit JK16 <player>
        after:
          '10': 
            - all:
              - random
                - cmd:/cmi kit Påfyll2 <player>
                - cmd:/cmi kit Påfyll2 <player>
                - cmd:/cmi kit Påfyll2 <player>
                - cmd:/cmi kit Boss3 <player>
                - cmd:/cmi kit Boss2 <player>
              - all
                - cmd:/lp user <player> permission set mobarena.arenas.slagmarken3 true

We could even make it even better by doing something like this:

    rewards:
      waves:
        every:
          '2': 
            - random:
              - 20% nothing
              - 10% cmd:/cmi kit Påfyll1 <player>
              - 10% cmd:/cmi kit Påfyll2 <player>
              - 30% cmd:/cmi kit JK32 <player>
              - 10% cmd:/cmi kit JK48 <player>
              - 20% cmd:/cmi kit JK16 <player>

[garbagemule]

This is not necessary

Before I address the feature request itself, I'd like to point out that YAML actually has excellent multi-line string support, so it is entirely possible to clean things up without any changes to MobArena.

Because MobArena trims spaces, as long as the value is parsed by SnakeYAML as a string with no linebreaks in it, you can pretty much do anything you want. This page explains it very well. In summary, use folded block style (>) and handle block chomping by stripping newlines (-). Here's a working example tested on Spigot 1.17.1 with MobArena 0.106:

'1': >-
  random(
    dirt,
    stone,
    diamond
  )

The extra 2 spaces of indentation for the three arguments aren't necessary, but they help mimic the structure we would have in a document-style implementation as suggested.

---

It makes sense to try to clear up messy reward sections that lump together lots of different things into one thing picker. The introduction of the advanced thing picker functions definitely brought messy reward sections along for the ride. I personally think this scratches the surface of a much bigger issue with the syntax: that there is no way to work on "reward sets" in isolation. If we expand the proposal in #212 just a little bit to include the advanced thing picker functions, it would be fairly trivial to just make a more explicit syntax for an "exploded spec".

The proposed spec in this feature request makes parsing really messy, especially from an extensibility standpoint. The presence of an arbitrary key should not determine the type of anything. Instead, the type should be determined by the value of a well-known key. This might sound like gibberish, but the essence is the difference between these two syntaxes:

'1':
  - random:
    - nothing
    - nothing
    - stone
'2':
  - type: random
    entries:
      - nothing
      - nothing
      - stone

In the first example, we have to keep track of a list of keywords that can't be used for anything else. There is no way we can have a property called random on any thing type, because it's taken by the random thing picker. The second example uses a predetermined key, type, that uniquely determines the type, so all other property names are fair game, and they will never conflict, because once the type is determined, a specific parser kicks in. It's a bit more verbose, but it's also a lot easier to document and explain. It's also consistent with wave types.

The second part of the suggestion about assigning explicit percentages (which probably should be its own suggestion and discussion), means dealing with this case:

'2'
  - type: random
    entries:
      - 20% nothing
      - 10% dirt

What does that mean?

(I had no user-friendly solution to the same problem back in 2011, which is why we have the infamous probability sums in default and special waves)