Zill O'll infinite plus english translation

[Tom]

Well, the translation HAS started in that I've finished a portion of file msgsec137, but no files have been completed yet. (They're pretty big, for the most part, and I tend to start with the biggest files to get them out of the way first.)

Here's an appropriate line from the game I'd translated earlier about "just getting started."

ORI_0019|アイリーンは剣の筋はいいし、#0A#しっかりした娘だ。ただ、まだ若いしな。#0A#ま、これからってところだ。#0A#お前さんもそうだぜ。今のうちに#0A#いろんな物を目に焼き付けて、そして、#0A#いろんなことを、自分で考えてみな。
NEW_0019|Irene's good with a sword.#0A#She's got her act together... But she's still young.#0A#Hmph, I suppose that means she's just getting started.#0A#Same could be said of you, I guess.#0A#Use this opportunity to burn everything you see into your memory.#0A#And do try to think for yourself as much as you can.

TM Zero's nearly ready for beta testing. Once that's over, I'll be able to focus on this project. I really love the Zill O'll world, and "Infinite Plus" certainly deserves a good translation. I promise to do it justice. The amount of text in the game is nothing to sneeze at, and the amount of branches in the story certainly is staggering, but I'll do it.

[Tom]

This needs some cleaning up, but it's a start:

https://twitter.com/RetroTranslator/status/848130056496963584

[Mugi]

looks like i have some text centering to do lol.

looking good, i cant really put to words how happy i am to finally see text on the game that isn't "OMG TESTING" for once.
i'll give it that though, the emulator makes it look awful

[Tom]

Yeah, moving the text to the left would be good, at least for this window.

For the story-text, it'd also be nice if you could expand the "speech windows." Even though the screen was widened for the PSP, the text windows still look like they're conforming to the standard TV screen size in the center; it's as if they carried them directly over from the PS2 version. If you could expand the width of the dialogue windows to spread out wider instead of just the center of the screen, the English version (which takes up quite a bit more space) will look a lot better.

Of course, it might be a pain if you (or anyone else) ever want to adapt the script to make a PS2 or PS1 version. (I don't care about the PS2 version, personally, but I'd really like to see a PS1 hack one day, and I'd definitely be willing to do the work needed to carry the script over to the PS1 original, should any hacker want to take on the project.)

[Mugi]

i can look into it but that might or might not be within the reaml of reasonable work load at all,
i noticed while doing rnadom playing and testing things that some text boxes have proprietary sizes and the ones that do not have a portrait on them are more narrow than the ones that do, incidentally making the text area of both cases the same size. along with that, there are some that are only two lines high or specifically made narrow to not cover up something from the game itself.
It's yet unconfirmed but based on what i saw so far, it appears that the text boxes themselves are sized on a case by case basis and propably lie somewhere deep within the event scripting which i have not reversed at all, in fact i dont even know where it is as of this moment.

regardless of if i look into it and find it and reverse engineer it, if the boxes themselves are indeed sized case by case, resizing them will be lots of fun for all the 70000 lines of dialogue
while i do agree that having them be a little bigger to properly hold the new text would be nice, there's propably more sensible solutions on how to approach that, such as either resizing the font which is very easy now that i took full control of the font parser, or simply using the linebreak jump to force text into a new box with a keypress.

i will look into it if it becomes too big of an issue to be left ignored.

meanwhile we are still looking into the gender variable, and i will embed the changes you requested to the executable regarding the starting scenario text strings in the character creation, along with the alignment fix of the text window in your screenshot.

[Tom]

I don't know if a smaller font is a good idea, especially on a portable screen that's already quite small. The windows are semi-transparent, so I think they already don't cover much up... Even if they are lengthened, it shouldn't be a factor... At any rate, if expanding them is not feasible, then I suppose leaving the font size as-is and just making the text jump back to the top of the window with a button press isn't that bad.

I can make that work.

[Mugi]

im not sure a smaller font is a good idea either, i originally remade the font to 8px tahoma, which is what i use in a lot of things but it seemed a bit small so i remade it as 9px tahoma instead (the font we are currently using.) Personally i dont have issues using a smaller one, but i can see that a lot of people propably would as it really is quite tiny.

either way, i will examine the possibilities we have.

on a side note, we dug into the text renderer with binaryfail and to our fortune the renderer itself contains a set of functions similar to the variable that are used to call the player's name, but are currently serving no use, and we are at work on harnessing these unused commands to create the gender variable function you requested. as for now it appears to be going on nicely, but i'll let you know more once we get to the point of actually testing it.

edit: requested changes to start scenario are done, i'll hook you up with it once i pack up some additional stuff i need to update on the current copy you have.

[mikeprado30]

That's another one getting my attention 

Good luck guys!

[Mugi]

we're hitting some lovely issues regarding the text parsing tool (hooray for incomplete testing) which will most likely cause some majore rewrites on how the mechanism the text is dumped and recompiled.
...we'll see how much that slows things down.

I emergency fixed files for Tom to proceed on his quest of figuring out how in the hell the scripts are laid out and translating them but that doesnt really fix the underlying issue that causes a number of script files to completely fail on recompile.

im really starting to think that it would have just been easier to ditch the mess of a text renderer the game has and rewrite it instead of trying to parse together a tool to dump and recompile according to it's obscure behavior #progrmmerproblems

it's getting along though, despite all the issues we've encountered during the last 48 hours, Tom's pushing forward like a machine... The hype is real people ! (it's still in super super early stages so dont wave your flags just yet. )

[Tom]

I think I'll wait for the recompiled script before continuing to work on it. Once I have the full script with the missing lines incorporated, I'll continue with the translation.

[Mugi]

I think I'll wait for the recompiled script before continuing to work on it. Once I have the full script with the missing lines incorporated, I'll continue with the translation.

