Improve accolade_data.cfg format

eps0003 commented 3 years ago

As a way to prevent merge conflicts when merging accolades from different tournaments with shared participants, I propose a change to the way accolade_data.cfg is formatted. This may also make adding accolades more accessible to people who lack the understanding of how to resolve merge conflicts.

Requirements

No existing lines must need to be modified to add new accolades
It shouldn't require more lines than the current format
It adheres to KAG's cfg format

Proposed format

epsilon =
    customhead 1548201600 51;
    gold; # 1 - Tournament A
    gold; # 2 - Tournament B
    silver; # 1 - Tournament C
    silver; # 2 - Tournament D
    bronze; # 1 - Tournament E
    participation; # 1 - Tournament A
    participation; # 2 - Tournament B
    participation; # 3 - Tournament C
    participation; # 4 - Tournament D
    participation; # 5 - Tournament E
    participation; # 6 - Tournament F
    participation; # 7 - Tournament G
    participation; # 8 - Tournament H
    github; # Reason X
    community; # Reason Y
    map; # Reason Z

Each medal is put onto its own line
~~Participation medals are calculated based on gold + silver + bronze + participation~~
Comments are moved to the same line as the entry it describes

Advantages

Reduces/removes the chance of merge conflicts occurring
~~Removes duplicate entries for players who participate and win a medal~~
Reduces line count

Disadvantages

Would take a lot of effort to reformat the file
~~The way participation medals are calculated might confuse people~~
Repetitive use of words like gold, silver, etc.

707BEATER commented 3 years ago

I think this is a great idea. When I first saw the accolade_data.cfg file it was a bit intimidating and unclear. However, this proposal definitely makes the lines of code a lot more organised and easy to read, as well as fixing the issue of merging conflicts.

bunniewormy commented 3 years ago

sounds good, but i dont like this part

Participation medals are calculated based on gold + silver + bronze + participation Removes duplicate entries for players who participate and win a medal

it's a disadvantage for me rather than an advantage

it should just be 28 lines for 28 participation ribbons even if somebody has 10 gold medals imo, like this also numbering in comments should stay the same

sussy_baka = customhead 420213769 69; gold; # gold 1 - yopyopyop gold; # gold 2 - adadadada silver; # silver 1 - blahaj silver; # silver 2 - amogus bronze; # bronze 1 - sus participation; # participation 1 - blahaj participation; # participation 2 - amogus participation; # participation 3 - yopyopyop participation; # participation 4 - sus participation; # participation 5 - adadadada participation; # participation 6 - alelelelele

if you do this, people will able to know the order of the tournaments every person played it + total amount of participation for each player easily so i think itd be good

(if youre not going to do this id rather keep the current version tbh)

eps0003 commented 3 years ago

it should just be 28 lines for 28 participation ribbons even if somebody has 10 gold medals imo

You didn't state the reason why you believe my proposal is a disadvantage.

There is a risk of someone forgetting to assign a participation accolade if the player also wins a medal. Removing the duplication reduces the risk of this. I believe reducing this risk while reducing the file size outweighs the initial confusion that comes with the change.

also numbering in comments should stay the same. if you do this, people will able to know the order of the tournaments every person played it + total amount of participation for each player easily so i think itd be good

I didn't think people actually went into this file to look at the number of each accolade when it's visible in-game. If they are just looking for the order of each tournament, that order is maintained but just without the number which I don't see as an issue.

If we do end up going with how it is currently, repeating the type of accolade before the number should ideally be removed. However, reformatting the file via code would make that a bit difficult to do so I guess it's fine if it stays.

eps0003 commented 3 years ago

In Discord, Bunnie and I agreed on a mix between her feedback and mine. The format has been updated in the original post.

transhumandesign / kag-base