search

nnguyen259 / KuroTools

Tools for working with Kuro no Kiseki .dat and .tbl files
MIT License
33 stars 7 forks source link

Additional schemas by soft #3

Closed SoftBrilliant closed 2 years ago

SoftBrilliant commented 2 years ago

For some reason no json generates despite the IDE giving no errors whatsoever. But otherwise, minus the large amount of missing info in the schema (much of the unknown values will need to be tested with actual modding on the PC version) this is basically complete aside from this one bug which I'm not sure why it's even occuring at all due to lack of error messages :/

TwnKey commented 2 years ago

Had a quick look. On my end I had to add an unsigned int after "empty5" because the script would get stuck in a while loop (thus not generating a json). However, the "flag" thing can't always be decoded with UTF-8 (it's fine when the flags equals "SC", but when the first byte equals 0xDD, it's invalid for UTF-8). I think @nnguyen259 already encountered something like that and made a custom encoding or something? I can look at it and help with that if need be.

SoftBrilliant commented 2 years ago

Okay, so I fixed quite a few bugs, then I set the flag1 thing to data8 just to simplify my life and not bother for now. Flag1, on the entry for Revenge Arrow, points to a "0xdd" value which utf-8 cannot read. What's weird is that, for every entry except Revenge Arrow, flag1 and flag2 point to the same value (this is why the recompiled version of the file is so much longer than the original one when recompiled since the script creates new offsets with identical entries when recompiling to tbl). Revenge Arrow is just in general a weird entry in general with a value that is used exclusively by it that idk what it does (the one called "vengeful_one"), and the fact it points back to regular attack as a skill substitute despite not using most of its data which is kinda weird. Though, in general, unless something is missing or you guys want to fix the bug with encoding and the 0xdd value, it should be usable in its current state and decompile and recompile just fine.

TwnKey commented 2 years ago

WhereisDD

In Ghidra you can see 0xDD is not a regular value, it probably doesn't do anything when set to 0xDD, and will just skip to the next byte. I suggest writing a parsing that just reads a null terminated array of bytes

SoftBrilliant commented 2 years ago

That would probably be the solution required here. Though since I don't know how to do that myself, I'll probably either tell people to modify the file in some way, or keep it as-is for now. I have no clue where to even start on modifying parser.py to change this myself anyhow :/

TwnKey commented 2 years ago

I would do it if I was sure @nnguyen259 didn't do it already.

TwnKey commented 2 years ago

So I'm guessing we're waiting for that "two pointers to the same thing" issue to be handled to merge Soft's stuff to the main branch, is that right? Because there are actual users of that tool now.