that'd be the best course of action at this moment. We rewrote the tool and made an initial version that dumps all the missing text now just to see how much was actually missing, and it's quite a bit actually.

We still need to figure out a nice way to lay it out and code a rebuild feature, but aside that it's now more or less getting there.
if you wish to see an example, one can be found here: https://pastebin.com/zUCEFTtA (this was just a test to get the full text out, ignore file formatting.)

this is a piece of msgsec014 with all it's missing content included.

as i explained to you on the PM, practically the issue was that the line end code (0x050505) does not actually end the entire text string in all cases. and the following lines of dialogue are followed by the code.
If you compare it to the initial dump you have you can see that all lines were dumped, but they were only dumped up to the point where it reaches the first termination code.

[Tom]

I see how it goes.

I'll use this opportunity to focus on some of my other projects.

[Mugi]

im hoping to have this solved by the weekend or during the weekend at the latest so it's not earth shattering, but it will cause us to rewrtie the already made files to accomondate the new file format.
it's really unfortunate but things happen. Im sure we'll survive

Edit: well, we are back on track more or less. New version of scriptdumper is now done and along with it, some previously unknown syntaxes were also embedded (text color codes now work !)
script rebuild mode exists but it's still unstable and under construction, but atleast the correctly dumped scripts can now be processed again.



the he/she gender variable for the protagonist will be the next thing on the list after the script recompile works.

i willl be supplying tom with new set of text dumps as soon as i finetune a few little things and from that point on our fight towards a 100% translation patch continues

[Tom]

Yeah, I got everything working with the new scripts and insertion... Thank you, Mugi... (I especially thank you for your technical support.)

Just a bit more copy and pasting from the old files to go...

https://twitter.com/RetroTranslator/status/850449925296988161

It's looking good so far. I just wish that the emulator didn't glitch out and stop showing any graphics sometimes, when enemies are on the screen. I hear the hardware doesn't have this problem... But as my PSP screen is broken (and I can only play it on a TV), it's a hassle to play it that way.

Perhaps there's some alternate setting in the emulator that will let it run more stably. We'll see.

I still have a few other projects vying for my attention, but progress is steady on all fronts.

[Mugi]

i updated my ppsspp to version 1.4 just yesterday and tinkered with the settings a little.

here's what i do know about issues in zill o'll.

1) the game randomly blackscreens when the "little bat" enemy is encountered on the field. I have so far never had this issue with any other monster in the game, but i hardly encountered all of them.
this issue only exists on the emulator.

2) the screen has an insane amount of tiny graphical errors when running on buffered rendering mode (the glow on the bottom and right of the screen is an indication of this. which causes further distortion of anything on the screen, not really noticeable unless you do side by side compares)

3) the graphical issues and the weird glow from the screen side can be taken off and most of the graphical glithces can be fixed by using vulcan as a rendering backend (the glow goes away on unbuffered rendereing with any backend though.) However, using unbuffered rendering with zill causes save/load menu to blink and be invisble. So it's a tradeoff.

what I personally do is use option 3 which makes the game look as it should and function correctly (so far atleast) and just keep only one save file. They save and load just fine if you know what to press, you just cant see a thing. Or simpy change the rendering mode when i load game and then change it back (the annoying part is that vulcan doenst support buffered rendering and changing it causes ppsspp to restart. so saving loading with vulcan is always lottery time )

[Tom]

I don't know how to use vulcan as a rendering backend.

[Mugi]

I don't know how to use vulcan as a rendering backend.

below the rendering backend there is the rendering mode which has 4 options.

practically the first 2 are what you want to use, skip buffer effects (unbuffered) or buffered.
as i said, buffered rendering makes the save/load menu work normally, but causes all kinds of graphics issues othervise. (with vulkan you're stuck with unbuffered because it doesnt support any other option yet)

[Bonesy]

tbh i'd get into contact with the devs maybe and see if they can fix it? there are people such as myself that can't use Vulkan and don't have a working psp (mine needs a memcard)

[Mugi]

tbh i'd get into contact with the devs maybe and see if they can fix it? there are people such as myself that can't use Vulkan and don't have a working psp (mine needs a memcard)

I suppose.

The problem with this is that I simply don't care enough about the emulator to spend my time with it. I use it on occasion to test simple things since it's a tad faster than copying an iso into the psp everytime I do changes, but generally speaking, I dont like emulators, I never have, and I never will. My mentality on hacking games revolves around the idea that it either works on the real thing or it doesn't, If it doesn't, I'll redo it until it does.

That's how I play my games too, and while I dont care about the emulator, I know a lot of people do, it's just not my job to get their things done.

As for vulcan, the game does work without vulcan too, I used to run it with openGL until earlier yesterday, and the performance is more or less the same, sans the fact that for some reason there is some very minor scaling happening on the screen (running it at 1x scaling and native res.) resulting in things like the pixel-perfect font I made looking.... well, less good than they should look. (this was a dealbreaker for me since practically all the testing I did on the emulator was text and graphics positioning related so pixel perfect output was a must.)

Im not particularly sure about the whole deal with the blackscreen glitch the game has though. This bug did not exist when I started working on zill o'll, and at the time I was running some REALLY old version of ppsspp (0.9.x something I guess.) It was after I updated it to a more recent version (above 1.0.0) it started doing that, and now that I tested I noticed that using vulcan still makes the character and the enemies momentarily blink but I never managed to make the game blackscreen.

I didn't test it with opneGL or D3D yet, chances are it was unrelated to the rendering backend, but who knows.

[Tom]

You may not care about the emulator personally, but if the emulator's glitch got fixed, it would be much easier for me to make progress with translating/editing/revising the script... And I know that's something that you want, so it might be in your best interest as well to take an active role in solving the glitch.