Gabriulio

Thank you, thank you, thank you. That tool managed to extract all text with no encoding issues whatsoever.

First of all, thank you very much for your help. The script might be encoded in UTF-16, but it appears to be a mix of LE and BE. Some parts are readable in one encoding, but not in the other. And some characters aren't readable in either of the two. For example, the following line: This is the very first line of dialogue in the game. Character name "ミニー" and the dialogue is "「きゃはははははは」". Now this is the line when using UTF-16LE: Total gibberish. But when we changed it to BE: It becomes partially readable. For example, "ミニー" becomes "胟ニー". I checked the other lines who only become readable when using BE, and they also have issues where some kanji or kana are displayed wrong.

Hello, I'm having trouble with the scripts for the Shingakkou series (the original game and the two fan discs) by Pil/Slash. The games seem to run on their own custom engine instead of a commercial one like NScripter or kirikiri. All files are contained in .dat archives that I can easily extract by using arc_conv. The visual assets and audio files aren't encrypted, so just running arc_conv is enough to obtain those files. The problem lies with the scripts. The scripts are encrypted as .scn files. Now, I must once again stress that the Shingakkou series does not run on kirikiri. Those scripts are .scn,.. NOT .ks.scn or .txt.scn. After testing three different tools meant to work on .scn kirikiri files (just in case), none of them worked. It's very likely that Shingakkou's .scn and kirikiri's .scn are different types of file whose extensions happen to share the same name. When I say the scripts are encrypted, I mean this: when opening those .scn on Notepad++, they only show gibberish even when changing the locale to Shift-JIS. Now, even though the scripts show gibberish, the filenames for backgrounds and voiced lines are clearly readable. To showcase this: Here's a raw .scn script open in Notepad++: Now, for the sake of making things more readable, let's temporarily remove the control characters: This is what we get. "bg_019a" is the filename of a background, and "augu_august_ed_bad1_00001" is the filename of a voice file. "00000D_0000qN0_m@W,g_0}00_k0c0S003___" is supposed to be the filename of a character sprite, but those are all written in Japanese characters which can't be properly displayed. It becomes obvious when you compare it to the way the character sprite filenames are structured: So yes, there must be a readable script in there, I simply don't know how to decrypt it. Of course, I can't rule out the possibility of arc_conv messing up the scripts when it extracted them from the sin_text.dat archive. Any help would be very appreciated. Here's a folder containing all the extracted .scn files and here's the original archive. Also, to clarify: I have tried using GARbro. It was in fact my first choice, however GARbro can only open some of the .dat archives and even those that it can open won't extract properly. I'm also using Japanese locale, that's how arc_conv managed to extract the character sprites without messing up their filenames.

But it... did upload correctly. Wait, wait, wait. There clearly is something wrong in here. First of all, I've just noticed that the actual nscript.dat really has only 0b. I just now did a series of tests: - First of all, I suspected the script might be contained in the .np files, and nscript.dat was just a dud because Nscripter needs that file despite whatever mumbo jumbo the programmer did. So I erased nscript.dat. The game didn't start and I got a warming that "the script couldn't be found". - After that I tried using a blank 0.txt and it didn't work again, with the warning being "*define label does not exist". Converting that 0.txt into a blank nscript.dat also didn't work either. Which is strange because how can the normal nscript.dat be necessary if it has 0b? - Then I tried inserting the nscript.dat from another VN, and its arc.nsa as well. In short, I was testing to see if the .exe could run another VN. It didn't work, but the warning it gave me was eye-opening: "*define label function overload". Somehow, the programmer managed to put the actual script in those .np files... I guess. I tried erasing those .np files one by one. Most of the files couldn't let the game run because of function overload. 00.np = *define 01.np-10.np, 90.np = *cg_mode Leaving only 91.np and 92.np allowed the other VN to run properly and without any errors, which means... I don't even know anymore. I never heard of that file extension being used in Nscripter until now, and googling it didn't show any results. If anyone wants to try making sense out of it, here are the .np files and the 0b nscript.dat.

Sure, here it is.

Ketsuhame. It's a doujin BL VN. The game runs fine without any problem whatsoever, it's just that I can't extract the script from nscript.dat.

So, I've downloaded this VN a few hours ago. It runs on Nscripter, and so I tried to extract the script from nscript.dat and the files from arc.nsa. However, I've run into some troubles: - First of all I've tried to use ExtractData, which tells me that "nscript.dat/arc.nsa does not exist". I found it strange since ExtractData works perfectly with other Nscript titles, and obviously those files do exist. - After that I tried usign NSDec and NSAOut. NSAOut managed to extract background/sprites/CGs/BGM without any problem whatsoever. NSDec on the other hand doesn't work at all. - Another thing I've noticed is a bunch of files with a .np extension, numbere 00-10 and 90-92. What exactly are those files? I've never seen those on a Nscripter game.