The "2000 limit no more" CSV

[Mok]

Can't the Deck Editor now show cards with special characters like Æther Vial?

Initially I thought the same, but then noticed the cards are there. For some reason the system sorts them after C and before D, so just press D and go back to get to them. I have no control over that as the list is managed by a standard system listbox. It can be modified (probabaly) to use custom sorting routine but it's harmless so not worth the effort

[Aswan jaguar]

Mok I am testing right now and can't thank you enough not only for the no2k limit that is a bad memory but also the game runs faster.

I meant the images are not showing.With the previous test release 2k_v1 and final csv from Sonic those images were showing.That's why I am wondering if there was a change.

[Mok]

I meant the images are not showing.

Ah, no, my cardartlib replaces each special & accented character by another one. In case of AE symbol it's E. If you were using Snacko's version, try it. I heard it has some problems with newest files but I haven't checked myself.

[Aswan jaguar]

Yes I am using Snacko's CardArtLib.
Edit* I love that you used Sonic symbols now that I see them in game they are much clearer than previous.

[gmzombie]

at least for me snackos mod does give me card art but it changes the AE cards to a ?ther but they still come up first.

[Mok]

Yes I am using Snacko's CardArtLib.
Edit* I love that you used Sonic symbols now that I see them in game they are much clearer than previous.

Actually I'm not using Sonic's symbols only his card backgrounds. Symbols were redone from scratch as the old ones were not enough for new cards.

If you are using Snacko's cardartlib then it should work like before (I think) as long as you replaced cardardlib.dll with his version. My cardartlib looks only into CardArtNew for images and not into the directory used by Snacko's replacement, the filenames require stripping of accented characters too, so not all will display correctly even if the dir is renamed.

[Aswan jaguar]

Most of our decks,all the newest and some old ones don't have the right cards in them as number sequence has changed so deck editor puts the cards that replaced them.Can't we make the Deck Editor to save them only with their card names and get loaded to the game with their names and not numbers?
Otherwise we should start manually and remake them.

[gmzombie]

i didnt have a problem with any of my decks and ive updated to the 2k no more + snackos mod..

io thought that i had a different deck but it only had 1 card that was different..im sure if i used some of the newer cards beforehand they might be different as well but im old school lol

[foolosopher]

Happy new year gang, it seems that we are good on the way to overcoming the 2k limit, I am currently testing 2k_v2 + snacko's cardartlib and only have the problem of AE showing as ? like gmzombie. Also in one game the AI stuck, but I think it's the usual problem and not 'cause of Mok's changes. A number of cardart is missing.

Gargaroz if you need help testing the tools Mok gave you, I am in. I would particularly like to check the csv-exe editor, and sources if they are available. Once csv is finalised, or at least the issue with representing the different expansions I can update the draft.c.

Another thing, I have a number of decks that don't show up due to csv diffs. I remember reading somewhere in the forums that someone had made a converter for this job but couldn't find it, so please post the link if you know it. It will save me and a few others quite some time.

And last but not least have a year's 2011 review, I like people telling stories

[Sonic]

Copied from 'Patches' thread.

Most of the long dashes in the text had been removed.

That's unfortunately a side effect of a gatherer export I used. Sorry, I wasn't going to apply changes by hand, there were too many of them. If I noticed it before... but now it's too late

I'm also restoring 'cutoff' text for the Planeswalkers. Excel has been whinging at having a formula symbol in the rules text field and returns a error when you try to correct the text.

Interesting. Did it happen only in the cells that started with "+"? I guess when excel assumed it's not a string cell, it cut it off for some reason. If you switch the cell to a string, it will allow fixing it in excel, but I'm curious if it won't cutoff the text again later.

Actually, the dashes had been removed from the Oracle file I uses as well. But no problem, I didn’t mind correcting them by hand. I think I’ve found all of them now.

The Excel/Planeswalker text problem is somewhat confusing. If it was related to the plus symbol it would affect all the planeswalker cards, but it doesn't. As you say, converting the offending cell to 'text' solves the problem - but weirdly you can convert it back to 'general' after you've correct the text without problems (unless you want to edit it again).
It only affects csv file imports though - as once the text has been corrected and saved as an xls file it retains it on reloading. Even works saving and loading as an xls file in OpenOffice.
So to be honest with you I think we’re going to have to keep the Excel file, and possibly stop distributing the csv files as they only seem to act as a resource for the updating process now. Especially when so many people use Excel, and it doesn’t really work for importing csv files.

Remember I’m not a coder, so feel free if any of the following falls under the heading of ‘utter twaddle’.
A few questions about the Sleight and Hack codes; I noticed you'd enter them, but some seem incorrect to my understanding. I’ll correct them manually if needs be.

Hack

|H1 = relates to an instance of a named Land - Swamp, Plains, Island, etc.

|H2 = Land based ability - Swampwalk, Plainswalk, Islandwalk, etc.

