Collectible Card Game Headquarters

Deus Leonis wrote:I'm getting an error dump crash when i click start after the intro when using the DLL.
I'm guessing it's not compatible with SKIDROW crack huh?

It works fine with the Skidrow crack (I'm using Skidrow for testing purposes) as long as you are using the correct patcher dll. There is a patcher for DotP 2013 and a different patcher (the one in this thread) for DotP 2014. They both have the same file name so they are somewhat easy to get mixed up. Also some users are reporting crashes in relation to certain combinations of mods so if you've downloaded all the mods already try removing them and installing them one at a time to see if maybe one of those is causing the problem.

RiiakShiNal wrote:

Deus Leonis wrote:I'm getting an error dump crash when i click start after the intro when using the DLL.
I'm guessing it's not compatible with SKIDROW crack huh?

It works fine with the Skidrow crack (I'm using Skidrow for testing purposes) as long as you are using the correct patcher dll. There is a patcher for DotP 2013 and a different patcher (the one in this thread) for DotP 2014. They both have the same file name so they are somewhat easy to get mixed up. Also some users are reporting crashes in relation to certain combinations of mods so if you've downloaded all the mods already try removing them and installing them one at a time to see if maybe one of those is causing the problem.

Thanks for the fast reply and you were right RiiakShiNal.
It was sumomole's mod that was incompatible with Thefiremind & kevlahnota's mod for some reason.
You're awesome!

Someone else reported an incompatibility between sumomole's and kevlahnota's mods. I don't think my DotP2014 mod contains incompatible material, at least for now (I hope it will never contain it ).

I have unified the WAD patches for both games (2013 and 2014) into a single DLL to prevent user error in the future. The original download links from the previous threads (2013 thread, 2014 thread) have been replaced with this new build.

You can tell you have the new version by checking the file details in Windows Explorer, it will now have version information.

Just like Deus Leonis, the game crashes when I start DotP 2014 with a modded .WAD. If I mod DATA_CORE, it crashes instantly. If I mod DATA_DECKS_D14, it crashes when I click on the "Ignite your spark" screen. In my case, no mods are used.

I use the correct .DLL, which file details confirms (DotP2013+2014 etc etc etc) and which is noticable as the game starts instantly instead of waiting for a short time.

I use the SKIDROW release and (un)pack with Gibbed Tools r6_b10 (the latest version).

I completely unpacked DATA_CORE.WAD and DATA_DECKS_D14.WAD, moved the originals away, then repacked them. No crashes, at all.

I never thought of trying to unpack and pack it without making edits.

That does seem to work. However, that raises the question: why does it not accept the edits I make? I made the very same edits I made to ALL 3 previous DotP games: remove the "@[number]" behind cardnames (so the AI doesn't shuffle the card on the bottom of the deck on lower difficulties). Example:

<CARD name="PREDATOR_DRAGON_348475@2" deckOrderId="20" />

becomes:

<CARD name="PREDATOR_DRAGON_348475" deckOrderId="20" />

But as soon as I do that it crashes.

Also, editing in DATA_CORE the file DIFFICULTY_SETTINGS.XML (setting the values of Mage and Archmage equal to the values of Planeswalker. Manually, of course, not by some formula or something) causes that to crash as well.

How come that all doesn't work anymore?

Have you tried putting the modified files into a new wad to override the base game wads and running with unmodified base game wads?

In other words create a new mod with your modified deck XMLs and difficulty settings then running the game with these wads:

• DATA_CORE.WAD (unmodified)
• DATA_DECKS_D14.WAD (unmodified)
• DATA_DLC_MY_NEW_MOD.WAD (contains your modifications)

I believe the culprit is a playable deck limitation. If you have too many playable decks, it simply crashes, as I discovered that at least 1 Revenge decks turned into always_available works just fine (all other edits in DATA_DECKS work fine as well). I posted my suspicion on the forums.

Regardless, I'd like to try making a new .WAD out of it to see if my suspicions are correct even in that case. I'm running in some trouble though. I know how to create a WAD for 2013, but this knowledge doesn't seem to help with 2014 as my edits don't show: I even deleted the Revenge decks (temporarily) from DATA_DECKS to ensure it wasn't reading those over mine, but even then they didn't show up. I also even made a differently named copy of DATA_DECKS with only the modified decks to ensure the structure's right, but even then: no appearance whatsoever.

If you can provide me with a sample WAD that triggers the crash I can look into why it occurs (that is, the internal reason, not "playable deck limitation") and if it's possible to correct it, no promises though. Note that I don't want your rebuilt version of the core WADs.

This wad seems to cause a crash on the Skidrow version (at least for me). I tried to keep things pretty minimal so this is basically just 9 copies of Hunter's Strength (minus unlocks) with different file names and ids so that the game thinks they are different decks.

For others not trying to reproduce the crash: DON'T DOWNLOAD THIS! This basically adds nothing to the game so it is pointless to have unless you are trying to crash the game.

Looks like the crash is caused by the 10th always_available="true" deck for content_pack="0". Don't know what it's trying to do to the 10th deck though.

Interesting, well I guess for now I'm going to need to change the Deck Builder to stop including this attribute (though it would be important for people on other platforms in which the steam_id_1 won't unlock the deck). In the mean time people can simply set the Deck Availability of the deck in Deck Information to "Locked" to prevent the Deck Builder from adding the attribute.

Thanks for the information.

The default content_pack value is 0, so if you don't include it, it will still occur. I think what should be done is figure out how to add custom content_pack IDs to the "owned" list.

Looks like that ID is checked against against a "ContentManager" class, which is exposed to Lua. There is also a "ContentPack" class as well, also exposed.