News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Nagato

Pages: 1 [2]
Script Help and Language Discussion / Re: 8x16 Kanji ID
« on: February 09, 2012, 08:07:56 am »
I'm not too sure about the red ones. The first one seems correct but is a bit out of place. The second one is probably wrong, so somebody should check on it.
I think the first one might be 悟 and the second one might be 数.

Newcomer's Board / Re: Help finding video/animation
« on: January 28, 2012, 12:54:19 am »
Take a look at MKDS Course Modifier. You can use it to extract the NSBTX from the NSBMD which the program can edit. Once you have the edited NSBTX you can just reinsert it back into the NSBMD. To reinsert the NSBTX file you would need to edit the total filesize at 0x08 and fix the section pointers. I threw together a quick tool since the entire process is just splitting the NSBMD into two and readjusting a couple things. It assumes that there will only be 1 TEX0 section in any files it deals with and will exit if it can't find one. The various tools I opened the modified file in showed that it at least worked there but I don't know how it'll work in-game. Here's the docs if you (or anyone else) wants to write something better for modifying NSBMD files.

Modified example:

Use it from the command prompt like so: insertnsbtx.exe 0623.nsbmd.decompressed 1.nsbtx test.nsbmd

Ghost Babel\Metal Gear-Jtext, Locked\*.txt - All ISO-2022-JP text files
Ghost Babel\Metal Gear-Jtext, Locked\Metal Gear Text - Plain .rtf file
Most of the filetype-less files in the Ghost Babel folder: EUC-JP text scripts. EUC-JP and not just plain ASCII is because of 99-129C.
Ghost Babel\MG English Final - Not sure which version exactly (judging from some of the strings in the file, probably Microsoft Word 97) .doc file. Definitely has the same format as a .doc file though.
Ghost Babel\MG English full - Same deal as MG English Final
Ghost Babel\syn.chara 1.doc - As the filetype says, just a doc file

Edit: Fixed some things.

Programming / Re: Help with Disassembling GB/GBC Roms with better aproach
« on: January 05, 2012, 09:05:20 pm »
My reason for posting that wasn't to say not to do it but to make sure he knew what he was getting into. It's a very ambitious project that is aiming way too high in my opinion. Tauwasser's comments covered a lot of the big issues with the proposal. It might be better to scale the goals back and work toward something smaller first. Unless you are dead set on having it as a separate application, consider using IDA as the base engine (which alone will already cover a lot) then build all of your analysis techniques into python scripts and run them using IDAPython. You will at the very least start with a very powerful engine and you will already have the basic techniques covered (following jumps/calls/etc).

Programming / Re: Help with Disassembling GB/GBC Roms with better aproach
« on: January 05, 2012, 06:24:20 pm »
I suggest studying the halting problem long and hard before going any further.

Script Help and Language Discussion / Re: 8x8 Kanji ID
« on: December 07, 2011, 10:15:57 pm »

本部(bullet icon)(乾?)前中立捕


If that's not 乾 then I'm not sure what it is.

ROM Hacking Discussion / Re: [PC] A couple of questions
« on: December 04, 2011, 04:12:18 pm »
I had a similar question to this, actually. I found the CreateFont() call in the game I'm working on and adjusted the region parameter accordingly (which created a whole lot of mojibake in my game), but the LPCSTR font name parameter points to a null value and the game still defaults to MS Gothic. I'm sure that I'm editing the right call, though. What's going on here?
What Klarth said is correct. From MSDN: "If lpszFace is NULL or empty string, GDI uses the first font that matches the other specified attributes."

If you want to use a specific font then you'll need to find a safe spot to put the font name into the EXE and then another spot to put a code cave at so you can push the new address. If you can't find a sufficient amount of blank space then you can add a new blank section to the EXE and just write all of your code and strings in there.

ROM Hacking Discussion / Re: [PC] A couple of questions
« on: December 04, 2011, 09:43:00 am »
If you want to make a thorough change to the locale you will need to hook the locale functions to ensure they say they all think they are running in ANSI instead of CP932. Off the top of my head these functions include GetACP(), GetLocaleInfo(), GetOEMCP(), GetConsoleCP(), GetConsoleOutputCP(). This isn't all of them but it covers most of the major ones I can think of. I didn't list any of the Ex versions of the functions so you will need to look at the MSDN pages for those to get a more thorough list.

To change the font you will need to change the calls to CreateFont() and CreateFontIndirect(). For the CreateFont()s you will need to change the charset parameter as well. Shift-JIS is charset 128 (0x80) so find that and change it to ANSI. Note that you cannot use any Japanese characters after you change the charset of the font or else you will start seeing gibberish characters. CreateFont() also accepts the name of the font so you can just change it from MS Mincho to whatever there.

