Hime-Works / Requests

Bug reports and requests that may require longer discussions and is not suitable to leave on the blog
http://himeworks.com/
GNU General Public License v2.0
7 stars 9 forks source link

Choice Options Linebreak/ Next Line Text #140

Open Arsist opened 10 years ago

Arsist commented 10 years ago

In your http://himeworks.wordpress.com/2013/03/06/choice-options/ the option text_choice(choice_num, text) allows you to bypass the default text limit and write text for choices, which I found to be very useful, especially combined with Large Choices. Questing/Group Managing with choices, etc, and a relation/reaction system is done much easier this way.

However, you cannot linebreak manually nor does the text go to the next line when the text extends further than the maximum width of the screen or when you press enter.

So I am curious to see how you feel on the ability to linebreak manually with say Enter or \LB or \n or whatnot.

I'm not for sure if that means that choices would be divided into windows or what that means, visually, but if so then Galv's http://galvs-scripts.com/2012/11/26/visual-novel-choices/ is an example of choices being divided, although they can't linebreak or have the functions that yours have.

HimeWorks commented 10 years ago

There would still need to be a way to tell the engine how many lines there are going to be in your choice.

This could either be done automatically (engine uses some algorithm to calculate how many lines you need), or manually.

None of the existing windows support variable line heights The main issue is the selection cursor. However, if you were to tell the window exactly how many lines each option needs, that might be possible.

Having multiple windows would make it easier, since then you just need to tell each window how many lines it should use for each option. However, that is specifically only if you want to use that kind of UI.

Arsist commented 10 years ago

I don't mind, I'm just curious if this is okay to you. It doesn't quite matter to me how the window is handled, as long as it has the function of multiple lines. Hahah.

HimeWorks commented 10 years ago

Having multiple windows and having a single window does have visual consequences. RM does not have support for making two separate windows look like a single window by somehow moving them close together.

Arsist commented 10 years ago

But for that Galv example I gave, you specify the text distance and they (appear at least?) to be different windows, or at least are separate groups of text divided by a given space. So couldn't the next window choice start such and such pixels after the bottom of the window of the previous choice? I must think of a good example! Hahah. And the all-one-window thing doesn't seem too important to keep.

HimeWorks commented 10 years ago

The default selection cursor is a rectangle whose height is determined by the height of the item, which is by default one line.

Galv's script uses a custom cursor which is just a picture. However, each choice is a static picture as well, so you can't have multiple lines and expect the picture to automatically adjust.

Arsist commented 10 years ago

Are you saying that the multi-line script cannot be done, even if it wasn't all one window and if the user were to manually input the size so that the game didn't have to determine it on its own? I'm sure I've seen text boxes whos size is determined by the width and height are determined by the text. Yay, I found it! http://www.rpgmakervxace.net/topic/6664-lune-message-system/ I'm thinking the start of the next choice box would be below the bottom of the previous, and it wouldn't matter if choices are different heights and widths; that'd just add a unique style to the game. Or it could just take the width of the widest choice box.

HimeWorks commented 10 years ago

Wouldn't that just look inconsistent?

Arsist commented 10 years ago

Wouldn't matter to me :) It could just be a personal option but other people could be interested as well.

Arsist commented 10 years ago

Yeah, like, if you think it would look that weird, then what may be done is that the width of the box takes on the (default?) width of the screen and the height feature uses something like what the one of that example I gave you does, then the next box starts below. Or whichever.