Navi - a message library (6/11 demo)

[coffee]

I like the way Robin's RTF library did them with commands inside {brackets}. It's a little easier to read if you ask me.

Yes, would be nicer to edit text using {...} or <...> specially with tag closure. And better if that could de defined/configured in options.

[litearc]

@Jasoco:

The 'press z' is only in the demo so you know what to press - I agree, it'd be really annoying and awkward to see that at the end of each message.

I like your idea of setting variables specific to the message class upon initialization instead of in the love.load - I guess that could keep the message class code more independent and localized. I'll add that to my todo list.

I'm not sure about changing the formatting style. I know it's not as flexible, but the main idea was to keep it as minimal as possible, i.e. use |: for a pause instead of {pause=50}. If there is a lot of push from the community to change the formatting style, I'll go with a more RTF-like style. As a side note, one thing I do plan to add is an alternate way of changing text color, i.e. currently you can only do |cff0000ff, but I will add an option like |c[red].

Finally, mymath.lua was meant to include all my own math functions, and like Roland_Yonaba mentioned, I would add more later on. I now moved everything to code.lua, which includes all general code-like functions, including math. I'm not keen on putting everything in one file since there are so many references between files, but I'll try to keep it more minimal. I plan on making an RPG with this, so there will be many different systems which will use the same functions, i.e. any menu system will use "input areas", which I am currently using for the "choices" in the message system. Input areas are defined in input.lua and should not belong in either message.lua or menu.lua.

EDIT:
@Roland_Yonaba: I'm not sure if you're confusing messages with lines of text. Each message consists of text that displayed all at once when the message is done. Right now, each message is handled independently, so the text boxes will change in height. I will add a feature to group messages together (maybe a new class?) so that messages are automatically split into smaller messages that fit inside the message box. As for scrolling text, I may add an option - I prefer new messages but scrolling text shouldn't be too difficult to implement.

@Ref: I wouldn't mess too much with the code right now, especially the code in main.lua. That's there just to show some examples of the system and I didn't care at all about how I implemented it. As mentioned, window height is auto-adjusted for the message.

[Jasoco]

Take a look at Robin's project to figure it out. I like how his lets you define the colors when the message is created and then use each one. His also lets you place images inline if you need to.

[MarekkPie]

Haven't looked at this too much, but I think you should be able to toggle between a button press skipping a message, fully completing a message, or speeding up the message writing.

If this is already in there, then ignore this post.

[Jasoco]

Yeah. I like it when the text speed just speeds up really quick instead of the text just filling in. Would be nice if there was an option.

Edit: Also, I think you should remove the reliance on a global variable called "kp" and instead have a function called "message_advance" or something that you place in love.keypressed that will check if advancement is allowed and advance it if so.

See, you're making your library have a lot of reliances on outside things and variables and tables. It should all be self contained and only require you to call a set of functions in each of the love functions like the play_messages function and the message_advance function I mentioned.

Oh, and how about a callback that can be called when the current message box is finished. And just move the math.round function into the library itself as a local function since it's small and everything should be self-contained.

[litearc]

@Jasoco: Cool, I'll add in an option to speed up instead of complete the text. So, 'kp' stores the last keypress. I'm not sure how to remove the reliance on it. I could have a message class function that stores the last keypress, but isn't that the same thing? Any ideas would be great. Also, can you clarify what you mean by the "message_advance"? I'll try to minimize the reliance on external stuff, and there are things (like math.round and certain variables) that can be put into text.lua. But there are others (like kp and certain variables that are used by other classes unrelated to message) that are bit more tricky. What do you mean by callback when the current message box is finished? There a property called "over" that gets set to true when the message is over. Using message:init() resets this as well as other variables so that the message can be played again.

Also, just a little update. I added a function that splits the message into several messages, each with up to a certain number of lines, and then resizes the window width and height (see pics below). Essentially, an RPG-style message box. The 1st pic is a normal message where you do not specify the # of lines. The 2nd and 3rd are pics of a message box that holds only 4 lines, so the message gets split.

[litearc]

One more update, faces!

... okay, I really need to get to sleep.

[Roland_Yonaba]

Much Love!
Keep up the good work...!

[Jasoco]

@Jasoco: Cool, I'll add in an option to speed up instead of complete the text. So, 'kp' stores the last keypress. I'm not sure how to remove the reliance on it. I could have a message class function that stores the last keypress, but isn't that the same thing? Any ideas would be great. Also, can you clarify what you mean by the "message_advance"? I'll try to minimize the reliance on external stuff, and there are things (like math.round and certain variables) that can be put into text.lua. But there are others (like kp and certain variables that are used by other classes unrelated to message) that are bit more tricky. What do you mean by callback when the current message box is finished? There a property called "over" that gets set to true when the message is over. Using message:init() resets this as well as other variables so that the message can be played again.

Yes, it is the same thing, but it's self contained. You use the message_advance function to call the command to advance to the next message if applicable. It is called From love.keypressed. The key you use would also be contained in the initialization function. I'm sure others can explain better. But you need to make anything having to do with this library self contained in the library itself. Nothing at all should be located outside and all interactions with the library should be performed by functions called from the love functions. No globals. The library should not refer to variables that you need to define elsewhere. This is what the initialize function would be for to keep it all self contained. This also includes the math file. Just put that round function in the library as a local function. It's small enough to not matter.

If I get time I'll make some changes to the library to demonstrate what I mean, because I like the potential of this library and want it to continue.

[coffee]

because I like the potential of this library and want it to continue.

No, you are totally in LOVE/obsessed with this library. I shouldn't have talked about it to you! Too late.

litearc, weren't you transferring this to a repository?