ROM Hack DS graphics .pac file

[yugdshack]

I want to hack the ds game;s graphics. When I was following the ultimate hack guide, I couldn;t find any narc/carc files, but only .pac fies. Does anyone know how to edit these files ?

 

[FAST6191]

I want to hack the ds game;s graphics. When I was following the ultimate hack guide, I couldn;t find any narc/carc files, but only .pac fies. Does anyone know how to edit these files ?

pac is something of a generic extension -- I have reversed at least three formats with the extension .pac and know of another three that others have done.

Still going by your other posts (by the way you do not have to trash them after they get answered -- others coming along and reading what went before is how we learn/get better at hacking) you appear to be tackling Yugioh WC 2011.
I had played with the game before but I do not think it was dealing with that.
Still you appear to have yet another filetype with the extension .pac
It actually appears to be quite complex as far as non NARC archives go which is unusual. I grabbed a small file, a large file and a medium file to have a look at. All appeared to house several dozen files a piece if the long list of names is anything to go by, similarly within those names there were gaps which usually indicates directories or something like it.

The first file after the names in calc2d.pac has RNAN early on which means NANR, before that though it has an 11 which means type 11 LZ compression, this lines up with the names thing as well which often had LZ in them.
The 11 is found at 1000 hex. No mention of that in the apparent pointer section that follows the names, this is OK as I often see offset pointers with the pointers starting at the start of the relevant section.

Stepping back from that for a second though we are going to have to consider this a bit before we jump into the extracting things gig.
Doing a search among the names gives 85 counts of 2E hex, 2E hex is the ASCII readout for a fullstop and is about the only thing the names have in common (none appear to be double extensions) so this calc2d.pac (all 237K of it) likely has somewhere around that of files.
Going to the pointer section, flipping and fiddling

The following is a text readout of hex editor for that selection. Format is location in the file for the first 8 digits, the first and second groups of four are the actual, albeit flipped, data from calc2d.pac (more on that in a moment) and the dots and random text are the ASCII readout.

