Jump to content

Recommended Posts

Nope. You'll have to compile it first. By running the build.bat, you'll get:

 

* in arc_conv directory:

 + arc_conv.exe

 + arc_conv.dat

 

text_conv.exe is compiled separately - simply go to text_conv directory and run compile.bat.

 

But before compiling, you'll need to get r56 update and overwrite "include" directory to enable support for more Littlewitch games.

 

Also, you'll need to download the latest repipack_filelist. It's mandatory for extraction of Littlewitch games, because their archives only contain md5 hash of filename, which is also used as encryption for the beginning of files. Without the list you won't be able to extract and decode them.

 

In the result, your directory tree should look like this:

 

+ arc_conv.exe

+ arc_conv.dat

+ repipack.txt

+ text_conv.exe

 

Edit: Uploaded arc_conv source in finalized state here:

 

https://github.com/dsp2003/arc_conv/archive/master.zip

 

Simply run build.bat, hit spacebar two times and you'll get ready-to-use build of arc_conv. Have fun. :)

Share this post


Link to post
Share on other sites

As promised to maef I will add the tool to remove the weird transparency shapes from BMP sprites in VNs, big thanks to luch who wrote the .bat file to loop the process for all files, folders and subfolders.

DOWNLOAD

- extract and place all files into the BMP sprites root folder
- run convert.bat to convert all files within the folder and all subfolders into transparent PNG

example

original:

KceC4f2.png

converted:

IOgnTOz.png

Share this post


Link to post
Share on other sites

Steve, sorry to disappoint, but these "weird" BMPs are in fact 32-bit Windows Bitmap files with alpha channel, which is a standard format (yet for some dumb reason most of applications are discarding the Alpha component from 32-bit RGBA BMPs). The "artifacts" you are seeing are generated by Photoshop's pre-optimizer algorithm designed for PNG's zlib to compress data better.

 

You don't really need to convert them, they can be easely opened, viewed and, if needed, (batch-)converted via AE's Image Tool into PNG and back to 32-bit BMPs:

 

ae_image_tool.png

 

Converting them via ImageMagick's convert.exe may cause data loss, because it crops out the "invisible" data in the process (which is known to crash certain VN engines, because they use it for own purposes and integrity checks). It was one of the reasons why I've bothered writing my own converter in the first place. :)

Share this post


Link to post
Share on other sites
You don't really need to convert them, they can be easely opened, viewed and, if needed, (batch-)converted via AE's Image Tool into PNG and back to 32-bit BMPs:

Converting them via ImageMagick's convert.exe may cause data loss, because it crops out the "invisible" data in the process (which is known to crash certain VN engines, because they use it for own purposes and integrity checks). It was one of the reasons why I've bothered writing my own converter in the first place. :)

 

Well it probably depends on the reason you are extracting them in the first place - if you want to work with the sprites as sprites for another game (or I guess edit sprites for a FanTL project or something), you probably want to have them in the original format with the alpha channels, just like you said. Or still have the option to convert them using the AE tools.

 

But the main reason I and many others use sprites is for further images, logos, signatures, avatars, videos such as MADs or stream overlays - and for all those purposes those alpha channels are useless, you just want the transparent image as quickly as possible, that's why I packed the tool since you just drop it in the folder and run it and its done, no need to open any gui, select what to batch convert, setup the batch conversion etc.

Removing all the "invisible" parts also ensures the lowest file size while keeping good image quality for future editing, resulting in much less space being taken away (which might not seem important at first but when you have hundreds of game sprites like I do, it starts to take some serious space on the harddrive, even in PNG xD)

 

So yes, I would agree with you that it is important to distinguish the 2 reason to have sprites, if you want them for games then not converting them is definitely the correct choice, if you just want them for your own graphics and videos, then the imagemagic convert is fairly great tool.

 

 

So maybe maef make a note of that, that the tool I uploaded is only meant to be used for further processing such as graphics and videos, and not to put back into the game.

Share this post


Link to post
Share on other sites

