Groovy Console

[overdhose]

I have been toying around a bit with the groovy console in an attempt to make it a bit more user friendly. However, I ran into a couple issues that require some consideration :

1 : typo's in commands can easily be caught, no prob there

2: however, typing a command line "teleport" without params actually suggests methods like Sleep(long) for example

3: typing a wrong parameter produces a pretty generic nullpointer exception, hard to do something decent with that

4 : as the console closes after a succesfull command, it becomes pretty unintuitive to display messages as you have to reopen the console to actually see them. the method runGroovyShell only returns a boolean, I'd suggest using an int type so we can actually differentiate at least 3 states :
0 : you did something wrong, the console stays open and gives feedback
1 : You requested info (succesfully), but the console has to remain open to type the next command
2 : command was succesfull and console was closed, feedback messages

and probably a 3: only the feedback message was updated / reset, and you now need to enter a command...

I also think it would be usefull to actually include a command which enables / disables the feedback messages, also thinking of the future and annoyances due to the fact that you can't scroll atm... I'm pretty sure scrolling will have to be considered to keep things clean... the text also hides behind other gui elements so you have to consider screen size etc...

basically, it would require quite some changes, I comitted what I did so far, dirty solution and everything, at https://github.com/overdhose/Terasology so you can review it if you like and make suggestions if you like...

 

[Cervator]

Make it so!

Although, I think you might just have committed locally and not pushed your code to GitHub? I don't see any changes listed there on your account

Your ideas all sound great, and the console needs work for sure. It probably also needs to be a formal GUI element rather than just text printed to a position. Looking forward to seeing the stuff, tho I prolly won't be able to play with it for a few hours

 

[overdhose]

m'yeah actually "commit" sounded quite up there somewhere... however I also "pushed" now but nothing seems to happen... I'll check that tomorrow, off now

 

[overdhose]

I realized my mistake heh I had checked out the original source to start and forgot to redirect Git that's why I couldn't commit online... but doesn't mind, I'll try to build an actual console, I saw there are already functions for scrolling ready, so I'll just glue that together and create some thing decent... just uch how would you like the data stored? xml or something? Would be nice to decide what help format you are gonna use, so we can build the console on that

 

[Cervator]

What kind of data? Config, UI component setup, etc? We have some existing config stuff if you look around and JSON would be ideal in general rather than XML, it gets along well with the original block definition format as well as JS for modding etc

And thanks!

 

[overdhose]

Well I was mostly thinking of the descriptions for commands, like when you type "help giveBlcok" you get an explanation about the command. I'll look into the json format, it's new to me as are many things here...

 

[woodspeople]

An improved console would be a HUGE help in bridging the gaps until the GUI grows to its full magnificence Also, leaving it in place might provide a geek-pride method of interacting with the system that the priesthood might choose to use even after an interface for the unwashed masses is ready to use. A command line does not necessarily have to be a stopgap. It can be a mysterious power. Two suggestions: a list of things you can get from giveBlock, because there are lots of them and they are cool. And: a "last command" stack like the up key in *nix. And a more obvious command-line cursor, can't see the thing right now.

 

[overdhose]

key up already gives you the last command btw

here's a json file I started :

