Collectible Card Game Headquarters

I saw. I'l go ahead and get started on it. A friend of mine is going to test the wad from her end when she gets back up (she's about to go to bed).

Hey, so I'm coding these manifest cards, but before I can do too much, I need to know if they're only going to be in the CW or if they're being released separately. If they're going to be separate, then I need to rename all of the functions and use new constants. If they're only going to be in the CW, then that won't matter. There are 15 total, it seems. So it'll only take a short time once I know which way to go.

I plan on including them in the official release as well. I'll be sure to make it so they don't conflict with one another.

I already renamed everything. The only thing left for you to change is the constant numbers in the lol.

Hey, all of the manifest cards have been coded and tested. I was done with everything last night except for Write into Being. I couldn't figure out why it wasn't working, but FINALLY realized this morning that I was accidentally putting the manifested card on the bottom of the library before manifesting, and thus the pointer to it was nil. Anyway, they're all working on my end with some moderately in depth testing. But I didn't test every last interaction, and there are bound to be some issues. One thing I already know won't work and don't know how to fix is copying a spell. If, for instance, Soul Summons is copied, then the card manifested through the copy will not be able to turn face-up.

This MIGHT be fixable by moving everything out of ObjectDCs and into a DualDataChest, but that would be a bit complex.

Also, I changed the constants to use 213. Please check them to make sure they won't interfere with any of your other constants (they're low 3-digit numbers, discounting the prefix, so it's likely you'll need to change them). I coded these slightly better than Neo's Morph cards in one respect: Neo's morph code uses lots of registers within the ObjectDC of a given object (well, not TOO many, but it uses a different one for each card or something like that if I remember right) and it uses various other chests which can easily cause incompatibilities. The manifest code all uses a specific set of chests. One ObjectDC on each card that directly manifests one or more cards at register 0, 1, 2, 3, or 4 (it varies depending on the exact requirements of the ability). It uses a single ObjectDC at a constant register on cards that manifest indirectly (by that I mean Whisperwood Elemental will make cards manifest using the chest register constant TEJ_MANIFEST_CHEST to avoid interfering with any ObjectDCs on the cards themselves). It uses a single DuelDataChest at that same register. Everything else is done within those three chests, so it shouldn't interfere with anything else.

Also, I got the manifested card viewing working When you activate a manifested card's ability, it'll look for any matching cards in your library, graveyard, hand, and battlefield (in that order) and show you the card if it finds one. Click finish (you can select the card but the selection is 100% irrelevant) and it'll turn face-up. Click cancel and it'll stay how it is. If it doesn't find a card, it'll display the name, types, subtypes, cost, power, and toughness and ask which to do. It actually works really well. It'll only have to use that backup for cards which only have one current copy across all your zones ('current' meaning it's not currently a copy of something else, which includes manifest and morph) or if you get an enemy's card (with Ghastly Conscription).

They've all been uploaded to the folder, Tejahn. That leaves only Wild Slash.

Great! I'll follow the link and download those from the Google Drive this evening to do some extensive testing.

Okay. Note that if the first manifest card didn't work for you, these probably won't either in your current game folder. You might have to make a clean game folder to test them. It still requires just the files in the zip I uploaded. Also, I did have my friend test them on her computer and they worked for her, too, so that's good news

I would like to test as well.

PMed you.

Kithkin, is it okay to provide you the Fate Reforged core before the official release on the 24th. You are a keen and analytical observer so I would like to get your feedback before the release. I extensively checked for in-game UI scripting errors but having another pair of eyes searching isn't a bad idea. Is this something you would be interested in?

Tejahn wrote:Kithkin, is it okay to provide you the Fate Reforged core before the official release on the 24th. You are a keen and analytical observer so I would like to get your feedback before the release. I extensively checked for in-game UI scripting errors but having another pair of eyes searching isn't a bad idea. Is this something you would be interested in?

I just returned from a birthday dinner, so much alcohol is involved.I will take a short nap, so it will still be in the middle of the night in my tíme zone. But yes, I am very much interested in any kind of testing.

Xander9009 wrote:This MIGHT be fixable by moving everything out of ObjectDCs and into a DualDataChest, but that would be a bit complex.

Note that ObjectDCs are already in the DuelDataChest() as that is the only good way to store them.

Code: Select all

DuelDataChest: Register 8192000 (RSN_REGISTER_OBJECTDC_CHEST): Chest
- Register 0 (RSN_REGISTER_OBJECTDC_CHEST_COUNT): ObjectDC chest count (n)
- Register 1: Chest
  - Register 0: ObjectDC CardPtr 1
  - Register 1: ObjectDC Chest 1
- Register 2: Chest
  - Register 0: ObjectDC CardPtr 2
  - Register 1: ObjectDC Chest 2
...
- Register n-1: Chest
  - Register 0: ObjectDC CardPtr n-1
  - Register 1: ObjectDC Chest n-1
- Register n: Chest
  - Register 0: ObjectDC CardPtr n
  - Register 1: ObjectDC Chest n

So you can think about ObjectDCs as a card-chest map within the DuelDataChest. Though it should be noted that it is possible for some of the card pointers within 1-n to be nil (due to cards changing zones). If a card pointer is nil and it is requested to make a new ObjectDC the functions will search for the first nil pointer and replace that chest with a newly created ObjectDC. If no nil pointers are found within the range of 1-n then it will create a new ObjectDC at n+1 and update the chest count.

It would be possible to create persistable Lua objects that mimic standard constructs (like arrays, maps, and sets) that use DataChests making them persistable across actions, abilities, and even across cards.

[lua] [string "TEJAHN_FRF_WRITE_INTO_BEING_100391964_TITLE (RESOLUTION_TIME_ACTION)~0x000005e6"]:6: attempt to index global 'oDC' (a nil value)

Kithkin wrote:[lua] [string "TEJAHN_FRF_WRITE_INTO_BEING_100391964_TITLE (RESOLUTION_TIME_ACTION)~0x000005e6"]:6: attempt to index global 'oDC' (a nil value)

Fixed in the folder I made in GD.

Hey Riiak. Do you have any ideas on how to make Soul Summons work right if copied? At the moment, if I copy the spell, then the top card is manifested (by the copy), but it doesn't the ability to turn face up. This is because the ability is granted by Soul Summons and the data for the ability to show is stored in the objectDC of the now nonexistent copy.

The only thing I can think of to solve this is to make a manager token, but I'm not sure if that's necessary. Doing that way would hopefully just mean adding the card to a list which the manager token grants the relevant ability and then what happens to the original card that caused it to become manifested doesn't matter.