thpatch / thcrap-tsa Goto Github PK

With base_tsa in the patch stack, the position of hints with Align : center is distorted.

This is what it should look like (without thcrap or with thcrap but remove base_tsa from the path stack):

After base_tsa:

The game version is v1.00a.

Hint file used

Version = 0.0

Stage : 1

Tips
Text    :"+"
Pos        : 0, 200
Count    : 0
Base    : start
Align    : center
Time    : 5000
Alpha    : 255
Color    : 81, 184, 135
Scale    : 1.0
End

Tips
Text    :"+"
Pos        : 0, 200
Count    : 0
Base    : start
Align    : left
Time    : 5000
Alpha    : 255
Color    : 81, 184, 135
Scale    : 1.0
End

Tips
Text    :"+"
Pos        : 0, 200
Count    : 0
Base    : start
Align    : right
Time    : 5000
Alpha    : 255
Color    : 81, 184, 135
Scale    : 1.0
End

StageEnd

Stage : 1

Tips
Text    :"-------------------You want sjf-------------------"
Pos        : -25, 124
Count    : 0
Base    : start
Align    : center
Time    : 5000
Alpha    : 255
Color    : 81, 184, 135
Scale    : 1.0
End

StageEnd

Stage : 1

Tips
Text    :"---------------LYX is watching you----------------"
Pos        : -25, 142
Count    : 0
Base    : start
Align    : center
Time    : 5000
Alpha    : 255
Color    : 255, 156, 47
Scale    : 1.0
End

StageEnd

Reported by /u/spaztron64 in this thread on /r/touhou.

Ideally, we also want to easily trigger bad or custom endings through simple and obvious gameplay decisions on Stage 1. This likely requires more ECL and binary hacks than simply changing if(stage == 6) to if(stage == 1) as we've been doing.

Alternatively, bad/custom/good endings could be chosen in a separate Windows dialog window during gameplay, like the one for #8.

Oh, and TH09. Good luck finding a hack that doesn't hang on a white screen after the staff roll.

Done:

• TH06
• TH07
• TH08
• TH09
• TH10
• Uwabami Breakers (?)
• TH11
• TH12
• TH12.8
• TH13
• TH14
• TH15
• TH16
• TH17
• TH18

This line (plus three subsequent lines) isn't being replaced by the en translation. All previous lines in this scenario are fine.

TH17.5 version: 1.04 Steam

real_bullet_size is outdated, and does not support EoSD and games after HSiFS.

EoSD:
THCrap has since added full support for EoSD. And resized EoSD bullets already exist

VD:
Violet Detector mostly reuses existing shot types from previous games. The only one that needs looking into is Dream Sumireko's zener cards.

WBaWC:
I believe Yachie's "Tortoise Sign" bullets are new. There's also Mayumi and Keiki's haniwas,

I don't know what I'm looking at! It'd be nice if this project had a readme describing what this is and how to use it, thanks!

A simple cheat feature such as "unlimited lives and bombs" for the shooters would be very useful to have.

Among other reasons, I personally need it to record videos of the game stories (since I do not possess the necessary play skills).

"Just use skip mode then". I would, but skip mode de-syncs the dialogue from the backgrounds, which add to the aethetics of the story mode.

"What about cheat engine?" It is counterproductive to have yet another process running in the background. Also, cheat engine has a steep learning curve and is not very intuitive to use. Besides, all the Touhou code tables are fragmented all over different web forums and need some deep digging to discover.

me when I accidentally start the game twice and then the next time it runs in full screen and resizes all my windows:

(I dont know if this is a problem with the base patches or the patcher, or user error)
Replacing character portraits causes some inconsistent behaviour in the touhou 18 trial.
Replacing reimu's base image causes this to happen:

Replacing reimu's face images doesn't seem to have any effect.
Replacing marisa's base image has a similar effect to reimu:

and face images don't seem to work either.
Sakuya's base image works fine:

