Allow custom types

[Eradev]

Allow Forge to read .txt files inside custom/typelists folder so set creators can add non-existing types.

[tool4ever]

It'd be nice to have it closer coupled with specific editions so non-legal types like Cyborg can also be moved.

[Jetz72]

Yeah, a single custom user typelist won't solve the issue that anyone installing a custom edition would have to manually merge them.

[Eradev]

It currently parse types before we handle the card rules files, and that is before the editions. I don't see exactly how it could be tied to editions easily?

[Jetz72]

Hmm. I think the custom editions folder is structured custom/cards/SET/[cardScripts] and custom/editions/setName.txt. I'm not a fan of this structure (decided to jot down the alternative I have in mind at #8126) but we could add custom/cards/typeLists/setName.txt as a temporary measure. Any file in that directory just gets loaded and thrown into Forge's type lists.

[Eradev]

The custom/cards folder can be anything really. You can just dump them all in one big folder and it'd work.

And I agree. It would be much easier to add a set if you didn't have to move between different folders.

[tool4ever]

It currently parse types before we handle the card rules files, and that is before the editions. I don't see exactly how it could be tied to editions easily?

editions are loaded before CardRules
so the order is fine imo

[Hanmac]

Probably need to remove the already exists checks, Spacecraft is already in two

[Eradev]

@tool4ever Is there more requested changes for this? I know @Jetz72 want to rework the way we load custom editions, but it'd be a breaking change that require more tinkering. This can be a stopgap so users don't need to constantly edit the typelists.txt file every time they update until we do.

[Jetz72]

My only concern is that we might add support for something then delete it or have to implement extra backwards compatibility stuff later. But we kinda make breaking changes to the card scripting API all the time anyway, and we have to include support for a bunch of stuff in the custom directory anyway if we're gonna modularize stuff later, so I guess that part isn't an issue.

It'd still be nice if we had a way for multiple custom sets to have their own types without needing to merge things manually, but I don't know if this will be used often enough to justify the extra work.

[Eradev]

It'd still be nice if we had a way for multiple custom sets to have their own types without needing to merge things manually, but I don't know if this will be used often enough to justify the extra work.

This already allows multiple sets to have their own type. It reads from all .txt inside a the custom\typelists, and ignore the existing types when adding.

[tool4ever]

@Eradev
well like I said when I looked at the code it seemed to load editions first...?
so I think you can easily add types as part of them instead which would make the whole process a lot smoother 🤷‍♂️

[Eradev]

@Eradev well like I said when I looked at the code it seemed to load editions first...? so I think you can easily add types as part of them instead which would make the whole process a lot smoother 🤷‍♂️

It seems to be loaded after at magicDb = new StaticData(reader,

[tool4ever]

yes inside the construction there you're loading editions first, then rules :p
that's the order you want...

let me try like this:
all you basically need to do is refactor loadDynamicGamedata slightly so it can be called with any given text file which you can then apply once for each edition

[Jetz72]

This already allows multiple sets to have their own type. It reads from all .txt inside a the custom\typelists, and ignore the existing types when adding.

Oops, missed that revision. Seems good then.

all you basically need to do is refactor loadDynamicGamedata slightly so it can be called with any given text file which you can then apply once for each edition

To clarify, you mean defining type lists directly inside custom edition files? That might be neat. Arguably overloads the responsibility of edition files, but custom editions probably do need to be able to do more than regular editions so they can extend the game like this.

Also brings to mind that that big if-tree when iterating over the file might be better handled by the FileSection utilities, like what CardEdition uses. Dunno how much that actually improves things though.

[tool4ever]

thanks