{ "commands" : [
{
"commandname" : "giveBlock",
"commandparams" :
{ "param" : [
{"paramname" : "blocknbr","paramdesc" : "numeric block number"},
{"paramname" : "blocknname","paramdesc" : "alphanumeric name of the block"},
{"paramname" : "quantity","paramdesc" : "number of blocks to add, 16 by default"}
]},
"commandDesc" : "Adds blocks to your inventory",
"commandHhelp" : "",
"commandexample" : "'giveBlock Water' Gives 16 water blocks\n'giveBlock IronPyrites, 42' Gives 42 Iron Pyrite (Fool's Gold) blocks\n'giveBlock Chest' Gives you a Chest block you can place, activate ('E'), put stuff in, destroy, pick up, place elsewhere, find same stuff in it!"
},

I'm planning to use that as a base for checking commands and suggestions, help etc....
hopefully it can be used for help to later

about the cursor... was also one of the first things I looked into, however making it blinking requires resources, so i left it like that atm.

 

[overdhose]

at this point, I was even pondering if it would make sense to let contributors add their own commands through a gui to make it hassle free, something similar to the prefab manager

 

[Cervator]

Hey if you can make it work, go for it

On the documentation per command stored in a separate JSON file - first thing that makes me think is that it will go out of date. I wonder if there's any way to use Javadoc in the GroovyConsole class to document each command, then somehow include that in the live console?

Beats having no doc for sure tho

 

[overdhose]

another noob question :

I had following command :
JsonReader reader = new JsonReader(new FileReader(".\\data\\help\\commands\\commands.json"));

the idea was to save the files in the \data folder from terasology, however atm this saves the files in the terasology root, not in src etc

obviously I'm doing something wrong, I just wonder what... else you'd have to copy \data\etc in your dev setup to use the console help

I also wondered if this is the right way to access spstate :
IGameState state = Terasology.getInstance().getCurrentGameState();
UIDebugConsole _console;
if (state instanceof StateSinglePlayer) {
StateSinglePlayer spState = (StateSinglePlayer) state;
_console = spState.getHud().getDebugConsole();
}

 

[Immortius]

Having the files in a separate directory wouldn't work for the applet anyhow. I would suggest having them in with the embedded resources and reading them through the asset manager (or in a mod, but that isn't ready yet).

That is the right way of accessing StateSinglePlayer - in practice you shouldn't need to and there is a bunch of functionality in there that shouldn't be, but I guess that is fine in the meantime. It is a little different in my fork - but only insofar as you would get the GameEngine rather than Terasology.

 

[overdhose]

some screens :

help

help commandList

help blockList (scroll up for rest)

 

[Cervator]

Awesome! That looks perfect, and very helpful. Nicely done!

I also like the backdrop. I wonder how a Dungeon Heart would look in blocks

 

[woodspeople]

Wow cool, super improvement! We will feature this in our next let's play

 

[overdhose]

glad you like it, glad to be of service

honestly json / gson gave me quite the headache, looking at the groovy code still does atm...

guess I'll quietly look at some more code once the console seems acceptible and figure things out... I lost a lot of time on things like Json / Gson, java itself and Groovy

also, as a lot of the gui is still a work in progress, my code might actually look a lot more ugly. And like I mentioned before, my files only work with the source / development branch, I'll try to figure out a way to make it work with a compiled version now. I'm unrefined like that.

 

[metouto]

Man-O-Man look at the "help blockList"

I like that best of all but I may be a little partial on that

Anyway overdhose, nice work

 

[Immortius]

Looks good!

A few comments:

• debugCollision shows the collision of nearby blocks
• dumpEntities writes out information on all entities to a text file for debugging
• Rather than a list of blocks and/or block numbers, it is the block family names that are worth displaying IMO. Block numbers can change from world to world, and while block names are alright, Things like BrickStairLEFT, BrickStairRIGHT, etc are all basically same to the player.

 

[Cervator]

This is too nifty to leave alone - so I've pulled it to develop, I hope you're OK with that

I included the "data" dir with the json files in the zip build step real quick for now (cake) so that version of the game will support the help commands. Applet still doesn't include it, but also doesn't crash, so hey. Files are being shuffled around in Immortius' branch anyway so we'll tidy up after that.

Functionality observations: Scrolling seems sketchy (might just be me), successfully executed commands should probably clear the line after completion?

Thanks a bunch and keep it up!

https://github.com/MovingBlocks/Terasol ... bf2f1527a1

Fun extra: "helpheplheplhpelheh blockList" still works, heh

 

[overdhose]

thanks for all the feedback, and sure use whatever you like.

about the blocklist : I pull it from within the block manifest class, so I believe it should show the correct ID's regardless (if i figured that out correctly at least), it's not a static json file. I was planning to add the family's to it, no worries.
Similarly, I use reflection to obtain a list of commands from groovy, so if you add a command without adding to the json, it will still show up in the list as an undocumented command.

I know the scrolling is unresponsive, it reminds me of certain applications when scroll wheels were new, I'll look into improving that... but at least it scrolls... kinda

help isn't a groovy command btw : I intentionally did it like that for now, it checks if the console string starts with help, splits the string based on spaces and does some magic. It wouldn't take much to change that if you prefer help to be part of the groovy commands.