First DotP2014 modding problems

[RiiakShiNal]

Also it looks like MANA_ABILITY is still extremely limited much like in DotP 2013, though it doesn't crash as much with certain values. So it looks like my first actual modding project for 2014 will be a rebuild of the mana system to use manual tapping and mana tokens(and see if I can get it to work with Burning-Tree Shaman while I'm at it).

[gorem2k]

I stumbled onto another problem. Now that I can grant activated abilities to cards in the graveyard, I have another issue that prevents me from coding Sedris, the Traitor King. In DotP2014 you can't refer to resource_id's of the original card from an ability granted to another card. This doesn't allow me to create the exiling delayed triggers when I unearth a creature using the ability granted by Sedris. Does anyone have a clever idea to overcome the problem?

Have you tried with linked_ability_group="1" ?
could you post this card here ?

using some parts of Sneak Attack, I was able to make Unearthed creature exile at end of turn but it didn't have haste. this is again a real challenge for a rookie like me.

[RiiakShiNal]

It appears as though we no longer have (or have access to) the Object Data Chest. We still have Object():GetDataChest(), but it appears to always return nil. I may be missing something (because it is late, and I probably shouldn't code when I'm tired), but if this is true it means no more fake characteristics and no more checking a DataChest from another card (at least not without some serious work-arounds).

I'll try some more tests tomorrow, but I don't think LinkedDC() can be used to check one card's data chest from another card (so it's not really a substitute for ObjectDC()).

Here is a test ability that shows the problem I'm running into:

Code: Select all

   <ACTIVATED_ABILITY>
      <LOCALISED_TEXT LanguageCode="en-US"><![CDATA[Test Me!]]></LOCALISED_TEXT>
      <COST type="TapSelf" />
      <PLAY_TIME_ACTION>
         Object():GetDataChest():Int_Set( 0, 1 )
      </PLAY_TIME_ACTION>
   </ACTIVATED_ABILITY>

This throws Script Log errors about trying to index a nil value on line 2 of the PLAY_TIME_ACTION.

[thefiremind]

It appears as though we no longer have (or have access to) the Object Data Chest. We still have Object():GetDataChest(), but it appears to always return nil.

This is not surprising: even in DotP2013, GetDataChest() didn't initialize the chest, while ObjectDC() did. It basically means that GetDataChest() was usable only after at least one call to ObjectDC(). ObjectDC() actually was a wrapper for MTG():ObjectDataChest(), which doesn't exist anymore, so goodbye ObjectDC.

if this is true it means no more fake characteristics and no more checking a DataChest from another card (at least not without some serious work-arounds).

Do you still have the code you used on DotP2013 for doing this check?
viewtopic.php?f=62&t=6784&p=92562#p92562
I'm pretty sure the result will be the same, but we won't know for sure until someone tries.

[RiiakShiNal]

This is not surprising: even in DotP2013, GetDataChest() didn't initialize the chest, while ObjectDC() did. It basically means that GetDataChest() was usable only after at least one call to ObjectDC(). ObjectDC() actually was a wrapper for MTG():ObjectDataChest(), which doesn't exist anymore, so goodbye ObjectDC.

I was afraid of that, though I do have some ideas on how to fake an ObjectDC(). Obviously it won't be as elegant as actually having the ObjectDC(), but I think it will work.

Edit: I actually got my idea working so for now I thought I would list it here to see if anyone else needs it.
ObjectDC Functions

Do you still have the code you used on DotP2013 for doing this check?
viewtopic.php?f=62&t=6784&p=92562#p92562
I'm pretty sure the result will be the same, but we won't know for sure until someone tries.

No, I don't still have the code, but I basically remember it (it wasn't very complex). I basically just used Ornithopter and modified it so that it's power would increase (based on powers of two) for each characteristic I was checking at the time (that way I could check up to 10 characteristics at a time fairly simply). I checked them both without setting the characteristics and with setting them (it was when I tested without setting them that I noticed that the results were constant and that they couldn't be set).

[thefiremind]

Edit: I actually got my idea working so for now I thought I would list it here to see if anyone else needs it.
ObjectDC Functions

That's very nice idea, it could be useful some time.

Now, this isn't really a problem, I'd just like to hear some suggestions about an idea. I'd like to make an echo deck with Thick-Skinned Goblin. In order to make him work, I'll give 3 options for the echo cost:

1. Pay the echo cost. Enabled only if I have enough mana.
2. Pay . Enabled only if I control a Thick-Skinned Goblin.
3. Don't pay. Always enabled, of course.

This would be good most of the times, but there's a scenario where it wouldn't: if Thick-Skinned Goblin loses all abilities during my upkeep (for example because of a Snakeform cast on him in response to an echo trigger), I shouldn't be able to pay .
So here's my idea: the ability of Thick-Skinned Goblin should also grant him a characteristic on layer="6" only during the upkeep. I would use a characteristic that doesn't add badges or information pages and doesn't do anything during the upkeep, for example CHARACTERISTIC_CANT_BE_COUNTERED (this actually never does anything on a card in play). Then my check for being able to pay would be: "Do I control a card named THICKSKINNED_GOBLIN that has CHARACTERISTIC_CANT_BE_COUNTERED?" A Snakeform should remove that characteristic and achieve the correct result.
Does anybody see a flaw in this idea?

[RiiakShiNal]

Now, this isn't really a problem, I'd just like to hear some suggestions about an idea. I'd like to make an echo deck with Thick-Skinned Goblin. In order to make him work, I'll give 3 options for the echo cost:

1. Pay the echo cost. Enabled only if I have enough mana.
2. Pay . Enabled only if I control a Thick-Skinned Goblin.
3. Don't pay. Always enabled, of course.

