NEMESiS wrote:I completely understand your point about having to sacrifice one option for another. I have been pondering the ability to just do the SVN system that you had mentioned and the more I think of it there is no way that we do not have to include the images. While downloading a core WAD weekly (I think nightly would be a bit excessive) how do we account for which images the end-users utilize? It is possible that 3 different user decide to use 3 different images for the same card. What kind of issues could this create? I am over thinking this? Because I think we would need to supply the image. Also, another option would be something like what thefiremind is doing here:
viewtopic.php?f=102&t=7426
No you are not over thinking anything yet. It would depend more on keying and card versions. Since from the sound of it you will be including images in the system, cards are coded to use specific images as such a card if used is bound to that image. Now using multiple images for the "same" card like
Elvish Hunter could be solved simply by keying things to the multiverse id.
Elvish Hunter in the Fallen Empires set has 3 images and 3 multiverse ids (1909, 1910, and 1911) as such there would be 3 "different" cards which point to a single image each. The coding of the abilities would be exactly the same as would most of the rest of the XML (except for flavour text which is different for each version). Then deck creators simply use the version (or versions if they want to spice up their deck with different images) they want. Now using multiverse id as the sole key has another problem, new cards that are released before they are put on gatherer (so we don't know the multiverse id yet). This issue could be solved by temporarily using negative multiverse ids for the database (not sure if it would work in the card XML though) or by using an internally defined key (we make up a key and use that for all records, even if we also store the multiverse id).
If you are going to do the SVN route then cleaning up, updating, and making more accessible the Community DLC SVN might be a better choice as it is already set up and that was probably the original intent. A weekly DLC is the same concept as a nightly and about the only difference would be in how frequently a wad is built. On a proper server this can be done by a batch/shell file which moves/copies files to the appropriate place and runs gibbed tools on them cleaning up afterwards, which would be called by a cron job which could easily be set up to run either weekly, nightly, monthly, etc.... You may not be able to do that on the server that the Community DLC is currently on so moving the SVN to another server may be part of updating it.
NEMESiS wrote:If a card has issues it can be added to a core fix WAD that could be centralized for most mods that are participating in this "repository and bug tracking system." I am thinking that a Core wad might get too massive (if we have to include images) to have to download it frequently.
Also since you will be including images and having a compiled WAD download hosting on a home server will probably not be recommended due to bandwidth considerations.
Though there is an option to reduce bandwidth consumption some. You split the compiled DLC into 2 WADs one contains just images for cards (this should only really change when new card images are added or a card image is replaced with a better image) and a second WAD that contains all the cards and functions (this file will probably change frequently, but will be relatively small in comparison).
NEMESiS wrote:As far as the other questions that you brought up I am going to need multiple answers from other modders on that as this is not for my own convenience but for the community as a whole. I will still answer your points with my own opinions:
At the end of the day I want this to be as simple and as convenient of a process as possible for all of us to use, if this turns out to not be the case then this project won’t work. If downloading a SVN can become too massive or inconvenient then I think version hell would be more appropriate and we can then have a Core Fix Wad as separate download to fix individual card issues. I would also be preferable to have accounts for users that want to upload data but not for those that want to download it (or read only permissions). As for the bug reporting we can have a thread where users can submit their complaints and then we can implement then separately. As far as duplicate submissions, well part of the point of this is to not have us all waste our time making the same card twice. Duplicates will have to be rejected unless the 2nd card can be proven to be better built. We could all add our own signature somewhere in the card to know who made it (if this is something anyone wants to do). Over all, I think it’s just best to allow us all (users with accounts) to just submit or created cards to the system without supervision as it would be too time consuming.
If you go the SVN route then about the only people you would actually want downloading the all the data from the SVN itself would be the actual card developers you would want end-users and deck creators downloading the compiled WADs specifically to prevent "version hell". That way when a person downloads a new version of the Card DLC they get all the properly working cards and all the decks created that use those cards will get "updated" automatically without deck creators needing to change their WADs. Much like how thefiremind and myself have our core WADs which change whenever we add or fix cards, but the deck WADs don't really change because they just reference the core. If you separate images and cards as I mentioned earlier then if a card is fixed people would only need to download just the Card WAD not re-download the images (images didn't change). This would make downloading faster for people just getting card fixes.
If you don't do the SVN route then the system could even be built so that when a person with an account uploads a card their username (accountname) is automatically added as an XML comment to the card's XML (relatively easy to do leveraging existing XML objects in various programming languages). Auto rejecting a second (duplicate) card is probably quite difficult to do in an SVN setup, but could be built into a custom system fairly easily. SVN operates by giving write permissions to all those allowed to contribute and basically trusts them to do what is right. A custom system would allow for a more customized approach, but requires that the system be built whereas SVN is already built and has a limited set of functionality that can be customized. More things could be done with a custom system though like renaming images and auto-updated all cards that reference that image, auto-formatting card XML to conform to a desired format (grouping type, subtype, and supertype tags together, ensuring any color tags come after any casting cost tags, proper indention is used for tags, etc...), automatically adding created by comments, being able to tag cards as needing an update (without actually changing the card XML). An ability search could be added to pull up cards that reference a particular function, has a specific trigger, or keyword (flying, haste, cipher, etc....) which could make updating or creating new cards easier, but would also add complexity to the system. For example someone finds a bug in a card that checks if an opponent has taken damage this turn, if the error requires a function to be updated or changed they could do a search for all cards that use that function which would give them a list of cards that could need changing.
So there are lots of things to think on and a bunch of people we would want to get feed back from both on what they would want from such a system and whether they would use the system or not. Feature wish list, gripes about previous attempts at such systems (what caused previous systems to fail), are pledges to use the system when it becomes available are all things that should be examined. If we were a company it would be relatively easy for the person in charge to say "you will use the new system", but since we are a disjointed group of people working for fun, getting a consensus may be difficult.
NEMESiS wrote:I appreciate your input on this and I don’t necessarily expect it to be a simple process. In fact, I am not even sure if this would even work so I am not getting my hopes high, I am just willing to experiment.
Being willing to experiment is a good approach to starting a project. Some projects intially sound like good ideas, but when it comes time to implement fail. Other projects don't necessarily fail, but require considerable adjustment to become practical and work out quite well only requiring minor adjustments. It is also important to have at least one person play "devil's advocate" (criticize the system, but by pointing where the system will fail or make mistakes rather than just dumping on the idea) as they tend to point out problems or important decision points that need to be addressed to make a successful system. A devil's advocate can also be described as a pre-alpha bug tester as they are mentally testing the system looking for faults (the more specific they can be the better).