So maybe maef make a note of that, that the tool I uploaded is only meant to be used for further processing such as graphics and videos, and not to put back into the game.

 

Yup was doing it.

Working on it, M'not slacking off !

 

@dsp2003

 

Are all the image formats displayed in the drop down menu implemented ?

There's a console message telling me it's not the case.

 

Is it also the case with archives ?

 

I mindlessly just copied everthing from both of these lists and told it worked.

I also checked with the console for archives, there didn't seem to be any problems.

 

But for images I'm not as confident.

Share this post


Link to post
Share on other sites
Are all the image formats displayed in the drop down menu implemented ?

There's a console message telling me it's not the case.

If you still have the AE back from 2012, please replace it with the latest build, cause it has a bug which prevented images from loading. You can simply drag-n-drop it onto the form regardless of file type. And yes, everything you see in the dropdown list is implemented, although [-] means the format is read-only.

 

Another power feature you might want to use is auto-joining of alpha masks. I.e. if there's a file called sprite001.jpg (or any other extension) and sprite001a.bmp, they will be automatically merged into single 32-bit image regardless of the former's bit depth. :)

Share this post


Link to post
Share on other sites

I've tested the tools for extracting arc*.nsa files on the tweaked versions of Umineko and Umineko Chiru (with PS3 sprites, etc). They don't seem to work. The program encounters an issue early in the extraction process and only a few bgm pics are extracted.

So it seems to work fine only for the original versions.

 

I didn't run it for too long but the arc*.nsa seemed to work for me for the game with updated graphics.

It started extracting the original sprites and I stopped it before anything new happened.

Maybe I didn't run it long enough ?

 

It's funny to see the original sprites in the archives though.

 

Edit : Actually I'm really confused ... the extraction process only extracts the old Backgrounds and sprites ...

Where is the rest Dx ?

Edited by maefdomn

Share this post


Link to post
Share on other sites

 

Edit : Actually I'm really confused ... the extraction process only extracts the old Backgrounds and sprites ...

Where is the rest Dx ?

With Umineko, you should have a folder with the japanese game, and inside it another folder with the tweaks (from which you run the english tweaked version). If you run the extractor inside the main folder with the japanese game, you'll only get the old stuff. You need to run it inside the tweak folder, with the new arc*.nsa files to get the new stuff.

But it didn't work for me in that folder.

Share this post


Link to post
Share on other sites

I went through and opened up Cocoro@Function!

 

I used exoozoarc for the .arc files

 

Voice.arc - all in-game voice clips
SysVoice.arc - all other voice clips (menus and stuff)
SysGraphic.arc - Images used for menus and interface
Se.arc - sound effects
Script.arc - .lua files
Rio.arc - .ws2 files
GRAPHIC.arc - character sprites
Effect.arc - .fx files
Bgm.arc - soundtrack

CHIP1 - background images

CHIP2.arc - some images with Bell, Taiyou

CHIP3A.arc - images with Asagao (some lewd)
CHIP3B.arc - images from lewdy scenes involving Asagao

CHIP4A.arc - images with Hijiri (some lewd)
CHIP4B.arc - images from lewdy scenes involving Hijiri

CHIP5A.arc - images with Mina
CHIP5B.arc, CHIP5C.arc - images from lewdy scenes involving Mina

CHIP6A.arc - images with Ibuki, Mebae
CHIP6B.arc, CHIP6C.arc, CHIP6D.arc - images from lewdy scenes involving Ibuki, Mebae

CHIP7.arc - images used for visual effects

 

The .dat files are all video clips, and anything you would want is pretty clearly labeled. You can use ExtractData to open 'em up.

 

Title.dat - opening title clip

PV.dat - promo video

OP01.dat, OP02.dat - OPs

ED.dat - ED

 

The others are

EFMOVIE_001.dat

EFMOVIE_002.dat

EFMOVIE_003.dat

EFMOVIE_004_1.dat

EFMOVIE_004_A.dat

