Introducing the Forge Workshop

[Max mtg]

Have commited some code that redirects the dependencies.
Didn't have a chance to test it though.

PS: You're right about concurrency - hope the static concurrent dictionary solves all problems.

[Max mtg]

If CardRuleReader is moved to core, can you make it so I can have it update existing rules from a new script, as it supported before? Or should I be creating a new CardRules instance whenever changes are made and passing that to a CardDb.getEditor() function?

yes, create new CardRules instances, please. They are meant to be immutable to be widely reused.
find some sample code on the place of the code that has been commented out a while ago.

I'm fine maintaining this dictionary in the GUI code so long as CardStorageReader remains in the GUI code to access it. Though it is going to make things trickier for building the dictionary across multiple threads.

Looks like CardStorageReader could accept some kind of observer at its constructor, and thus all classes interested in newly created cards will get their data.

[Max mtg]

What do you think of establishing a solid schema for text files' name composition, so that you can derive filename directly from card name programmatically (just without that dictionary)?

2. It could be useful for this project if cards loaded from files take priority over cards loaded from zip, so that player could override a few cards' rules, save their scripts into a few files and load those instead of the canonical version stored in zip.
So the 'use zip' parameter will be gone from CardStorageReader and you'll be able to save new versions of cards even if the original is stored in that archive.

[drdev]

What do you think of establishing a solid schema for text files' name composition, so that you can derive filename directly from card name programmatically (just without that dictionary)?

2. It could be useful for this project if cards loaded from files take priority over cards loaded from zip, so that player could override a few cards' rules, save their scripts into a few files and load those instead of the canonical version stored in zip.
So the 'use zip' parameter will be gone from CardStorageReader and you'll be able to save new versions of cards even if the original is stored in that archive.

I was not intending to allow end users to modify existing cards, but rather make a duplicate of the card with a different name and modify that. We need to be able to distinguish between custom cards and real cards.

So there's no need to allow modifying and saving cards loaded from zip file. That's why I currently don't allow editing any such cards.

As for being able to directly map a card name to the file it's stored in, I don't think that helps us any. I'll still want to cache the script text for each card somewhere for the sake of search functionality I'm planning as well as having an easy way to detect changes made, so that structure might as well store a File object too.

[Max mtg]

Ok, as you wish.
Anyway, the load priority is already implemented in CardStorageReader, so if you don't support the idea, we might leave that as it is. Some power users still might add their cards to filesystem to override or extend the card set manually (without support from UI side)

About immutable CardRules... just found a reason against this idea. Imagine there's a deck, you are about to edit certain cards. Since deck holds references to PaperCards, and they in turn link to CardRules, their card rules won't get updated. So... it looks like I'll have to add a method to CardRules to replace its contents with those of another instance. (something like a method copyFieldsFrom(CardRules newRulesShell))

[drdev]

That's why I had it updating existing CardRules objects in the first place. Can we just re-use what I had written into CardRulesReader already that you reverted?

[Max mtg]

That's why I had it updating existing CardRules objects in the first place. Can we just re-use what I had written into CardRulesReader already that you reverted?

Do you mean to read tuples of <Rules, File, Text> instead of just rules?

forge.card.CardDb.Editor.putCard(CardRules, List<Pair<String, CardRarity>>) now handles case when the passed cardrules object matches an existing card, and updates the found instance's fields.

[drdev]

Alright, I think I've got it all working again, though I had to make a few tweaks to what you did. Let me know if it's all acceptable now.

[Max mtg]

I have changed the what didn't seem right in core classes.

[lugaru]

A year and a half ago I started the task of porting a friends custom set he made in 2002 into forge. While I suck at coding, I've got enough cut and paste and trial and error skills to get cards to work on my own slow deadline. At some point I stopped but now that I see Workshop as a tab in every new build, I was wondering if there is currently any unlocked functionality to it in the test builds or is it just there as a placeholder for future development. If you guys do get it working, that would be really exciting for people who make cards as a hobby like me and my friend. Personally I'm porting in my cycle of 5 Legendary 4 color creatures that act as really funky and flavorful commanders.

Also if Workshop becomes a thing and all of the creative types move over to Forge to port their sets... we might need a way to import custom content within forge. Right now it is not too much hassle... copy a stack of folders into the Cardsfolder zip, copy the edition file (a new addition I LOVE) and then modify some other files so it is draftable. That said it would be awesome (once there is a demand for it of course) if we could import a zip from within forge and have it place the cards in roaming, the decks (precons) in decks, files where they go but then allow you to select the parameters of the set you imported (does it show up in Quest Mode? Is it Modern? etc).