Start with changing the charset of CreateFont() and then move on to the other functions if the game still doesn't work properly.

Newcomer's Board / Re: Visual Novel Scenario Encyption?
« on: December 02, 2011, 10:18:25 pm »
It depends on what version of Reallive your game uses. If it's below Reallive 1.4 then rlBabel (included with rldev) should be able to handle all of the text stuff just fine. If rlBabel doesn't work with your version then you'll probably be stuck with the default fonts and without built-in wordwrapping. I'm not sure how the engine handles text overflow without rlBabel but with it, it can properly create new pages and such. There really aren't any rules you can go by. Just figure out what looks best in-game and go with that.

Newcomer's Board / Re: Visual Novel Scenario Encyption?
« on: December 02, 2011, 03:24:11 am »
Sounds like a problem with the disassembler. It might require some hacking around with the source code to get it to disassemble properly. To edit the text you just need to edit the .sjs/.utf files and then reassemble the scripts with rlc.exe.

Newcomer's Board / Re: Visual Novel Scenario Encyption?
« on: December 02, 2011, 01:57:02 am »
I'm trying out the fork as we speak, and hopefully I'll be able to report back on that on the morning. Currently I'm feeling like a bit of an idiot for tying to look up what on Earth this error message is telling me to do.

Error:Error:unable to locate reallive.kfn. Try setting $RLDEV to your RLDev installation directory.
This is only a problem when the paths aren't set or are set incorrectly. The easy way to fix it is to copy the files from the "lib" folder into the "bin" folder. The harder (but still easy) way is to modify the PATH variable to include the directory with the .kfn file.

Also, seeing as you worked on Kanon, d'you mind if I ask whether that game had .gan files on the disc? I know they're some sort of scheduling/management program (which  reads them as corrupt), but do VN companies usually leave them in there? The game I'm working on has a whole folder of 'em, and it seems a little odd to me, but then again, I don't know a lot about how companies do their work.
I'm actually not sure what program you are referring to. Kanon had 1 gan file but no programs for them from what I remember. GAN files are just animation instructions. You can convert the GAN files to xml with rlxml included with rldev if you want to look at them.

Newcomer's Board / Re: Visual Novel Scenario Encyption?
« on: December 01, 2011, 08:10:23 pm »
Haeleth released his rldev toolset for the Reallive engine a few years back but he has since left the community so it's pretty outdated. Here's an updated fork in case Haeleth's version doesn't work. If *that* one still doesn't work you can try tracking down Richard_23 and ask him for rldev 1.51. I'm not sure if he's released it publicly but I know he made his own fork for the Little Busters! project which has additional encryption that Haeleth's version doesn't support.

As for the .cgm and .tcc files, I don't recall us ever having to edit those for the Kanon project so you probably don't need to touch them unless you have a specific reason for wanting to modify them. If you're looking for the images then they are usually in the G00 folder. rldev supports conversion to and from the g00 format so you're covered there, too.

Personal Projects / Re: Magna Carta
« on: October 30, 2011, 08:54:07 pm »
"All the time. I want to stay here with you. I also think with you, and I want to make to live in harmony harmony. Oh, I love you."

Song lyrics? >_>


Programming / Re: Looking for a Tileviewer with Tilemap Function
« on: October 16, 2011, 08:35:38 am »
I played around with it a little bit. Here's everything I could figure out:

The first dword is the offset to the section after the file table (or size of file table + 4, however you want to look at it). Take that number, subtract 4, and divide by 4 to get the number of files in the MAP.

Each file except one seems to be an image. The ones that are images usually start with 0x00000010 and followed by 0x00000008 or 0x00000009. The ones that break this mold start at 0x30618. Since there's 3 files that are images and 3 files that aren't, and the images are fragmented, the last 3 files are probably information for those images. Just a guess so it could be wrong.

The images that have 0x00000010 and 0x00000008/0x00000009 have the following format:
dataOffset+0x08 - dword, size of palette
dataOffset+0x14 - start of palette
dataOffset+0x14+paletteSize - image data

Back to the header of the .MAP:
I'm not sure what the data at 0x20-0xb0 is based on this one file.

0xb0 - The map for MGEN99.TFS
0xb4 - Width (in tiles)
0xb8 - Height (in tiles)
Starting at 0xbc is the tile data. Each entry is a dword.

The offset 0xb0 will probably change depending on the data starting at 0x20.

Pages: 1 [2]