ODW - Multi-Language System Plugin

[r66r]

Hi @Burtoz

Thanks for reporting the problem... and solving it at the same time.

After analysis, it seems that the GALV_MessageStylesMZ plugin is looking for the \pop code in the "Game_Interpreter.prototype.command101" function. However, at this point in the MZ engine execution, it's possible that my plugin has not yet decoded the contents of the text message box, so only ${M001.EV001.PG01.TX03} is parsed.

So, removing the \pop code from the JSON file and placing it directly before/after ${M001.EV001.PG01.TX03} is a good solution, the other one being maybe to place my plugin before the GALV one (to be tested if it has not been done).

 

[Burtoz]

the other one being maybe to place my plugin before the GALV one (to be tested if it has not been done).

I tried at first step and it not works.

 

[r66r]

I tried at first step and it not works.

Thank you for letting me know. I will look into fixing this compatibility issue in the next major release.

 

[Burtoz]

Thank you for your great work!

 

[Jacie0krece]

(Sorry for bad english, my native language is polish)
Hi, your plugin is awesome, and I had been using it in my game from the beginning!
But I have a problem involving a possible conflict with another plugin (VisuStella's Element and Status Core). The problem is that when there are 2 things to translate in the enemy's name (e.g. nature and the enemy's true name), only the first thing is translated, leaving the second in the ${RawFormat}. For now, I have thought up a workaround (Leaving only the enemy's name and letter), but I would still appreciate a fix.

 

[r66r]

Hi @Jacie0krece

Thanks for using my plugin.

As I understand it, the problem you are experiencing is more related to the way texts are decoded by my plugin. In some cases, it does not allow to process the encoded texts of the database which would contain twice the pattern ${...} like this.



I tried to find a quick solution. Unfortunately, this does not solve all the cases I have tested so far. So I will look for a better and cleaner solution in a future release. In the meantime, there are other ways to solve your problem, which will require more or less work.

Spoiler: The easy solution

In your JSON files, just create as many text codes as there are elementary enemies.

${Enemy1-FireElement} => "Enemy1-FireElement" = "Bat Fire",
${Enemy1-WaterElement} => "Enemy1-WaterElement" = "Bat Water",
${Enemy2-FireElement} => "Enemy2-FireElement" = "Rat Fire",
${Enemy2-WaterElement} => "Enemy2-WaterElement" = "Rat Water",
...

Spoiler: The nested solution

In your JSON files, you create as many text codes as there are elementary enemies as in the easy solution, but you only create the text codes of the elements once. This allows you to reuse them in other circumstances.

${FireElement} => "FireElement" = "Fire",
${WaterElement} => "WaterElement" = "Water",
${Enemy1-FireElement} => "Enemy1-FireElement" = "Bat ${FireElement}",
${Enemy1-WaterElement} => "Enemy1-WaterElement" = "Bat ${WaterElement}",
${Enemy2-FireElement} => "Enemy2-FireElement" = "Rat ${FireElement}",
${Enemy2-WaterElement} => "Enemy2-WaterElement" = "Rat ${WaterElement}",
...

Spoiler: The dynamic solution

In your JSON files, you simply create the text codes for elements and enemies, but add a variable to the decoded enemy text.

${FireElement} => "FireElement" = "Fire",
${WaterElement} => "WaterElement" = "Water",
${Enemy1} => "Enemy1" = "Bat \\V[1]",
${Enemy2} => "Enemy2" = "Rat \\V[1]",
...

In a map, you then assign the element's text code to the variable used by the decoded enemy text, in an automatic event when the map is loaded, as below.

Variable0001 = ODW.MLS.getText("${FireElement}");

This will load the decoded text of the element into the variable, which will then be automatically added to the decoded text of the enemy whenever the enemy's text code is used (message, battle log, etc.). Useful, for example, if all enemies on a map are of the same element.

Show text: ${Enemy1} displays "Bat Fire".

Let me know if that helps.

 

[Jacie0krece]

Thanks for your support!
Unfortunately, my problem is slightly more complicated, and I forgot to give context the previous time.
In my game, enemies have a "nature" that's randomized from 25 possible options. Keeping the nature randomization while also solving the problem would force me to bloat both the Database and the language files with 26 entries per enemy (25 for nature and 1 for randomizing). I think that I'll stick to my original workaround (Hiding the enemy's nature) until the problem is truly fixed.

 

[r66r]

Unfortunately, my problem is slightly more complicated, and I forgot to give context the previous time.

No problem. I'll try to find another solution that will work for you.

In my game, enemies have a "nature" that's randomized from 25 possible options. Keeping the nature randomization while also solving the problem would force me to bloat both the Database and the language files with 26 entries per enemy (25 for nature and 1 for randomizing).

Just out of curiosity, how did you register your enemies in the database? And when and how do you want to display the name+element of the enemy? Screenshots to give me an idea are welcome (by DM if you wish).

My plugin only supports the display of text codes that have been passed as parameters to the basic display methods of RPG Maker MZ (see core javascripts). The random creation of the enemy name+element must therefore be done before the text code(s) are sent for display. Hence the need to know how and when you create this random combo to find an adequate answer.

Note that my third solution that uses a variable is one that could potentially solve the problem and make it easier to manage the element randomization.

 

[Jacie0krece]

No problem. I'll try to find another solution that will work for you.


Just out of curiosity, how did you register your enemies in the database? And when and how do you want to display the name+element of the enemy? Screenshots to give me an idea are welcome (by DM if you wish).

My plugin only supports the display of text codes that have been passed as parameters to the basic display methods of RPG Maker MZ (see core javascripts). The random creation of the enemy name+element must therefore be done before the text code(s) are sent for display. Hence the need to know how and when you create this random combo to find an adequate answer.

Note that my third solution that uses a variable is one that could potentially solve the problem and make it easier to manage the element randomization.

As seen on the screenshot, this is how I did the enemies. Nothing weird, especially for this stage of the game's development.


The random combo is made by the VisuStella's plugin itself, as seen on this screenshot (The "Randomize for Enemies" field is set to "true":


And that plugin also changes the names to contain these values:


The names for the natures are set inside the plugin.


Changing the plugin order didn't change anything - with the language plugin being over element one and being below it. While I also have all of the tier 1 VisuStella plugins and VisuStella core, I have this bug reproduced on a project containing only this and VisuStella's ElementStatusCore plugins active, which you can download from my Google Drive.

 

[r66r]

Thanks a lot @Jacie0krece for the "bug" project sample. I was able to test and point out exactly where the problem was.

The good news is that the bug is apparently not an incompatibility with the VS plugin. As you can see below in the screenshots, in the case of the battle log, the decoded texts are complete (nature + name). The problem encountered is in the enemy selection list.

The bad news is that the problem is similar to a case I detected and for which I can't understand the reason of the malfunction (see this post). For some reason, the detection of the second ${} pattern does not work in some cases, but in others it does.

In this case, the display in the battle log works, because the text is processed several times. So even if on the first pass it is not decoded completely, on the second or third pass, the decoding is complete. As for the enemy selection list, the text is processed only once, so if it is not decoded completely, there is no further processing to finish the decoding, hence the incomplete processing.

So I will try to find a fix before the next main release. But it may take some time, sorry.

Spoiler

Battle start


Battle select



Battle log

 

[r66r]

Update v1.0.1 - 19.09.2022

Update v1.0.1 available, which fixes the problem in the above posts.

Thanks to @Jacie0krece and @Silva for their help.

 

[Jufry_A]

Hi r66r, can I use JSON format like this?

"008": {
        "eren01":"Take a look\\|There seems to be a secret passage"
    }

Just to make it easier to read. But, its ok if too hard to implement it.
thanks for the great plugin

 

[r66r]

Hi @Jufry_A

Unfortunately not, the JSON file must be valid, and the example you give is not. And for best compatibility, it is important to keep it that way. However, nothing prevents you from creating a 008.json file in which you put the information between {}.

And thanks for the compliment about the plugin.

 

[Burtoz]

Hi @r66r ^_^
I have another problem with GALV_MessageStylesMZ with \pop and text wrap.

If in .json file I write:
"Text001": "Hello World \nHello World",
and in Text Event:
${Text001}\pop[0]

Text wrap appears on the screen only if I insert a 'Face' in the 'Show text' menu.
Without 'face image' will appear only the text before the code \n

 

[r66r]

Hi @Burtoz

In short, the problem is the way multiline texts are stored in RPG Maker. By default in message boxes each line is stored separately. With my plugin the text is stored on one line, because the "\n" are not processed. And so, Galv's plugin considers that the text has only one line to display, and it calculates the height of the popup accordingly... which has the effect of hiding the following lines which are then correctly processed by my plugin.

So I found two ways to solve this problem.

1. Split the text into several lines to display it in the popup. But you have to move "\pop[0]" to the beginning.

Spoiler

2. Use the code below in a new JS file:

• Copy and paste the code in a new file "ODW_MultiLanguageSystemPatch.js"
• Add this plugin right after the "ODW_MultiLanguageSystem" plugin

In this case, there is no need to modify the original text in the message box. But the constraint is to always use a text of the type ${...} in this message box, otherwise it does not work anymore.

Note that this is just a quick patch, but it could probably be improved to make it compatible in all cases. Another point to know: if the @Galv's plugin is updated, this patch may not be effective anymore. Let me know again if you encounter other errors in the future.

Spoiler: PATCH CODE

//===========================================================================
// Open Digital World - Multi-Language System Plugin Patch
//===========================================================================

/*:
 * @target MZ
 * @plugindesc [v1.0.0] - Patch for Galv_MessageStylesMZ.
 * @author Open Digital World
 * @orderAfter ODW_MultiLanguageSystem
 *
 * @help
 * Patch for Galv_MessageStylesMZ.
 */

var Imported = Imported || {};
Imported.ODW_MultiLanguageSystemPatch = true;

var ODW = ODW || {};
ODW.MLSP = ODW.MLSP || {};
ODW.MLSP.pluginName = "ODW_MultiLanguageSystemPatch";
ODW.MLSP.pluginVersion = [1, 0, 0];

// Overwrite the Galv function.
Window_Message.prototype.changeWindowDimensions = function() {
    if (this.pTarget != null) {
        Galv.Mstyle.testActive = true;
        let w = 0;
        let h = 0;
        const faceoffset = $gameMessage.faceName() ? ImageManager.faceWidth + 25 : 0;
        const xO = $gameMessage.faceName() ? faceoffset : 8;
        const gameMessageTexts = $gameMessage._texts[0].split("\n");
        // Calc text width
        for (let i = 0; i < gameMessageTexts.length; i++) {
            let lineWidth = this.testWidthEx(gameMessageTexts[i]);
            if (w < lineWidth) w = lineWidth;
        };
        w = w + $gameSystem.windowPadding() * 2 + xO + Galv.Mstyle.padding[3] + Galv.Mstyle.padding[1]; // padding!
        w += this.galvExtraWidths();
        this.width = Math.min(Graphics.boxWidth,w); // can't be wider than the screen!

        // Calc minimum lines
        let minFaceHeight = 0;
        if ($gameMessage._faceName) minFaceHeight = ImageManager.faceHeight + $gameSystem.windowPadding() * 2;

        // Calc text height
        let textState = { index: 0 };
        let extraFontHeight = 0;
        const lines = gameMessageTexts

        // Dodgy way to modify text line height if the \{ \} text codes are used.
        for (let i = 0; i < lines.length; i++) {
            let up = (lines[i].match(/\\{/g) || []).length;
            let down = (lines[i].match(/\\}/g) || []).length;

            // Height
            extraFontHeight += extraFontHeight + ((up - down));
        }
        extraFontHeight *= 24;

        // Escape characters from text
        textState.text = this.convertEscapeCharacters($gameMessage.allText());


        // Build actual height from everything
        const allLineHeight = this.calcTextHeight(textState,true);
        const height = allLineHeight + $gameSystem.windowPadding() * 2 + extraFontHeight;
        const minHeight = this.fittingHeight(gameMessageTexts.length);
        this.height = Math.max(height,minHeight,minFaceHeight);
        this.height += Galv.Mstyle.padding[0] + Galv.Mstyle.padding[2];
        this.height += this.galvExtraHeights();
        this.yOffset = -Galv.Mstyle.yOffset - this.height;

        Galv.Mstyle.testActive = false;
        this.otherMStyleCommands(); // stop certain things happening when drawing the text that was used for determining size.
    } else { // if this.pTarget is null
        // normal message window
        this.yOffset = 0;
        this.width = this.windowWidth();
        this.height = this.fittingHeight(4) + Galv.Mstyle.padding[0] + Galv.Mstyle.padding[2];
        this.x = (Graphics.boxWidth - this.width) / 2;
    };
};

Spoiler: CORRECT USE

Spoiler: Won't work anymore

 

[Burtoz]

Thanks a lot @r66r !!
I'll use the quick patch.

Your work is great! ^_^

 

[Jacie0krece]

Hi, it's me again.
I wanted to future-proof my game to support more languages which don't have the same writing system (e.g. Japanese, which I am learning) by making the names of the main characters translatable instead of being hardcoded, but there's the problem: while the translatable character names work fine in the message boxes, they don't work on the battle GUI. I use VisuStella's Battle Core if that matters.

This is how the actor fields are arranged in the database:


And that's how it appears in-game:

 

[r66r]

HI @Jacie0krece

There could be several reasons why this doesn't work. So I suggest you do these checks below and tell me if any of them solve the problem.

1. ODW_MultiLanguageSystem plugin inactive: see if this plugin is active in the list of plugins (this is the only case among all my tests that leaves the ${...} displayed in the character name).
2. Displaying the console log: press F8 and see if by any chance there is a message in the console that indicates an error.
3. Missing translation: check that the text ${...} is present in any of the JSON translation files.
4. Plugin conflict: disable one by one the plugins that could have an impact on the display in the battle scene in order to identify the one that could be the cause of this problem.
5. Plugin order conflict: if a plugin causes a problem, try to place it before the ODW_MultiLanguageSystem plugin in the plugin list.

Unfortunately, apart from disabling the ODW_MultiLanguageSystem plugin, I have not been able to reproduce the problem, even with the Visustella plugins. If we can identify the source of the problem with the above steps, it will be a good thing. Depending on the plugin, I could then develop a patch... although if it's a Visustella plugin, I'm not sure I can do it since I don't have access to their source code (but I'll try anyway ).

 

[Jacie0krece]

I tested it, and it looks like Core Engine breaks something with it.

As a reference, this is how the battle menu looks if I disable your plugin (Look at the downright corner, since Minami's name is still hardcoded into the game)


And this is how it looks with only your plugin installed. It's clear that Maximilian's name is working properly, but, well, everything else isn't. (I had to downscale it slightly due to the forum's server not letting the original file, as it was "too big to process"):

This is how it looks in the menu when all plugins are active:


This is how the console looks like when I used the battle test (most screenshots are on it, but it also works in normal playtest - I didn't try it while deployed though.)

Also, I can't put your plugin above Core Engine, as your plugin must be under Options Core, which needs to be under Core Engine.

By the way, I just updated all free VisuStella plugins, hoping it would change something. It didn't, but updating plugins is rarely a bad thing.

I hope that this info will help you in fixing this error, and in meanwhile, I'll just return to the traditional way of hardcoding these names. It was mostly future-proof anyways.

 

[r66r]

Good news: I was able to reproduce the case with a new project and only the plugins below installed in their latest version.



After analysis, it turns out that the problem can come from both the VS Core plugin and the VS Battle Core plugin. It seems that VS does not use the standard Bitmap.prototype.drawText() function of RMMZ, because at no time could I detect via my plugin that this function was called to display the character name.

Probably it comes from the fix found below in the VS Core plugin documentation... and that would explain why in my first tests this morning with an older version of the VS Core plugin, the problem did not exist.

 * Status Window Name Vertical Cutoffs
 *
 * In the battle status windows, whenever actor names are displayed, the bitmap
 * used to display their name text do not extend vertically all the way,
 * causing letters like lowercase "Q" and "G" to be cut off, making them hard
 * to distinguish from one another. The Core Engine will remedy this by
 * extending the bitmap to allow enough room. Fix made by Irina.

So I'll see with VS if they can give me the details of the function they use, and so I can try to patch the problem. If not, it will remain an incompatibility that cannot be solved, sorry.

Edit: VS team contacted by email... now wait and see.