[VXA] ATS: Message Options 1.0.7

I think its this thread I want out of all the other threads dealing with this ATS.

I MAY have found an issue....

Its merging the text into one, instead of into separate

The first attachment show my text and the second one shows the in game where the text is being merged into the same message box when they should be separate message boxes.

am I doing something wrong....or....

If the two messages used different settings, then the messages would be separate. However, as the message settings have not changed (faces, area displayed, etc), the script determines that they are the same and merges them. This is a feature.

You can disable this option globally within the script by locating the 'append_text' option and setting it to false. Or, you can set the option to false on the fly by using 'ats_next(:append_text, false)' (disabling append_text only for the next message window) or 'ats_all(:append_text, false)' (disabling append_text until it is re-enabled).

Well in this case I would have to do it for the next window due to the fact that just setting it to false disables it for those messages that have line breaks.

Then there is a problem:

1) if I use the script call and set it, globally for all messages as false then - text that scrolls or line breaks are NOT appended when they should be.
2) my windows for one character is above him while for the player moves to above the player (position is different)


also using ats_next(:append_text, true) on text that either scrolls or has line breaks does not work either. it wont append the text to the original message

Actually, my assumption that the script determined similarities between messages might be incorrect. Glancing at the script, only the name of the face graphic might be used.

Is there any way that you might be able to create a quick project that displays what you are talking about? I am having a difficult time grasping your situation. I have never really encountered an issue with this script before.

The way it currently works is that, as Exhydra indicated, it checks all the default properties of the messages: face, background, and position, and if they are all identical, then it will append the text.

Anyway, I am a little unclear as to what you are asking me. It sounds like you want to keep the :append_text for most messages, but there are some occasions when you don't. As far as I can see, unless there is some meaningful property whereby I could automatically tell which occasions are which, then the only way that can be done is manually. However, if there is some other property that you think the script should account for automatically, then I am willing to hear you out.

To do it manually, Exhydra is correct; you can either turn off the :append_text feature for all messages if you don't want it ever, or, alternately, you can turn it off by ats_next before the messages for which you don't want it.

It sounds like you are saying there is a problem with ats_next(:append_text, true), but in my tests I am unable to produce any error. What I suspect you are doing is putting ats_next(:append_text, true) between every message, which would break it since then the messages are no longer adjacent. If you are using ats_next(:append_text, true), then you only need to place that code before the initial message, not every message you want appended to it. In other words, it would be:

@>Script: ats_next(:append_text, true)
@>Show Text: blablabla1
@>Show Text: blablabla2
@>Show Text: blablabla3

and not:

@>Script: ats_next(:append_text, true)
@>Show Text: blablabla1
@>Script: ats_next(:append_text, true)
@>Show Text: blablabla2
@>Script: ats_next(:append_text, true)
@>Show Text: blablabla3

However, you would only ever need to use that code at all if your default is that :append_text is false.

Additionally, another way you could separate messages manually without modifying the :append_text feature is to keep :append_text set to true and simply insert a blank comment between any text commands you want separated.

the second way with the blank comment worked. thanks

Can this script change the position of the face box and mirror the face?

No. That will be coming in a separate script.

Hey modern algebra, this is an amazing script! Thank you for sharing your hard work with the RM community. So, I may have found a bug with :fit_window_to_message. When used in a script call before a message that also sets another feature of ATS (any feature, such as :letter_se, or with :message_name), the problem is a visible empty window that interrupts the messages.  Edit: This happens using \nb{Name} as a message code too.

Spoiler for:

@>Script: ats_all(:fit_window_to_message, true)
                    :ats_next(:message_name, "Rick")
@>Show Text: Texty-text
@>Script: ats_next(:message_name, "Priest")
@>Show Text: Texty-text
@>Script: ats_next(:message_name, "Natalie")
@>Show Text: Texty-text

And here is an image of a similar code and event command that causes the same issue. This is with \nb{Name}, but its effect and outcome is the same. The change to the value of :message_name creates a erroneous blank window with the next name.

Spoiler for:

Which creates this before Natalie's message, interrupting before her resized-to-fit-window-to-message appears:

Spoiler for:

At the moment, after some troubleshooting, I think it might not have to do with :message_name, or any other ATS value being changed. It might have to do with the control characters. Because if I use an \. (wait 1/4 second before displaying text), it appears briefly. If I change \. to \|, that blank window skips ahead to the next Show Text, parses the control command, and it interrupts for exactly one second, unexpectedly, before showing the next message. It disrupts the flow of messages. The excitement of FIT is soured!

