Alternative User Command System

[appleman3]

Tried of the horribly inefficient, static command system? Is the enormous Commands.java file giving you headaches? Look no further, for there is a better way.

I have designed (and created) a new Command System for use in Repacks.

What is a Command System? Obviously, the system of files that handles your player/gm/admin commands. Currently, in MoopleDEV rev90, that is a single file called Commands.java.

I mention MoopleDEV because that is the repack I designed this system for. In theory, you should be able to apply my system to any (odinMS based) source.



Features:
- Each command gets it's own Class
- TreeMap Command cache
- Commands will update themselves without restarting the server
- You can use any 'trigger' you want. E.x. !listcommands is the same as @listcommands


I have provided all of the commands I saw in Commands.java. They should serve as examples for how to create more commands.

Also, I have provided a !listcommands that fully functional without need for revision. (A.k.a. you don't have to go through and edit it yourself, it's completely done)


Attached is a .zip file with everything you'll need (including Step-by-step install directions for NetBeans).


Below is a copy/paste from the README:

Spoiler:

This is an alternative command system, written and tested for MoopleDEV rev 90.

It's main feature is that commands will auto update (WITHOUT having to restart
the server). The only draw back to this system is that it may prove to be a little
difficult to set up for inexperienced programmers. If you follow my instructions
step-by-step you shouldn't run into any troubles.

-----------------------------------------------

Step 1:

Install MoopleDEV. Make sure it actually RUNS and there are no errors that you caused.

If you can't install MoopleDEV then I'm afraid I can't help you.

-----------------------------------------------

Step 2:

Close NetBeans/Eclipse and anything else you happen to have open.


If you do not do this step, you may accidently over-write files.

-----------------------------------------------

Step 3:

Open your MoopleDEV folder.

Inside your MoopleDEV folder should be another folder called "src"

Open this folder and navigate to the following location:


MoopleDEV/src/client/


(I.E. double click on "src" then on "client")

-----------------------------------------------

Step 4:

You should see another folder called "command"

DELETE this folder (or move it, in the event you want a backup)

-----------------------------------------------

Step 5:

Copy the "commands" folder (found in this .zip file) into your "client" folder.


In other words, you're replacing your "command" folder with my "commands" folder.

-----------------------------------------------

Step 6:

Go back to your "MoopleDEV" folder.

Click on "src"

Click on "net"

Click on "channel"

Click on "handler"

Find "GeneralChatHandler.java"

Replace this file with my "GeneralChatHandler.java" (found in this .zip file)


To replace:
Drag my GeneralChatHandler.java file into the folder


In other words, replace the following file:
MoopleDEV/src/net/channel/handler/GeneralChatHandler.java

with my GeneralChatHandler.java file.

-----------------------------------------------

Step 7:

Open up NetBeans (or Eclipse, or whatever you use to edit files)

-----------------------------------------------

This is where it starts getting harder, but you can do it!

The following instructionst are specifically for NetBeans! If you would rather
use Eclipse or some differnt IDE, you must be smart about what you need to change.


Step 8:

Open up the file "ServerConstants.java" which is in the "constants" folder

-----------------------------------------------

Step 9:

In that file, find the following line:


public static final String HOST = "...";



Directly UNDER that file, paste the following lines:


/**

* How long (in milliseconds) the server should wait before re-checking files.

*

* Increase to improve performance.

*/

public static final int COMMAND_CHECK_INTERVAL = 3000; // 3 seconds


/**

* The directory where your IDE stores .class files.

* NOTE: Must point to the client.commands.impl location

*/

public static final String CLASS_DIR = "<PATH_TO_MOOPLE>/build/classes/client/commands/impl";


-----------------------------------------------

Step 10:

Replace the <PATH_TO_MOOPLE> with your actual path!

For example, my path would be:

C:/Users/<MY_NAME>/Desktop/MoopleDEV


which means my CLASS_DIR looks like:

public static final String CLASS_DIR = "C:/Users/<MY_NAME>/Desktop/MoopleDEV/build/classes/client/commands/impl";



