SQLite Data Engine

[Braids]

Ah, they were being passed through getCard. Do we actually need to do that?

`
lots of things call CardFactory.iterator() {often by treating AllZone.getCardFactory() as an Iterable}. many if not all assume that the Card objects are results of getCard.

The way I see it, the only thing needed outside the game(and that may exclude libraries) is oracle text(and other characteristics), and that should be parseable in ReadCard using Description tags.

`
possibly so. i don't want to put oracle text in our txt cards if we can help it. ReadCard CardReader could get the Oracle text from some other file. why? unless we want to keep relocating our repository from the Dimwits Making Copyright Allegations DMCA whiners, we must keep Oracle text outside the code repository.

Even if we don't want to create a separate UnparsedCard class, I'm fairly certain that could be added to Card as a boolean, and checked in e.g. DefaultPlayerZone.add.

`
i'd advocate for a separate class. it's easier to understand. though i think the name could use some work. then again, i could be swayed toward using a relational db for oracle information. notice the pun? maybe it's not a pun. i somehow doubt it's a coincidence that the official card text is called "Oracle" when that is also the name of a popular relational database management system.

would a relational database be faster or more memory efficient than Generators? we would need hard evidence to be certain.

By "fleshed out" cards I meant Card Objects, in the MTG Rulebook sense, but yes, the existence of hand/grave abilities does require slightly earlier parsing.

`
i know that Forge checks for static abilities on cards in libraries. i'm not sure why, though. i would tend to think that only cards in hands, exile, battlefield, graveyards, and command zones need abilities. if someone knows of a counterexample, i'd love to know. 1996 World Champion does not count.

And finally, I'm not quite sure if I am volunteering for anything, but I may indeed have a decent amount of free time within the next month.

`
ok.

[zerker2000]

lots of things call CardFactory.iterator() {often by treating AllZone.getCardFactory() as an Iterable}. many if not all assume that the Card objects are results of getCard.

Right, but would they break if fed CardFactory.map data instead?

possibly so. i don't want to put oracle text in our txt cards if we can help it. ReadCard CardReader could get the Oracle text from some other file. why? unless we want to keep relocating our repository from the Dimwits Making Copyright Allegations DMCA whiners, we must keep Oracle text outside the code repository.

My problem with that argument is that we already are, spread as it is across CardFactory*.java and cardsfolder/*/*(and possibly AbilityFactory*, though when I last checked all AFs used $Description).

Even if we don't want to create a separate UnparsedCard class, I'm fairly certain that could be added to Card as a boolean, and checked in e.g. DefaultPlayerZone.add.

`
i'd advocate for a separate class. it's easier to understand.

Though it may be better coding practice, it does necessitate the refactoring of all CardFactory.iterator() users, which may otherwise be avoidable.

i know that Forge checks for static abilities on cards in libraries. i'm not sure why, though. i would tend to think that only cards in hands, exile, battlefield, graveyards, and command zones need abilities. if someone knows of a counterexample, i'd love to know. 1996 World Champion does not count.

Not explicitly, but casting restrictions(e.g. Skyshroud Condor) work wherever, and are technically static abilities(I'm not sure how/if they're implemented in forge). Either way, any revealed card should be parsed completely.
Also, you missed _____.

[Rob Cashwalker]

would a relational database be faster or more memory efficient than Generators? we would need hard evidence to be certain.

If the field you're searching for is indexed in the database, then it is quite a bit faster than filtering. The index is usually stored and processed as a binary tree, which you're quite familiar with. Memory wise, I can only say that we shouldn't need 8500+ cards-worth of ability objects in memory at any time, which the database could hold anyway. The only data it would need to contain is the printed text, name, mana cost, type, set/rarity, rules text, p/t and possibly the SVar metadata. Then add the indexing trees for nearly every field the DB and you still probably clock in at a lower total volume of memory needed.

The biggest advantage would be in the simplicity of pulling lists meeting nearly any combination of parameters with no explicit code or confusing Lamda Lamda Lamda Nerds.

[Braids]

lots of things call CardFactory.iterator() {often by treating AllZone.getCardFactory() as an Iterable}. many if not all assume that the Card objects are results of getCard.

Right, but would they break if fed CardFactory.map data instead?

`
yes, definitely. it happened. now, it may be interesting to store allCards' contents in the map's values instead. but i don't know what would break. it would probably be very subtle.

. . . i don't want to put oracle text in our txt cards if we can help it . . . why? unless we want to keep relocating our repository from the . . . DMCA whiners, we must keep Oracle text outside the code repository.

My problem with that argument is that we already are, spread as it is across CardFactory*.java and cardsfolder/*/*(and possibly AbilityFactory*, though when I last checked all AFs used $Description).

`
my vision is to only have Java code specific to the rules of the game and to certain cards. i'd prefer we store and distribute the rest in some other fashion. perhaps this isn't important until our repository gets hit with its first cease & desist. which hasn't happened yet. at least my pestering will have made people aware beforehand. we've already moved to a distributed revision control system as a result, to protect the repository.

i'd advocate for a separate class [like UnparsedCard or such]. it's easier to understand.

