[New feature] A real console

[StefanP.MUC]

I just implemented some new console (screenshot attached). As of yet it does nothing but look fancy. For toggling it press "F11" (this button will be user defineable later, of course). When the console is active, the GUI gets invisible and vice versa (this is up for discussion - I did this for the time being because I couldn't figure out how to put it over CEGUI, this seems to be a common problem regarding to the Ogre/CEGUI forums).

One of it main features is an easy command adding: we only need to say (pseduo code)
console.addCommand("nick", *funcPointerToNickFunction);
and the command "nick" will then execute NickFunction()
If we decide to add a scripting language later, the commands should be easily extendable by scripts.

Another feature that is possible with the console: All regular Ogre LogMessages can be redirected into it (it can easily be setup as a LogListener). But this is also up for discussion.

For some reason it doesn't display the text, but this could be a conflict with the other "console" that we have currently or with the input manager (this needs a lot of cleaning anyway to make user definable buttons possible). The plan is to replace the current console completly.

[oln]

Nice work.
I think you might have forgotten to commit some files.

Might be an idea to use functors rather than, or in addition to, function pointers. Alternatively boost::function/tr1::functiion, as we already depend on boost to some degree, which is an even cleaner way to do the bindings.

[svenskmand]

Nice work stefan

[StefanP.MUC]

Ah, yes, forgot to gitify the new files (as always )... Just commited them.

Tomorow (maybe today already if I find time), I'll tweak the console a bit and try to get the text displayed properly. When his works we can switch fully over to the new console.

Yes, using something better than function pointers sounds good.

[StefanP.MUC]

OK, got the text and input working. See screenshot. Colors and positioning are up for discussion. Oh, and don't forget to fetch the material from the svn if you want to try the console out.

TODO:

• [meta] discuss layout (colors, position, size)
• [meta/code] discuss and then implement the prompt behaviour (top or bottom? line count? line width in characters?). This may not need only number changing but could need code changing.
• [code] bugfixing (none known yet, but I bet there will be )
• [code] to switch from the current terminal to the new console we should first finish GameState (oln) and do some changes to InputManager (Stefan) to get clean code from the beginning (can be considered as a part of ODFrameListener clean up)
• [code] decide and implement best way to define commands (functors?)

[svenskmand]

I would vote in favor of having a scripting language in the game, that will also make it easier to make custom scripting in game maps, and do advanced stuff, think tower defense in WarCraft 3 and the likes.

[StefanP.MUC]

The basics commands (nick, start, quit, ...) should stay fixed (->hardcoded), like it is now. After adding a scripting language it won't be a problem to extend the console to also check for scripted commands (or to let the user add custom commands).

By the way, just pushed some tweaks to the console. Later this day, I'll try to switch from the current one to the new console. When this works, we can start working on further cleaning up the FrameListener and InputManager by getting the commands (>1000 lines) converted to functors.

[StefanP.MUC]

New screenshot with the console in action. Put the console at th bottom, made it scmaller and redirected the command imput to it. The output still goes through the old TextRenderer because this would need some huge changing... (the current command handler is a >1k line function consisting of loads of nested if's...)

Oh, and by the way, forgit to mention this: The console also has a scrolling feature. You an scroll up and down through the messages with PageUp/PageDown.

What's next?
1) Firstly I can further cleanup the Inputmanager (console input is now handled by the console and not by the framelistener).
2) a history feature would be nice (shouldn't be too hard, only need to store the commands in a vector)
3) then the new command system (I vote for functors, any further input welcome)
4) then the huge >1k line processCommand function can be changed to the new command system
5) be happy (the FrameListener will then almost ONLY be doing what is it for: frame listening)

[StefanP.MUC]

point 1) and 2) done:
- the actual KeyListener function (keyPressed) is finally pretty clean.
- You can now scroll through your entred commands with up and down in the console.

[svenskmand]

Good work Stefan

[StefanP.MUC]

I did some further thinking about the commands: Maybe it's really better to implement ALL commands with Lua (I think that is what svenksmand meant). Then we don't need some hardcoded commands and some Lua scripted ones (what would require different code to execute the commands).

This also saves us the implementation of functors or use boost or something. Also, then it is fully unified.

Any counter-arguments on using Lua for everything?

[StefanP.MUC]

Brainstorming:

Should we register the console as a Ogre::LogListener? The two main pro/con arguments I can think of currently:
Pro: realtime access to the log output (easy error hunting, at least on errors that doesn't crash the whole game).
Con: console text get's heavily polluted (-> annyoing if you want to type commands and eveything is full of messages).

[oln]

The ogre log handler allows 3 different message levels, so if it's possible, we could just let the critical messages go to the console. (Or make it adjustable.)
There is some spam in the log that we could probably remove as well. There is a lot of debug output every turn printed that isn't really any interesting unless one is working with creature AI or something.

[StefanP.MUC]

Yes, this is possible. The console has inherited a messageLogged() event function that has to say where the message is displayed. I can then simply ask for a specific log level.

This will be in my next commit.

[StefanP.MUC]

Ok, pushed.

The console is a configurable loglistener now. Default behaviour is: print only critical messages. The allowed messages can be turned on by calling the setAllow*(bool) methods (* being Critical, Trivial or Normal).

[StefanP.MUC]

It's now possible to scroll the console output text with the mousewheel.

I will also add CTRL+Wheel scrolling for the console history (entered text).

Brainstorming:
How should the console react? How should it feel? Should there be a cursor, for example? Is the curently used right bracket ("]") on the prompt line good? What colors should the background have? What color should the text have?

[svenskmand]

I think there should be a blinking cursor. Have darkgray/black transparent background and gray/lightgray text. I do not know about the prompt character if any.

[StefanP.MUC]

Just pushed an update to the Console (screenshot attached):

- The background is darker (defined in console.material, pull from SVN!)
- It now has a blinking cursor (blink interval: 0.5 seconds).
- The prompt is now ">>>" instead of "]"
- the prompt is now always at the bottom (before it scrolled with the rest of the text)
- the text scrolling works better (the text is not scrolled out of the console anymore if there's no upcoming text)
- input history can now be scrolled with CTRL+mousewheel (in addition to Up and Down buttons)
- text display can be scrolled with mousewheel alone (in addition to PageUp/DOwn)

Any further ideas, wishes, input?

[svenskmand]

Nice good work

[oln]

Nice work.
I noticed that the game segfaulted if i tried to spam the console. (More precisely, the lines list seemed to get corrupted.)

[StefanP.MUC]

Yeah, I had this bug, too. It seems to happen if you enter text to fast. But this could also be releated to AngelScript because all text that is not c++ hardcoded is passed to AS. Maybe there's something wrong (but I'm not sure where to look, because most of the time the console works perfectly fine, even with spamming it).

[farcodev]

no idea apart to say that's a great addition