AI reveals morph creatures
Discuss Upcoming Releases, Coding New Cards, Etc.
PLEASE DO NOT REPORT BUGS HERE!
PLEASE DO NOT REPORT BUGS HERE!
Moderators: BAgate, drool66, Aswan jaguar, gmzombie, stassy, CCGHQ Admins
AI reveals morph creatures
by drool66 » 06 Aug 2021, 01:03
Context: https://www.slightlymagic.net/forum/viewtopic.php?f=25&t=30534#p249354
The other issue is the right click>original type> option, which reveals the original card. I was going to try doing a do-si-do with the card and a face-down card, then socking the original card's id in targets[13], so that the original_internal_card_id is a face down card and the id to morph into is the real card's id. The code for a face-down creature (including the special ones for Illusionary Mask and Ixidron and manifest and who knows what else) would than have an option for the controller to view the original card and flip it if legal. No idea if that would work well or at all, but that's the concept I was thinking of. If it doesn't work, just changing the dialog will still be a significant upgrade. Nope. If anything ever changes its type it will revert to a face-down creature permanently. Maybe there's another solution.
While I'm at it I'll change EVENT_TURNED_FACE_UP to dispatch normally. Then, modify the ten or so cards that interact with other cards turning face up, and the others that respond to their own event to check affect_me().
I was going to go with a DIALOG() call as you suggest, probably with options slightly weighed in favor of playing face-down - not sure what other factors to consider. Manifest & Illusionary Mask don't display a dialog and the other two aren't yet coded. Ugh... I hope there's nothing with morph that doesn't call the main functions.The AI's choice for a plain do_dialog() is deterministic - whatever you pass in as the last argument, the AI picks that. All you have to do is not call do_dialog() if the AI's going to pick "Play face-down". Or even not call do_dialog() at all if it's for the AI. Just make sure you only do that if it's actually the AI picking, not just player 1, or you'll break multiplayer even worse. (Of course, that also means if multiplayer ever becomes even sort of playable again, you'd need a different solution, like promoting to a DIALOG() call and passing DIALOG_FULLCARD_CSVID(CARD_ID_FACE_DOWN_CREATURE) when player == 1.)
The only real issue in the short term is making sure every card with morph or megamorph actually calls casting_permanent_with_morph(), and nothing handles it on its own.
Is this also an issue for manifest? How about the other cards that let you move objects from hidden zones to the bf face-down? (I think that's just Illusionary Mask, Tezzeret, Cruel Machinist, and Yedora, Grave Gardener?)
While I'm at it I'll change EVENT_TURNED_FACE_UP to dispatch normally. Then, modify the ten or so cards that interact with other cards turning face up, and the others that respond to their own event to check affect_me().
The latest images for Manalink will be here.
The latest Manalink installation directory will be here. Well, not quite, anymore. Check the latest patches.
The latest Manalink installation directory will be here. Well, not quite, anymore. Check the latest patches.
-
drool66 - Programmer
- Posts: 1163
- Joined: 25 Nov 2010, 22:38
- Has thanked: 186 times
- Been thanked: 267 times
Re: AI reveals morph creatures
by Korath » 06 Aug 2021, 06:11
If you use DIALOG(), you can't use it to weight the options unless you just show the face-down version every time.
The context menu with the "Original Type" submenu is created in wndproc_CardClass()'s WM_INITMENU handler. The relevant part starts at 0x48c1e2 and decompiles to something like:
There's three ways to deal with it.
The context menu with the "Original Type" submenu is created in wndproc_CardClass()'s WM_INITMENU handler. The relevant part starts at 0x48c1e2 and decompiles to something like:
- Code: Select all
oiid = j_get_displayed_original_internal_card_id(player, card);
get_displayed_whose_phase_and_displayed_phase(&whose_phase, &phase);
if (iid != oiid)
{
AppendMenuA(popupmenu_CardClass1, MF_POPUP, popupmenu_CardClass2, str_Original_type);
ModifyMenuA(popupmenu_CardClass2, 0x72, MF_STRING, 0x72, cards_ptr[CardIDFromType(oiid)]->full_name);
}
There's three ways to deal with it.
- Move the whole handler into wndproc_CardClass_hook() in windows.c. This is best in the long term - you're eventually going to have to do it anyway if you want to add new items to this menu like Shandalar does - but the most work right now. If you go this route, it should be clear where Shandalar version differs from the original, and the handler in Magic.exe starts at 0x48c09e so you can get the globals' addresses from there.
- Patch magic.exe to change the part inside the braces. Would work, but it's much easier to...
- Patch magic.exe to change the assignment to oiid. Since it's already passing player and card, all you need to do is change the target of the call to your own function in ManalinkEh.dll, and make it return the card's actual original_internal_card_id if you want the submenu to appear, or its internal_card_id if you don't. The instruction you want to alter is
- Code: Select all
48c1ea: e8 c1 cf fa ff call 0x4391b0
-
Korath - DEVELOPER
- Posts: 3707
- Joined: 02 Jun 2013, 05:57
- Has thanked: 496 times
- Been thanked: 1106 times
2 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 35 guests