EFMOVIE_004_C.dat

EFMOVIE_004_D.dat

CUBE_01.dat

CUBE_02.dat

 

These all seems to be for visual effects.

Share this post


Link to post
Share on other sites

Hey, folks. :) Accidentally, one of my contributors requested me to add newer Will Co Arc v2 format support (which turned out to be the same format as in exoozoarc). Either way, now you can open and repack those archives with AE.

 

I've also made some fixes to Alcot 48 format and added read-only (for now) Alcot 32 sub-format support. :)

Share this post


Link to post
Share on other sites

Tlg files are such a pain ^^

There seemed to be a tlg Susie tool but all the links are dead and Susie is kinda obsolete by now.

 

I only entcountered tlg in FSN and most apps used to deal directly with tlg for you.

 

And the game is so recent ...

 

I can't even find any extractors for Hikibi Works. :(

I'll keep searching, but I have low hopes.

 

http://fileformats.archiveteam.org/wiki/TLG_(KiriKiri)

http://kikyou.info/tvp/files/

I found these, you've probably found them too, but just in case.

Share this post


Link to post
Share on other sites
Is the E17 SCR Tool usable right now ?

It was usable since 2007, but mind you, it's only compatible with KID Engine VNs (i.e. Ever17, Ai Yori Aoshi and Memories Off 2nd. Some people also reported success with decrypted Never7 scripts) and the whole processing is very tricky and undocumented. Basically, I'm keeping this tool included into main code instead of making it a separate utility because I'm still working on fixing Russian translation of Ever17 and need a quick access to script chunk recombiner.

 

How it works:

1. Extract contents of script.dat via Archive Tool.

 

2. Make separate directory for each .scr file (not required, but strongly recommended)

 

3. Open .scr file via E17 SCR tool and press "Export chunks" button. Repeat for each .scr file

 

4. You'll get bunch of xxxx.scr_chunk_xxx files, which are now can be easely edited via HEX editor. The 0x01 opcode is used for word wrapping.

 

5. After saving results of your work, open .scr file which lies along with chunks and (if "Automatically import on loading" option is enabled) you'll get xxxx.scr_compiled with freshly edited strings (if autoimport is not enabled, just hit "Import chunks").

 

6. "Save copy into directory" does exactly that - when compilation is finished, it copies xxxx.scr_compiled into entered path and renames file into xxxx.scr. Once you'll recompile all edited scripts, you can combine them into new script.dat.

 

7. "Compile from list" is a batch compilation mode, which requires two conditions:

a) All scr files must be placed into their own subdirectories. For example: op00\op00.scr, sa01\sa01.scr, etc.

B) The list must contain directory names ONLY, which names must match with corresponding .scr files.

For example:

 

op00

sa01

sa02

etc.

 

--------

 

On another news, I've tried addressing several major bugs and design flaws of AE and working on version 0.6.10.420.

 

Among lots of improvements, I've fixed distorted interface under non-western locales. Feel free to check out current work-in-progress build and let me know if it works for you.

Share this post


Link to post
Share on other sites

The interface looks the way it is supposed to. No more distortions, so that's good.

Now the console is usable \o/.

 

However I still get the message : "WARNING : Your operating system is UNSUPPORTED. Errors are likely to occur" under jap locale.

 

I don't know if that has something to do with my Locale or Win 8.1.

However I haven't entcountered any problems so far

Share this post


Link to post
Share on other sites
I don't know if that has something to do with my Locale or Win 8.1.

Windows 8.1. I don't have resources nor time nor wish to implement workarounds for dumb NT 6.x (Vista/7/8/8.1) memory and file access lockups. Technically, if you'll use AE outside of Program Files directory (which is protected), it will work as supposed to. Otherwise, I won't be able to help. Simple as that.

 

Edit: People has reported bugs when Aero theme is enabled - image tool controls disappear. The solution is to stretch AE's window a bit until they'll show up again. Apparently, this is Aero's bug, as it won't happen when classic theme is enabled.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.

×