my command interpreter

A new update is now available, introducing seasons and more!
  • Finally got all the red squiggly lines to go away. So I'm just posting in hopes for some feedback. I want to make sure I'm going in the right direction.


    The idea is to eventually offer a suite of commands and additional plugins that can be interfaced by the console. The output is a guiPanel which pops up in the middle of the screen wheras the standard console box is for input. I like this route better than the current implementation which uses the chat window as output and when you are on a busy server.


    Some improvements I want to do (what I can think of right now):
    1. make console output fancier which would include multiple colors and indented lines. I don't know if the text colors supported in Player.sendTextMessage are supported in guiPanel text.
    2. pass an array subset of the arguments to each command, rather than the full one. Shouldn't be that hard.
    3. Possibly abstract the commands. It seems un-necessary since each command will just parse the argument array and return a string. Maybe as the API advances and we can do custom panels with buttons and dropdowns then I'll need more functionality besides returning a string so abstraction will make more sense.
    4. Make the guipanel invisible by default. I just realized that it will be drawn as soon as gameplay starts :(
    5


    So here is my primary class:




    And here is the command interpreter



    And an example command:



    Java
    package rwZorkConsole;
    /**
    *
    * @author zork
    */
    public class cmdHelp {
    public static String parse(String[] args) {
    return "Welcome to ZorkNet (znet), for all your adventuring needs!";
    }
    }
  • Just had a cursory look. A few comments:


    1) Purely stylistic, but usually classes have initial upper case while variables have initial lower case. So, the class consoleListener and the class commandInterpreter would usually be spelt class ConsoleListener and class CommandInterpreter.


    Also the variable commandInterpreter CI; would be better spelt CommandInterpreter cI;. This has some consequences, as when the variable is used later as in CI.parseString(tokens); the 'instict' would be to see the invocation of a static method parseString() of a hypothetical class CI.


    2) In line 12 of the CommandInterpreter constructor, the parameters passed are not used, rather literal values used in their stead; if the use of literals is intentional, then it is useless to pass any parameter to the constructor.


    3) The CommandInterpreter class is derived from GuiLabel and its text is repeatedly set, but the label itself is never shown on the screen of any player; am I missing something?


    4) Do I understand correctly that the GuiLabel origin of CommandInterpreter is used only to display generated text? Why not using it also to display the command themselves? And perhaps even to select them by intercepting a few strategic key presses, without relying on memory?

  • Just had a cursory look. A few comments:


    1) Purely stylistic, but usually classes have initial upper case while variables have initial lower case. So, the class consoleListener and the class commandInterpreter would usually be spelt class ConsoleListener and class CommandInterpreter.


    Also the variable commandInterpreter CI; would be better spelt CommandInterpreter cI;. This has some consequences, as when the variable is used later as in CI.parseString(tokens); the 'instict' would be to see the invocation of a static method parseString() of a hypothetical class CI.


    Yes you are correct. It is stylistic but I am not following the standard. I'll fix this. I jump back and forth between different languages and forget those little things.


    2) In line 12 of the CommandInterpreter constructor, the parameters passed are not used, rather literal values used in their stead; if the use of literals is intentional, then it is useless to pass any parameter to the constructor.

    Gotcha. I added the constructor because Netbeans was complaining about one not being there. There is no reason to modify the values so I restored it to the constructor generated by default. That was probably me trying to fix something from before but now it seems incorrect. Thanks for the catch :)


    Java
    public commandInterpreter(float x, float y, boolean relativeposition) {
    super(x, y, relativeposition);
    }


    3) The CommandInterpreter class is derived from GuiLabel and its text is repeatedly set, but the label itself is never shown on the screen of any player; am I missing something?

    I don't know what you mean by the text being repeatedly set. The idea is that the command argument typed into the console is read and depending on what each command does will determine what text is printed to the screen. The string will be appended to or replace the contents of the stringbuffer. or The screen is made visible and shows the contents of the stringbuffer. into the standard command console... StringBuffer is actually old and I should use StringBuilder instead. Maybe something better is available in JDK 8 but I haven't looked yet.


    4) Do I understand correctly that the GuiLabel origin of CommandInterpreter is used only to display generated text? Why not using it also to display the command themselves? And perhaps even to select them by intercepting a few strategic key presses, without relying on memory?

    I could print the original command and format it to look more like an actual operating system command line. The string shown can be anything I want it to me. I'm mainly focusing more on the structure of the plugin and not really the content yet.. What do you mean by select them ? What memory issue do you see?

  • I jump back and forth between different languages and forget those little things.

    :D

    Quote
    Java
    public commandInterpreter(float x, float y, boolean relativeposition) {
    super(x, y, relativeposition);
    }

    :thumbup:

    Quote

    I don't know what you mean by the text being repeatedly set.

    Sorry, perhaps "repeatedly" is not appropriate: the label text is set in several points of the code, and one would assume that the purpose is to show this text.

    Quote

    [...]determine what text is printed to the screen.

    Well, I cannot see any point where the GuiLabel is actually displayed. The text IS set, but never shown, as far as I can see.

    Quote

    What do you mean by select them ?

    As I described elsewhere (but I do not remember where... :whistling: ). "Taxi" could be listed in the GuiPanel with a big 'T' (upper case, coloured, bold, whatever) and the press of the [T] key intercepted, triggering the correspondent code. Similarly for the other commands.

    Quote

    What memory issue do you see?

    Human memory, player memory, not RAM! :D No (or less) need to remember command orthography, to pay attention to typos and so on.

Participate now!

Don’t have an account yet? Create a new account now and be part of our community!