Home of the Touhou Megapack

Currently, I'm planning on:
+ Adding thprac
= Fixing non-default config files present in the Yumejikuu disk images
- (Possibly) removing the old English hardpatches for most Windows games

That last one is going to continue to be controversial, and I'm still not sure if the time will be right for it by next version.

How about adding this to the pack: https://nyaa.si/view/1518521

It contains bug fixes and emulation tweaks for the PC-98 games. More info: https://warosu.org/jp/thread/39459091

>>8
This is a neat project, and I'd certainly be interested in improving the PC-98 content in the megapack. However, the two obviously have fairly different goals, so it's not like I would just plop the whole thing in and call it a day. Could you explain more about the choice of emulators, how they're set up, and why/when one is better than the other or NPII-fmgen?

>>6
>That last one is going to continue to be controversial, and I'm still not sure if the time will be right for it by next version.
Using thcrap for all Windows games should be fine now. Also, I'd suggest to add ISO files, THRotator and the Soku rewired pack. It includes QoL mods wich can be easily toggled.
https://soku.delthas.fr/

>>10
>ISO files
Could you elaborate on that?
>the Soku rewired pack
This definitely feels out of scope. From the beginning, I didn't include what I suppose is the predecessor it, the pack from the Soku Wiki that came with Sokuroll, a macro recorder, and such. The megapack does currently contain Sokuroll, because basically everyone uses it and thus it's basically essential for netplay, but the other features are much more niche.
Packs like this and the PC-98 Experience are great because they come with all the features you could ever want for a specific game or subset of games, but my goal for the megapack has always been to provide only the essentials for every game; I think everyone is better served when both options are available. If you think there are features in there besides Sokuroll that fit the bill, I can consider incorporating them, and either way, I'll link any specialty packs that look good in the README and in the torrent description.
>THRotator
Again, feels niche. Correct me if I'm wrong, but it's not like many people are going to need this because they're forced to play on a vertical monitor, right? And it doesn't seem to fix any major bugs.
However, thank you as always for bringing both of these to my attention.

>>11
>my goal for the megapack has always been to provide only the essentials for every game
i apologize, I didn't understand that was your goal. So yeah, Soku rewired and THRotator are definitely out of scope.
>Could you elaborate on that?
I was suggesting to replace patched games by the ISO files created from the original CD releases (you probably should add game updates if you choose to do that).

ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
https://touhou-project.news/news/8892/

Hey, any updates on the next release? No rush of course :)

>>14
Yes, sorry for not posting in a while, but rest assured, I haven't forgotten. As usual, I'm waiting a little while to see if there are any official patches released, and to give time for any other suggestions that the new game might inspire. Plus, I have been a little busy with other responsibilities recently, though that's no excuse for slacking off.
At this point, it should be safe to move forward with everything on the to-do list, so I'll get to work over the next few days and will at least post an update if I'm not finished within the next week.
Thank you for checking in!

>>15
No stress at all! Life and personal wellbeing is most important :) definitely excited for the next release, whenever you'll get the chance to have it all done