and replacing her face images works, but they are offset to the left. (Didn't get a screenshot)
Sanae has a mixture:

I've had no issues editing any other images.

script_latin causes hint files to not display properly. First image is unpatched (also works with base_tsa alone) and second is running script_latin and base_tsa. Both are on vpatch.

hint file used

The game will store the last position of it's window in it's .cfg file and pass it as the X and Y parameters for CreateWindowExA. The problem is that the game won't do things like check if that position is within any monitor plugged in.

I last opened th185 with the game window on my second monitor. I no longer have it but the game will still try to place it's window in the space that monitor used to occupy. Because of that, the game is outside the boundaries of the monitor I still have, and therefore invisible and impossible to select

All this patch does is to change the parameter of all calls to DwmEnableComposition() from 0 to 1. This is exactly the sort of thing that can quickly be implemented using thcrap's function detour API and then automatically work for every build of every existing and possibly future Touhou game.

This needs a plug-in system (thpatch/thcrap#48) because Aero support should stay an optional feature. Apparently, there are problems with certain graphics drivers that lead to crashes when Aero is not disabled, which is probably why ZUN chose to do it in the first place.

Marking as minor though, since current versions of Windows don't have Aero anymore.

The one remaining problem is that some character names will always appear greyed out. To understand why this happens, and how one might fix it, we need to understand how the whole system works to begin with:

When the game loads the character names from world.txt, it will add whitespace characters before and after the name. The game will also create text strings made up only of whitespace that are the same length as the character names (including the whitespace).

The game will call draw_ctext and, and use a format string of %s%s%s. The game calls draw_ctext 3 times with parameters as pictured in this graphic. Note that "Real character name" includes the whitespace, in all graphics

Every row in this crudely drawn graphic represents a set of parameters for a draw_ctext call, every column represents an indivdual parameter for the draw_ctext call in question. Every call to draw_ctext will draw to a different surface (ANM VM), with all the surfaces being overlayed ontop of eachother. The reason ZUN does this is because ZUN's text rendering code doesn't allow using different colors with only one draw_?text call

The exact same code is also reused for the 2 character names right below, except this time the calls look like this:

And for the tutorial stage, the same code is used once again, but with these parameters:

The problem mentioned at the start of this issue occurs because thcrap will replace both the real character names and the whitespace with a new string, causing a grey character name to overlay the yellow one. To solve this, thcrap would need to replace whitespace strings with strings that use the layout engine to create the exact right amount of whitespace for the translation string, or that entire code would have to be completely rewritten.

This works in the full version, here's a replay to prove it. Mainly important because deathbombing not working also breaks the auto-bomb cheat patch under this circumstance.

If you decide to fix this, make sure that it doesn't actually break replays. If it does, we'll have to put this into the cheat patch instead of base_tsa.

With thcrap enabled replays did not progress through stages so it's only plays only one stage that we select in the menu.
https://user-images.githubusercontent.com/6560567/125425157-9a255f29-5e99-43d8-b9f9-689ab29dbc69.mp4
Here's how it works on a non-patched Steam version:
https://user-images.githubusercontent.com/6560567/125425552-208606b4-1060-49e8-8e23-0821b2339376.mp4

My configs and logs:
thcrap_log.zip
config.zip

Any luck to fix desync issue in this game as well?

Meaning that the buttons for the second joypad have to be mapped by pressing the buttons on the first one. The game basically assumes both controllers to be identical, so to speak.

In DirectInput mode, Key Config works as expected – button presses are only accepted from the joypad assigned to the currently selected side (1P or 2P), and are ignored from the other joypad.

Here's a score.dat for TH08 that crashes the game on startup:

===
Exception c0000005 at 0x004A5CFF (Rxa5cff) (\th08.exe)

Registers:
EAX: 0x00000000 ECX: 0x00000005 EDX: 0x06B60DB8 EBX: 0x00000005
ESP: 0x0019FCD8 EBP: 0x0019FCE4 ESI: 0x00000001 EDI: 0x0A245EA8

Stack trace:
[09] 0x00448651 (Rx48651) (\th08.exe)
[08] 0x0045A881 (Rx5a881) (\th08.exe)
[07] 0x00459BC4 (Rx59bc4) (\th08.exe)
[06] 0x00458375 (Rx58375) (\th08.exe)
[05] 0x00441B9A (Rx41b9a) (\th08.exe)
[04] 0x004A631F (Rxa631f) (\th08.exe)
[03] 0x74FC8654 (Rx18654) (\KERNEL32.DLL)
[02] 0x77234B17 (Rx64b17) (\ntdll.dll)
[01] 0x77234AE7 (Rx64ae7) (\ntdll.dll)
===

Other games might be affected by similar ZUN bugs.

We probably can't restore those in case of a corruption, but it would be nice to print a more specific error, with the option of creating a new score file, rather than just crashing and forcing players to debug the issue themselves.

Bonus points for actually preventing the root cause.

This seems to be a normal install, but the font in these dialogs is too wide. (Shouldn't it be that Cirno font or something?) Problem is the same regardless of JP or US locale, or the use of thpatch or vpatch.

This game guards its character unlocks in some weird way, so that you don't actually unlock most of them by simply starting a new game from Stage 9 and viewing the ending. See ae8f89b for my previous failed attempts at fixing this.

Pretty much a very minor, needlessly perfectionist issue, since unlocking everything with Skipgame does work nicely, and translators will be using that patch anyway, or are already running on some fully unlocked score.dat.

This ZUN bug is fixed from TH08 onwards. Would be nice to backport this fix to TH07 and TH06.

The resolution of th06->th10 is small (640x480), so the game's window is too small in windowed mode.
This plugin would change the window's size to the size of the screen without the taskbar. Eventually, it could force windowed mode even if the game is set to fullscreen, and have a setting to use windowed fullscreen.

Require thpatch/thcrap#48

This can happen if the game opens the cfg file with dwCreationDisposition = CREATE_ALWAYS and never writes to it.

Probably that's because th18's custom.exe already supports English (for non-Japanese locale)?
But we need support for non-English-speaking users too, just like the older games.

On my system, TH09 is the only game affected by this, but there have been reports of TH11 causing the same issue on other systems. Therefore, this is not a DirectX 8 vs. DirectX 9 issue that could be solved with a converter DLL. It also happens in both DirectInput and WinMM modes.

Since Touhou Patch Center now has a Russian translation for this game, we need a font that covers at least Cyrillic in addition to Latin script. Once we have shipped thcrap's new font replacement system (thpatch/thcrap#19), we could probably just slim down Touhou Biolinum enough so that existing translations still fit and be done with it:

{
    "fontrules": {
        "* 48": "* * 14 500"
    }
}

If that doesn't look too awful, that is.

This problem comes up very regularly in the #support channel on Discord, due to common laptop resolutions like 1366×768 or similar being smaller than the recommended 1280×960 resolution.

Could be solved in a number of ways that are better than crashing:
• Still running the game in 1280×960, but downscaling the rendered image to match the maximum resolution.
• Switching down to 960×720 or even 640×480 as necessary. (This is what windowed mode does.)
• Or just simply showing a clear error message.

Fixed in v1.00c, but it really should be fixed for the trial version as well.

As a workaround, the game does properly recognize these replay files if you put them in both the game directory and %APPDATA%\ShanghaiAlice\th13tr\replay.

An idea we just discussed for displaying the translator's notes from the wiki directly to the game.

[21:37:26] Splashman: mm, idea: y'know those notes we have in the translation boxes?
we could try to display them in-game as an optional "translator's notes" feature, like in anime subs.
because nobody playing the game would know what "Thorium" is, except chemists and people who paid attention in chemistry class.
[21:43:46] Nameless: Yup, that's definitely doable.
[21:46:44] Nameless: And has no further dependencies on any other feature.
[21:47:34] Splashman: great. only then we'll have to introduce public and private notes.
[21:47:55] Splashman: public: for the player
private: in-progress translation notes
[21:50:47] Nameless: With all the existing ones being made private, yes.
[21:53:58] Nameless: The solution I'm thinking about basically boils down to extending the layout syntax, so that you have

<n$This is an explanatory text at the end of any translation unit that tells the player what the characters were actually talking about>

and then we have a Direct3D overlay that renders the text on top of the existing scene.
[21:54:45] Splashman: mm, only the placement and formatting needs to be determined for each game. I'm thinking either on top of the screen or below the dialogue boxes
[21:55:32] Nameless: Which has the advantage that we don't have to add any game-specific hacks, and can do it for any piece of text in the game while still timing the note to the exact time where the actual text is rendered.
[21:56:37] Nameless: I was thinking about just having a small 2-3 line "log section" at the bottom of the screen that fades in and out when something is displayed.
[21:57:22] Nameless: Can be conditionally moved to the top of the screen in case the game just rendered a text near the bot- oh, wait, it can't.
[21:57:33] Splashman: it also doesn't need to look super-pretty, just well placed and readable
[21:58:46] Nameless: Yeah, we just take the font we already use to render text.
[21:58:57] Nameless: Maybe cutting the size in half.

Replays of TH10 and TH11 runs famously tend to desynchronize if the replay is started on Stage 4 (in TH10) and Stage 6 (in TH11).

The common workaround for this issue is to just start the replay in question from the stage before and fast-forward through it. Still, this is highly annoying to new players. Therefore, it should either be fixed or clearly marked as out of scope, depending on whether fixing ZUN bugs unrelated to translation is still something you want to do in this project. (That's what made me ragequit, after all.)

If you do: I assume that fumbling around with the ECL files might be enough to fix it. @Nutzer, could you take a look?

As said in the commit message for 8942468, some binhacks aren't implemented for the 2 playism versions (the demo and the full one) of Touhou 14. Most important ones are :

• everything related to in-game spell alignment ;
• the safe sprintf for in-game spells.

You don't hear this in the original game since the title screen BGM starts with ~1.9s of silence, but it will become a mild annoyance for BGM modders, who currently have to remember to also start their modded title screen BGM with some small (and probably undefined?) amount of silence to work around this issue.

If previous files in %APPDATA%\ShanghaiAlice\th15\autosave were created with TH15 running at a different resolution, the game doesn't recognize them and silently overwrites them on the first save.

I expected that the setting would apply to both BGM modes.

Since we already use libpng for image patching and sprite boundary dumping, this could very easily be done without requiring any game-specific code by detouring the Windows file APIs. One caveat, though:

(21:00:53) linkmauve1: Warning about that, PNG is very slow to encode.
(21:01:24) linkmauve1: If possible store the raw image data in a buffer and pass it to an encoding thread.

In EoSD, After you enter Music Room and exit, and enter Score - Spell Card History then some lines of the spell card names cannot be seen at the spell card history page.

Below are the captures I took when executed thcrap with only base_tsa applied, for test purpose.

You can see that Marisa (Love Sign) is disappeared. The same happens to Reimu.

This is the bug on base_tsa so when language patch is applied this thing happens too.

(Plus, the right half of the music comments cannot be seen if you execute EoSD with thcrap when only base_tsa applied. This thing does not happen when language patch is applied.)

This is something I noticed when watching a replay of a playthrough that happened to use the Gluttonous Centipede card. After completing a stage, the Centipede's damage multiplier would be reset to 1.000 (which is normally preserved in between stages and only reset after losing a life or bombing). This would nearly instantly cause a desync and make any replay that uses this card completely meaningless unless you instantly bomb at the start of every stage to manually reset the Centipede's multiplier.

Modders usually want to change the game in more drastic ways than translators - adding new dialogue scripts with new text boxes, modifying danmaku scripts, or even changing parameters of shot types. All of these break existing replays recorded on the unpatched game. This would require players to closely keep track of the patches used for each replay.

By allowing patches to change the replay file name format used by the game, we easily eliminate this confusion.

The straightforward solution would require location of the replay format strings, and probably a new safe sprintf hack for each game. Automatically constructing such a new pattern from the patch stack might also be worth a thought.

Completion status (the list entries for all the ZUN games will be added as I go)

• TH06: 3ba69cb e3fc307
• TH07: 3ff6580
• TH75 (Tasofro)
• TH08 31fc5b1
• TH09 b29f724 d8a7a27
• TH95
• TH10 e61ae83 abe4720
• TH105 (Tasofro)
• TH11 6c4a28e
• TH12 52a5cf4
• TH123 (Tasofro)
• TH125
• TH128
• TH13 b2f398e
• TH135 (Tasofro)
• TH14 a3b22a2 ad62b64 3755330
• TH143
• TH145 (Tasofro)
• TH15 1786a24
• TH155 (Tasofro)
• TH16 ec2aad4
• TH165 94070f9
• TH17 ec2aad4
• TH175 (Tasofro)
• TH18 965418b 8cc2567

Additional notes:

• so far I noticed that TH06 and TH07 will copy the file name into a buffer with a fixed size... of 512 bytes which is more than twice the size of a buffer with size MAX_PATH

• th125 will concatenate the path to it's appdata directory with the scorefile name into a separate buffer on the stack.

• A game being marked as (Tasofro) doesn't mean adding the replay and scorefile name stringlocs is something @brliron has to do. If anything, he might only have to help me out a little