next »

[Michael]

Hmm, I've done some searching within the classes and their methods and it seems that the java version is quite limited to some features compared to the groovy version, as is not so sure about that, did you actually make feature implementations for the game with groovy, because I searched these jar files:

• meta-jb-cmd-1.0.0
• meta-jb-core-0.25.1
• meta-jb-json-1.0.1
• meta-jb-shell-1.1.1-SNAPSHOT
• meta-jb-swing-0.25.1-SNAPSHOT
• meta-jb-util-0.25.1-SNAPSHOT
• Mythruna-Client
• Mythruna-Core

..which all contained your package as your website name (I won't say it), and I did not find a method for "addShellCommand" and I am guessing that you actually created the script in groovy, because I found this within the "BaseUiEnvironment.groovy" and "BaseScriptEnvironment.groovy":

Code:

void addShellCommand( Shell shell, String name, String description, String help, Closure exec ) {
    
    String[] helpArray = null;
    if( help != null )
        helpArray = help.split( "\\r?\\n" );

    cmd = new ShellScript( description, helpArray, exec );
    shell.registerCommand( name, cmd );
}

I was able to put it in a plain groovy file to implement, just not in java

[pspeed]

addShellCommand() is a convenience function for adding a command to the shell.  It takes care of a lot of the boilerplate for you but you can also do it directly from Java... you just have to do it manually.  (Interesting note: in the new version of the API you can add commands directly to the "shell" object without passing it to some other function.)

The "shell" environment variable is really just a variable on the player context... which is the object you get in any player events like playerJoined.

So you can implement and add your own commands that way using the meta-jb command classes.  (meta-jb is one of my open source projects... the oldest one, actually.)

Implementing a command in this way is probably too much for me to go into at the moment.  I think there is some default command you can extend and just override the execute methods or something.  I was going to try to find a good example of writing a player command in Java but I've implemented all of them in groovy because it was so much easier.

Even if you want to write the command logic in Java it's still probably easier to wrap it in groovy boiler plate and then call your custom method to do the work, passing it any of the relevant environment that it needs.

[Michael]

I would like to apologize if this is actually taking up quite a bit of your time, I appreciate the knowledge that you are feeding me so much. This API thing is so stressful, but so fun!

As a side-note, any plans for the new API to come out? Like the next public release or alpha? (I wish I was a donor, I could have the API by now )

[pspeed]

The API will be different in the next version I release.  Partially because I cleaned up some things and partially because so much of the engine has been rewritten.

[Michael]

I think I will stick to groovy until you release the new version to the public, or not. We'll see how far I get

ehh,.. 6 months away

[Michael]

One thing that really ground my gears was that the game always crashed if I did something wrong, so I'm working on a plugin (to be released in a couple weeks with basic fundamentals) and I just put some try..catch statements so I don't get as mad

[pspeed]

One thing that really ground my gears was that the game always crashed if I did something wrong, so I'm working on a plugin (to be released in a couple weeks with basic fundamentals) and I just put some try..catch statements so I don't get as mad

Yes, you need to deal with your errors.

[pspeed]

I think I will stick to groovy until you release the new version to the public, or not. We'll see how far I get

ehh,.. 6 months away

I thought I gave you enough information to have you continue with Java.  I thought the questions were answered.  Using the easier approach, you are even somewhat insulated from engine changes... and would at least know right away when you tried to compile.

That is the hidden advantage to the Java approach is that you will detect those sorts of problems right away when you try to someday compile against the new engine.  Many of the same errors may lay hidden until runtime in Groovy.

[Michael]

I think I will stick to groovy until you release the new version to the public, or not. We'll see how far I get

ehh,.. 6 months away

I thought I gave you enough information to have you continue with Java.  I thought the questions were answered.  Using the easier approach, you are even somewhat insulated from engine changes... and would at least know right away when you tried to compile.

That is the hidden advantage to the Java approach is that you will detect those sorts of problems right away when you try to someday compile against the new engine.  Many of the same errors may lay hidden until runtime in Groovy.

You gave me quite a great amount of information and you did answer every single question, just the fact that I believe I will do better with more practice in java when I get a better understanding of everything.

The main thing I really like to do is transfer a plugin from groovy into java as good practice, which I plan on doing with the current plugin (write in groovy, transfer to java) or I may intertwine groovy and java.

[Michael]

I am able to retrieve some attributes of the player, but the attributes I get are located in that player's JSON file, which doesn't load their current location. I have this code to actually get their location, that searching doesn't resolve the answer.

Code:

//player = e.getContext();
Vector3f playerX = player.getPlayerData().getLocation(String paramString);

The getting of the location requires a String.. I have seen in your groovy file "player-commands.init.groovy" that you used this to get their location for the escape command:

Code:

on( [playerConnected] ) {
    type, event ->
        
    Object p = conn.getAttribute( "player" );

    println( "Adding player commands to " + p.get("userInfo.userId") ); 
    
    addShellCommand( shell, "escape", "Teleports you above your current location at 160 meters.", null ) {
        pos = getLocation( connection );
        console.echo( "Warping to:" + pos.x + ", " + pos.y + ", " + 160 );
        warp( connection, (float)(pos.x + 0.5f), (float)(pos.y + 0.5f), 160.0f );                          
    }
}

I have been looking into it, and I know that these are some classes that sort-of work to receive the location, but I cannot construct it correctly:

HostedConnection (jME Class File)
PlayerConnectionContext

Could you fill me in on more information when you have any spare time, or when you feel like being nice? I will continue to try to find the correct way to construct it, lets see who finds out first

[pspeed]

Player location is on the player entity.

In the snippet of admin script you post, getLocation() is part of the API that I've exposed.  Its implementation is different on single player and multiplayer so I abstracted it away.

For the current player getLocation() is supposed to work without any parameters.  I maybe had an issue with that at one time... or maybe it doesn't work from within the shell commands (it relies on script-specific context and shell commands are run outside of that).

If you have access to the player entity, you can also just grab the Position component:
pos = player[Position.class];
...which will have location and facing.

[Michael]

I guess I forgot to state that I am still doing this in java; I tried this code, and it throws an error at Position.this for being No enclosing instance of the type Position is accessible in scope:

Code:

Vector3f playerLoc = Position.this.getLocation();

On a side note,  will try to legitimately get the location like this, no errors, just would like to ask if this would be correct:

Code:

Vector3f playerX = player.getPlayerData().getLocation(Float.toString(playerLoc.x));

[pspeed]

I guess I forgot to state that I am still doing this in java; I tried this code, and it throws an error at Position.this for being No enclosing instance of the type Position is accessible in scope:

Code:

Vector3f playerLoc = Position.this.getLocation();

On a side note,  will try to legitimately get the location like this, no errors, just would like to ask if this would be correct:

Code:

Vector3f playerX = player.getPlayerData().getLocation(Float.toString(playerLoc.x));

This is kind of just random gibberish that looks similar to code.  No offense but it is.  You can't just pass magic things.  The player data is a general bucket for storing persistent player data.  It might store all kinds of locations like "lastLocation" or "myDogsLocation" or whatever.  At any rate, it is totally not what you want to use.

The code on the groovy side for doing this is so much easier that it pains me every time I have to write the 20 lines of Java code to do the same thing. (exaggerating)

Is this from a shell command or something else?  It's important because you will need to access quite a few different things and how you access them is different depending on where you are running.

[pspeed]

So, wherever you are running this it seems like you have a player object and that the player object is probably some kind of PlayerContext.

In that case, getting the position in Java should be something like:

Code:

EntityId playerEntity = player.getPlayer();
GameSystems systems = player.getSystems();
EntityData ed = systems.getEntityData();
Position pos = ed.getComponent(playerEntity, Position.class);
Vector3f location = pos.getLocation();

[Michael]

Paul, you were SO right..

Implementing a command in this way is probably too much for me to go into at the moment.  I think there is some default command you can extend and just override the execute methods or something.  I was going to try to find a good example of writing a player command in Java but I've implemented all of them in groovy because it was so much easier.

Adding a command in groovy:

Code:

addShellCommand(shell, "test", "a test command", null) {
    console.echo(player.name)
}

Adding a command in java (it will even make modifiers final, which I don't like to do when they aren't really "final"):

Code:

ShellCommand cmd = new ShellCommand() {
	private static final long serialVersionUID = 1L;

	public Result execute(Environment env) { //This method is.. nothing..
		return null;
	}

	public boolean isSimple() { //This method is.. nothing..
		return false;
	}

	public String[] getHelp() {
		String[] helpArray = {"Test help information", "More help information"};
		return helpArray;
	}

	public String getDescription() {
		return "Just a test command";
	}

	public int execute(ShellEnvironment shellEnv, String str) {
		e.getContext().echo(e.getContext().getPlayerData().get("characterInfo.name"));
		return 0;
	}
};
shell.registerCommand("test", cmd);