Manalink C/ASM Dll

[Snacko]

I'll have the package + dll that supersedes the old ManalinkEh.dll with all the Harry cards today or tomorrow posted.
I would like to have an argument with Harry, but he always runs away without having any counterarguments, so I don't even know if he has any better ideas how things could be solved.
I agree with Huggy that things are way too chaotic and undocumented, however I don't see any push to make it more ordered. I can see that only Bog Wraith and jatil try at least to tie up the loose ends so the project can progress in a healthy manner.

[Huggybaby]

however I don't see any push to make it more ordered.

Hmm, we must not be seeing the same thing. Don't worry, we'll be ordered alright.

[HarryPitfall]

Do everything you want, I'm not part of manalink anymore, I'll just post all bugs that I found. I'm now a normal user that will play the game.
Just remember, that coding isn't a problem since long time... most of the cards are just done directly in assembler by people that KNOWS what is doing... if this 'speedup' on coding will help to fix the broken cards, will be ok...
Is very bad, that normally, I don't get much support from other members... I ask for information, open threads, and barely gets good results... this happen in the past with the proxy generator, and this happens again now here... this is why I'm leaving about development here...

[Snacko]

I integrated all of the Harry cards into the dll. As you can see you can code the cards / functions in both asm and C. There is no example, but you can call the asm functions like shadow or horsemanship that Harry coded in asm via C.
http://www.mediafire.com/download.php?ygngmlwjz2d

@Harry
The problem is not coding the cards but organising the code, even if you code the cards in asm it's much easier to read them with meaningful labels, logic checks and function names. The quality of the code consists of two things: does the code work as intended and how easy it is to understand the logic behind the code. Currently the second one is lacking and it looks like the work of of someone who writes the code so it would be unreadable and thus makes him indispensable. However this is a community work so the idea should be the exact opposite, make everything well documented and easy to understand (depends on the reader knowledge).

[HarryPitfall]

I disaprove this kind of code... really disaprove...
I have here the correct way to code some cards using only yasm, and now, with you code... here's to start? You didn't include the yasm.exe, gcc... even a build bat...
After Jatill release, I'll take this over again, and use only my dll code, pure asm, sorry... If you really have a compiled c dll working, he can add at next address...
This mixup is much more BAD than pure asm, pure asm makes only the people that really know what is doing to work.
Programming isn't for everyone, sorry...
I need to take over and DO WHAT I BELIEVE is correct!
If a good pure C dll coming, marvelous, lets add another dll at $03000000 imagebase, don't touch what is already working.
I know that you have good intentions, but i'll not let this gets messed up... also, instead, spread more information about magic.exe instead say anything about how is coded, like you did before, OK? I have my own learning curve, and is good as it is!

It's my terms to work... if people really wants that I continue here to help!

[Bog Wraith]

Sorry Harry but as I said in my other post...

viewtopic.php?f=25&t=979

You will not dictate to anyone how things are done here.

Either share in the development with everyone and try to be reasonable, or not!

Enough is enough!

[jatill]

I'd like to start getting deep into coding cards with C and creating a big API. I have 2 major roadblocks that need to be addressed first.

1) I don't know what I'm doing. Could you (Snacko or Lonefox) please create a bare-bones tutorial for how to add a card to the existing dll? I'm talking a couple hundred words or less, just a rough sketch of what to do, for someone who doesn't know a thing about dll's or whatever. What you could explain in 10 minutes will save me (and everyone else) hours of trying to learn to my own. Don't want to type it all down? Give me a phone call, seriously.

2) The 2000 card limit. It seems kind of pointless to create a whole new infrastructure if we can only code a few hundred more cards. If this an issue we think can be overcome, as we approach the limit?

---
One immediate question I have is, 'how and where do new functions get added?' It must work, if you got lonefox's code to work, but how?

Next. I run make an generate ManalinkEc.dll (without making any changes at this point). I rename this to ManalinkEh.dll, and copy it into my magic directory. Then I run magic.exe and get the error ManalinkEh.dll is not a valid Windows image. What's the problem?


Lonefox-
Have you written any new code since your last release, or can I assume that all that's written is what you submitted?

[Snacko]

How to add a card:
1) Create a new file in cards/, most likely you want to code in in c so card_name.c
2) Write some card code, see the c cards
3) If you want to write a function create it in functions/
4) Edit manalink.h to add functions declarations / constants you want to use in the c code
5) If you added any global variables / functions from the exe to manalink.h edit manalink.lds and add their addresses
6) Edit ManalinkEh.asm and add an extern / jmp for your function/card. The jumps will always have the same position in the dll. There shouldn't be any functions there really as cards should be recoded in c or as a final alternative asm via yasm, and those don't need the static address jump. Only cards coded directly via skyeditor or olly would need those.
7) If you have the gcc compiler + yasm + make + binutils all you have to type is "make". It will assemble all the files and you'll get ManalinkEh.dll you can use in Magic.exe

Moving to a new infrastructure is never pointless, if it makes the code clearer and easier to manage (source revisions systems / diffs etc). Plus once the limit of 2000 is removed all you get is profit from adopting the new system sooner than later.

Redownload the new one with harry's cards, I included some fixes there.
http://www.mediafire.com/download.php?ygngmlwjz2d

[jatill]