You can test and verify this issue in your demo, and with 1.0.4. I have a tiny script that Andrew (Anaryu, of anti-lag fame) released with his unencrypted Boutalles project (here) that also can size the window and fit window to message. His message enhancements and the accompanying shortcuts, which is a modification he wrote, can correctly change window width and height dynamically with each message. Of course, this isn't compatible with any other message system, and I don't need his neat shortcuts or the Minitext. I'm referencing it, because something in there might be useful to help. I am by no means fluent in Ruby, so it's Greek to me. But, I think this is the effect that is intended with :fit_window_to_message, only your system is so much more compatible and its capabilities are exactly what a message system should include. I love your public instance variables and the configuration that they allow. I don't like to use the text codes anymore than I need to, so I love to be able to change their values, via Script calling. That customization follows in the tradition of your own work, Woratana's NMS for VX/RGSS2, and Dubealex's AMS for XP/RGSS. I heartily give you major respect for that. And major respect for releasing a demo with your system, because, on a personal note, I think it's awesomely encouraging when scripters show and display how their genius scripts run and work. With this generation of VX ACE, it's really disheartening to see that several popular scripters have opted out of helping newcomers and oldcomers alike with demonstrating their creations and their hard efforts. You're different. Thank you for your demo. (By the way, it should be updated.)

Is this solvable without rewriting several methods? I hope there's a solution somewhere I'm missing, modern algebra!

Thanks for the kind words and the detailed error report. I will investigate it tomorrow and get back to you.

I really love the ATS Message options, but i think It would be perfct if it had the option to create the speech bubbles...

Thanks for your effots, btw.

Well, it's been two months. You obviously have other priorities and I respect that. I'd like to see your ATS suite completed, but I don't think it will. As a fan of yours, it's disappointing how lacking the VXACE experience is, without your scripting.

It's still a great piece of code. Thanks for your time, anyway.

Sorry, I forgot about your request. I have updated the script to version 1.0.5 to correct that error.

It is only a minimal fix at this time. I think I need to update the paragraph formatting aspect of these scripts.

Hi modern!
Want to report a bug: When I've installed your Quest Journal script I get this error message:
"Script: 'ATS: Message Options' line 1015: NoMethodError occured.

undefined method '>=' for nil:NilClass"

If I remove Quest Journal, Message Options works just fine.

I tried inserting them into the same project and I didn't get any error. Under what circumstances does that bug occur? Would it be possible to create a new project with just those two scripts in it, recreate the error, and then send that project to me?

Well the error occured when I activated a treasure chest or talked to a npc. Anything with text except for the menu.

But it's fixed now. I inserted your Quest Script without my own quests in my project... and every thing seems to work fine now...
So I think I broke some thing when I made my own quests....

Welp, glad that's fixed now. Sorry to have bothered you with this

Anyway, thanks for your quick reply! And keep up the fantastic work!

I don't seem to be able to change the pitch of the letter SE in game. I've tried putting them in the same script box but it's not working... It actually seems to reset it all...Maybe I'm doing something wrong?

EDIT: Figured it out. It was formatted all wrong.

EDIT2: Or maybe not? Because it treats the pitch as 100 if the values are the same...

You're right. That's a bug. I updated the script to v. 1.0.7 and you can retrieve it from Pastebin. All the configuration is the same, so save your copy of that part so you don't have to repeat it.

That worked. I just replaced the whole thing as the only thing I changed was the text SE.

For some reason the faces are scrolling up with the first part of the text. Aren't they supposed to stay still?

No, that feature will be coming when I write the ATS: Face Options script and give the face more independence. Until then, the face will not scroll with the text.

No, it's scrolling when it shouldn't be.

What do you mean? Can you recreate the error in a demo and show me?

For some reason the text won't even append at all unless I have Message Options.

And forgive me for my choice of text to test with.

Sorry, I was unclear. I meant that what is happening in the demo is what is supposed to happen. "The face doesn't scroll with the text," as in when the text scrolls down, the face does not come with it.

The reason that is not part of the script is because the ATS: Face Options script is planned, and the work necessary to make the face stationary would substantially need to be repeated. I'm sorry that it has taken so long to release that script, but the alternative was to wait to release this script until ATS: Face Options was ready, in which case neither script would have yet been released.

As for "the text won't append at all unless I have Message Options," that's not true. The text is appending, it's just that the scrolling feature is part of the Message Options script, not the Formatting script. The primary purpose of Formatting is to automatically format the text so that you don't have to pay attention to individual line lengths. However, since your text boxes are already perfectly manually formatted, you don't notice any difference; none of the text from subsequent messages is added to the initial message since those words don't fit.

If your message had been formatted like this:

@>Text: 'People1', 3, Normal, Bottom
 :        :Snow is a block
 :        :that is found near Ice Plains and Taiga biomes. Snow can be
 :        :removed
 :        :like any other block.
@>Text: 'People1', 3, Normal, Bottom
 :        :Placing a
 :        :light source will cause snow around it

Then you would have noticed the appending.

Anyway, I hadn't realized that this was being posted in the ATS: Formatting topic. Since scrolling is a feature of Message Options, I am going to move this discussion into that topic.