I’ve found the codes in the ‘Type Text’ field - I was under the impression that Sleight and Hack only work on the 'Rules Text' field.

Sleight

According to the Text.res and Texz.res files – and using the ‘_BLACK’ entry purely as an example - Sleight would seem to work on the following 4 text strings.

@WORDSTOSLEIGHT_BLACK
4
black
Black
non-black
non-Black

I assume as part of the coding 'black/Black' relates to the relative colour and 'non-black/non-Black' relates to all colours other than the named colour - so inserting the ‘|S’ code mid string in the ‘non-black’ text – as in 'non-|Sblack' – could possibly cause problems.

Although, the ‘non-Black’ entry seems a bit strange anyway, as the colours are never written capitalized in the rules text, unless at the beginning of a sentence, and ‘Non-black’ would be more grammatically useful for the same reason.

Anyway, as far as I can make out from the Oracle file is all instances of ‘non-black’ have now been replaced with ‘nonblack’.
So would changing the text strings in WORDSTOSLEIGHT_XXXXX entries in the Text/Textz.res files be enough to adapt the Sleight codes to the new wording – or is there more coding involved?

[Mok]

Hack

|H1 = relates to an instance of a named Land - Swamp, Plains, Island, etc.

|H2 = Land based ability - Swampwalk, Plainswalk, Islandwalk, etc.

I’ve found the codes in the ‘Type Text’ field - I was under the impression that Sleight and Hack only work on the 'Rules Text' field.

Nope, I dunno where you got that info from but as far as I understand it, there's just:
|H - "a swamp", "an island", "a forest", "a mountain", "a plains"
|H1 - plural form so "swamps", "islands", "forests", "mountains", "plains" (ofc plains can use either |H1 or |H2)
|H2 - anything else (singular) so "swamp", "swampwalk", "nonswamp", "non-swamp" etc.

According to the Text.res and Texz.res files – and using the ‘_BLACK’ entry purely as an example - Sleight would seem to work on the following 4 text strings.
(...)

The truth is, all sleighted/hacked changes are only that... a text replacement. It doesn't matter what kind of |H/|S tag is used for the card to work. Properly coded card will work even if the tags are missing completely. So as long as it displays after using a hack/sleight card, it's fine. I agree that I haven't tested it much, but from my point of view, adding special version for "non-", "non" or whatever is unnecessary. The code replacing is not comparing words, but going byte by byte to find a |S. So it should work. I haven't checked it much though. Doesn't really matter at the moment, a lot of cards are badly coded anyway and won't work hacked/sleighted properly.

(Edit: Just tried it on Angelic Voices and after change the card displayed "nonBLUE" so while it may not look the best, it works without any special tags, just normal "non|Swhite".)

As for hacking the type text, I only added cleaning the type line from |H tags so far. Adding proper support won't be trivial as normally you can just hack a forest into becoming a plains. Here it's not so simple. The original engine didn't support hacking type line as it was added to rules much later.

[Sonic]

OK. I’ve had to shuffle your posted quotes a bit, in an attempt to make my reply clearer.

Hack

|H1 = relates to an instance of a named Land - Swamp, Plains, Island, etc.

|H2 = Land based ability - Swampwalk, Plainswalk, Islandwalk, etc.

Nope, I dunno where you got that info from but as far as I understand it, there's just:
|H - "a swamp", "an island", "a forest", "a mountain", "a plains"
|H1 - plural form so "swamps", "islands", "forests", "mountains", "plains" (ofc plains can use either |H1 or |H2)
|H2 - anything else (singular) so "swamp", "swampwalk", "nonswamp", "non-swamp" etc.

Actually, now I’ve looked more closely into it that makes a lot more sense than the CSV information found in the WIKI – and would further be confirmed by the following information found in the Text.res file.

@WORDSTOHACK_BLACK
6
1swamps
1Swamps
2Swamp
2swamp
a swamp
a Swamp

As in:
|H1 = swamps/Swamps
|H2 = Swamp/swamp
|H = a swamp/a Swamp

I agree that I haven't tested it much, but from my point of view, adding special version for "non-", "non" or whatever is unnecessary. The code replacing is not comparing words, but going byte by byte to find a |S. So it should work. I haven't checked it much though.

The suggestion wasn’t to add a special version for “non” – merely remove the hyphen from the current “non-” in the list of currently recognised Sleighted text strings. (See below)
Now the Oracle rules text have removed all instances of the hyphenated “non-colour” string. The only cards in the current xls file still using the original hyphened wording in its rules text is ‘Necropolis of Azar’. Obviously this card being unique to the game never existed as paper stock and therefore isn’t included in the updated Oracle rules – its current text is taken from its original wording.
So by removing the hyphen from the wording in this single card, the hyphened text string “non-” becomes redundant throughout the entire game.

The truth is, all sleighted/hacked changes are only that... a text replacement. It doesn't matter what kind of |H/|S tag is used for the card to work. Properly coded card will work even if the tags are missing completely. So as long as it displays after using a hack/sleight card, it's fine.