BE SURE TO USE FORWARD SLASHES (/)... NOT BACK SLASHES (\)! I don't care if you're using windows, use forward slashes :P


-----------------------------------------------

Step 11:

Build your Project by pressing F11 (Or by going to Run > Build Main Project)

-----------------------------------------------

Step 12:

Enjoy!


-----------------------------------------------
-----------------------------------------------
-----------------------------------------------

In order for the commands to update you MUST re-build every time.

E.x. if you want to change the command !ap then you should:


A) Change everything you're gonna change
B) "Build" your project (F11)
C) Wait for NetBeans to finish building...
D) Enjoy, your command has automatically updated



Few things you should be aware of:

1) There is a command called "listcommands" which will list all of the commands
you can USE. This DOES NOT auto-update (waste of resources). In order to update
it, simply login and use the command "!listcommands update" exactly like that.
--> Of course, you only need to update if you DELETE or CREATE new commands.

2) Continiously checking if the command changed would be a waste of resources so it
only checks once every 3 seconds (at max). Please note that if you "build" again,
there is a good chance the program will be lead to believe you changed every command
even if you didn't. Don't worry too much about this as loading new commands does
not take all that long.

3) Your bats will display information when commands are loaded (so you can tell if
something is going screwy and it's constantly reloading commands). Don't worry,
those are NOT error messages. There will be an influx of loading when the first
command is used (as all commands will be loaded at once).

[MentaL]

[iAkira]

I'm gonna look into this

[nugyyman]

Wow, diffrent class for each command ?!
I dont get the point, I always use diffrent class for each GM level (player, donator, gm, admin) or subjects like charCommands, warpCommands, banCommands and so on..

[Kaynu]

Interesting, but this doesn't look like its more ideal.

[Fraysa]

- Each command gets it's own Class

lolwut? overload much?

[appleman3]

Interesting, but this doesn't look like its more ideal.

I admit that there is probably a better solution. But, any solution that involves a long chain of if-else statements where the commands are so close together you can hardly tell some of them apart is not better.

lolwut? overload much?

It does make for a lot of extra classes, but there's nothing really wrong with having a few extra. The entire point of OOP is to organize. I could probably have made a way to group similar commands (like !drop and !item) but there weren't all that many really similar commands to begin with... so I didn't bother for the sake of simplicity.

[SuperLol]

lolwut? overload much?

No, please don't talk about stuff you don't know about.

There are a few advantages and disadvantages to this, depending on how it is implemented.

My current system is like this:
I have created classes for most commands (say/notice are together, the @stat commands are together in the custom source), and they are loaded into a hashmap during first command use. Disadvantage, holding the object (it's very small though so doesn't matter for mem usage). During usage, it would do a containskey, and get which is faster than if/else if/else (even though it's negligible, really).

It's more about the structure of the source and simplicity than for other things. If you'll look at the odinms system, it works like this too. Classes for similar commands.

On topic:
Great job on this, looks similar to mine too :P. I'm not sure why you used a treemap though, hashmap will do unless you really need an order to them. Anyways I sometimes do wonder if the method that handles the command should actually be static. In a way static makes sense as well.

[appleman3]

On topic:
Great job on this, looks similar to mine too :P. I'm not sure why you used a treemap though, hashmap will do unless you really need an order to them. Anyways I sometimes do wonder if the method that handles the command should actually be static. In a way static makes sense as well.

I guess I should have used a HashMap instead. Only issue would be I'd have to figure out approximatively how many commands there are to take full advantage of the performance boost. Doing that is easy enough (since I'm already doing that in the !listcommands command).

I didn't go with static because I'm storing the commands as instances of a command class. Since I'm already doing that, it wouldn't matter one way or the other if the handleCommand method is static.

[Anujan]

May as well just use the command scripting odin included

[misterb98]

I'm a total noob at all of this, but good job!
I didn't have to do anything and now I gots good commands.
The only thing i wish for is a
@warp [map ID]

but besides that, exelent job!