Thank you for that. Nimble Mongoose successfully coded!
Let the era of c-coding magic cards commence

[mathusalem]

Geez, Jatill you're so unstopable, you should have played in a James Bond movie !

[jatill]

Man, I am already in love with the new format. Here's the entire code for werebear (plus a line elsewhere saying where the elves code lives):

int card_werebear(int player, int card, int event)
{
if(event == EVENT_POWER || event == EVENT_TOUGHNESS)
{
if(player == affected_card_controller && card == affected_card && count_graveyard(player) > 6)
event_result += 3;
}
return llanowar_elves(player, card, event);
}

The learning curve for this project just dropped through the basement!

For my next trick, I think I'll update the code to just be:

int card_werebear(int player, int card, int event)
{
if(event == EVENT_POWER || event == EVENT_TOUGHNESS)
{
if( has_threshhold() )
event_result += 3;
}
return llanowar_elves(player, card, event);
}

[HarryPitfall]

At least, I hope that when a mod is released, all source code is released as well, so, anyone can continue the work.
Just a question... How "GetCardInfo" can be done in C ? Like check for tap? Can a function be in assembler to return information?

.GetCardInfoStatus:
push ebp
mov ebp, esp
mov ecx, [ebp+0x8]
mov eax, [epb+0xc]
call 0xXXXXXX <- get card info
mov eax, [esi+0xXX] <- put eax (result) the card status (+0x38)
leave
ret

this will be like int GetCardInfo(int, int) in C... will work?

or he can just use mov eax, esi... and fully decode the cardinfo structure...
struct CARDINFO {
...
...
} *pCARDINFO
pCARDINFO GetCardInfo(int, int)
This will help to fix/speed up things... more knowledge is needed about engine internals...

Also, I manage to have a ready to compile install (only the .exe needed to compile, minimalistic), that works... if anyone is interested, I download the c/asm pack from snacko, add the .exe needed, and run make (everything is fine... it's appear).
I can zip it to be ready to run.
Or just get these files from Dev-Cpp install and put on same directory of makefile:
make.exe; yasm.exe; gcc.exe; cc1.exe; as.exe; ld.exe

[jatill]

Harry-
Would you mind zipping up those exe's and putting up a link? That would be really handy.
I agree that all source code MUST be released with the patches, and I'll start the trend tonight when I release again. Also, we should update the wiki with all the functions we have written, so we'll have a documented API.

I don't know if there is a better way to do this, but here's how I'm going to code up the getCardInfo stuff. I'm just going to write a bunch of small functions that call getCardInfo and return the result. So for example, I'll have a funciton is_tapped(player, card) that will call get 401A40 and inspect the particular value, and return 1/0. It's a hassle, but I don't know a better way.

Looking at the decompiled magic.c, it would seem we can call it directly, but I don't understand this code at all.
int __usercall sub_4016A0<eax>(int a1<edi>, int a2<esi>, int a3, int a4, char a5)
{
if ( a5 != 54 )
goto LABEL_5;
sub_401A80();
if ( *(_DWORD *)(a2 + 4) == dword_7A398C && *(_BYTE *)(a2 + 80) == dword_738C84 )
{
dword_6205B4 = *(_BYTE *)(a2 + 56);

[HarryPitfall]

The decompiled code isn't that usefull... 'cause the source is C++ and is decompiled in C... methods of objects are decompiled in a weird way...

Well... a asm function to get the 'state' of a card will be like this:

Code: Select all

.GetCardInfoState:
  push ebp
  mov ebp, esp
  mov eax, [ebp + 0x08]
  mov ecx, [ebp + 0x0c]
  call 0x401a80
  mov eax, [esi + 0x08]
  leave
  ret


and the C declaration of the function...

Code: Select all

  int GetCardInfoState(int, int)

int IsCardTapped(int Player, int Card) {
  return GetCardInfoState(Player, Card) && 0x10;
}

int IsCardSummonSick(int Player, int Card) {
  return GetCardInfoState(Player, Card) && 0x20000;
}


This is until he can figure the structure returned by 0x401a80 function... :/

[LoneFox]

.GetCardInfoStatus:
push ebp
mov ebp, esp
mov ecx, [ebp+0x8]
mov eax, [epb+0xc]
call 0xXXXXXX <- get card info
mov eax, [esi+0xXX] <- put eax (result) the card status (+0x38)
leave
ret

That is almost correct. The compiler expects functions to keep esi unchanged, so you have to push/pop it.

or he can just use mov eax, esi... and fully decode the cardinfo structure...
struct CARDINFO {
...
...
} *pCARDINFO

pCARDINFO GetCardInfo(int, int)

It would be a cool thing if you guys dumped into the wiki everything you know about this pCARDINFO or card_instance_t or whatever we will call it.

About the 2000 card limit: so far I have found three static arrays that limit the number of cards (there are others, but they appear to be "large enough"). The one at 0x55D0E0 is used in many places, but it is larger than 2000 already (ida pro finds next data item at 0x560F6C, and the array contains pointers, so there is room for exactly 4003 of them). Two others (0x60EFDC and 0x73BAE0) have no room for expansion, but are used much less (about 20 cross-references total, not including the code that loads them from cards.dat), so they can be moved elsewhere with decent amount of work. Of course there may be more problems that I haven't found yet. The function that reads cards.dat and fills these arrays is at 0x402170.