Better in game help

[Josharias]

I want a more website style in-game help system so that players can browse through help and understand what the content in the game is all about.

• Modules should be able to easily add new content and append to existing content
• Use the new BrowserWidget
• Possibly also export as html?

[Cervator]

If we could code-fy the basic tutorial text like that and export them straight from there to a wiki or other site during builds ... that would indeed be cool :-)

Or the other way around: Keep the wiki GitHub repo as a sub-module for /doc in each module then you can update docs by simply editing the nice wiki and have the code build bundle it for display in-game. That's a longer discussion with some experimenting though - I saw that creative use of Git sub modules a little ways back and it might be more workable than subs in general. Unsure yet, need more time.

Would be nice having a way to write docs in an actual editor where you can see how it displays immediately, including images/icons. Then just render a limited pseudo-markdown/html in the browser widget. Maybe you could handle a changelog that way too, for display elsewhere ...

@MarcinSc / @msteiger - ping

[emanuele3d]

I like the idea! Certainly hypertexts made a big difference to humanity over the past 25 years, I don't see why they shouldn't do the same to Terasology. =)

What's the BrowserWidget current feature set? What can it chew on? Regarding the output to html, if the input to the browser widget is already an XML-based string, it wouldn't be too difficult to make a XSLT sheet to do the conversion.

[MarcinSc]

Just a quick update from the battlefield - I'm adding support for some basic HTML parsing (limited tags supported) into the engine - I'm not sure if that's where it belongs? @Immortius @Cervator

The HTML parser has pluggable support for additional tags (also used internally for the known tags) so that some mod specific tags could be introduced - for example crafting recipes for parser used in a JoshariasSurvival, etc.

In addition, I'm cleaning up the flow rendering to be similar to the one used in HTML (support for flow="right/left" and clear="right/left/both"), rather than supporting only one paragraph with one flow element.

I'll be also adding a debug command that will open a UI with BrowserWidget on top, TextArea with status bar on bottom, and each time you type something in the TextArea - the document will be re-parsed and displayed in the BrowserWidget above. In case of errors - the status bar will indicate that. I'm also not sure of where this would belong? @Cervator

[immortius]

Hmm, there's probably no reason any of that needs to be in engine as such. I could see that having a basic html rendering widget would be nice in the core nui widget set though. I assume you would mostly support <p> <a> <u> <i> <b> <img> <font> and maybe <ol> <ul> <li> <table> <tr> <td> <th>?

In addition, I'm cleaning up the flow rendering to be similar to the one used in HTML (support for flow="right/left" and clear="right/left/both"), rather than supporting only one paragraph with one flow element.

You mean in the browser widget? Or broader than that?

[MarcinSc]

At the moment it supports: "p", "a", "i", "b", "img" and "font" (name and color). There is a few caveats of course - "i" and "b" are supported if HTMLFontResolver (provided) provides the font in bold/italics/both flavors.

There is no underline, because the Font class in NUI does not provide information on where it should be placed, it also does not provide a baseline for the font, so at the moment rendering characters of different font within the same line looks weird.

Flow layout in the browser widget.

[Cervator]

It sounds like it / most of it would belong in a widget module of some sort that Journal and others would then depend on

Should we make a "Browser" module and move discussion/work there?

Or are there perhaps any libraries/frameworks out there that'll do most the hard part we can just implement somewhere? Maybe embedding a whole actual browser in-game would be overkill, but it worked in some places like EVE :-) Has some interesting side potential too for interacting with stuff outside the game

[MarcinSc]

I think it might be used by the engine itself, for example to display change log (after adding support for <ul>) and maybe in the future the mods might provide an "HTML" page to display some info on the mod, therefore I'd vote for keeping it in the engine. Especially that it's not that much of code (20-ish classes).

[Cervator]

UI support stuff in NUI then. Not sure where the more gameplay-y stuff starts that might go in a module :-)

[MarcinSc]

I can put the "editor" command in my Incubator then.

[immortius]

Font technically isn't part of NUI. Not that it matters much, but ideally NUI would eventually split off into its own library, with dependencies on another library providing core game asset types such as Font.

Hmm, I'll throw up an issue to add underline support into either nui or Font (or a bit of both), depending where it fits. Fonts naturally have a bottom location, and I guess underlines would be drawn at a set location relative to that. (at -1 or -2 pixels, probably). So the question is around what draws the line and where the information is.

[immortius]

HTMLFontResolver (provided) provides the font in bold/italics/both flavors.

I'll have to see what this does, but I would have thought skins would be used to provide the different fonts to use in different situations, not some other mechanism.

[immortius]

Actually, on further thought I assume you are providing a font name in the font tag, and then resolving actual font from there. Which is why you need a resolver and cannot use skins. Which makes sense.

You could consider supporting the general html class attribute as well or instead and using that to determine a family in the skin to use for rendering text, and then use italic, bold, bold-italic as modes.