Language Patching?

[Acrylic]

Not sure if this is possible or not, but couldn't you open up the kMS wz files in a hex editor and change all the korean to english text? O.o...

[jessiebelle]

that sounds like it could end up being borderline packet editing . . .

[Valarius]

that sounds like it could end up being borderline packet editing . . .

...

I'm not sure you understand what packet editing is, then.

@ OP: I'm sure the idea on paper sounds feasable, but you must understand that values are checked clientside and serverside. I don't think a language patch will be possible now, or in the near future.

[HiiEN]

Not saying I know anything about data extraction however, I believe if this was possible it probably would have been discovered and leaked long ago. If this is a true possibility (which I doubt), then for one, you'd probably be only able to see it on your own computer.

[Fiel]

This is not possible with the current knowledge of the WZ files. If it were possible with the current knowledge of the WZ files, it would require extensive modification to those files and, even then, not all text would translate (like buttons and all NPC text).

[Acrylic]

This is not possible with the current knowledge of the WZ files. If it were possible with the current knowledge of the WZ files, it would require extensive modification to those files and, even then, not all text would translate (like buttons and all NPC text).

Well assuming each "bit" of the korean is a seperate hex, you could easily replace it with English and then fill the rest with spaces. I realize that the UI (that uses images) wouldn't be translated, but I assume that most of the NPC text (ones controlled by the client) would be editable.

[Fiel]

Well assuming each "bit" of the korean is a seperate hex, you could easily replace it with English and then fill the rest with spaces. I realize that the UI (that uses images) wouldn't be translated, but I assume that most of the NPC text (ones controlled by the client) would be editable.

No. Each piece of text you read in GMS is written in ASCII which is one byte wide. Each character written in KMS is written in UTF-8 which is two bytes wide. See the problem?

[Acrylic]

No. Each piece of text you read in GMS is written in ASCII which is one byte wide. Each character written in KMS is written in UTF-8 which is two bytes wide. See the problem?

Couldn't you write the text in UTF-8 so that it would work in kMS?

[Fiel]

No, because the principle part of UTF-8 is that each character is only as wide as it needs to be.

[Clysse]

Fiel with all due respect, you can code a UTF - 8 in roman characters..

so its entirely possible

[Fiel]

Of course you can, but Acrylic asked about a language pack, which means a full translation from one language to another. You could, if you wanted to, switch the string to be ASCII instead of unicode and then work within the limitation of bytes that you have, but that would be a large limitation. It would be much better to have no such limitation, but that would require a repacker. The reason why I said that it was "not possible with our current knowledge" was because there were still unknown bytes in the WZ files at the time of writing. Not knowing these bytes made a repacker impossible. Now that these bytes are known (at least by me), this is no longer an issue and a full language pack can be created without character limitations.

The image that Acrylic posted in reference to this topic did not use a repacker. He worked within the limitation of the unicode bytes given to him.