Updates now that I've started:
- There's a little more work than I expected translating and typesetting character profile images from the Gouyoku Ibun website.
- I personally don't play the fighting games, so I need to do a little digging on the current state of 15.5 netplay.
- The homepage for NP2fmgen ( http://nenecchi.kirara.st/ ) isn't up at the moment, and has been spotty for the last half year or so, although the maintainer seems to still occasionally post on X, so I'm not sure what the deal is there. I think I'm going to leave all the PC-98 emulation stuff as "good enough", especially since the PC-98 Experience pack maintainer never got back to me with any details on improving it. I'll link that pack in the README and torrent description, anyway.

Other than that, it's coming along fine.

Okay, the easy parts are done:
+ Added the three new games.
+ Added thprac, and a corresponding section in the README.
+ Added a section with links to other packs in the README.
- Removed all redundant hardpatches. This means all except for 1-5 (obviously); 7.5, 10.5, 12.3, and 13.5, which aren't (fully) supported by thcrap; and 9, for which thcrap and Adonis can't be used simultaneously.
= Fixed any possible score/config cruft in all the PC-98 games.
= Updated the README to reflect all changes to the pack and to included software.

Things yet to be done:
- I still can't get a clear answer about how people play 15.5 nowadays.
- Some material for 17.5 still needs a TLC.
- The character descriptions in omake.txt for 19 have still not been translated. This is a little more than I feel confident in doing on my own, so I may wait a while longer to see if they get finished on thpatch.net, as I'd really prefer not to leave them out.
- I found a patch for 19 that allows direct P2P netplay ( https://shrinemaiden.com/index.php?topic=491.0 ), so I'll test and probably add that. It's not strictly necessary now, but certainly will be in the future.

Hi, I'm the maintainer of the Touhou98 Experience pack. I've just found this board after taking a closer look at the description of the torrent on nyaa (>>8 wasn't me).

>Packs like this and the PC-98 Experience are great because they come with all the features you could ever want for a specific game or subset of games, but my goal for the megapack has always been to provide only the essentials for every game
The Experience pack does include everything I could think of (even a set of pictures with trivia, made by the guys who created the English patch), but its main point is allowing people to play the games in the same way they would play the windows-era games, that is, by simply double clicking on an exe (or a shortcut to it) without having to open the emulator and assign to it the image file for the game you want to play, nor having to change the settings every time you want to play a different game.

It works like this:
Each exe actually has the same contents, they all just call the config_swap.bat inside the \emulator\configs folder and pass their own filename (ie the game number) as argument.
The bat script grabs the config file corresponding to that game number and copies it over the emulator's settings file, then finally starts the emulator.

I think this makes the PC98 games much more accessible, not just to lazy guys who don't want to bother setting stuff up, but also to people who play the games often and prefer not to waste time if that can be avoided. Thus, I would still recommend including it in the all-in-one pack, maybe without most of the stuff contained in the Extras folder. We could call it something like "The Touhou98 Experience Lite", to differentiate it from the full version that can be downloaded separately.

(cont.)

Second post is about the choice of emulator, but I've decided to test NP2fmgen thoroughly first just in case it's better than what I remembered. I'll post the rest later.

>>19
>>20
Oh, this is great, thanks for getting in touch.
My choice to use NP2fmgen is based on one anon's recommendation and this MotK thread ( https://www.shrinemaiden.org/forum/index.php?topic=11117.0 ), which at least at one time seemed to be the cutting edge of PC-98 Touhou emulation. I'm not well-versed enough to say exactly how good it is, it's just better than Anex86 and I haven't gotten any complaints about it.
I do like the use of custom executables to simplify launching the games, and the script for changing emulators is pretty slick, too. My main concerns are the crustiness of DOSBox and whether the resolution changer and optimizer are really necessary, and in an ideal world I'd prefer to only have one emulator anyway.
In any case, I'll wait for the rest of your post for now.

Apologies for dragging this out, I'll have an opinion ready tomorrow around this hour.

Might as well get a simple trip just to avoid any confusion caused by my dynamic IP.

Alright, I've done quite a few tests, which fortunately proved to be very fruitful. Here's the full story, tl;dr at the bottom.

When I first started playing the PC98 games, DOSBox-X was my emulator of choice, mainly due to its more user friendly interface compared to Project Neko and due to its dynamic recompiler, which seemed to work more efficiently on my weak PC.
After a while, I've learnt about the DWM being a thing, and exclusive fullscreen mode being the only way to avoid it and play with lower input lag. DOSBox-X has no support for exclusive fullscreen (yet, at least), thus I've looked back at Neko Project, and between fmgen and 21/W I went with the one which seemed to be updated more frequently (and had a proper home page). The latest version didn't support exclusive fullscreen though, so I was forced to grab an older version, the latest among the ones which still supported it. In hindsight, I should have taken a second look at fmgen right there, as I've now found out it supports exclusive fullscreen even on its latest version. Also, 21/W seems to crash every time I switch to fullscreen on the newer PC I'm using now, so I can safely scrap it.

NP21fmgen seems to run quite well, although at the default speed multiplier set on the all-in-one pack (x64) it seems to hit some sort of limit even on this Ryzen 3600X, so I've had to bump it down to x54 for it to run smoothly. This brings me to the second matter: emulation speed.
As the guy on the thread you've linked mentions, MS Extra is the most crucial stress test in the whole series, especially this part with the cards all firing huge bullets at the same time: https://files.catbox.moe/ojs49d.png

The way the multiplier works is that if you set it too low, the CPU you're emulating will be too slow to run the game at full speed on the busiest parts (like MS Extra), so the framerate will drop and you'll get a high slowdown percentage at the end of the run, but if you set it too high your PC itself will be too slow (or limited somehow, as it seems by the fact my CPU usage on task manager was just 5%, with four cores out of 12 being 15% occupied and the rest idling) to run the emulator itself, and it will run slowly most of the time (which fortunately makes this issue easier to recognize), although you won't get a high slowdown percentage because the emulated machine thinks it's running at full speed at all times.
From a quick test, x56 looked like a decent compromise which allowed the section with the cards to run at almost full speed, but this multiplier is too high on weaker PCs. After trying it on a notebook with an old ULV i5 it still runs fine. It would be nice if it had a setting for running as fast as the PC will allow, and this is something DOSBox-X supposedly has (named "auto-cycles"), but it seems not to run as fast as it could by setting the cycles/ms manually. Regardless, setting it to 80000 cycles/ms (equivalent to a Pentium at 133MHz) allowed the stage to run at almost full speed on both computers, so this is what I will use in the future. It also shows how wrong I was to set the speed to that of the processor recommended by ZUN (486DX2 at 66.3MHz), which runs fine in most cases but not the heaviest ones (mainly MS Extra and MS Boss 6).

2/4

Another advantage DOSBox-X has is its fullscreen mode keeps the monitor's current resolution, allowing to upscale the image with nearest neighbor and thus maintain the game's crispiness, compared to the blurriness you get by sending the monitor a low resolution image. Setting integer scaling on the GPU settings allows this to be solved when playing on Neko Project, but I'm not expecting most people to have that enabled. Also, despite the fact DOSBox-X does not support exclusive fullscreen, I've noticed the input lag to be on par with fmgen's, probably because of its better optimization compensating for the increase provided by the DWM.

Lastly, something both emulators seem to be tied on is sound accuracy and accuracy of the sprites, for which a good test is checking the barrier behind the glass on the background of SoEW Stage 4: https://files.catbox.moe/qqbcr4.jpg
This barrier shows up as an orange square on some emulators (like older versions of Neko Project), but it's always been fine on DOSBox-X and it's fine on the latest version of fmgen.
One last reason for my preference for DOSBox-X is the large team of people working on improving it constantly. Its dynamic recompiler used to have a problem on HRtP, which made the orb float permanently in the air due to an inaccuracy in the floating point computation unit (https://user-images.githubusercontent.com/6245486/113099169-6634b780-91ae-11eb-8960-87739eb854f0.mp4) but that's been recently fixed, removing any drawbacks this emulator had.

3/4

tl;dr:
NP21/W is shit, DOSBox-X and NP21fmgen are both great and going into the next release of the full Experience pack, if I had to choose only one I would go with the former because it's more efficient on weaker computers and it's got nearest neighbor upscaling for a crispy image on fullscreen.

Stuff I'll be working on for the next version of the pack:
- Replacing NP21/W with NP21fmgen
- Allowing people to edit the emulators' settings and have them saved without them getting replaced with the default per-game settings every time they start the emulator from a game exe (this would allow tweaking the speed accordingly to the user's PC)
- Replacing th01j with the Aniversary Edition from http://rec98.nmlgc.net/blog, on which all bugs have been fixed

4/4

Interesting stuff, thanks for the in-depth explanations. I do have a couple of questions.

>From a quick test, x56 looked like a decent compromise which allowed the section with the cards to run at almost full speed, but this multiplier is too high on weaker PCs. After trying it on a notebook with an old ULV i5 it still runs fine.
What exactly does this mean? If it runs fine on the notebook, then by "weaker PCs", you mean ones even weaker than that? In any case, a sensible default setting is nice, but one size will never fit all, and I think anyone trying to squeeze perfect performance out of these games can and should be expected to tweak their own settings.

>Another advantage DOSBox-X has is its fullscreen mode keeps the monitor's current resolution, allowing to upscale the image with nearest neighbor
I tried this out, and yes, that's true. So then, what exactly is the purpose of SetRes? You say in the help file:
>Dosbox-x is unfortunately incapable of changing the screen resolution when going fullscreen so this needs to be done by hand.
But why would you need to do that at all? If you set the system resolution to 640x480 and then send it to a display that's physically 1920x1080, aren't we right back to the blurry-by-default problem, same as with Neko Project?

>Allowing people to edit the emulators' settings and have them saved
What exactly would this entail? Because with that feature and the custom executables, I'd be convinced to use those and DOSBox in this pack.

As a general update for everyone, everything else on the to-do list is done. I'm now only waiting on a translation of 19's omake.txt (not for too much longer) and, possibly, to change the PC-98 emulation portion of the pack.

>>27
>What exactly does this mean?
That's my mistake, I wrote about it being fine but decided to give it another try first and noticed it was not fine at all, so I changed the phrase before that one, but forgot to change the rest.
x56 does not run fine at all on the notebook, meanwhile the setting that made the game run fine on the desktop PC on dosbox-x still runs mostly fine on the notebook (which, to be accurate, is an acceptably-powered surface pro 5 with an i5-7300U).
Do keep in mind we're considering MS Extra specifically, though, which is the absolute heaviest these games can get. Most games will still run fine even if the core speed hasn't been set perfectly.

>In any case, a sensible default setting is nice, but one size will never fit all
Yeah, I agree with this. Some people will still have to tweak the speed to fit their needs, but at least dosbox-x makes it more likely to find a sweet spot that will run well.

>what exactly is the purpose of SetRes?
Its purpose has now been surpassed. It used to allow forcing 480p on the monitor more quickly by just creating a shortcut, instead of changing the resolution by hand on the Windows monitor settings panel every time, and playing at 480p makes dosbox-x lighter to run because of skipping the scaling engine, but from recent testing I've noticed it barely slows down the emulation at all, nowadays, and if needed people can set Output>OpenGL (instead of Output>OpenGL Nearest) which results in a near-zero slowdown. That's something I plan to add to the readme.
Thus, the focus has shifted into using the scaler instead of avoiding it.

(cont.)

>[editable settings] What exactly would this entail?
I could use an opinion here. I've thought of two ways to implement it:

1. (per-game configs)
- There's a full config file for each game in a separate configs folder (like currently)
- Each file contains a comment on the first line, telling what game it's for
- Whenever a game is started, the first line on the current config in the emulator's folder is checked, to check what game was that config for
- If it's the same as the chosen game, nothing is done to it and the emulator is started
- If it's a different game, it gets copied into the configs folder, overwriting the config for that game, then the config for the chosen game is copied into the emulator's folder (like currently done) and the emulator is run

2. (universal config)
- There's a config file for each game in a separate configs folder, but it only contains the absolutely essential settings needed to run them (e.g. GDC at 2.5MHz for PoDD and 5MHz for the others, names of the hdd files)
- Whenever a game is started, the settings from the config of the game chosen are copied over to the config file in the emulator's folder, overwriting the corresponding old settings
- The config file in the emulator's folder contains all the settings (including the settings from the latest run game), and is for the most part common to all games

I'm leaning more towards the second type, since, although the games might have slightly different requirements, I believe most people would prefer not to have to set their emulation speed four more times once they've found a sweet spot.
By the way, something I've forgot to say, which is a minor con for dosbox-x, is the need to save the settings manually after changing them, by going to "Main>Configuration tool>Save...>Save". Otherwise the config file will remain unchanged and the emulator will reload the previous settings at restart. This will need to be stated and highlighted on the readme.

>>30
Yeah, the second makes sense.

If I were to use this system in the megapack, I'd make it look like this:
- The names of the shortcut executables and the .hdi files would match the ones currently used.
- I would include only one emulator (DOSBox), maybe both 32- and 64-bit versions.
- Rather than including original JP text files, which can be copied out from the games themselves using DiskExplorer, I'd grab whatever parts are translated on the wiki and place them in a story_e folder, same as for the Windows games.
Firstly, from a technical standpoint, does this sound good? Secondly, as far as credit goes, separate from linking your pack in the README and torrent description, would it be okay to indicate that this system is essentially your work, merely tweaked a bit for the purposes of the megapack?

>>31
>The names of the shortcut executables and the .hdi files would match the ones currently used.
So you mean like "(TH01) Touhou Reiiden ~ The Highly Responsive to Prayers.exe"? That can be done but we would need to remove the parentheses and probably the dash too. The batchfile language is very primitive and glitches out when given those as input, unless a very elaborate method for sanitizing inputs is implemented (which I've done before so maybe I could implement it here too, actually).
>I would include only one emulator (DOSBox), maybe both 32- and 64-bit versions.
That's fine. I really wish I could know the performance difference betwee the two, because if minimal then we could just keep the 32-bit version. Maybe I'll run some tests later.
>Rather than including original JP text files, which can be copied out from the games themselves using DiskExplorer, I'd grab whatever parts are translated on the wiki and place them in a story_e folder, same as for the Windows games.
That sounds great.
>as far as credit goes, separate from linking your pack in the README and torrent description, would it be okay to indicate that this system is essentially your work, merely tweaked a bit for the purposes of the megapack?
Sure. I'm not using any nicknames on the readme since I don't really care about credit (I put myself as "some anon from /jp/" there), but what I do care about is for people to know where to find me (as the bottom of the readme says, "Gameplay threads at /jp/") so they can give me feedback to keep improving the pack. My only goal is getting as many people as possible to play these games.

An alternative solution for the game's names would be having each game's exe files in a separate folder with the full name of the game, just like the windows-era games, with the exe and hdi files contained in each, with the thXX/thXXe naming (again, like the windows-era games).
The folder structure would look like this: https://files.catbox.moe/x9xcap.png
This would also make it a bit easier to upgrade from the current version of the Experience pack, by moving the hdi files over without having to rename them.

In theory, the game-specific configs could also be moved to the games' individual folders, but since they depend on the type of emulator that's being run, they're probably best left inside the "emulator" folder.
I'm not completely sure about moving the hdi files either, if someone changes the folder names of the games the setting telling the emulator where to find the hdi would break, so the "disks" folder might be best left alone.

>>32
>we would need to remove the parentheses and probably the dash too
Actually, I tested that beforehand to make sure, and (at least on my machine) it just works. Using Kaikidan, I changed
- the name of the executable to (TH05) Touhou Kaikidan ~ Mystic Square.exe
- line 1262 of th05.conf to imgmount d "..\disks\(TH05) Touhou Kaikidan ~ Mystic Square.hdi"
- the disk file, likewise, to (TH05) Touhou Kaikidan ~ Mystic Square.hdi
Booted right up, no complaints. I don't see any particular reason why this wouldn't work on older versions of Windows (10 Enterprise LTSC, 21H2), but then again I'm no expert.

More importantly, you make a good point about the alternative folder structure. That actually makes perfect sense - put th##.exe and story_e in fully-named folders, to be consistent with the Windows games, then put the disk files in a separate single location to make them easier to use with DiskExplorer or other emulators.

>>34
You're right, looks like I was slightly misremembering how the exe files work. They don't call the config_swap script and pass their own filename to it (in which case, and following your example, they would pass "(TH05) Touhou Kaikidan ~ Mystic Square" and break the script), instead each exe has its thXX label prewritten on it, and passes that to the script after calling it. I did that precisely to avoid the exe files from breaking if renamed. This also means the config files don't need to be renamed, and in fact if they were renamed they would also break the script.

So yeah, the only real change needed is for the exe files to call "..\emulator\configs\config_swap.bat" instead of ".\emulator\configs\config_swap.bat"

>>35
The executables have to be recompiled to target a different location, right? Would it instead be possible to, say, put that string in a config file so that people could move/rename the emulator folder? You could even have the default location hardcoded, then make the program generate a config file containing it if no such file already exists, just like how the Windows games handle th##.cfg.

And the second option from >>30 couldn't be done with a batch file, so wouldn't you have to move that functionality into the C program as well? Sounds like not too much work, but certainly not trivial.

>>36
>The executables have to be recompiled to target a different location, right?
Yep.
>Would it instead be possible to, say, put that string in a config file so that people could move/rename the emulator folder?
That'd be easy. I'll also need to implement an error message in case the targeted config_swap file is not found, but it's no big deal.
>You could even have the default location hardcoded, then make the program generate a config file containing it if no such file already exists, just like how the Windows games handle th##.cfg.
That's a little less easy but it can be done.

>And the second option from >>30 couldn't be done with a batch file, so wouldn't you have to move that functionality into the C program as well?
I was actually planning on having the config_swap script take care of that. It doesn't make much difference in the case of programs contained in the all-in-one pack, which is trustworthy, but when it comes to the Experience pack I tried to have exe files that were as simple as possible and leave the heavy work to the bat scripts, which are in plain text and can be verified easily by people who don't want their stuff to be deleted by a malicious program. I've even included the source code of the exe files in the Extras folder so that particularly untrusting people could check those too.

I should be able to take care of the above in a couple days more or less.

>>37
>I've even included the source code of the exe files in the Extras folder
So you have, neat.
If you're already going to try to read from a config file, surely that's the hard part, since working with text files in C isn't very pleasant. But you'll need to have a failure case for the file not existing anyway, so it shouldn't be much extra complexity to handle that case by trying to open the file in write instead of read mode, writing the default location to it, then proceeding as if that location had been read.
I'm extremely curious to see how you can copy lines from one file and use them to overwrite specific lines in another with a batch script, I had no idea such a thing was possible. Then again, I have never tried to do more that the bare minimum with Windows scripting, I would always just jump ship to Python for anything more complex.

>it shouldn't be much extra complexity to handle that case by trying to open the file in write instead of read mode
Yeah, you're right. I haven't used C for a long while so I couldn't remember for sure if it would be as simple as that.
>I'm extremely curious to see how you can copy lines from one file and use them to overwrite specific lines in another with a batch script, I had no idea such a thing was possible
It certainly is, although it does imply rewriting the whole config file each time, while checking every line to find out if it needs to be copied over as it is or replaced with a line from the game-specific config.

Although very rudimental, batchfile is a language which allows you to do anything you want with files. I've got a lot of experience with it from developing this program for the 4cc, which has been used for years to prepare the modded files containing the teams' custom player models to use on PES:
https://github.com/the4chancup/4cc-aet-compiler
In the Engines folder you'll find plenty of decently advanced modules, like for example bins_update and teamid_get. This tool started out very simple so batchfile was the best language for it, but now it's become a castle made of sticks and stones, and although it's quite solid it's not apealing to some prospective contributors who would much prefer to use python, so I'm planning on rewriting it from scratch.

>>39
Forgot the quote >>38

I've managed to make some decent progress (after fighting with code::blocks not wanting to accept MinGW on this new windows install).
The new exe files are ready, with cfg checking, reading the path from it if it exists, creating it if it doesn't, and checking of the location of the config_swap bat, plus a message box asking the user to set the proper path if it was not found.
Here's a preliminary version of how the pack would end up looking: https://files.catbox.moe/ih1pk3.7z
The config files still need adjusting to the new version of dosbox-x so the games will run a bit slowly on this, it's just meant for showcasing the new exe files and the structure.
Next up is preparing the per-game configs and adjusting the bat script. I should manage to get it done by sunday.
After that, I'm planning on posting it on the gameplay thread, to have a few people test it before it goes live both as a standalone and as part of the all-in-one pack.

By the way, if any of the txt files from the games are missing a translation on the touhou wiki, I recommend trying chatgpt for that. Translation is definitely its strongest suit.

Also, here's the source code for the exe files in case you want to take a look.
https://files.catbox.moe/rwt2mw.7z

>>41
Nice, looking good. Whenever you're ready to post the full pre-release version, send me an email with the link, and we can work out any last details as well.

Funnily enough, there is just one text file that I'd like to include that's untranslated, the おまけ.TXT for 3. (Anything else untranslated is fine to leave out, either redundant information or technical stuff not related to the story.) I might take a crack at doing it myself, since I've been having to do quite a bit of editing on the translated versions anyway.

In practice, it probably wouldn't often be an issue, but I don't like the fragility of the config file system, especially since you're sometimes prompting users to edit it manually. Rather than just blindly reading from the start of the file, you could make it a bit more robust with something like:

do {

    fscanf_s(fptr, " %127[^\n]", bat_path);

} while(bat_path[0] != "#");

on line 25 of bat_naming.h. (Not tested, by the way, just pulled out of my ass.) Maybe note somewhere that the path can only be up to 127 characters, as well.
Of course, I understand that trying to pin down every error case - especially on user input - is a huge headache, and that these particular programs should only be expected to work well enough.

Email sent.

After taking a closer look at these translations of the text documents from the PC-98 games, I realize that some of them are actually terrible. I would not be satisfied with simply including them in that state, and would much prefer to give them a thorough editing or even try to translate them from scratch, not just for this pack but for the benefit of anyone using the wiki.
However, that's a lot of work. I think I'd like to push that off to version 6, and for now just get version 5 out the door, since its been long enough already and all the other changes are basically done.

After waiting a few days to make sure no one ran into any problems, I have finally uploaded the final version of the v2.00 PC98 pack.
https://boards.4channel.org/jp/thread/45114072#p45189200

To turn it into the "Lite" version you just need to delete the "extras" folder, and adapt the readme file however you see fit.