Breaking the 1114 limit in POC

[vjeko1701b]

So, since YGO 2005-11 .bin database files are fully compatible with all versions of the POC games, I've been trying to break the 1114 limit that is probably set in the engine. Can't be 100% sure, but no edit of any of the bin files made any difference.

So far, I've searched for any instance of 1114 in hex (5A04) in all three engines and there's quite a bit of results. Trough some elimination, I've tried replacing some with 2350 in hex (2E09) which is the size of 05-11 YGO card database. I skipped a fair number of instances with repeating patterns after 5A04.

I'm guessing a limit of this kind wouldn't have to be repeated over 20 times in the engine. Even if it was there for every bin file individually, which would be extremely superfluous, it would still need at best 8-9 repeats, especially since the engine references different languages not by separate strings to bins, but by an automatic extension recognition (eng, spa, ita...etc)

One instance crashed the game, others made no difference.

Next I tried the last line position in the .bin databases in hex (08B5 for 1114 cards and 125D for 2350 cards). I theory, the POC engine could be programmed to read up to a specific line in the bin files. Again, not much progress was made there. Another problem was that although POC engine had quite a few instances of 5A04 and 08B5, YGO engine ususally didn't have any for 2E09 or 125D but then again, by that time, perhaps they changed it to have no limit when it came to the card slot/database size.

Then last slotted card. POC - Slime Token (8307), YGO - Gear Golem (F30B)

Last I tried highest internal indexed cards in each game, for POC that would be Launcher Spider (5509 in hex) and for YGO it's Gear Golem (F30B in hex). Perhaps the POC games were limited to the highest inside index after which they stop. Again, no additioanl cards appeared.

This thread is mostly for brainstorming. Perhaps one of the mentioned methods was the solution, I just did it wrong, calculated the hex wrong or missed something. Perhaps someone will have a better idea based on these attempts.

[derplayer]

Hey,

i think it's not going to be an exact value that you can replace in hex editor.
When i worked on YGO2, i noticed an interesting file.
In YGO2 2006 beta, there is a source code leftover file, related to the card IDs.

#define	DEF_ALLCARD_BEGIN	4007
#define	DEF_ALLCARD_END		(7039+1)
#define	DEF_ALLCARD_NUM		2659
#define	DEF_ALLTOKEN_NUM	30
#define	DEF_ALLDATA_NUM		(2659+30+1)
#define	DEF_ALLLINK_NUM		779

It's more like they start at a random index to obfuscate stuff. My guess is that the POC variables related to the card limit are similar structured? Maybe this helps you.

[vjeko1701b]

Interesting. Viewing at the code, would those appear as values pretty close to eachother?

Not sure what exact value would be BEGIN and END at 4007 and 7039+1 respectively.
All card NUM would probably be 2659 playable cards
All token NUM 30 tokens
All data cards+tokens+1 additional
All link value 779...no idea...
771 was the original POC unlocked card number. Add to that 4 tokens, 3 god cards and glory, that would be 779
Perhaps all cards carried over from previous versions? That wouldn't make much sense.

Perhaps if I translated these values into hex, find their format in the YGO2 exe and then search for a similar thing in POC, just with it's own values

One things that does help is that there's a mentioned of the exact number of cards but without tokens and 1 other. So I could try to look for 1109 instead of 1114 in POC exe. Also, there are 5 tokens, so along with 5504, there should be 04 nearby.

[vjeko1701b]

What about this sting of numbers

55 04 8B C7 5F C1 E0 04 03 C2 5E 89 45 08 5D 5B 83 C4 0C C2 0C 00 8B 45 08 89 55 04

Starts at 50917....

You have 55 04 (1109), then 04 very close and then again 55 04 pretty close

But honestly, even opening ygo2.exe from 2006, I couldn't find any sufficiently close appearance of values 4007, 2659 and 779...or to be more precise A70F, 630A and 0B03.

[vjeko1701b]

I even tried some light analysis of poc and ygo2 in ghidra...honestly, it's gonna take someone much smarter to figure this out...

Seeing this uncompiled code from ygo2, I would say it's probably possible but finding it is like searching for a needle in a haystack without even knowing what a needle was.

[derplayer]

I played around a bit and found those two interesting address (JTP v1.1) that are inside the BIN files handling code. I edited them to match YGO1 code (0x045B (1115) -> 0x092F (2351)) and a modified card_pack.bin with 2351 entries. It seems that the files are loaded correctly into memory and all, but the card list is still showing 1114 cards only...

[derplayer]

Uhh...

[Ahmed-Mortis]

I found them but it didn't work, still showing 1114 for some reason

[vjeko1701b]

Niiiice!

[vjeko1701b]