00000C00 FFFF 0000 0000 0000 ........
00000C08 0000 0000 0000 00A9 ........
00000C10 0000 0200 0000 0107 ........
00000C18 0000 0400 0000 05A6 ........
00000C20 0000 0A00 0000 042B .......+
00000C28 0000 1000 0000 0537 .......7
00000C30 0000 1600 0000 00E4 ........
00000C38 0000 1800 0000 00E4 ........
00000C40 0000 1A00 0000 00E4 ........
00000C48 0000 1C00 0000 00E4 ........
00000C50 0000 1E00 0000 00E4 ........
00000C58 0000 2000 0000 042B .. ....+
00000C60 0000 2600 0000 042B ..&....+
00000C68 0000 2C00 0000 042B ..,....+
00000C70 0000 3200 0000 042B ..2....+
00000C78 0000 3800 0000 00F3 ..8.....
00000C80 0000 3A00 0000 00BD ..:.....
00000C88 0000 3C00 0000 0128 ..<....(
00000C90 0000 3E00 0000 04FD ..>.....
00000C98 0000 4400 0000 0553 ..D....S
00000CA0 0000 4A00 0000 05D2 ..J.....
00000CA8 0000 5000 0000 00F1 ..P.....
00000CB0 0000 5200 0000 00F1 ..R.....
00000CB8 0000 5400 0000 00F1 ..T.....
00000CC0 0000 5600 0000 00F1 ..V.....
00000CC8 0000 5800 0000 00F1 ..X.....
00000CD0 0000 5A00 0000 057D ..Z....}
00000CD8 0000 6000 0000 0549 ..`....I
00000CE0 0000 6600 0000 054F ..f....O
00000CE8 0000 6C00 0000 0566 ..l....f
00000CF0 0000 7200 0000 00E1 ..r.....
00000CF8 0000 7400 0000 1EA5 ..t.....
00000D00 0000 9400 0000 036C .......l
00000D08 0000 9800 0000 0D9B ........
00000D10 0000 A600 0000 2875 ......(u
00000D18 0000 D000 0000 3017 ......0.
00000D20 0001 0200 0000 1385 ........
00000D28 0001 1600 0000 1977 .......w
00000D30 0001 3000 0000 1695 ..0.....
00000D38 0001 4800 0000 166B ..H....k
00000D40 0001 6000 0000 17EF ..`.....
00000D48 0001 7800 0000 2B69 ..x...+i
00000D50 0001 A400 0000 2ABA ......*.
00000D58 0001 D000 0000 2AC2 ......*.
00000D60 0001 FC00 0000 2BB8 ......+.
00000D68 0002 2800 0000 19AA ..(.....
00000D70 0002 4200 0000 0C3B ..B....;
00000D78 0002 5000 0000 222B ..P..."+
00000D80 0002 7400 0000 21A5 ..t...!.
00000D88 0002 9600 0000 2356 ......#V
00000D90 0002 BA00 0000 22FB ......".
00000D98 0002 DE00 0000 1957 .......W
00000DA0 0002 F800 0000 1BBA ........
00000DA8 0003 1400 0000 0042 .......B
00000DB0 0003 1600 0000 00E0 ........
00000DB8 0003 1800 0000 0272 .......r
00000DC0 0003 1C00 0000 005D .......]
00000DC8 0003 1E00 0000 0272 .......r
00000DD0 0003 2200 0000 0272 .."....r
00000DD8 0003 2600 0000 0272 ..&....r
00000DE0 0003 2A00 0000 0272 ..*....r
00000DE8 0003 2E00 0000 0272 .......r
00000DF0 0003 3200 0000 0272 ..2....r
00000DF8 0003 3600 0000 0272 ..6....r
00000E00 0015 0000 0000 0000 ........
00000E08 0003 3A00 0000 0272 ..:....r
00000E10 0003 3E00 0000 0272 ..>....r
00000E18 0003 4200 0000 0272 ..B....r
00000E20 0003 4600 0000 0272 ..F....r
00000E28 0003 4A00 0000 0253 ..J....S
00000E30 0003 4E00 0000 012C ..N....,
00000E38 0003 5000 0000 0267 ..P....g
00000E40 0003 5400 0000 0267 ..T....g
00000E48 0003 5800 0000 0267 ..X....g
00000E50 0003 5C00 0000 0267 ..\....g
00000E58 0003 6000 0000 0267 ..`....g
00000E60 0003 6400 0000 0267 ..d....g
00000E68 0003 6800 0000 0042 ..h....B
00000E70 0003 6A00 0000 06DF ..j.....
00000E78 0003 7200 0000 06DF ..r.....
00000E80 0003 7A00 0000 06DF ..z.....
00000E88 0003 8200 0000 06DF ........
00000E90 0003 8A00 0000 06DF ........
00000E98 0003 9200 0000 06DC ........
00000EA0 0003 9A00 0000 05FA ........
00000EA8 0003 A000 0000 002B .......+

That is 86 lines for those without the benefit of a line count. Given the first is presumably a marker of some form that looks good -- if it has subdirectories I have occasionally seen pointer sections shunted to the later section and it all gets messy.
Back on topic as it were such a setup is common enough and is likely the classic pointer and file size combo. Will have to confirm that later though.

Back to the names.
On the face of it they look like normal names but look closer and there are all sorts of numbers in the mix as well. Going back to the gaps this might line up with directories.

A bit of fiddling (every file name in this file appears to start with d_ so I latched onto that as a replacement point) gives this rather crude names list for the first section, I also replaced all 0000 with new line and 3 so you can see the split. However I did not remove all the mixed in numbers at this point

3

d_dentaku_coin_obj01.lznanry
d_dentaku_obj01_top.lznanr
d_dentaku_obj_number.lznanr{
d_dentaku_obj_under.lznanrz
d_dentaku_obj_under01.lznanr-
d_dentaku_obj_under02_en.lznanr2
d_dentaku_obj_under02_fr.lznanr$
d_dentaku_obj_under02_ge.lznanr;
d_dentaku_obj_under02_it.lznanr%
d_dentaku_obj_under02_sp.lznanro
d_dentaku_obj_underfr.lznanry
d_dentaku_obj_underge.lznanrf
d_dentaku_obj_underit.lznanrx
d_dentaku_obj_undersp.lznanrI
d_dentaku_saikoro.lznanr
d_dentaku_coin_obj01.lzncer
3

3

3

3

3

3

3

3

3

3

3

3

3
p
d_dentaku_obj01_top.lzncer
d_dentaku_obj_number.lzncerr
d_dentaku_obj_under.lzncers
d_dentaku_obj_under01.lzncer$
d_dentaku_obj_under02_en.lzncer;
d_dentaku_obj_under02_fr.lzncer-
d_dentaku_obj_under02_ge.lzncer2
d_dentaku_obj_under02_it.lzncer,
d_dentaku_obj_under02_sp.lzncerf
d_dentaku_obj_underfr.lzncerp
d_dentaku_obj_underge.lzncero
d_dentaku_obj_underit.lzncerq
d_dentaku_obj_undersp.lzncer@
d_dentaku_saikoro.lzncer
d_dentaku_coin_obj01.lzncgrr
d_dentaku_obj01_top.lzncgr
3

3

3

3

3

3

3

3

3

3

3

3

3

3

d_dentaku_obj_number.lzncgrp
d_dentaku_obj_under.lzncgrq
d_dentaku_obj_under01.lzncgr&
d_dentaku_obj_under02_en.lzncgr9
d_dentaku_obj_under02_fr.lzncgr/
d_dentaku_obj_under02_ge.lzncgr0
d_dentaku_obj_under02_it.lzncgr.
d_dentaku_obj_under02_sp.lzncgrd
d_dentaku_obj_underfr.lzncgrr
d_dentaku_obj_underge.lzncgrm
d_dentaku_obj_underit.lzncgrs
d_dentaku_obj_undersp.lzncgrB
d_dentaku_saikoro.lzncgr
d_dentaku_top_bg.lzncgr
d_dentaku_top_bgfr.lzncgr
d_dentaku_top_bgge.lzncgr
d_dentaku_top_bgit.lzncgr
3

3

3

d_dentaku_top_bgsp.lzncgr
d_dentaku_under_bg.lzncgr 
d_dentaku_under_bg2.lzncgrx
d_dentaku_under_bg2_16.lzncgr
d_dentaku_coin_obj01.lznclry
d_dentaku_obj01_top.lznclr
d_dentaku_obj_number.lznclr{
d_dentaku_obj_under.lznclrz
d_dentaku_obj_under01.lznclr-
d_dentaku_obj_under02_en.lznclr2
d_dentaku_obj_under02_fr.lznclr$
d_dentaku_obj_under02_ge.lznclr;
d_dentaku_obj_under02_it.lznclr%
d_dentaku_obj_under02_sp.lznclro
d_dentaku_obj_underfr.lznclry
d_dentaku_obj_underge.lznclr
3

3

3

3

3

3

3

3

3

3

3

3

3

3
f
d_dentaku_obj_underit.lznclrx
d_dentaku_obj_undersp.lznclrI
d_dentaku_saikoro.lznclr
d_dentaku_top_bg.lznclr
d_dentaku_top_bgfr.lznclr
d_dentaku_top_bgge.lznclr
d_dentaku_top_bgit.lznclr
d_dentaku_top_bgsp.lznclr
d_dentaku_under_bg.lznclr+
d_dentaku_under_bg2.lznclrs
d_dentaku_under_bg2_16.lznclr
d_dentaku_top_bg.lznscr
d_dentaku_top_bgfr.lznscr
d_dentaku_top_bgge.lznscr
d_dentaku_top_bgit.lznscr
d_dentaku_top_bgsp.lznscr
d_dentaku_under_bg.lznscr4
d_dentaku_under_bg2.lznscr
3

3

3

3

3

3

3

3

3
l
d_dentaku_under_bg2_16.lznscr

The extensions (the four characters after LZ) and the earlier foray into the meat of the file says all classic DS SDK graphics formats.

Section wise that is 16 names, 16 names, 16 names, 17 names, 16 names, 18 names and 1 name.
The numbers before the first name in each section and after the runs of 00
061B19
061A70
061B1B
061912
061912
061C66
061D6C
Often I would have expected a file count here. Chances are we are not dealing with pointers and I doubt it is section length either.
On the other hand looking at the 00 sections the last names are always clean/not followed by anything so chances are the numbers are for the upcoming name.
That seems a lot more promising as it is typically one different to the length of the name and I probably should have seen that coming.

I have stuff to do so hopefully this points you in the right direction.

Edit.
I had an extra 5 minutes. I yanked a type 11 compressed NCGR file out of the 2d thing I was working with and decompressed it and opened it with Crystaltile2, it was a UI element and did not have a palette so a picture will likely not do you much good. It worked though.

 

[yugdshack]

To be precise, I am trying to change the name of the song in the song selection menu. (Though i can't figure out where that is)

I had played with the game before but I do not think it was dealing with that.

I am using the Japanese rom, btw


Edit.
I had an extra 5 minutes. I yanked a type 11 compressed NCGR file out of the 2d thing I was working with and decompressed it and opened it with Crystaltile2, it was a UI element and did not have a palette so a picture will likely not do you much good. It worked though.[/quote]

In the logo.pac, it had lz5bg and 5bg files, any way to edit them? When I try to open it in crystaltile2, it;s blurry, do you know any good viewer/editor for these files ? Thank You

 

[Auryn]

What game are you working on??

 

[yugdshack]

What game are you working on??

Yugioh World Championship 2011. I changed the rom's music, but the CPU's thinking sometimes get partially frozen until I close my ds or mash the buttons. I changed the music because I did not like it. Now I replaced all the SSEQ files with one that has 0 BYTES and the bad music no longer plays, also the CPU doesn't freeze.

Also I am no longer going to hack the visuals, but if you can help out others, that's cool too.

 

[Auryn]

Oic, well i never worked with any sounds on the NDS so i am sorry i can not help you there.
I worked on sound on video so what i can think is that you inserted a song with a too high rate so that it takes too long to buffer (if there is such function on the NDS).