Crusade possible?

[Vervandi]

Hello all. I am working on my first custom deck. I wanted to try something simple, so I went with an old classic white deck I used to see a lot in our play group back in the 90s. All the cards I have made work great thanks to the information I have found on this forum, with the exception of one card... Crusade.

Here is the latest attempt I made at the card:

Code: Select all

<FILTER>
    return FilteredCard() ~= nil and
    FilteredCard():GetCardType():Test( CARD_TYPE_CREATURE ) ~= 0 and
   filteredCard:GetColour():Test( COLOUR_WHITE ) ~= 0
    </FILTER>
    <CONTINUOUS_ACTION layer="7C">
    if FilteredCard() ~= nil then
       local characteristics = FilteredCard():GetCurrentCharacteristics()
       if characteristics ~= nil then
          characteristics:Power_Add( 1 )
          characteristics:Toughness_Add( 1 )
       end
    end
    </CONTINUOUS_ACTION>

I want it to give +1 +1 to all white creatures in play, mine or otherwise. I'm pretty sure I am messing up the filter. Any help would be greatly appreciated!

[sumomole]

Hello all. I am working on my first custom deck.

FilteredCard():GetColour():Test( COLOUR_WHITE ) ~= 0

[thefiremind]

Hello all. I am working on my first custom deck.

FilteredCard():GetColour():Test( COLOUR_WHITE ) ~= 0

Just to clarify a bit more: you are using filteredCard which is a variable that you never declared in that block. Some original cards declared

Code: Select all

local filteredCard = FilteredCard()

and if you ask me why, I don't know (avoid typing 2 more characters?), but if you don't declare anything, you have to use FilteredCard() directly.

[Vervandi]

Thank you both for the help! Indeed, that was the issue. I still couldn't get it to work after adding the () so I rewrote it once again declaring the variable as they did on the cards I used for reference. I'll post it here for future noobies who run into similar issues:

Code: Select all

<FILTER>
    local filteredCard = FilteredCard()
    return ((filteredCard ~= nil) and 
    (filteredCard:GetColour():Test( COLOUR_WHITE ) ~= 0) and
    (filteredCard:GetCardType():Test( CARD_TYPE_CREATURE ) ~= 0) and
    (filteredCard:GetZone() == (ZONE_IN_PLAY)) and
    (filteredCard ~= Object()))
    </FILTER>
    <CONTINUOUS_ACTION layer="7C">
    if FilteredCard() ~= nil then
       local characteristics = FilteredCard():GetCurrentCharacteristics()
       if characteristics ~= nil then
          characteristics:Power_Add( 1 )
          characteristics:Toughness_Add( 1 )
       end
    end

Thanks again!

[RiiakShiNal]

Some original cards declared

Code: Select all

local filteredCard = FilteredCard()

and if you ask me why, I don't know (avoid typing 2 more characters?), but if you don't declare anything, you have to use FilteredCard() directly.

Actually, if programming for efficiency that can sometimes make sense.

FilteredCard() is a function and will involve several steps to get a value including setting up memory for the function to run, storing a return pointer, and allocating memory for a return value in addition to going out and getting the value. Only using this is the most efficient method if you only need to call this function once. Also using this method can be important if the value is expected to change within a block (not the case for FilteredCard()).

Setting up a local value and putting the value of FilteredCard() in it uses the overhead from the first call to FilteredCard() plus memory to store the return value (likely a pointer so an additional 4-bytes), but subsequently calling the local value no longer incurs the overhead from calling the FilteredCard() function. This is the optimum method to use if you need to access the return from FilteredCard() multiple times in a block. This can also make debugging easier because you don't have to step through a function to see if you have the right value because you've already stored it and also prevents repeatedly stepping through the same function multiple times to get the same result.

Though with computer speeds now and the large amounts of memory we have the overhead from calling a function repeatedly is usually not noticeable, but there are also many programmers who either are following good efficiency habits from years of coding or simply want to have all values in locals to make debugging easier who will almost exclusively use the latter method. Programmers who are not concerned with extreme optimization or don't have the same rigid background as other typically older programmers will often use the first method for relatively simple functions like FilteredCard() because the lost performance and increased overhead is usually non-noticeable.

Boiled down if you are going to use FilteredCard() (or any retrieval function) multiple times to get the same value in a block using a local variable is more efficient. If you only need to call the function once then using the return from the function directly (without setting up a local) is more efficient.

Edit:

I still couldn't get it to work after adding the () so I rewrote it once again declaring the variable as they did on the cards I used for reference.

It is case sensitive so you would have also needed to capitalize the leading "f" in "filteredCard" in addition to adding "()".

[Vervandi]

RiiakShiNal, that was probably it. Either way, it is working great now . Also, thanks for the information on filtering, it's hard to come by!

[RiiakShiNal]

Actually, most of that is general information on dealing with functions that return a value and how it relates to efficiency. I simply used FilteredCard() as the example because it was what this thread had been talking about.

[thefiremind]

Actually, if programming for efficiency that can sometimes make sense.

I thought about the issues you mentioned, but when I look at the useless loop for drawing 1 card, or the quite common "for i=0,1-1", it becomes hard for me to believe that efficiency was a concern for the developers.

[RiiakShiNal]

I never said all developers were programming for efficiency, they probably had a team working on the cards with who knows how many revisions going into the cards. They may even have some automated tools for building cards that put in some of that code. Anyway all we are doing is making guesses as to reasons things are the way they are and since we aren't the original developers all it will ever be is guesses.