Remove repacking support from thdat?

[nmlgc]

It simply leads too many newcomers to Touhou modding into needlessly going the static patching route, when they should be using thcrap instead to keep the intent of their modifications clear, benefit from our fixes to ZUN bugs and hot-repatching, and to later ease a potential distribution of their mods. thcrap has been pretty stable since the beginning of the year, I can't remember any bugs in the core engine lately.

Can't we just put a "You probably don't want to do this, use thcrap instead. Are you sure? [y/N]" message?

Really, what are the remaining use cases for .dat repacking? Even if you don't intend on publishing your patch ever, a local thcrap setup is a much more convenient development environment.

Someone will just fork the project and put .dat repacking back in!

Like the one 4chan did which didn't even last a month?

People will just use old thtk versions instead then

Doesn't mean we can at least disapprove of repacking going forward.

Unless I'm seeing big protests about this, I'll be removing this feature ~~at the end of the year~~ once thcrap has its own sufficiently good infrastructure in place:

• [ ] Provide decent (i.e., non-Python) tools for creating and packaging patches
• [ ] Document thcrap more clearly
• [ ] Redo file breakpoints to allow adding custom files

[DankRank]

Instead of removing it by the end of the year, how about removing it in 3 Days:tm: when thcrap is properly documented through something other than source code, and when we have guides describing how to get started making patches?

[nmlgc]

I agree, that would be more a reasonable course of action. While we do have a guide on Touhou Patch Center, that one really is in need of a rewrite to remove the emphasis on servers, together with the necessary Python scripts to get rid of that dependency.

[brliron]

Important

We need some scripts in thcrap to automagically create patches. With an UI if possible. I've explained to 2 or 3 people how to create patches, and the easiest way is "which pseudo do you want to use? What is your mail/contact page/whatever? Ok, take that zip file and extract it in the thcrap directory". Also, people are expecting far less from thcrap (and they don't read the readme), they don't think it can just load files uncompressed, and before even trying to put their files in thpatch/lang_en/th06/, they try to find the command to pack a given directory into a dat file. At least that's what I think, they're surprised when I tell them "just put that file here and run the game". Edit: and also something in the scripts to create a standalone patch.

Less important

Even without thcrap_update.dll, thcrap is still a botnet. I'm currently working on hiding some bitcoin mining code in the th155 pl parser, that's why it takes so much time. More seriously, "go make your own patch with thtk" is the best answer we can give to "thcrap is a monopoly".

[nmlgc]

Turns out we also need to make sure that thcrap runs stack file resolution for files that aren't included in the original .dat, to allow extra files to be added. This currently wouldn't work for the majority of TSA games. Added a task list to the first post.

[Lymia]

I would personally rather treat thtk as an independent tool for lower level patching, rather than part of or strongly related to thcrap itself. I do not agree with this course of action.

[mokou]

I don’t think we should get rid of the .dat file creation. If you want to encourage use of thpatch then we should instead add those non-python packaging tools into thtk itself and make it the default when (re)packaging.

This would also help with exporting only the changed files to the thptch repo format so we don’t end up with mods that mistakenly have all of the assets from the game duplicated in the patch when the author only changed a few files. IIRC that has happened before.

[I-Tom-I]

I disagree with this change, instead there should be the ability to easily generate patch files for the files you would have repacked in to a dat.