Console extensions

[Hybrid]

So, I was thinking about trying to test the render architecture I'm designing in my other proposal, and I realized that I would have to design a whole NUI interface to get anything done, and unit testing would be fairly difficult since the architecture involves a lot of hot-swapping of Nodes and automating that would take a ton of extra work.

I'm a bit of a linux poweruser, and I quite like the idea of seperating policy from mechanism, just wrapping all the tricky stuff in executables, and then work on top of those.

So I was thinking, why can't we do that here?
Here's my though process:

• Each module defines a ConsoleProvider with methods for each command it supports(we could use reflection here).
• The user can run the commands from the console in the same way, but prefixed with the module name.

For example, if I wanted to list the active Nodes, I could do something like this:

• /render/ list "nodes"

If I wanted to see everything a Node was connected to:

• /render/ inspect <nodename>

If I wanted to disable a Node, I could do this:

• /render/ disable-node <nodename>

These functions would be defined something like this:

String <command-name>(String args[]);

Possibly with some of that annotation magic(I'm still not entirely sure how that works).

Here's some potential upsides:

• Testing is easier.
• Most Terasology programmers probably use Linux, so this should feel natural to them.
• The system can be extended to a basic scripting language.

Any opinions?

 

[Skaldarnar]

I don't see a big difference to the system we currently have. Essentially, the only thing this proposal solves (in my understanding) is that different modules can define commands with the same name. For instance, there might be a "debug" command for various modules. this might just be solved by adding the module name prefix automatically whenever the command system finds two commands with the same name. In addition, it should always be allowed to prefix a command with the containing module name.

I can follow your argument that testing will become a bit easier with it. However, what I would like to see is a way to hook up better testing and debugging means with commands. For instance, I'd like to have a (common) debug mode command to toggle on/off visual indicators, enter an extended logging mode just for specific modules, etc. I don't know how much of this would be possible (or feasible), but adding extensibility to this aspect of the engine could help a lot. As I'm not absolutlely sure about the current state, some of this might already be possible (e.g., hook up custom debug information to the F3 debug output in-game).

 

[Hybrid]

Yeah, I know it's a bit lacking. It's just a shower thought(literally).

I'm not entirely sure what you mean by commands.
If you mean hooking up things to the console, that's exactly what this is supposed to do. The whole idea is to hook everything up to a CLI, and then do whatever you want from there.

And there's no reason why NUI windows can't have a ConsoleProvider.

As for logging, if there's a way to automatically bump up the log levels from outside the module, you can just hook that in. I haven't looked at the logger code yet, so I'm not sure there.

Yes, most of this stuff is possible. But right now, it also needs to be coded in, and usually can't be changed at runtime(or it is possible, but setting that up needed a ton of UI code). A CLI can expose access at the function level, and writing a provider is about as easy as writing a bunch of stub functions.

Also, since consoles implicitly work through text formats, we can also send that data through a socket connection(or something) which means we can most of the processing for external connections for free.


It's nothing big, but I think it would be nice to have.

 

[Hybrid]

But yeah, I'll take the GSOC tag off. That was pretty silly, in retrospect.

 

[Skaldarnar]

Nah, not silly. We just talked at cross purposes. I was thinking about the in-game console all the time, not of a CLI interface for Terasology. Having clarified on that, I'm not sure that's the way we want to go. We should support more command line flag, I agree, but I don't know how much effort we want to put into a CLI interface. I'm actually not sure how many of the developers really use a Linux system...

We have, on the other hand, plans to work on a REST interface for our game server. In theory, an advanced interface could also provide means for debugging. In a similar fashion, external applications could query and update properties of a running instance (could be on the same machine). This approach would bundle the effort in providing a single interface. What do you think?

 

[Cervator]

Another option: put some additional work into the TeraEd facade.

IMHO more outright command line flags would be awkward - even if they are the Linux Way. We already have TeraEd that wraps a rendering debug console around the game window. How about we just extend it to where you can do more outright interactions with rendering debug actions? Possibly you could even have TeraEd reload the wrapped game, if that's even needed. At present when you apply changed graphics settings something in the rendering system reloads automatically. What benefit is there really to reloading the entire game that we can't already get in-game? It takes a little while to start up after all.

TeraEd could be issuing the same kinds of commands you could have available via regular in-game console. Interested 3d wizards could use either approach. The REST interface concept is leaning toward using some sort of headless client to be able to execute regular in-game functionality (including console commands) so any more commands added for debugging rendering could also be available there - although I don't know if that makes any sense at all (you'd be querying the server - but for graphics debug?)

There is also the behavior tree editor that already supports building a graph out of nodes in an in-game UI. So there's a potential foundation to start building on.