Remove all <related> for <reverse-related>

[mainman879]

"related" was used a handful of times and never seemed to be very consistent when it was used. This change makes it so that every single relation uses "reverse-related" instead.

[mainman879]

@tooomm just mentioning you because you were interested in this change.

[tooomm]

"related" was used a handful of times and never seemed to be very consistent when it was used. This change makes it so that every single relation uses "reverse-related" instead.

you were interested in this change.

It doesn't have to be this change exactly.
But I noted the inconsistency and want to think about a uniform way in handling our relations.

The general way is to reverse connect cards, and that is for a reason. The token creating source is simple not part of the file and we have to do it that way. That's mostly the case when a token is created by a card.
For other creators the source is a token defined in the file already, so we have the option to directly connect it and list the token output there. That's mostly the case when a token is created by another token.

Token <---reverse-related--- Card
Token ---related---> Token

Token <---reverse-related--- Token works as well of course and is used as well. Sometimes even additionally.

As an example I pulled Kiora and Basri:

• normal entries show the card relation between each other
• bold entries are the ones that are actually present in the token file

External Card DB	Token DB	Token DB
x	<---reverse-related--- ---related--->	<---reverse-related--- (but to PW, even though the creator is the emblem!)

External Card DB	Token DB	Token DB
x	<---reverse-related--- ---related--->	<---reverse-related---
	<---reverse-related---

The above example shows that it's not always done in the same way, some are defined from both sides, some only related etc.
I'm aware that not all of them are needed to make the file work! But describing relations from both direction can be helpful when working with the file and make it easier to understand a connection no matter at which single entry you look.

What do others think?
Is it a useful enhancement to always have "double tags from both direction" when looking at the file?
Or should we always use reverse-related only?

Are there cases where we need the related tag and can not use reverse-related?
If not, just going with reverse-related always results in the cleanest token file, but working with it can be a bit tricky sometimes.

Something like my example above can be part of the docs to better describe and understand how the file works.

[mainman879]

What do others think?
Is it a useful enhancement to always have "double tags from both direction" when looking at the file?
Or should we always use reverse-related only?

I think there is no real benefit to having redundant entries. We should try to avoid it when possible as it's just bloat.

Are there cases where we need the related tag and can not use reverse-related?

I cannot think of a single instance where related would be needed instead of reverse-related.

If not, just going with reverse-related always results in the cleanest token file, but working with it can be a bit tricky sometimes.

I do not see how related or reverse related can be trickier than the other.

[tooomm]

I cannot think of a single instance where related would be needed instead of reverse-related.

Me neither. Probably a safe pattern then to always go with reverse-related over related connections and unify the token linking style. 👍

If not, just going with reverse-related always results in the cleanest token file, but working with it can be a bit tricky sometimes.

I do not see how related or reverse related can be trickier than the other.

If you only think about putting the data in, there is not too much difference probably.

But if you also consider people looking in the file for reviewing or checking entries there is a difference.
The related tags are more straight forward and right below e.g. the emblem with its text describing what it does, you often see if the connection is correct or not right away. With reverse-related you have to jump back and forth in the file and it therefore can be more error prone in theory.
It's only a small portion of connections though. And Angel__ doesn't tell you if it's the one with the right keywords... so, yeah.

I'm fine with always going for reverse-related. 👍

[mainman879]

But if you also consider people looking in the file for reviewing or checking entries there is a difference.
The related tags are more straight forward and right below e.g. the emblem with its text describing what it does, you often see if the connection is correct or not right away. With reverse-related you have to jump back and forth in the file and it therefore can be more error prone in theory.
It's only a small portion of connections though. And Angel__ doesn't tell you if it's the one with the right keywords... so, yeah.

I'm fine with always going for reverse-related. 👍

Whether we go with related or reverse related would result in very similar amounts of jumping around. I think that it would even result in more to use related at all. The reason for this is that all token information is in its own individual entry, so any "related" instead of "reverse related" would require you to confirm that the related token is correct.

For example lets use the same example above of Basri Ket's emblem. There is only 1 Basri Ket emblem, but 7 different "Soldier" tokens. So if you do a "related" relation from the emblem to the soldier you are required to double check all 7 soldier tokens to make sure you get the right one, then go back up to the Basri Ket relation and make sure it has the right number of spaces. If you do reverse related however you know there is only one emblem to be related to, so you do not need to double check with it.

[tooomm]

I think this is good practice

Once this is approved and merged, I'll update the little docs compilation in the wiki and put a note there.

Edit: Now all related tags are gone

[Psithief]

There was never meant to be any consistency.

Using <related> on the source or using <reverse-related> on the target are completely equivalent, so it was up to the author (i.e. me for a very long time) to use whatever they felt like using.
If it was more convenient for me to write <related> on a new token that created an existing token then I'd do that instead of going to the target token and inserting a <reverse-related> there.

For example, I assume that when I first wrote <related> for Kiora's emblem, it was less effort to write <related>Kraken</related>.

Other examples of <related> were

• Boar making Food. Food already existed, but this Boar was new, and creating the relationship meant not needing to update the Food section.
• Whale making Kraken, it says <text>When this creature dies, create a 9/9 blue Kraken creature token.</text>, so why go find the Kraken token when it can be linked from here and the element's done?

I'm fairly sure I also would have left it in as an example of what the system was actually capable of.
If you have a <reverse-related> element, what's the original element? Here was an example of that mystery element.
Presumably it could have been useful for anyone making their own token files.

@tooomm The Kraken's relationship to Kiora, the Crashing Wave was an error made by Zach but not caught until now.

@mainman879 Enforcing consistency here means removing a tool from the author's toolbox. I strongly disagree that there's any benefit to this.