2000 cards limit

[foolosopher]

@Gargaroz
this can't be done as Mok suggested as you have global arrays which are constructed way before the variable in magic.exe gets populated with. You have to read cards.dat by yourself then malloc the arrays at dll main.
Well I can make the changes if you don't change anything in decv2 update.

Could we at least make it a bit dynamic by using "sizeof(card_data)" * "card_limit" for the table allocations, or do we have to change hard coded pointers?
I don't know what is happening in the asm part, but if we rewrite the dlls, it should be doable.

[Mok]

@Gargaroz
this can't be done as Mok suggested as you have global arrays which are constructed way before the variable in magic.exe gets populated with. You have to read cards.dat by yourself then malloc the arrays at dll main.
Well I can make the changes if you don't change anything in decv2 update.

Could we at least make it a bit dynamic by using "sizeof(card_data)" * "card_limit" for the table allocations, or do we have to change hard coded pointers?
I don't know what is happening in the asm part, but if we rewrite the dlls, it should be doable.

I don't understand why you can't allocate things on the fly... the original code is mostly like that, apart from a couple of structs on stack that were exactly 2000 entries. You read the global number of cards and use it to allocate your structure. Not everything needs to be static. I'm not a fan of local structs of 1000s of entries on stack. I don't think ManalinkEx.dll needs any modifications in this way, there are mostly cards that look clean.

[foolosopher]

I 'm with you on that, for me the best thing would be to load only the ones you need at a time. The only time you need all the cards is when you open the deck editor, otherwise when you play you only need the cards of the decks which usually is about 120-130 cards. Even for that, maybe we could load it set by set < 2000, but we have to modify the exe and I don't know how to do that.
The problem is that we had the 2000 hard coded at several occasions and that there were some static pointers pointing at certain areas, If we can remove that or make it dynamic, then we remove the limit or this is what I thought so far, please correct me if I am wrong.

[Snacko]

@Gargaroz
this can't be done as Mok suggested as you have global arrays which are constructed way before the variable in magic.exe gets populated with. You have to read cards.dat by yourself then malloc the arrays at dll main.
Well I can make the changes if you don't change anything in decv2 update.

Could we at least make it a bit dynamic by using "sizeof(card_data)" * "card_limit" for the table allocations, or do we have to change hard coded pointers?
I don't know what is happening in the asm part, but if we rewrite the dlls, it should be doable.

I don't understand why you can't allocate things on the fly... the original code is mostly like that, apart from a couple of structs on stack that were exactly 2000 entries. You read the global number of cards and use it to allocate your structure. Not everything needs to be static. I'm not a fan of local structs of 1000s of entries on stack. I don't think ManalinkEx.dll needs any modifications in this way, there are mostly cards that look clean.

malloc uses heap not stack, however I agree that there is a lot of sub-optimal code around; no differentiation between passing by value vs reference; magic numbers all around (no enums or not used) and the list goes on;

if you allocate memory on the fly you don't have a place to deallocate it other than dllmain anyway; so you can allocate preemptively and keep allocation / deallocation close code wise;

also gcc won't put variables bigger than 32kB on the stack so it's not a problem; it's important to keep in mind that variables on the stack have a faster creation time and access time; also global variables in c which aren't referenced in other modules end up on heap

those cards you call are pretty much rules extensions which keep huge amount of useful and useless data around in the currently static size arrays

[Mok]

So how many of different 'versions' of the game were/are available? 2 official ones maintained by Gargaroz and how many others (in the past too)? Any links? I'm asking about coded versions and not images/csv/etc. updates.

[Snacko]

The development was pretty much continuous. First people hacked after each other in asm into exe (via olly I suppose) hopefully not overwriting each other (god only knows what got changed and maybe broken). Then c coded cards where the development was fully continuous(jatill -> gargaroz).

[Mok]

The development was pretty much continuous. First people hacked after each other in asm into exe (via olly I suppose) hopefully not overwriting each other (god only knows what got changed and maybe broken). Then c coded cards where the development was fully continuous(jatill -> gargaroz).

Ok. I'm thinking of dumping the cards from exes and doing something similar as with csv ie. join them together, that's why I asked for other versions as some cards were definitely left out of both current versions.

[Aswan jaguar]

If you are referring to this there are 4 current versions Manalink Constructed,Manalink Limited,and 2 clones of Limited via bat the Golden Years mod,and the New Limited.There are cards though that were coded but aren't in any of the above current versions.

[Mok]

If you are referring to this there are 4 current versions Manalink Constructed,Manalink Limited,and 2 clones of Limited via bat the Golden Years mod,and the New Limited.There are cards though that were coded but aren't in any of the above current versions.

Are these developed independent of each other? Or is it only a question of choosing different cards in .csv? Am I right that all cards are compiled in both Constructed and Limited and share the same addresses just may not be enabled?

