ROM Hack How do you edit a palette in nds games if it is LZ77 compressed?

[Saif007]

How do you find colour palettes in a nds rom where they are LZ77 compressed?

 

[FAST6191]

Most palettes are not compressed but there are some exceptions, especially when they are contained within other files (2d graphics might have their own palette bundled with it, or oftentimes before the 2d graphics start).

Names and extensions, including directory names, is where most start.
This can also include looking in the same folders that you find the 2d graphics in, or files with the same names as those of the 2d graphics (or a version of it blah_npc_01.img blah_npc_02.img blah_npc_03.img and so forth might just have a file like blah_npc.pal).
Most tools like crystaltile2 and tile editors in generally will usually have an option to take a selection of data from one part of the file (or a savestate, though probably not for
the DS). For some reason crystaltile2's is in the hex editor window rather than graphics.

You need not find your chosen file right away -- if you find one palette in the game then chances are most of the rest use a similar pattern.

You can forcibly decompress things ( https://www.romhacking.net/utilities/826/ being command line can easily have a batch file made to decompress whatever you like in a long list) and then try searching for things like mentioned in other replies (find the palette from memory http://problemkaputt.de/gbatek.htm#dsmemorymaps and compare to your newly decompressed files)

Beyond that then corruption/file swapping if you don't know assembly/tracing. If you edit the file and play the resulting game and something has changed then as you hopefully know what you changed then you can.

Beyond this then we are probably are tracing. The palette if it is used in the game will have to land in said 05000000h region. Personally I would find when the graphics get used in the game and note when. Either at the start of the level or maybe even start of the room that area will be written to.
Load up a debugger (no$gba debugger is your best bet here) and set a break on write for the particular part of the 05000000h region that it gets written to (depending upon how the graphics setup is done there can be multiple areas, no sense making more work for yourself so narrow it down).
If it is compressed then it might use the BIOS compression so you will see a call to that (they are called SWI aka software interrupt) somewhere in the instructions preceding it. If the game uses its own decompression (possible as it can be faster, and can be custom -- for the GBA then several dragon ball z games have some fun here) then you get to step backwards through that to where it first lands in memory.
From here you can try searching for this initially compressed data (it will likely be the same as it is in the ROM after all), or you can follow it right back up the chain to the read from the DS ROM itself. As mentioned in an earlier post the DS does not have the cart or parts thereof variously visible directly in memory like most other cart systems before it (including the GBA) so it behaves more like a CD/DVD based system and has a little chip it speaks to so as get data from the ROM. http://problemkaputt.de/gbatek.htm#dscartridgeprotocol covers how that works, B7 is the command there). You might also be able to stop a step before that (or skip fiddling with the read commands) as chances are it will use one of the read options it has available within games (Nintendo also provides a nice library to handle reads that more devs use) and it will try to hunt down what file it wants to put there from the file names and allocation table which you can then look up and grab yourself.
Bonus of doing this is any custom compression or encryption will necessarily have to be handled, and all this will give you exactly what it takes to do it.
You might also find a file table in the memory somewhere and set a break on read to that around the time the thing will be starting to be loaded and go from there.

Tracing is one of the higher end skills of a ROM hacker but a basic version like above and also in https://www.romhacking.net/documents/361/ (an older concept for the GBA but more worked examples is good and other than the file system thing is much the same between systems) can be performed with more modest skills* than it might take for other things like fiddling with AI, figuring out compression routines, fixing bugs and what have you but still nothing that I would not expect reasonably capable computer people to pick up with an evening or so fiddling.

*if you can follow along to find the character the guide wants then you can probably find a NPC or something you also want to edit using much the same technique, just slightly tweaked. Alternatively if you can remake the link for another emulator -- that one being command line makes it tedious for some, and no$gba also does GBA debugging which is probably a shock given the name, so do it in a graphical one then you are probably also capable of twisting it a bit.