Either way just a question and some advice for a distant future (I'm sure a bunch of other priorities exist) and meanwhile I'm back to work on importing custom cards... I've done 60 from his set and 2 of my commanders.

[drdev]

I started the development on the Workshop, however I only got as far as allowing editing of existing script files. I have since moved on to focus on major UI improvements and now starting up the mobile version of Forge. Given the extent of that project particularly, I don't think I'll be returning to work on Workshop anytime soon.

That said, if somebody else wants to step in and add custom card/set creation tools to Workshop as I had originally envisioned, that would be awesome.

I'm glad to hear interest from the community in using Forge to port custom sets. I still have high hopes of seeing downloadable custom content for Forge in the future, and perhaps even built-in community tools for designing, prototyping, and playtesting custom sets.

Thanks.
-Dan

[friarsol]

I'm glad to hear interest from the community in using Forge to port custom sets. I still have high hopes of seeing downloadable custom content for Forge in the future, and perhaps even built-in community tools for designing, prototyping, and playtesting custom sets.

Related to this, I've been considering moving the organization of the cards folder from Alphabetical to first printing.

For example, in Alpha there would be 290 card scripts. In Beta there would be 2 scripts (COP Black and Volcanic Island). Unlimited or Chronicles would have 0 scripts. For new sets, if the card is a reprint, it wouldn't be added to the folder (since it already exists).

In this manner we would still have a similar structure for scripts we have now that would be more conducive towards Custom Sets. We wouldn't have the issue of 1900 files in the S folder, since the most files a single folder would have is a few hundred scripts. Theoretically, there could be some support for checking this folder for an edition file, which would load the edition into Forge, even though it doesn't exist in the res/editions/ folder. It would be formatted exactly the same as current edition files, thus making the whole custom set a single drop into a single directory.

[lugaru]

Thanks! Even if the Workshop can is kicked way down the line and probably requires somebody else to pick it up, editing text files still works perfectly fine now.

As for possibly switching the format from A, B, C, D to like Alpha, Beta, etc. would be huge in terms of easily adding custom sets. Also if it creates a file for the Editions folder, man that is a time saver, it took me about an hour+ to type up my friends one. Now my understanding is that the big advantage of the Edition folder is that it allows for multiple versions of cards (like gorgeus Zendikar lands or reprints with new art) but we can always add those manually after 99% of the work has been done for us by a script.

[drdev]

I'm glad to hear interest from the community in using Forge to port custom sets. I still have high hopes of seeing downloadable custom content for Forge in the future, and perhaps even built-in community tools for designing, prototyping, and playtesting custom sets.

Related to this, I've been considering moving the organization of the cards folder from Alphabetical to first printing.

For example, in Alpha there would be 290 card scripts. In Beta there would be 2 scripts (COP Black and Volcanic Island). Unlimited or Chronicles would have 0 scripts. For new sets, if the card is a reprint, it wouldn't be added to the folder (since it already exists).

In this manner we would still have a similar structure for scripts we have now that would be more conducive towards Custom Sets. We wouldn't have the issue of 1900 files in the S folder, since the most files a single folder would have is a few hundred scripts. Theoretically, there could be some support for checking this folder for an edition file, which would load the edition into Forge, even though it doesn't exist in the res/editions/ folder. It would be formatted exactly the same as current edition files, thus making the whole custom set a single drop into a single directory.

For organization sake, could we maybe take this one step further and have a folder for each block, and then have subfolders for each set in the block? We should also create a separate folder for custom vs. printed sets so we don't end up overwriting somebodies custom sets if Wizards decides to release a block or set with the same name. It will also allow us to differentiate between custom and non-custom cards in Forge, which could be nice for Deck Editor filters, but would be definitely necessary for network play.

Since there are also standalone sets to consider, I'm envisioning a structure like this:

What do you think? Even if you guys don't like the idea of having separate folders for blocks, I'd still highly recommend having separate printed vs. custom folders. Or perhaps just load custom cards from AppData instead of looking for them in the res folder.

[lugaru]

Just wanted to add that I'm working on my first 'forge mod' which is really simple... 5 new cards, one alternate art. I may be able to set up a 'mods' thread in whatever section you guys consider appropriate (either main or development).

I've got 'two more coming' but those will be forever, one is my friend Tom's huge (360 card) set and one is a really gorgeous mesoamerican (Aztecs and pirates) set made by another guy who gave me permission to port it to forge.