[Aswan jaguar]

As Gargaroz who made the last 2(Golden Years,New Limited) said:"They are modified versions of Manalink Limited"-They are not independent.

[Gargaroz]

Mok, 90% of new card code is in the C compiled DLL (you could check the pointers in the "ManalinkEh.asm" file), but obviously as we have only 2000 slots available, the "cards_ptr" is different for each version.

All versions share the same Dlls, but each has 3 different files : an edited Magic.exe with the cards_ptr we need, the CSV file and the Dat file (both of which are created through the editor, I don't know how exactly the editor inject the code in Magic.exe, I only knwo it uses you csv2dat program).

Lastly, I'll ask the question again, as I think you haven't understoof what I meant : could we set up an "automatic" process to inserting the cards_ptr into the new Exe, like creating a CSV-like text file and make a program that parse it, convert it to data and then inject it into the executable ? That'll save us a lot of time when editing.

Also, for everyone working on the "ultimate CSV" : I'm convinced that would be really better if we move ALL the new coded cards after the original ones. As Mok said, slot until the end of Legions are somewhat hardcoded, so they should be left alone.
We also need to group the new cards by sets and some gaps are needed to complete the sets in a second time.
Plus, "animated lands" and their conterparts needs to be inserted like this :
2001 Treetop Village
2002 Treetop Village Ape
This could save us a lot of trouble in the coding process (and we could get rid of "get_id_by_name" more easily).

[Mok]

Mok, 90% of new card code is in the C compiled DLL (you could check the pointers in the "ManalinkEh.asm" file), but obviously as we have only 2000 slots available, the "cards_ptr" is different for each version.

All versions share the same Dlls, but each has 3 different files : an edited Magic.exe with the cards_ptr we need, the CSV file and the Dat file (both of which are created through the editor, I don't know how exactly the editor inject the code in Magic.exe, I only knwo it uses you csv2dat program).

Sure, I'm just asking for .exe/.dat pairs so the card_data_t contains as many cards as possible Why redo them later.

[Gargaroz]

Wops, I didn't think you were still here !
However, here's a brief "map of the situation" :

Costructed version --> only the really powerful original card were kept, we literally overwrote everything we could to insert new cards, so perhaps it's better if you avoid getting the data from this version, as many hardcoded slots are overwritten.

Limited version --> Contains all the original featured cards. Some slot left empty in the original version were used to store new cards, but this shouldn't be a problem, right ?

Golden Years --> Sama as Limited Version.

New Limited --> Only the unlimited cards are kept, the rest was overwritten.

I just remembered an important fact : when making your changes, rember that we need to keep the part of code that enables the Rules Engine card (check the "pregame" function in "rules_engine.c"), otherwise many new cards will not work.

Also, did you implemented Shroud or it was originally featured ? If yes, could check the new keyword "hexproof" and implement it too ?.

[foolosopher]

Mok you can also find exe/dat pairs in the patches section

viewforum.php?f=85

I 'd rather start with clearing the code,
Snacko I still have the env I set up for drawcard.dll, I think it should be OK for the dlls, so how do we proceed?

[Mok]

Wops, I didn't think you were still here !
However, here's a brief "map of the situation" :

Costructed version --> only the really powerful original card were kept, we literally overwrote everything we could to insert new cards, so perhaps it's better if you avoid getting the data from this version, as many hardcoded slots are overwritten.

Limited version --> Contains all the original featured cards. Some slot left empty in the original version were used to store new cards, but this shouldn't be a problem, right ?

Golden Years --> Sama as Limited Version.

New Limited --> Only the unlimited cards are kept, the rest was overwritten.

I just remembered an important fact : when making your changes, rember that we need to keep the part of code that enables the Rules Engine card (check the "pregame" function in "rules_engine.c"), otherwise many new cards will not work.

Also, did you implemented Shroud or it was originally featured ? If yes, could check the new keyword "hexproof" and implement it too ?.

Thanks for the list, but in the end I'll simply drop the idea of touching card_data_t. There's just too much random broken data in the current version(s). Also this 'shroud' is not implemented by me and is an example of someone redefining things without checking if the previous value is used or not, I want no part of this It's surprising that you managed to get this far without things breaking up left and right. I guess the AI engine is flexible enough to ignore broken results or these are rated so low that some sane choices are used instead.

I'll try to get Magic.exe and ManalinkEx.dll ready for large .dat today. These will *not work* properly because card_data_t is completely invalid inside, and ManalinkEh.dll is not fixed. But at least it will not crash and should hopefully work fine when you get to fixing the missing parts (card_data_t, final csv and recompiled ManalinkEh.dll). I'll skip fixing some code that was originally used in constructed games (the original one) as it seems you replaced it with your own constructed so it shouldn't matter.