`
Though it may be better coding practice, it does necessitate the refactoring of all CardFactory.iterator() users, which may otherwise be avoidable.

these would have to be changed anyway. just about everything iterating over the CardFactory is interested only in printed/Oracle data. rarity, color, sets.

[Braids]

would a relational database be faster or more memory efficient than Generators? we would need hard evidence to be certain.

If the field you're searching for is indexed in the database, then it is quite a bit faster than filtering. The index is usually stored and processed as a binary tree, which you're quite familiar with.

but is this stored in RAM?

Memory wise, I can only say that we shouldn't need 8500+ cards-worth of ability objects in memory at any time, which the database could hold anyway.

true enough.

The only data it would need to contain is the printed text, name, mana cost, type, set/rarity, rules text, p/t and possibly the SVar metadata. Then add the indexing trees for nearly every field the DB and you still probably clock in at a lower total volume of memory needed.

ok. that sounds cool.

The biggest advantage would be in the simplicity of pulling lists meeting nearly any combination of parameters with no explicit code . . .

no explicit code? how would you manage that? sql counts as code.

[Snacko]

Yes in memory db isn't something new.
You can check out a DeckEditor in java I maintain viewtopic.php?f=29&t=464. It uses h2 in memory db + on disk serialization for sql queries.

[zerker2000]

my vision is to only have Java code specific to the rules of the game and to certain cards. i'd prefer we store and distribute the rest in some other fashion.

My vision also heavily features forge understanding card plaintext. As things stand, however, half of cardsfolder has AF scripting. This code, while admittedly non-java, does specify the behaviour of relevant cards. Sure, if a proper parser was set up, we could simply use a scrape of Gatherer; when I tried to, it was as difficult as you would expect, and I ultimately ran out of time/steam. Something may be concocted in the future, but for the moment, forge includes the cardset. Is there any harm in reusing it?

[Braids]

my vision is to only have Java code specific to the rules of the game and to certain cards. i'd prefer we store and distribute the rest in some other fashion.

My vision also heavily features forge understanding card plaintext. As things stand, however, half of cardsfolder has AF scripting. This code, while admittedly non-java, does specify the behaviour of relevant cards. Sure, if a proper parser was set up, we could simply use a scrape of Gatherer; when I tried to, it was as difficult as you would expect, and I ultimately ran out of time/steam. Something may be concocted in the future, but for the moment, forge includes the cardset. Is there any harm in reusing it?

`
specifying the behavior of a card in a scripting or programming language is not the same as copying the card text. that is defensible in countries such as Germany, from what i've heard.

you want to parse plaintext and convert it to the scripting language? i've heard that discussed before. it is a real innovation!

reuse what is there, eh, ok. at the very least, are you able to avoid placing any more verbatim oracle text in the repository? or can you store your card text elsewhere and have the user download it separately?

[jendave]

my vision is to only have Java code specific to the rules of the game and to certain cards. i'd prefer we store and distribute the rest in some other fashion.

My vision also heavily features forge understanding card plaintext. As things stand, however, half of cardsfolder has AF scripting. This code, while admittedly non-java, does specify the behaviour of relevant cards. Sure, if a proper parser was set up, we could simply use a scrape of Gatherer; when I tried to, it was as difficult as you would expect, and I ultimately ran out of time/steam. Something may be concocted in the future, but for the moment, forge includes the cardset. Is there any harm in reusing it?

A good place to start is viewtopic.php?f=27&t=1347
The "Magic Data" project scrapes the Gatherer and puts it into plain text or XML. I did look into creating a DSL for parsing the text into code, but it is quite a task. You may want to look at jRuby or Scala. Good luck!

[Rob Cashwalker]

Quite frankly, I don't mind Oracle text residing in each supported card.txt file. What I didn't like was the data file for the entire current-known multiverse having to be distributed in the beta release.

Having the Oracle text available in the card files would benefit the deck editor immensely, as the cards don't need their objects populated just to display the right text. Therefore the card object could be created more dynamically.

I'm considering using Java to dynamically manipulate the card.txt files to add/update the draft data as SVars. I don't see any reason a similar in-game function could be used to pull the oracle text into the card file post-distribution.

[Braids]

Quite frankly, I don't mind Oracle text residing in each supported card.txt file. What I didn't like was the data file for the entire current-known multiverse having to be distributed in the beta release.

Having the Oracle text available in the card files would benefit the deck editor immensely, as the cards don't need their objects populated just to display the right text. Therefore the card object could be created more dynamically.

how about putting that oracle text into a database (sql, berkeley, whatever) outside the git repository and have forge download/update the database post-install? that would leave card txt files to just contain script code and whatever other metadata they need for rules implementation.

I'm considering using Java to dynamically manipulate the card.txt files to add/update the draft data as SVars. I don't see any reason a similar in-game function could be used to pull the oracle text into the card file post-distribution.

those txt files are heavily tied to the current practice of loading the entire multiverse of cards.

[Rob Cashwalker]

The trick is that I'm not sure there's any way to reliably modify an SVar of the original card object, as opposed to all the copies that get made. Modifying the card.txt file pretty much guarantees that all future copies of the card will have the right meta data. (at least following a restart...)

[Braids]

The trick is that I'm not sure there's any way to reliably modify an SVar of the original card object, as opposed to all the copies that get made. Modifying the card.txt file pretty much guarantees that all future copies of the card will have the right meta data. (at least following a restart...)

i'm losing steam in this discussion. can you continue with a backup plan to reduce verbatim card texts in case we get a DMCA notice?