*oh i confused the thread..
Sorry, I'll repost it here.
Please understand that English is not my native language.
[Multiple Message Windows Ex]
https://forum.chaos-project.com/index.php/topic,11299.0.html
[Localization]
https://forum.chaos-project.com/index.php/topic,12164.0.html
Hello, this is my first time on this forum!
Originally, I was looking for a script related to localization, but after looking around, I found a very attractive script.
So, I tried to use both scripts, but when I apply both,
Localization script not working.
The Ruby language is so new to me that I don't know where to start and how to put it together.
Can anyone help me?
Can you describe in more detail what exactly is not working? Demos for the two scripts no longer exist so I don't want to go through the effort of trying to setup a project.
Something I noticed is that, if you try to use \Loc[] in your text boxes, it might be conflicting with MMW because \L is letter-by-letter mode. So use \loc[] instead.
To be more specific, it's like this
-When only localization scripts are used
-When only multi-window messages are used
Both work well without any issues.
However, for some reason, if you use two scripts at the same time,
Reserved words in localization scripts seem to be ignored.
I just realized from your answer that L and LOC can be confused, and changed the corresponding part in the localization script.
return string.gsub(/\\[Kk]\[(.+)\]/) { self.read($1) }
I changed it to and printed the message.
However, the output result was "\k[n]" and was not processed at all.
I tried running it again with only the localization script.
This time, the results were exactly what I wanted.
So I'm just guessing that maybe something in the multiwindow script is overriding the reserved words part of the localization script.
Or even if it has been processed, I think it is being overwritten again.
I had to setup a project to see this for myself. As it turns out, MMW changes the behavior of $game_temp.message_text to be an
Array rather than a
String, which ends up breaking the Localization script.
What we need to do is make an add-on for MMW by aliasing the
replace_basic_code method and call upon
Localization.localize's logic:
class Window_Message < Window_Selectable
alias f0_localize_rbc replace_basic_code
def replace_basic_code
@text.gsub!(/\\[Kk]\[(.+)\]/) { Localization.read($1) }
f0_localize_rbc
end
end
It works very well!
Thank you so much for setting up and analyzing the project!
In addition, there seems to be a phenomenon where the location of my custom message window is overwritten due to the same problem. I will try this.
Location solved!
Actually, I kept looking for related things and changed them one by one.
It was not a short time, but it was a success.
But there is one problem with using it.
When I use \a[name], the symbol "♬" appears after the reserved word.
As for me, I don't know what this means or why it appears.
This problem made a serious situation become quite cute.
If anyone knows the reason, please let me know
I'm not getting that symbol, but I am getting the character with octal value of \016 (which just renders as a missing glyph: ౝ ). That value is what substitutes the \a.
In MMW, if you take a look at
def update_text, it evaluates each character one-at-a-time.
# Get 1 text character in c (loop until unable to get text)
while ((@c = @text.slice!(/./m)) != nil)
# Plays Sounds for each Letter, Numbers and Spaces Excluded
play_sound
case eval_text(self.contents)
when 0 then return
when 1 then next
end
# Draw text
self.contents.draw_text(4 + @x, 32 * @y, 40, 32, @c)
The
eval_text method is where the backslash flags are processed. Depending on what the flag is, it can return a value of 0 or 1, which will stop it from being drawn. Because it's still drawing \016 to the window,
eval_text must not be returning anything.
Let's look at where it handles the character \016:
def eval_text(bitmap)
...
if @c == '\015' || @c == '\016'
if @c == '\015'
# ...ignore this...
elsif @c == '\016'
@text.sub!(/\[(.+?)(?:(\d+))?\]/, '')
name = $1.to_s
end
create_name_sprite(name) if name != ''
create_face_sprite(face)
end
Notice that there is no
return called here. If I simply add
return 1 right below the line
create_face_sprite(face), it no longer draws \016.
This is clearly a bug with the script.
Ah, it was a bug.
This has definitely been fixed.
However, despite all these modifications, I found one serious problem.
Using this script will drastically slow down the processing of events located on the map.
To test it, I increased the variable with a parallel processing event.
Before applying the script, it quickly increased at a steady rate and easily exceeded 1000.
However, when I applied the script, it became 1/100th the speed before (not the exact number).
It even got slower as time went on in the game, and I had to leave the game on for a few minutes to get it past 100.
Aside from the automatic and parallel processing events, the game ran quite normally. There was no frame drop or anything.
Wow, that's super weird, great work finding out about that one. Alongside a console window (https://forum.chaos-project.com/index.php/topic,7816.0.html), I made a simple parallel process event that would print out the difference in time since the event last ran (making sure to initialize the global variable prior to it):
now = Time.now
puts now - $prev
$prev = now
The times between each call increases by 0.025 seconds = 1 frame, if the game is running at 40FPS.
I had to put a lot of debug calls throughout the MMW script until I finally found what was causing it, indicated between the lines I marked below:
class Interpreter
def setup(*args)
drg128_setup(*args)
# index of window for the message
@msgindex = 0
$game_temp.message_text, $game_temp.message_proc = [],[]
#-----------------------------------------------------------------
if @list.size > 1
templist = @list.pop
@list << RPG::EventCommand.new(106,0,[1]) << templist
end
#-----------------------------------------------------------------
# whether multiple messages are displaying
@multi_message = false
end
What this is doing is, before running the event, it adds a "Wait 1 frame" event command to the end of the list. A parallel process will call this
setup every time it runs, so your event list keeps getting longer and longer, filled with Wait commands.
Obviously this was not intentional for parallel process events, so it was probably designed for the on-trigger type events. I'm not sure why it arbitrarily adds a 1 frame wait at the end to every event...
but we can make sure that it only ever does it once:
if @list.size > 1 && @list[-2].code != 106
templist = @list.pop
@list << RPG::EventCommand.new(106,0,[1]) << templist
end
Yes it works great!
Thank you so much for your help!