Community Wad 2015 - Development

First up, if anyone thinks we need a better name for this, then give me some ideas and we can vote on it. Community Wad was just the name I picked when I first started with the original, and it just sort of never got updated to anything better.
Anyway, this thread will eventually be put to rest. It's just a central place to talk about how we want this set up, what we think will work, what we think won't, things like that. Once we have a working version, I'll make some new threads. So far, I've got these in mine: Main, Bugs, Requests, Modders' Discussion. I really doubt it'll stay that organized, but at least the framework for organization will exist.
Currently, I haven't modded 2015 myself, so this is just what I've read in the Information Pending thread. I'll get around to acquainting myself with it in the near future.
Current Modability:
To the best of my knowledge, we can do the following:
We cannot do the following things which would be very useful:
Some of the modding of the game, should the above not be figured out, will involved replacing cards. If this is done, then the AI may end up using the replaced cards as well, ruining their decks (and most likely any of yours that also use the card).
One workaround for this lies in the possibility that the game can handle an unlimited number of cards in a duel and that we can figure out how to add and modify decks by directly editing the profile. Doing so would allow us to use RiiakShiNal's 2014 Deck Builder to build a deck from all of the available cards (after making a folder it can read with all of the game's core cards), and then using a separate program to add that deck to your profile.
Whether or not that's possible, the Community Wad will probably remain more or less the same. It will consist of a Google Drive folder which all modders can access. That folder will be packed daily into a wad, just like the 2014 version. That wad should be usable in-game. I'll write a tool to isolate and convert any cards we can (anything that only uses known functions, and doesn't use deprecated constants or anything).
TFM made a thread for discussing the known differences between 2014 and 2015 (while I was making this thread). We can talk about the differences in card structure and file structure here, though. That thread seems more focused focused on what a card can and can't do, rather than simply how they're different.
Things that need addressed:
In other news, I wonder if the profile is the reason for the card limit. It could also simply be that there's an indexing loop somewhere in the game's code which caps at 1024 and could be removed relatively simply. I don't know the odds of removing or working around that limit, but it will probably decide how we mod, so we should definitely get some tests done on that.
EDIT:
Also, something that was never really addressed in the CW, functions and constants. What I did was each function file contains an organized listing of all constants it uses, all of the functions, what they do, inputs, and outputs. Each constant is also listed in a separate file specifically for looking them up. That file does not declare the constants (they're commented out) but shows the number (to avoid overlap) and which files declare/use those constants (in case they need changed). This has proven very effective at preventing overlap. The different kinds of data chests can share constants, so the constants are separated based on what kind of chest they affect: PlayerDataChest, DuelDataChest, RSN_ObjectDC, RSN_Characteristics. None of these will overlap or interfere with one another, so working with constants to avoid overlapping within them, as well, is pretty simple.
I realize we already mostly do this on our own. I just wanted to discuss it since it's not something which has ever been addressed as a group.
Potential best practices:
Also, function names. Many functions are widely useful, but no one knows about them. Many are confusing and hard to find. One thing I've done with the functions I've written in the CW is to give the function files simple names, and always prefix the functions with the file name. All of the morph functions start with CW_Morph_... This way, when it's seen in a card's code, there is no question about its origin. Which file to look in to see exactly what the function does is obvious. It keeps everything clean and understandable, even with many modders.
Working separately, with everyone making their own mods, prefixing functions with initials made a lot of sense. Do we still want to do that? I personally think it's no longer necessary. If we follow the naming above (which is more widely useful), then avoiding conflicts is a natural side effect.
I'm not trying to dictate anything. I'm just giving a starting point for the discussion.
Anyway, this thread will eventually be put to rest. It's just a central place to talk about how we want this set up, what we think will work, what we think won't, things like that. Once we have a working version, I'll make some new threads. So far, I've got these in mine: Main, Bugs, Requests, Modders' Discussion. I really doubt it'll stay that organized, but at least the framework for organization will exist.
Currently, I haven't modded 2015 myself, so this is just what I've read in the Information Pending thread. I'll get around to acquainting myself with it in the near future.
Current Modability:
To the best of my knowledge, we can do the following:
- Create uncompressed zed files
- Create wad files
- Replace cards
- Add a limited number of cards using wad files
- Add functions and other files using wad files
- Add art files for use in duels using wad files
- Add art for use in duels and the deck builder using zed files
- Unlock cards by modifying the profile
We cannot do the following things which would be very useful:
- Add/modify a deck by directly modifying the profile
Some of the modding of the game, should the above not be figured out, will involved replacing cards. If this is done, then the AI may end up using the replaced cards as well, ruining their decks (and most likely any of yours that also use the card).
One workaround for this lies in the possibility that the game can handle an unlimited number of cards in a duel and that we can figure out how to add and modify decks by directly editing the profile. Doing so would allow us to use RiiakShiNal's 2014 Deck Builder to build a deck from all of the available cards (after making a folder it can read with all of the game's core cards), and then using a separate program to add that deck to your profile.
Whether or not that's possible, the Community Wad will probably remain more or less the same. It will consist of a Google Drive folder which all modders can access. That folder will be packed daily into a wad, just like the 2014 version. That wad should be usable in-game. I'll write a tool to isolate and convert any cards we can (anything that only uses known functions, and doesn't use deprecated constants or anything).
TFM made a thread for discussing the known differences between 2014 and 2015 (while I was making this thread). We can talk about the differences in card structure and file structure here, though. That thread seems more focused focused on what a card can and can't do, rather than simply how they're different.
Things that need addressed:
- Adding decks directly to the profile (this would need to be spirolone or thefiremind or anyone who isn't me and understands that; I'd rather focus on the other things than deciphering the profile)
- Converting the art to zed files (should be pretty simple, I can do this)
- Converting all of the cards that can be (I can also do this)
- Setting up the Google Drive folder and granting editing privileges (obviously that's definitely up to me)
- Deciding how we want to mod*
In other news, I wonder if the profile is the reason for the card limit. It could also simply be that there's an indexing loop somewhere in the game's code which caps at 1024 and could be removed relatively simply. I don't know the odds of removing or working around that limit, but it will probably decide how we mod, so we should definitely get some tests done on that.
EDIT:
Also, something that was never really addressed in the CW, functions and constants. What I did was each function file contains an organized listing of all constants it uses, all of the functions, what they do, inputs, and outputs. Each constant is also listed in a separate file specifically for looking them up. That file does not declare the constants (they're commented out) but shows the number (to avoid overlap) and which files declare/use those constants (in case they need changed). This has proven very effective at preventing overlap. The different kinds of data chests can share constants, so the constants are separated based on what kind of chest they affect: PlayerDataChest, DuelDataChest, RSN_ObjectDC, RSN_Characteristics. None of these will overlap or interfere with one another, so working with constants to avoid overlapping within them, as well, is pretty simple.
I realize we already mostly do this on our own. I just wanted to discuss it since it's not something which has ever been addressed as a group.
Potential best practices:
- Never use a number directly in a card which affects other cards. Always reserve and use a constant.
- Never declare a constant/use a number in a function below 100 to affect a card.
- Never use a number above 99 directly in a card.
- Never use an unbounded variable in a function used in a card's shared data. (Don't do this: "RSN_GetObjectDC(Object()):Make_Chest(Object():GetRef())". Instead, use a constant, and put everything inside that constant's chest.)
Also, function names. Many functions are widely useful, but no one knows about them. Many are confusing and hard to find. One thing I've done with the functions I've written in the CW is to give the function files simple names, and always prefix the functions with the file name. All of the morph functions start with CW_Morph_... This way, when it's seen in a card's code, there is no question about its origin. Which file to look in to see exactly what the function does is obvious. It keeps everything clean and understandable, even with many modders.
Working separately, with everyone making their own mods, prefixing functions with initials made a lot of sense. Do we still want to do that? I personally think it's no longer necessary. If we follow the naming above (which is more widely useful), then avoiding conflicts is a natural side effect.
I'm not trying to dictate anything. I'm just giving a starting point for the discussion.