Purely as a bit of deductive reasoning on my part (and I’m not challenging your considerable coding knowledge one iota here), but as to whether within the code, the string “non-colour” has any actual relation to a coding equivalent of ‘all other colours other than the named colour’ is in fact relevant. Logically, the fact that a “non-colour” string is specifically listed and therefore identified as being different from just a single named “colour” string would tend to suggest it might hold some significance in that respect – even looking at it from the point of view of a non coder.

(Edit: Just tried it on Angelic Voices and after change the card displayed "nonBLUE" so while it may not look the best, it works without any special tags, just normal "non|Swhite".)

Taking that exact point and adding it to my observation of the possible significance of the “noncolour” string above – plus the fact that currently Sleight seems to be set up to recognise a hyphen in a “non-colour” text string.

Checking the Cards.dat file from the original Microprose game shows that the original usage of |S in relation to a “non-colour” text string was “|Snon-colour”

Terror - |Snon-black
Holy Light - |Snon-white
Necropolis of Azar - |Snon-black

So to use your Sleighted White-to-Blue as an example, and the information in the current Text.res file. You find the wording of “non-” will not actually be capitalized after the text has been Sleighted – whether the |S tag in the rules text is entered, “|Snon-white” or “non-|Swhite”.

@WORDSTOSLEIGHT_WHITE
4
white
White
non-white
non-White

@WORDSLEIGHTED_BLUE
4
BLUE
BLUE
non-BLUE
non-BLUE

Subsequently the resultant ‘user observed’ Sleighted text will read “non-BLUE” regardless of whether it relates to a Slighted ‘colour’ or ‘non-colour’ text string.

Which raises the question: If “non-” in a rules text string has no user information or other coded significance; why then account for it at all?

In fact, with all the “non” entries in the current xls file set to “non|Scolour” that is exactly the case – all instances of “non” in the text strings are entirely ignored. Effectively rendering the “non” wording irrelevant as a recognised Sleighted text string.
Although, I’d possibly conclude that Sleight won’t currently work when tagged as “|Snonblue” anyway – due to the Oracle rules text removing the hyphen after “non” as previously mentioned.

Doesn't really matter at the moment, a lot of cards are badly coded anyway and won't work hacked/sleighed properly.

And that’s partly where my thinking has been going - if there is a significance in the coding to having “non” in a text string and all the rules entries are tagged “non|Swhite” rather than the expected “|Snonwhite” – none of the cards identified as having a “noncolour” string will work anyway, whether they are correctly coded or not.

I hope all this makes sense – I’m pretty sure there’s some element of logic in there somewhere if I’ve only I’ve explained it right. Just throwing a few ponderings about as food for thought, really.

As for hacking the type text, I only added cleaning the type line from |H tags so far. Adding proper support won't be trivial as normally you can just hack a forest into becoming a plains. Here it's not so simple. The original engine didn't support hacking type line as it was added to rules much later.

I was under the impression the Hack tag wouldn’t work in the ‘Type Text’ field anyway – and so was surprised you’d entered it into the ‘Type Text’ fields. To find that you’re now attempting to implement Hack in the ‘Type Text’ field goes way above the call of duty in my mind. If as you suggest getting it to work at all will be a feat in itself.

[foolosopher]

Hi guys,
I 've been looking into draft.c in order to fix it. The code logic can stay more or less the same for the time being, but the main problem is how to get the expansions properly. With the current structure of the csv I thought of two ways, which I will describe for scrutiny.
1) scan the expansion columns and select the cards that have some rarity value in the specific expansion column.
2)Create some ready tables for each expansion, probably in the form of delimited files with the name of each expansion, containing only the expansion's cards' names according to card_id.h and each card's rarity e.g
Τther Adept,1
Τther Burst,2
Τther Figment,1
So when trying to find the expansion cards, you scan the relevant file and fill the table[cards_num][rarity] e.g expansion[500][1], and
table[Τther Adept][1];
table[Τther Burst][2];

and the first column will correspond to each card's ID.
The only thing I am not sure if it's doable is if you place in the first column elements the scanned name as characters, it will then be interpreted as an ID according to the definitions of card_id.h
Waiting for your thoughts.

[Mok]

1) scan the expansion columns and select the cards that have some rarity value in the specific expansion column.

Just keep in mind that csv file is no longer directly accessed by the game so it might not be available for any scanning. Columns with expansions are available in rarity.dat. The file is simple (4 bytes with number of cards, 4 bytes with number of expansions and then rarity data). Each expansion takes 3 bits so each card occupies (number of expansions*3+7)/8 bytes of data. Possible values for 3 bits: 0 = nothing, 1 = common, 2 = uncommon, 3 = rare, 4 = mythic, 5 = land, 6 = special, 7 = (unused).

[Gargaroz]

Just keep in mind that csv file is no longer directly accessed by the game so it might not be available for any scanning.

You mean "not the entire CSV file" is accessible from the game, right ?