[SOLVED!] YANFLY MESSAGE SYSTEM - NAMEBOX ALIGNMENT ISSUE [VX ACE]

Posts

Pages: 1
Hey guys, been using the Yanfly Ace Message System which is absolutely phenomenal! However, when testing my game I've been running into a very specific issue that I'm starting to believe is a bug in the script.

In the message system, the namebox can be drawn by prefixing your message with '\n'. If you change that to a '\nr' the box will be aligned on the right of the screen, which I use often since I have character portraits alternating on both sides. I've run into an odd issue however that every time the very first instance of the message box starts with a right alignment, the namebox shifts about 20 pixels or so to the left.

This ONLY occurs upon starting a new game or loading a save file, and IF the first message box drawn happens to have a namebox prefixed with 'nr'.

It's far from a game-breaking issue and it only occurs with a rather specific condition, but since players can load up save files at any time, I can't design around it unless I start every single dialogue with a left namebox alignment. It looks rather sloppy with my custom text box, so I'd like to figure out a way to fix this if possible. I reproduced the bug on a fresh project, so I know it is coming directly from this script. Just curious if anyone else has encountered this issue and if there is any kind of known workaround? Thanks!

Here are some screenshots to illustrate what I'm talking about:


SunflowerGames
The most beautiful user on RMN!
13323

It looks like the script isn't really going into effect until something happens.
Have a look at what control switches and variables need to be hit for the script to work (or script call.)
Well there are two variables associated with Name_Window that caught my eye, but I can't seem to make any sense out of them.

NAME_WINDOW_X_BUFFER = -20     # Buffer x position of the name window.

NAME_WINDOW_PADDING = 20 # Padding added to the horizontal position.


Changing the window buffer doesn't seem to have any visible effects unless it is to a positive number, which then shifts it that many pixels to the right. Changing the window padding directly shifts the text - higher numbers move it to the left and lower move it right. However, changing either of these numbers doesn't change the fact that the first name box (if it starts with /nr) is shifted differently than the rest.

I don't really understand RGSS3 enough to know exactly what's going on behind the scenes, but I would guess it has something to do with the way the buffer or padding are being called. Here's a link to the script in question.
SunflowerGames
The most beautiful user on RMN!
13323

Is this the code your using:
(Sorry I don't really know enough about scripting to really help. I was hoping there was some sort of control switch you were using.)

# \nr<x> - Creates a name box with x string. Right side. *Note
#
# *Note: Works for message window only.
#

Could you possibly put spaces before the actor's name so it will appear in the correct place. This doesn't solve the problem, but will make it look nice.

Weird, I can't replicate the issue. I have a project with only YF's message system for a script mod I did for somebody that tested \nr and it works fine when I talk to the NPC with it first or last. Here's the project if it helps at all. If you make a demo project showing the error in action I can take a look at it.

e: The npc on the right uses \nr in my demo project.
author=kory_toombs
Could you possibly put spaces before the actor's name so it will appear in the correct place. This doesn't solve the problem, but will make it look nice.


Yeah, I'm using that /nr segment. Thank you for the suggestion! But unfortunately, since the issue only occurs on the first message that appears when you boot up the game, I would have no way of knowing whether the player just loaded up a save file and this is the first text they are seeing in this session... or if they had already been playing prior to a message (and therefore the bug wouldn't be occurring, so adding a space in that instance would tab it too far over). It's a really specific condition that sets off the bug.

author=GreatRedSpirit
Weird, I can't replicate the issue. I have a project with only YF's message system for a script mod I did for somebody that tested \nr and it works fine when I talk to the NPC with it first or last.


Thank you for taking the time to help! I took a look at your demo and it led me to discover another specific condition that I forgot to mention. I am actually modifying the font size inside of my name box so that the name text looks smaller than the rest of the text. The name text is size 20 while the regular text is size 24. So my commands that are causing the issue are actually prefixed with:
\nr<\fz[20]Name>


It seems that it's the change in font size that is likely causing the issue then, because if I take out the line about the size change, it doesn't occur any more. Maybe it sets some sort of spacing for size 20 text, and then permanently switches that spacing amount once I switch over to 24? I tossed an NPC on the far right of your scene that demonstrates the issue.

Although it's not the most ideal solution, I suppose this means that if I modify my custom text box image and use the same size text all across the board, I can avoid the issue. But that would still mean going through every single line of dialogue and removing the text size change code... ugh. It would be neat if we could solve the actual problem, but since I have a viable workaround now, don't worry about it if you don't have the time to devote to researching it any further.

Thanks for your help guys, this is certainly progress!
SunflowerGames
The most beautiful user on RMN!
13323

Perhaps the order in which you write that tag could effect it. You could also use a different script to effect font.

Also if you have made changes in scripts it helps to start a new game for the script to actually work properly. Did you test this script out in mid build?

Ahh, I see the error now. When the name window is calculating its own width it uses the width of all the text its passed. It includes the \fz code without processing it. The name window is reused across multiple uses so once the font size changes once it affects all future calculations where it gets the width of all the text passed to it. I'm going to see if I can fix it because that is bad.


e: Fixed it. The \fz code was being offset by a later calculation so the fix came down to getting the delta in the text size from the old to the new font size. In the script around line 630 there should be:
when 'FZ'
      contents.font.size = obtain_escape_param(text)

Change it to

when 'FZ'
      old_width = text_size(text).width
      contents.font.size = obtain_escape_param(text)
      new_width = text_size(text).width
      dw += new_width - old_width
Demo project here, changing the demo you sent back.
Wow, that amazes me how you were able to just pick up on that error like that! Thank you so much! That fixed the issue entirely.
Pages: 1