This would be good most of the times, but there's a scenario where it wouldn't: if Thick-Skinned Goblin loses all abilities during my upkeep (for example because of a Snakeform cast on him in response to an echo trigger), I shouldn't be able to pay .
So here's my idea: the ability of Thick-Skinned Goblin should also grant him a characteristic on layer="6" only during the upkeep. I would use a characteristic that doesn't add badges or information pages and doesn't do anything during the upkeep, for example CHARACTERISTIC_CANT_BE_COUNTERED (this actually never does anything on a card in play). Then my check for being able to pay would be: "Do I control a card named THICKSKINNED_GOBLIN that has CHARACTERISTIC_CANT_BE_COUNTERED?" A Snakeform should remove that characteristic and achieve the correct result.
Does anybody see a flaw in this idea?

The only possible problem I can see would be if the characteristic doesn't stick around long enough to be checked because it means nothing on a card already in play. Though honestly I don't think that will be a problem.

On an unrelated note I'm making good progress on manual tapping for mana and related. I've got it working for multi-colour lands, with Burning-Tree Shaman, and I'm currently trying to get it working for Mana Flare (so far looks promising, I just need to get the selection working right).

Does anyone know of any other cases I should look at?

Update: I now have my method working with Mana Flare as well. Now I'll move on to see if I can get it working with Exotic Orchard.

Update 2: I now also have it working with Exotic Orchard and Reflecting Pool, also the AI seems to have a basic understanding of how to use manual tapping, though it still prefers regular Auto-tapping. I can't remove the Basic super-type from the basic lands or the game crashes when trying to play a match. Also I've noticed that the basic lands when auto-tapping do not cause the BECAME_TAPPED_FOR_MANA trigger to activate so Mana Flare and similar cards will only work for manually tapped lands.

Since no-one has spoken up about any other cases I should look at, I'll dedicate some time to making some more mana related cards before releasing.

[thefiremind]

Onto another problem: I'm trying to code Prototype Portal, but I can't make the activated ability available. I haven't forgot linked_ability_group="1", and the LinkedDC card pointer is correctly set because the card successfully "nails" onto the Portal.
These are 2 versions of the activated ability cost:

Prototype Portal activated ability cost | Open

Code: Select all

    <AVAILABILITY>
    local imprinted = LinkedDC() and LinkedDC():Get_CardPtr(0)
    return imprinted ~= nil and EffectController():CanPayManaCost("{"..imprinted:GetConvertedManaCost().."}")
    </AVAILABILITY>
    <COST type="TapSelf" />
    <PLAY_TIME_ACTION>
    local imprinted = LinkedDC() and LinkedDC():Get_CardPtr(0)
    if imprinted ~= nil then
       EffectDC():Set_CardPtr(0, imprinted)
       EffectController():PayManaCost("{"..imprinted:GetConvertedManaCost().."}")
    end
    </PLAY_TIME_ACTION>

Code: Select all

   <COST type="Generic">
      <PREREQUISITE>
      local imprinted = LinkedDC() and LinkedDC():Get_CardPtr(0)
      return imprinted ~= nil and EffectController():CanPayManaCost("{"..imprinted:GetConvertedManaCost().."}")
      </PREREQUISITE>
      <RESOLUTION_TIME_ACTION>
      local imprinted = LinkedDC() and LinkedDC():Get_CardPtr(0)
      if imprinted ~= nil then
         EffectDC():Set_CardPtr(0, imprinted)
         EffectController():PayManaCost("{"..imprinted:GetConvertedManaCost().."}")
      end
      </RESOLUTION_TIME_ACTION>
    </COST>
    <COST type="TapSelf" />

The copy on EffectDC allows me to keep a pointer to the exiled card even if the Portal leaves the battlefield before resolution. Anyway, both versions don't let me activate the ability. What's wrong?

[RiiakShiNal]

Have you tried removing the CanPayManaCost check to see if the ability becomes available (essentially just check to make sure "imprinted" is not nil)? If it works and the ability becomes available then that probably means that the result from CanPayManaCost or the result from GetConvertedManaCost is somehow wrong. If it does not become available then we found the problem and "imprinted" is nil.

[thefiremind]

It seems that "imprinted" is nil indeed. But how is it possible, if I see the card attached to the Portal? Both read the same pointer. The problem must be related to the usage of LinkedDC inside a cost prerequisite or inside an availability.

[RiiakShiNal]

Well, to find out if it is limited to just being accessible in the action blocks, you could try simply leaving the ability as permanently available and see if you could cast a copy. If in the first method it taps the land in the PLAY_TIME_ACTION, then you will know that "imprinted" is not nil. If it doesn't tap the land then either you imprinted a 0 casting cost card or "imprinted" is nil there too (which could indicate a problem with the LinkedDC, which may mean that LinkedDC is nil and that there is some issue with how abilities are linked or how you have them linked).

Granted these are just guesses made on partial code.

[thefiremind]

Well, to find out if it is limited to just being accessible in the action blocks, you could try simply leaving the ability as permanently available and see if you could cast a copy.

It seems this is the right guess: the ability works perfectly when it's permanently available, so LinkedDC can't be accessed in COST or AVAILABILITY blocks (one more downside when comparing to the old ObjectDC... ). Is there another feasible way to limit the usage of the ability?

[RiiakShiNal]

Have you tried my ObjectDC replacement to see if you can use it in the AVAILABILITY or PREREQUISITE blocks?

[thefiremind]

I haven't tried yet, but I think I should... after all, the transform mechanic would need it as well, so better starting now.

[RiiakShiNal]

Well it should be easy to use. Instead of LinkedDC() use RSN_ObjectDC() and hopefully it will work for you.