Shandalar - Program Bugs
Backfire cast on AI creature will damage AI for 4036 damage next damage to it (fix completed)
How to reproduce :
- Cast Backfire on AI creature
- Damage AI with player creature or spell
Edit: For some reason Backfire work correctly in a clean game so here attached are the decks that reproduce this behavior everytime
- Cast Backfire on AI creature
- Damage AI with player creature or spell
Edit: For some reason Backfire work correctly in a clean game so here attached are the decks that reproduce this behavior everytime
- Attachments
-
- decks.zip
- (952 Bytes) Downloaded 181 times
Last edited by Korath on 24 Nov 2015, 03:27, edited 2 times in total.
Reason: version NB1->TH1; component Individual Card->Duel Engine
Reason: version NB1->TH1; component Individual Card->Duel Engine
Comments
Posted by Korath » 30 Oct 2015, 13:33
The second deck included isn't the same one in your screenshot; it has GW weenies and elephants.
And I'm not getting the bug. Here's what happens:
And I'm not getting the bug. Here's what happens:
- AI plays a Windswept Heath, sacs it to fetch a Savannah, and casts a Savannah Lions.
- I play an Island and Backfire the lions. (The lions don't attack after that.)
- A couple turns later when I have three lands, I cast a Phantom Warrior and attack the next turn; or I cast a Psionic Blast targeting the AI.
- Backfire doesn't trigger and AI takes the right amount of damage.
Posted by stassy » 03 Nov 2015, 13:28
Tested with another computer and getting crash everytime AI or player attack with a creature enchanted with Backfire
Here is the dump (300 Mo compressed to 40 Mo):
https://www.dropbox.com/s/3kb7ih3ihjaij ... ar.7z?dl=0
tested with this deck in mirror shandalar duel
Here is the dump (300 Mo compressed to 40 Mo):
https://www.dropbox.com/s/3kb7ih3ihjaij ... ar.7z?dl=0
tested with this deck in mirror shandalar duel
;test
;
;User
;User E-Mail
;03/11/2015
;1
;4th Edition
;
.575 10 Backfire
.4161 10 Metathran Soldier
.126 20 Island
Posted by Korath » 03 Nov 2015, 16:19
Still doesn't crash for me, and your dump file isn't showing anything obviously wrong.
What's your environment? I can tell it's 64bit Win7 from your dump file, but I seem to recall you run it under emulation on a mac? (Or am I confusing you with someone else?)
Shandalar.ini file?
I'm attaching a slightly modified version of the NB1 Shandalar.dll. It logs an excessive amount of data around the point in dispatch_event_raw() that you crashed at in your dump. Please run using that, and paste me the last couple dozen lines of the shandalar_dll.log file it produces. (The log file will be very, very large, but only the last part will be useful.)
What's your environment? I can tell it's 64bit Win7 from your dump file, but I seem to recall you run it under emulation on a mac? (Or am I confusing you with someone else?)
Shandalar.ini file?
I'm attaching a slightly modified version of the NB1 Shandalar.dll. It logs an excessive amount of data around the point in dispatch_event_raw() that you crashed at in your dump. Please run using that, and paste me the last couple dozen lines of the shandalar_dll.log file it produces. (The log file will be very, very large, but only the last part will be useful.)
- Attachments
-
- shandalar-893-g9c21fdd-bug837-log.zip
- (2.58 MiB) Downloaded 162 times
Posted by stassy » 10 Nov 2015, 17:49
The Shandalar folder is the same for all tested computer : win xp sp3 celeron computer, win xp sp3 pentium laptop and w7 i5 computer ; all crash at some point the next step Backfire is cast and enchanted creature attack.
Shandalar.ini only has debug mode on and AI set to 1540, everything else is untouched
Attached is the archive of the log file, 68 Mo compressed to 47 kb
Shandalar.ini only has debug mode on and AI set to 1540, everything else is untouched
Attached is the archive of the log file, 68 Mo compressed to 47 kb
- Attachments
-
- shandalar_dll.zip
- (1.62 MiB) Downloaded 167 times
Posted by Korath » 21 Nov 2015, 15:57
Caused by a data conflict in Backfire's eot_toughness between recorded card_from (so the Aura knows it can attach to an object with shroud or hexproof if it was put on directly on the battlefield without being cast) and its counter for number of damage triggers that need resolving.
Affects only version NB1. TH series and earlier don't have card_from so don't record it. AS happens to store the counter in byte1 of eot_toughness instead of byte0, and all card_from values have byte1 clear. (Furthermore, AS makes card_from valid during EVENT_RESOLVE_SPELL so no cards currently have to record it - probably no cards at all will have to; I can't imagine one that checks to see e.g. if it was cast from your hand or your graveyard or whatever except while it's resolving, entering the battlefield, or being cast. enchant_target_impl() still records the value in AS, since I didn't feel up to verifying that no individual auras use the data beyond the common check, but I'll do that now.)
Affects only version NB1. TH series and earlier don't have card_from so don't record it. AS happens to store the counter in byte1 of eot_toughness instead of byte0, and all card_from values have byte1 clear. (Furthermore, AS makes card_from valid during EVENT_RESOLVE_SPELL so no cards currently have to record it - probably no cards at all will have to; I can't imagine one that checks to see e.g. if it was cast from your hand or your graveyard or whatever except while it's resolving, entering the battlefield, or being cast. enchant_target_impl() still records the value in AS, since I didn't feel up to verifying that no individual auras use the data beyond the common check, but I'll do that now.)
Posted by Korath » 21 Nov 2015, 16:20
Can also occur with cloning cards (Copy Enchantment, Clone, etc.) used on cards that don't expect card_from or mana-spent-to-cast values in eot_toughness. Cloned Enduring Renewal, El-Hajjaj, etc. will get very confused, for example.
This is a lot more difficult to deal with, and also affects TH.
Will investigate how feasible it is to backport making card_from valid during EVENT_RESOLVE_SPELL and TRIGGER_COMES_INTO_PLAY to NB; and to make mana_paid_colors valid at least in EVENT_RESOLVE_SPELL, so that individual cards that need it at other times can record it then, after they've been cloned and so on.
This is a lot more difficult to deal with, and also affects TH.
Will investigate how feasible it is to backport making card_from valid during EVENT_RESOLVE_SPELL and TRIGGER_COMES_INTO_PLAY to NB; and to make mana_paid_colors valid at least in EVENT_RESOLVE_SPELL, so that individual cards that need it at other times can record it then, after they've been cloned and so on.
Posted by Korath » 21 Nov 2015, 16:53
It's pervasive. Won't fix for TH, except to remove recording of mana colors in clone-like cards; this'll make a Clone of a Tin Street Hooligan or Shrieking Grotesque think it was cast for free. By far the lesser evil.
For NB, will do a full backport from AS for card_from, then use that machinery to store mana paid colors (and amounts) as well. Could also use this to make x_value valid at resolution, so cards wouldn't have to store it in their info_slot; but then we'd be back to not being able to find the cmc of x cards on the stack for e.g. Spell Blast, so we're stuck with that.
For NB, will do a full backport from AS for card_from, then use that machinery to store mana paid colors (and amounts) as well. Could also use this to make x_value valid at resolution, so cards wouldn't have to store it in their info_slot; but then we'd be back to not being able to find the cmc of x cards on the stack for e.g. Spell Blast, so we're stuck with that.
Posted by Korath » 22 Nov 2015, 02:05
commit 6a07d25892e7df906d32d666354686cf67e2c1b6
Author: Korath <dgk@Dirge.none>
Date: Fri Oct 30 04:36:12 2015 -0400
[NB] cast_from=>card_from so it doesn't imply "cast"; +CARD_FROM_CAST
(cherry picked from commit 7a089886c6ca4c937356ecbe7658999b016227b6)
commit fd669ef774638c405a6a372a9981b18903b5a34c
Author: Korath <dgk@Dirge.none>
Date: Fri Oct 30 04:53:24 2015 -0400
[NB] make card_from valid during TRIGGER_COMES_INTO_PLAY, TRIGGER_SPELL_CAST
(And XTRIGGER_LAND_PLAYED, though it's mostly irrelevant there.)
The major consequence is that another parameter is needed for put_into_play().
CARD_FROM_PUT_INTO_PLAY is implied, but it still needs CARD_FROM_HAND,
CARD_FROM_GRAVEYARD (new), CARD_FROM_LIBRARY (new), etc. too. CARD_FROM_0 is
used in a couple places for uncommon sources - the stack (in Desertion),
outside of the game (Wishes, Ring of Ma'ruf), and I suppose eventually from
ante. Free cards (at duel start, and from the debug menu) reuse
CARD_FROM_CREATED_TOKEN (new) - mostly for convenience, since all other
remaining uses of put_into_play_for_exe() called from Shandalar.exe are for
token creation.
Moved from exe:
oubliette_helper_4()
Incidental:
Minimize internal use of *_for_exe() functions; add add_card_invisible() to
fill a major gap left by that.
(cherry picked from commit ffb6a50fa9093238c5409583ac32f971a912cff5)
Author: Korath <dgk@Dirge.none>
Date: Fri Oct 30 04:36:12 2015 -0400
[NB] cast_from=>card_from so it doesn't imply "cast"; +CARD_FROM_CAST
(cherry picked from commit 7a089886c6ca4c937356ecbe7658999b016227b6)
commit fd669ef774638c405a6a372a9981b18903b5a34c
Author: Korath <dgk@Dirge.none>
Date: Fri Oct 30 04:53:24 2015 -0400
[NB] make card_from valid during TRIGGER_COMES_INTO_PLAY, TRIGGER_SPELL_CAST
(And XTRIGGER_LAND_PLAYED, though it's mostly irrelevant there.)
The major consequence is that another parameter is needed for put_into_play().
CARD_FROM_PUT_INTO_PLAY is implied, but it still needs CARD_FROM_HAND,
CARD_FROM_GRAVEYARD (new), CARD_FROM_LIBRARY (new), etc. too. CARD_FROM_0 is
used in a couple places for uncommon sources - the stack (in Desertion),
outside of the game (Wishes, Ring of Ma'ruf), and I suppose eventually from
ante. Free cards (at duel start, and from the debug menu) reuse
CARD_FROM_CREATED_TOKEN (new) - mostly for convenience, since all other
remaining uses of put_into_play_for_exe() called from Shandalar.exe are for
token creation.
Moved from exe:
oubliette_helper_4()
Incidental:
Minimize internal use of *_for_exe() functions; add add_card_invisible() to
fill a major gap left by that.
(cherry picked from commit ffb6a50fa9093238c5409583ac32f971a912cff5)
Posted by Korath » 22 Nov 2015, 02:11
commit 6eae9661f1428757176f976fd18571a72846c711
Author: Korath <dgk@Dirge.none>
Date: Sat Nov 21 21:10:12 2015 -0500
[NB] #837: eliminate RECORD_CASTFROM_IN_EOT012_AND_MANA_COLORS_IN_EOT3()
enchant_target_impl() checks card_from directly in its EVENT_RESOLVE_SPELL
handler.
clone_event_as_comes_into_play_impl() resets card_from (and, if it's copying an
Aura, adds CARD_FROM_CLONED_AURA) and forwards it when forwarding
EVENT_RESOLVE_SPELL. No non-aura cards looked for card_from data in
eot_toughness, and no auras looked for it except within enchant_target_impl().
Author: Korath <dgk@Dirge.none>
Date: Sat Nov 21 21:10:12 2015 -0500
[NB] #837: eliminate RECORD_CASTFROM_IN_EOT012_AND_MANA_COLORS_IN_EOT3()
enchant_target_impl() checks card_from directly in its EVENT_RESOLVE_SPELL
handler.
clone_event_as_comes_into_play_impl() resets card_from (and, if it's copying an
Aura, adds CARD_FROM_CLONED_AURA) and forwards it when forwarding
EVENT_RESOLVE_SPELL. No non-aura cards looked for card_from data in
eot_toughness, and no auras looked for it except within enchant_target_impl().
13 Posts
• Page 1 of 2 • 1, 2
Ticket details
- Ticket ID: 837
- Project: Shandalar
- Status: Fix completed
- Component: Duel Engine
- Project version: Thieves Hideout 1
- Priority: Normal
- Severity: Major
- Assigned to: Korath
- Reported by: stassy
- Reporter's tickets: List all tickets
- Reported on: 29 Oct 2015, 11:32
- Last visited by Korath » 02 Jul 2017, 00:12.