I red the guide and you said:
Once finished go through the normal translation process including the "Prepare Project for Batch Translation" and "Fix Cells and Check for Errors" buttons. (I have the sugoi server running but there is nothing there too..)
but I tried 4 times and it's stuck there, also... it uses SLR right? or does it use an AI to translate? I'm kinda new to all AI stuff
I red the guide and you said:
Once finished go through the normal translation process including the "Prepare Project for Batch Translation" and "Fix Cells and Check for Errors" buttons. (I have the sugoi server running but there is nothing there too..)
You sent me all information except the actually important bits lol.
SEP is meant to be used on a folder with PNG files in them.
How does your folder look like, how does the log processing them look like?
In your screenshot is not a single object, so it doesn't look like it actually processed anything.
That means you did not press the fix cells and check for errors button before exporting.
But also means something else went wrong because technically there should be a failsafe to remove the context IDs regardless...
That means you did not press the fix cells and check for errors button before exporting.
But also means something else went wrong because technically there should be a failsafe to remove the context IDs regardless...
Comparing with MTool is difficult because the tools do not have the same purpose.
MTooL is a one-click MTL tool to just quickly generate a partial translation.
SLR is meant to create high quality translation patches meant to be shared with other people.
But to try to list differences anyway:
MTool
SLR
Can translate in seconds
Even on good hardware a translation can take a long time
Translations are pretty idiot proof, it just works. (Most of the time)
SLR expects you to actually read and follow instructions and adjust things manually, not to just press the translate button, and skipping all pre and post processing. While it is much more user friendly than all options I had 3 years ago, if your goal is just a quick fap without brain function, this is not a tool for you
Because it's using injectors it allows changing of font and font size on the fly
Font changes need to happen outside of the tool according to the used engine
Automatic word wrapping
Word wrapping values need to be adjusted depending on the game, but wraps more logical
Has a built in cheats
Does not grab data that could be used for cheating
Tiny size
Extracts to 5GB, if you use DSLR and SEP can easily grow to 60GB
Needs Internet Connection
Fully Offline unless you use an external provider
Runs on pretty much any hardware
Needs a lot of ram, and if you are using advanced features like DSLR and SEP you need substantial hardware or it will take an insane amount of time
If something isn't translated afterwards you're out of luck.
Can translate absolutely everything including picture based text, but doesn't necessarily tell you where the text is and what formatting a certain custom plugin needs, expects you to decrypt/encrypt certain files yourself
Has a file size limit for free users and limits to certain translators
Does not have any limits on file size, you can use whatever translator you want
Follows Chinese laws (You know if that's something you have to care about or not.)
Does not follow Chinese laws
TLDR: If you are looking for MTool, stick to MTool. Because this is not MTool.
TLDR; "SolvedTM" 2 problems, the starting bracket getting duplicated or appearing when it shouldn't by deleting the "bracketsatfront" and "bracketsatback" logic, since the \" logic seems to work fine without it, and OpenRouter LLMs seem to require an additional header in the request for it to work with reasoning. The reasoning response is still not in the message, so TranslatorSLR will still show an error of "no reasoning model found in the response," because it's actually in it's own header. I did not touch that, because I don't know if it's necessary for the software to parse the reasoning commentaries.
Find the modifications in the attachment.
I though the 「 problem of appearing at the start was localized only on the LLMs I was using (qwen3-30b-a3b-abliterated-erotic-i1_0 Q3_XXS/Q6_M, then also tested Sugoi-32B-Ultra-GGUF Q4_K_M), but then I tried out deepseek-chat-v3.1:free from OpenRouter and found the same problem, so it must be the software.
Here's some different examples of original text and their deepseek v3.1 (w/o reasoning because of something I talk about later):
I checked the input and output of the LLM, just to verify it wasn't something rare, and it seemed fine.
Instead of 「」, it had \" which are fine.
However, later in the code section where the \" are replaced with the actual original marks, they get duplicated.
After a bit of clumpsy debugging, I believe the code about "bracketsatfront" and "bracketsatback" around line 1930 from addons/SLRtrans/TranslationEngine/DSLREngine.js are the culprit.
My guess of why it only happens to the bracket on the front and not at the back is because of order. Since the bracket at the start would result in 「\" and at the end would be \"」, it appears that the back case gets the \" erased by the latter checks and the front case replaced by a second 「 instead.
My suggestion is to avoid the bracket front and end alltogheter and depend on the \" put by the LLM. I haven't done much testing yet, but I would assume it should work better, since LLMs may move the bracket term around. I tried it with the examples provide, and even though it results in different text (because I'm translating only those lines) the problem seems solved by commenting those two conditions.
The problem is if this gets in conflict with another kind of brackets, like the ones for the whole sentance. Those might get wrong, but even then, as seen at the second example I've shown, the LLM may move the whole bracket line, so there's no easy way of making sure the LLM is doing it right.
Second point, reasoning from local LLMs worked fine, but both DSLR Sugoi and OpenRouter Deepseek prompted an error about reasoning not being found. From Sugoi I thought it was normal, as far I know, it doesn't have any reasoning, but Deepseek does, so what gives?
I checked the LLM response and did not have any reasoning, checked OpenRouter's
You must be registered to see the links
, and found that they require an additional line in the request. To solve this, just modify around lines 1025 and 1607 on DSLREngine.js:
Now the LLM response includes a "reasoning" section apart from the "message", which SLRTranslator fails to parse since it's not within the message (this is my guess on how does it with the other LLMs) and, thus shows the same error of "Not reasoning model found", but should be okey, I guess.
TLDR; "SolvedTM" 2 problems, the starting bracket getting duplicated or appearing when it shouldn't by deleting the "bracketsatfront" and "bracketsatback" logic, since the \" logic seems to work fine without it, and OpenRouter LLMs seem to require an additional header in the request for it to work with reasoning. The reasoning response is still not in the message, so TranslatorSLR will still show an error of "no reasoning model found in the response," because it's actually in it's own header. I did not touch that, because I don't know if it's necessary for the software to parse the reasoning commentaries.
Find the modifications in the attachment.
I though the 「 problem of appearing at the start was localized only on the LLMs I was using (qwen3-30b-a3b-abliterated-erotic-i1_0 Q3_XXS/Q6_M, then also tested Sugoi-32B-Ultra-GGUF Q4_K_M), but then I tried out deepseek-chat-v3.1:free from OpenRouter and found the same problem, so it must be the software.
Here's some different examples of original text and their deepseek v3.1 (w/o reasoning because of something I talk about later):
I checked the input and output of the LLM, just to verify it wasn't something rare, and it seemed fine.
Instead of 「」, it had \" which are fine.
However, later in the code section where the \" are replaced with the actual original marks, they get duplicated.
After a bit of clumpsy debugging, I believe the code about "bracketsatfront" and "bracketsatback" around line 1930 from addons/SLRtrans/TranslationEngine/DSLREngine.js are the culprit.
My guess of why it only happens to the bracket on the front and not at the back is because of order. Since the bracket at the start would result in 「\" and at the end would be \"」, it appears that the back case gets the \" erased by the latter checks and the front case replaced by a second 「 instead.
My suggestion is to avoid the bracket front and end alltogheter and depend on the \" put by the LLM. I haven't done much testing yet, but I would assume it should work better, since LLMs may move the bracket term around. I tried it with the examples provide, and even though it results in different text (because I'm translating only those lines) the problem seems solved by commenting those two conditions.
The problem is if this gets in conflict with another kind of brackets, like the ones for the whole sentance. Those might get wrong, but even then, as seen at the second example I've shown, the LLM may move the whole bracket line, so there's no easy way of making sure the LLM is doing it right.
Second point, reasoning from local LLMs worked fine, but both DSLR Sugoi and OpenRouter Deepseek prompted an error about reasoning not being found. From Sugoi I thought it was normal, as far I know, it doesn't have any reasoning, but Deepseek does, so what gives?
I checked the LLM response and did not have any reasoning, checked OpenRouter's
You must be registered to see the links
, and found that they require an additional line in the request. To solve this, just modify around lines 1025 and 1607 on DSLREngine.js:
Now the LLM response includes a "reasoning" section apart from the "message", which SLRTranslator fails to parse since it's not within the message (this is my guess on how does it with the other LLMs) and, thus shows the same error of "Not reasoning model found", but should be okey, I guess.
What game are you testing on? I would much rather fix it not escaping the brackets properly, than remove the system. That just sounds like some niche problem in one of my regex patterns.
DeepSeek V3 is not a reasoning model, using the enable reasoning stuff "normally" changes to The R1 branch. Not necessarily a bad model, but slower and much more expensive. I wouldn't recommend using it.
The thing telling you that no reasoning was found likely means that the way that particular model communicates does not require the cleanup step and you can just turn it off in the options menu.
As long as the reasoning text doesn't actually show up in the translation, everything is fine.
Edit: I guess I should change the description of enable reasoning.
The thing that probably doesn't come across is that I view reasoning as a bad thing.
Because it eats tokens and obviously you do not want reasoning in your translation, you just want the translation.
All that option does is try to find a reasoning block in the translation and get rid of it, so that you can use a reasoning model as if it isn't one.
Edit2: I should probably remove the notice when it doesn't find something, have it enabled by default, and rename it so it's clear what it does. So you can disable it in case you have a special case in which it removes something it shouldn't, but you generally do not need to worry about it.
What game are you testing on? I would much rather fix it not escaping the brackets properly, than remove the system. That just sounds like some niche problem in one of my regex patterns.
Find the .trans file attached for the non-reasoning version. You can find the game at Ryuu's place for Games by searching the RJ code on their search function.
DeepSeek V3 is not a reasoning model, using the enable reasoning stuff "normally" changes to The R1 branch. Not necessarily a bad model, but slower and much more expensive. I wouldn't recommend using it.
The thing telling you that no reasoning was found likely means that the way that particular model communicates does not require the cleanup step and you can just turn it off in the options menu.
As long as the reasoning text doesn't actually show up in the translation, everything is fine.
"DeepSeek-V3.1 is a large hybrid reasoning model," a noob's trap.
It doesn't matter how long I try to understand these things, they always seem alien to me. I thought reasoning would be better than without, but it seems that there are cases were they aren't.
EDIT: And sorry, the actual error is "[DSLR] Unable to detect anything." which is what you guessed.
I prefer anime-sharing with no bias whatsoever. *cough*.
I'll look into the bracket issue. That code turned out pretty messy so I'm not super surprised if it screws up.
When it comes to smaller LLMs reasoning models are generally better, because they are much more likely to follow complex orders, and tokens don't really matter if you host yourself.
But when it comes to large commercial ones like DeepSeekV3, that follow complex stuff without issues, the reasoning is more of an annoyance, because it doubles the cost of using the model and since the thing you are looking for is a translation, and not a novel about why something could be a translation, the reasoning text doesn't really do anything.
Find the .trans file attached for the non-reasoning version. You can find the game at Ryuu's place for Games by searching the RJ code on their search function.
My bad then. I made me a fool falling for the
You must be registered to see the links
"DeepSeek-V3.1 is a large hybrid reasoning model," a noob's trap.
It doesn't matter how long I try to understand these things, they always seem alien to me. I thought reasoning would be better than without, but it seems that there are cases were they aren't.
EDIT: And sorry, the actual error is "[DSLR] Unable to detect anything." which is what you guessed.
I've investigated it more now and the issue seems to also be DeepSeekV3.1.
If I use deepseek-chat-v3-0324 on Map03 cell 575, the result is exactly as expected. If I use DeepSeekV3.1 it no longer correctly isolates Silver Harp and just has one floating bracket. I need to run more tests, but for now it doesn't seem like switching to 3.1 is a good idea.
The double bracket stuff on Map03 cell 576 is regardless of model, that one is actually DSLR screwing up, I'll fix that next update.
Edit: Curse the English language and its stupid ' shortening.
The reason it's screwing up is because the thing inside the brackets translates to "I'll remove the barrier if you bring me a harp."
Which means the script that also handles things in ' ', detects the ' in "I'll" as another quotation to be considered.
Edit: Curse the English language and its stupid ' shortening.
The reason it's screwing up is because the thing inside the brackets translates to "I'll remove the barrier if you bring me a harp."
Which means the script that also handles things in ' ', detects the ' in "I'll" as another quotation to be considered.
I don't know where, but for what I've seen in the code, the brackets are replaced by \' before sending to the LLM and then rewritten by searching \'. Unless it's actually scaping the apostrophe and searching that, then maybe it should be \\\' instead, I guess. If it's that, then another reason to hate special characters.
I don't know where, but for what I've seen in the code, the brackets are replaced by \' before sending to the LLM and then rewritten by searching \'. Unless it's actually scaping the apostrophe and searching that, then maybe it should be \\\' instead, I guess. If it's that, then another reason to hate special characters.
I red the guide and you said:
Once finished go through the normal translation process including the "Prepare Project for Batch Translation" and "Fix Cells and Check for Errors" buttons. (I have the sugoi server running but there is nothing there too..)
I changed SEP to now actually tell you if it found usable files or not.
That it didn't was honestly just terrible design on my part.
And this is how the project looks like when processing a file worked:
Tried to translate this game but the Tool says doesnt recognize the engine. Is called Godot engine, would you know what translate tool would work for this:
Tried to translate this game but the Tool says doesnt recognize the engine. Is called Godot engine, would you know what translate tool would work for this:
I pretty much only know stuff about RPG Maker and I want to keep this project focused, so it doesn't end up like T++. (Advertises support for 500 things, but none of it actually works properly.)
But I know that cactuar worked with Godot Engine before, maybe ask them.
