Collectible Card Game Headquarters

Here i will try to keep you updated of the bugs on DOTP2012 this community had fixed.

For those interested in colaborate the code repository is https://bitbucket.org/pcastellazzi/dotp-2012-fixes

The latest mod including all bug fixes described in the repo can be downloaded from: https://bitbucket.org/pcastellazzi/dotp ... LC_1000.7z

Also if you know of a new bug please post it here and we will try to fix it as soon as we can.

Can you fix Grim Lavamancer not showing the target for it's activated ability? Whenever I play against it I don't know what it's going to hit.

Aarala wrote:Can you fix Grim Lavamancer not showing the target for it's activated ability? Whenever I play against it I don't know what it's going to hit.

The problem with Grim Lavamancer is that the game considers the cards you exile as the "primary" targets of the spell, so it doesn't bother pointing to the other target (which is the real one, but the game can't understand it).
The card should be completely rewritten, with the cards to exile stored in target data chest 1 and the real target stored in target data chest 0... but even with this, there's still a chance that the bug won't be fixed.

Anyone who wants to fix Grim Lavamancer should also look at Into the Earthen Maw, which has shown 3, 2, 1, and 0 targeting lines at various times.

It all starts from bad coding inside the game anyway. I can't understand why the coders didn't use a simple rule like "every target that is marked as NotTargetted() doesn't produce a line, every other target produces it".
I coded some cards that required to select something as a cost using the method that you see in Into the Earthen Maw (Bone Splinters for example), but it doesn't feel like a cost anymore... for example, you can't cancel the play if you need to. I know it's not a big deal, but it's frustrating that we can't make something perfect because of bad coding on the base.

Aarala wrote:Can you fix Grim Lavamancer not showing the target for it's activated ability? Whenever I play against it I don't know what it's going to hit.

Thank you for pointing this out. I will look into it as soon as i am able.

Pandemonium (and I presume Warstorm Surge by extension) doesn't resolve when the creature gets killed on the stack.

Aarala wrote:Pandemonium (and I presume Warstorm Surge by extension) doesn't resolve when the creature gets killed on the stack.

What do you mean by "killed on the stack"? If you kill it in response to Pandemonium's activation and the latter doesn't resolve, then yes, it's a bug. But the creature needs the time to make a brief trip to the battlefield.

thefiremind wrote:What do you mean by "killed on the stack"? If you kill it in response to Pandemonium's activation and the latter doesn't resolve, then yes, it's a bug. But the creature needs the time to make a brief trip to the battlefield.

Yea sorry I should have said it tries to sort a nil value since the creature is destroyed before the effect resolves.

I understood the problem, it's on both Pandemonium and Warstorm Surge, while Electropotence has been coded in a simpler way (which could actually hide the same bug, but for a different reason: I'd suggest to test).

The fastest fix for Pandemonium and Warstorm Surge is to substitute all the "_CardPtr" with "_ProtectedCardPtr", which aren't deleted when the card they point changes zone.

Also be careful when evaluating cards that have "CH" instead of the usual Multiverse ID in the filename: they are cards made for the challenges and could contain code that makes them work as intended in the challenge but is completely out of place otherwise (many creatures made for challenges attack each turn if able, for example). I can't see anything out of place on Pandemonium, though, so it should be safe to use outside the challenges once the bug has been fixed.

GamerXYZ0 found a bug in Iona's Judgment:

Code: Select all

    <RESOLUTION_TIME_ACTION>
    Object():GetTargetCard():RemoveFromGame()
    </RESOLUTION_TIME_ACTION>

It's missing the check for not being equal to nil. So it should be:

Code: Select all

    <RESOLUTION_TIME_ACTION>
    if Object():GetTargetCard() ~= nil then
      Object():GetTargetCard():RemoveFromGame()
    end
    </RESOLUTION_TIME_ACTION>

thefiremind wrote:GamerXYZ0 found a bug in Iona's Judgment:

Code: Select all

    <RESOLUTION_TIME_ACTION>
    Object():GetTargetCard():RemoveFromGame()
    </RESOLUTION_TIME_ACTION>

It's missing the check for not being equal to nil. So it should be:

Code: Select all

    <RESOLUTION_TIME_ACTION>
    if Object():GetTargetCard() ~= nil then
      Object():GetTargetCard():RemoveFromGame()
    end
    </RESOLUTION_TIME_ACTION>

This one was already fixed. The current version of the DLC include the fixed version.

Aarala wrote:Pandemonium (and I presume Warstorm Surge by extension) doesn't resolve when the creature gets killed on the stack.

This two and Electropotence had been fixed. The repo is updated with the latest changes.

About Grim Lavamancer, as suggested by thefiremind the targeting issue is a problem with the engine. I can code the card in a way to workaround this, but exiling cards would be part of the ability and not its cost, which may trouble you later. i.e. if the card is countered cards are not going to be exiled as they should.

I do not think the trade-off is worth it. What do you think?

pcastellazzi wrote:About Grim Lavamancer, as suggested by thefiremind the targeting issue is a problem with the engine. I can code the card in a way to workaround this, but exiling cards would be part of the ability and not its cost, which may trouble you later. i.e. if the card is countered cards are not going to be exiled as they should.

I do not think the trade-off is worth it. What do you think?

If you pay the costs in PLAY_TIME_ACTIONs, you do it before any answer can be played, so that's not the problem. The problem is that it won't be treated as a cost. I was wrong when I wrote that this prevents you from cancelling the play while you are paying, because with Grim Lavamancer the cards are exiled right after being chosen, so the play can't be cancelled anyway. The difference is that the cards with properly coded costs ask for the target first, and for the costs after. I find confusing to choose the target first in some cards and the costs first in other cards (especially if one of the cards is Glare of Subdual which has very similar "card pools" for both cost and target). We could still choose the target first while using the PLAY_TIME_ACTIONs, by sorting them in a certain way, but would this prevent the bug from being fixed?

thefiremind wrote:

pcastellazzi wrote:About Grim Lavamancer, as suggested by thefiremind the targeting issue is a problem with the engine. I can code the card in a way to workaround this, but exiling cards would be part of the ability and not its cost, which may trouble you later. i.e. if the card is countered cards are not going to be exiled as they should.

I do not think the trade-off is worth it. What do you think?

If you pay the costs in PLAY_TIME_ACTIONs, you do it before any answer can be played, so that's not the problem. The problem is that it won't be treated as a cost. I was wrong when I wrote that this prevents you from cancelling the play while you are paying, because with Grim Lavamancer the cards are exiled right after being chosen, so the play can't be cancelled anyway. The difference is that the cards with properly coded costs ask for the target first, and for the costs after. I find confusing to choose the target first in some cards and the costs first in other cards (especially if one of the cards is Glare of Subdual which has very similar "card pools" for both cost and target). We could still choose the target first while using the PLAY_TIME_ACTIONs, by sorting them in a certain way, but would this prevent the bug from being fixed?

The order of costs would be wrong, you will select a target, then the cards to discard and finally pay mana and tap the card. Still better than to not know where is going to hit you. I will give it a try.