I can't find the exact addresses of the strings needed to break the limit.

[vjeko1701b]

Update - I managed to find the appropriate strings but after edit, I'm still at 1114 cards in the game. Perhaps I have the wrong version of the .exe?

[kiemkhach]

@vjeko1701b I'm also trying to break the 1114 card limit. I'm using the free version of IDA combined with AI to analyze and reverse engineer the exe file. I've narrowed down about 4 to 5 suspected locations for the 5A04 limit. If you're still interested, I'd love to collaborate with you.

[kiemkhach]

My plan is: first, I will try to break the 1114 card limit. The next step is to reverse engineer most of the important functions, especially those affecting card effects. The final step is to try adding new code by packaging it into libraries and importing them into the executable file. This will be a very long journey, so I would be very happy if anyone could join me.

[derplayer]

Sounds great! Good luck with it. When you reverse all card related functions and their locations, the effects could be backported from the YGO2 executable, its the same structure/framework they work in and even the CPU handling code for those effects.
For raw engine functions, you can look them up in the yaneSDKv2 public domain opensource code (v2 was used by Power of Chaos games) https://github.com/derplayer/OpenJoey/tree/master/examples/yaneSDK2_165

[kiemkhach]

wow thankyou. that would be helpful for me.

[kiemkhach]

@vjeko1701b about your source code (https://github.com/derplayer/OpenJoey/tree/master/examples/yaneSDK2_165)
I remember we had a discussion about how to calculate the card properties. I suggested an Excel file; however, at the time, my formula had a slight error. Specifically, the order of the greater type should be as follows:

// Card property enums
enum MonsterType {
TYPE_UNUSED = 0x00,
TYPE_DRAGON = 0x01,
TYPE_ZOMBIE = 0x02,
TYPE_FIEND = 0x03,
TYPE_PYRO = 0x04,
TYPE_SEA_SERPENT = 0x05,
TYPE_ROCK = 0x06,
TYPE_MACHINE = 0x07,
TYPE_FISH = 0x08,
TYPE_DINOSAUR = 0x09,
TYPE_INSECT = 0x0A,
TYPE_BEAST = 0x0B,
TYPE_BEAST_WARRIOR = 0x0C,
TYPE_PLANT = 0x0D,
TYPE_AQUA = 0x0E,
TYPE_WARRIOR = 0x0F,
// Additional types when useSecondary flag is set
TYPE_WINGED_BEAST = 0x10,
TYPE_FAIRY = 0x11,
TYPE_SPELLCASTER = 0x12,
TYPE_THUNDER = 0x13,
TYPE_REPTILE = 0x14,
TYPE_TRAPCARD = 0x15,
TYPE_SPELLCARD = 0x16,
TYPE_NON_GAME_CARD = 0x17,
TYPE_DIVINE_BEAST = 0x18
};

Additionally, for trap/spell cards, we have the following types:
00006001 Normal Spell
00006401 Field Spell
00006601 Equip Spell
00006801 Continuous Spell
00006A01 Quick-Play Spell
00006C01 Ritual Spell

00005021 Normal Trap
00005221 Counter Trap
00005821 Continuous Trap

As you can see, the 6th byte specifies the type of S/T. Specifically:
0 => Normal
2 => Counter
4 => Field
6 => Equip
8 => Continuous
A => Quick-Play
B => Ritual

The unplayable cards will be in the format: 00007001. In Joey's deck, there is only one card: "Glory of the King's Hand".

[derplayer]

ah yeah i noticed issues with winged beast type in the cardlist scene and fixed it a month ago but have not pushed yet, its now up

[kiemkhach]

Regarding breaking the 1114 card limit in POC, there's another important issue besides modifying the exe file (related to the data.dat file).
Data.dat contains two very important files: card_id.bin and cardintid.bin.

• Card_id.bin, as the name suggests, stores a list of IDs (of the 1114 cards) in the order of card index. We can consider card_id.bin as a mapping of cardIndex => cardID.
• Conversely, card_intid.bin stores a list of card indexes in the order of cardId. We can consider card_index.bin as a mapping of carID => cardIndex.

The problem is that the card_index.bin file has a fixed length of 4096 bytes, storing indexes for 2048 IDs. Why 2048 IDs and not 1114?
Because the card IDs of all the cards are not contiguous. For example, in Joey's case, there are no card IDs in the range 1924 to 1999, while 2000 is the card ID of BEWD (alternative art). And card_index.bin still needs to store 4098 bytes for the index of 2048 IDs (even though there are zero bytes representing IDs that are not in use). => Problems will arise if we add a new card with an ID greater than 2048.

In summary, we also need to try doubling the length of the card_intid.bin file to 2*4096 to see if POC works.