dsp2003

Hi! The problem is not with the repacker, but with the script format itself. You need to resave all scripts of that nukige (so much K-On!, wow) in either Unicode or Shift-JIS, otherwise the engine will complain that you're mixing different encodings and refuse to start-up. Same case was when me and my friend translated Aozora Gakko no Sensei-kun (http://vndb.org/v632) - we had to repack the entire data.xp3 on-the-fly by using command-line version of xp3 repacker module in the end (you can grab it here, btw).

Blake, yes, this is how it's supposed to work. If you have problems with the game, please tell which one it is, as not every engine was 100% reversed. Sometimes it's impossible to generate byte-identical archives even with using of original extracted files, as they may implement protections or hidden fields which AE may possibly ignore when extracting data. Each such case must be studied with high precision.

After several days of headache I'm happy to present you new AE VN Tools build, now with full YU-RIS v4.90 archives and read-only YCG images support (they're named as .png, although the structure has nothing in common with normal PNGs, apart data compression (zlib)). I'll add creation of YCG images only if there will be a need for this. Although it's not that hard (split image in half, compress each part separately), but I don't want to do extra work without a purpose. P.S. The tool is only able to generate YU-RIS archives of certain versions, yet can open any version from v1.00 to v4.00 with no code changes thanks to my heuristics algorithm. If you need support for a particular version, please let me know (supplying the version number and encryption flag (0xFF or alike, see "Format" line in the GUI) will be enough).

Added support for YU-RIS v4.90 in AE. Details are here.

Ahem. Reverse engineering is legal. On the other hand, if you disassemble proprietary code and simply copy-paste it to your project, there might be problems. But if you're using it purely as reference to write documentation of the process, then somebody else writes code based on this documentation, it is 100% legal. Personally, I do not disassemble code at all. All I do is inspect data structures in HEX editor and writing my own code which parses them and attempts to decode/re-encode and reassemble. Many people consider this type of reversing very basic and cumbersome. I find it entertaining, even though it makes me impossible to hack something as hard as RealLive/Siglus.

In order to address the problem with Rejet and alikes, I've implemented new setting for AE: "Extract files into subdirectory which contain archive's filename", which is now enabled by default. The build which supports this feature is 0.6.10.420 2014/07/17. You can get it here. In case of scenario.rpd, new AE will create path "scenario.rpd~\scenario\". This is because the "scenario" subdirectory is a part of original archive's structure! No wonder people were messing it up, because they thought the directory was generated by archiver (which wasn't the case at all).

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.

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: -------- 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.

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.

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.

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: 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.

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.

Yes. The proper GUI should be rendered like this: Oh, and by the way, you can get the textual list of supported formats by switching to "Console" tab and typing in "d:arc" command (without quotes).

AE's (AnimED) maintainer here. Please refrain from posting direct links to files. Like I said on the homepage, they are deleted and replaced with newer versions from time to time, so your users will eventually get 404 errors. Next, please do not run AE under Japanese locale!! Like any non-unicode Delphi VCL application, it was only designed to run under either western or cyrillic-based locale, hence the application is rendered with wrong font proportions and distorted interface when you're doing that. Unfortunately, there's no way for me to fix this, even if I'll swap the development to more recent Delphi version. If you have problems or noticed any bugs, feel free to report them to my issue tracker at github. Another generic tool which wasn't mentioned here is arc_conv by w8m. Since r56 it's distributed as Open Source. Note it was written in NASM, so making changes to the codebase is nearly impossible, unless you have a deep Assembly knowledge. The distribution is password-protected, please read the ReadMe first to obtain it.