~Hakurei Shrine~ > Touhou Projects
Strawberry Bose Translation and Gameplay Changing Patch Center
<< < (2/27) > >>
Validon98:
Oh, the second part of the post was mostly just saying that even with .tarc, the .srb files haven't changed at all in terms of how they work, so I can still edit the Global.srb and reinsert it without any issues.

I have tested a little more, and I have isolated the problem with the encoding to the conversion from .srsdb to .txt and back (the extraction and reinsertion isn't the problem). If I were to use mauve's .srsdb to .csv converter, it'd probably work, the problem is that mauve only created a tool to put the .csvs back into .pak files, not a .csv to .srsdb converter. If I had something like that, I think that'd fix the problem we've been having with that, but I don't know how to convert back the other way myself. In any case, I'm not too worried about it, the only thing it affects is not being able to use symbols.

In other news, the monster.srsdb is done now, so I'm working on the chr.srsdb file. I think for Offensive Support vs. Defensive Support, I'll go with Serela's suggestions and call the first Sabotage and the second Support (Suppress makes sense too but I think Sabotage sounds better, and it makes it a little clearer as to what that means).

EDIT: So I both ran into and solved a problem which can retroactively help with something back in Devil of Decline. So, usually % signs in databases and coding in general is used to mark formatting in strings, like where to place variables, etc., so a single % sign in a string will screw up everything and throw like a million errors. Of course, the Strawberry Bose games use double-width % signs in order to get around that, and also because, well, Japanese is basically double-width everything. Buuuut double-width characters break, so I had to figure out how to insert the single-width version without everything getting super screwed up. I thought there was no way to write them in as an escape character (which is usually something like /n or something depending)... until I found out you just type %%. So that's one thing fixed.

But along with that comes another issue, mainly "doppel type is important and you kinda need to have that written a certain way to count as a certain doppel type", sooo I'm running into another problem with that since it breaks the script and all soooo I need to figure out how to change the typings so that it'll display the proper thing at the top right.



This is what I mean (notice how Saya is counted as "Hereafter Are" even with just Kasen on). Also this is my expansion file, hence why I'm level 79 and all, no I didn't do that much in my LP file offscreen, good god getting to level 40ish at where I am is an achievement, level 79 is so damn far away. :'D

EDIT 2: ...Looking at the main doppel types in the files, they are literally described as "Soldier, Archer, Magician, Priest, Other". So my favorful names WEREN'T wrong.

EDIT 3: Fixed, just needed to change the names in the chr.srsdb to English and similarly change those same names to English that were in the Global.srb (since they were probably equated to each other and it was running into an encoding problem that made the Japanese string from the chr.srsdb not equal to those in the Global.srb). Everyone's got their proper titles and the like sorted out.
Serela:
Sabotage... that works too, although it sounds slightly out of place to me (but this is mostly an opinionated thing- however, the definition is closer to damaging/vandalizing something, which is a little different). If we use a different kind of word entirely though... "Impair" did just occur to me as a really good one. I've even seen it used as a term for debuffs in a couple games before. (Not that Arcana had the most amazing translation...) Although , if you've edited Sabotage into any images or something, well, it isn't -that- important.

--- Quote from: Validon98 on June 25, 2016, 05:03:45 PM ---If I were to use mauve's .srsdb to .csv converter, it'd probably work, the problem is that mauve only created a tool to put the .csvs back into .pak files, not a .csv to .srsdb converter.
--- End quote ---
Hmm. Although mauve is entirely uninterested in the fan translation scene now, I could maybe ask about that. Since it can convert srsdb to csv, it theoretically wouldn't be that hard to make it work the other way around...

Actually, wait, this isn't even necessarily an issue after all, is it?!

Because... you have the GoS/DoD tool to unpack the .pak file back into an .srsdb, right?  :getdown:
Validon98:

--- Quote from: Serela on June 26, 2016, 12:38:01 AM ---Actually, wait, this isn't even necessarily an issue after all, is it?!

Because... you have the GoS/DoD tool to unpack the .pak file back into an .srsdb, right?  :getdown:

--- End quote ---

I can... see if it works. I'll try something really, REALLY silly and attempt to use a copy of the DoD game.pak and try to basically wildly experiment with some stuff. It's probably not going to work in the slightest, but stranger things have happened.

EDIT: Nope, nope, nooooope, doesn't work, it just combines the original file with the new file and sorta overlaps things here and there. It's... not gonna cut it.

EDIT 2: I should also mention that while this shouldn't be a big deal now, I messed around with some files for the other .tarc using games, and uh... the .srsdb converter screws some of those files up bad (as in "converts text to hexidecimal for no good reason"). By that I mean the one given to me by the Korean patch crew, mauve's works just fine on them.
Serela:
Well, if the .pak unpacker unpacks them into .srsdb files, I don't see why not :D ...unless it has some weird index thing and totally garbles up unrelated files that aren't supposed to be in there? If it tries to do that you could rename it to one of the tables that IS supposed to be in the .pak, because it's not like the file normally keeps the same info/size as it's changed mid-translation. You'd just replace a proper table instead of adding a new one~

I don't see why not!

MAN THIS WOULD BE EVEN FUNNIER THAN THE TRILINGUAL CORRESPONDENCE. If it works (or even if it doesn't) I'll -have- to mention this to mauve the next time I see him. Jerryrigging gold.
Serela:
TALKING IN EDITS IS AWKWARD VALIDON

I ALREADY POSTED A RESPONSE AND IF I JUST EDIT MY POST YOU MIGHT NEVER SEE IT

And you just edited it again. It'd be so easy to miss these, too. Well, if that's the case, it's doubly important to either find a jerryrigged solution (YOU BETCHA I'VE STILL GOT MORE IDEAS) or I'll ask mauve later if it wouldn't be much trouble to upgrade his srsdb->csv converter to work the other way around.

Two more ideas:Add a fuckton of junk space into the start of the NoR table, enough to be larger than the dod one you're starting with. (So, you'd probably use a small table for convenience.) The idea is it may only overwrite onto the junk space, which you'd delete anyway. Or you could literally just -paste the new table onto the end of the original DoD one-. Ahahahahaaaaa  :getdown:
The other is, -is- it possible to just add a completely new table into the .pak instead of replacing one? I know the korean tool says it only works if you swap out single tables at a time from an existing .pak file (or tarc, whatever) but can mauve's just totally repack a .pak from the extracted data instead of switching in- or swap in a table that isn't replacing one even though normally you wouldn't ever need to do this? Then it'd have no data to overlap the new file -with-... as far as I know, I haven't used these things. This idea is a little more assumptiony than the other. :T
Navigation
Message Index
Next page
Previous page

Go to full version