Mythruna

Modder's Workbench => Scripting => Topic started by: Michael on July 12, 2013, 03:44:06 PM



Title: Paul, API: Info/Allow Suggestions?
Post by: Michael on July 12, 2013, 03:44:06 PM
I would like to know if there is any actual information discussing the official API that is going to come for v.ALPHA, such as will it be similar to the current API, and will it be accessible with .jar files?

Also, are we allowed to discuss the upcoming API along with suggestions to it regarding certain things as methods and names for methods?

Thank you.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on July 12, 2013, 09:23:14 PM
Not sure how to answer this one.  Yes it will be similar.  Yes it will be different.  The java code will be in jars.  The groovy code will probably also be zipped into the jars.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on July 12, 2013, 09:49:18 PM
Okay you got the first question down (sorta).
a.) the code will be somewhat the same, but different for the API

will it still use groovy, or will we actually get to use java?
----------
Will we be allowed to discuss the API and suggestions for things that go into the API (what methods are called, how you do this in that in code, put suggestions for names of enumerations, classes, classes that you extend from, classes that you implement from, ect ect.)


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on July 12, 2013, 10:00:18 PM
Okay you got the first question down (sorta).
a.) the code will be somewhat the same, but different for the API

will it still use groovy, or will we actually get to use java?

You can already use groovy or Java... so I have no idea what you mean here.

----------
Will we be allowed to discuss the API and suggestions for things that go into the API (what methods are called, how you do this in that in code, put suggestions for names of enumerations, classes, classes that you extend from, classes that you implement from, ect ect.)

You can... I don't know how you could have enough information to really make informed suggestions but you are welcome to discuss it.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on July 13, 2013, 12:08:50 AM
Mneh,
Sorry Paul, I mean from a previous thread I talked about getting the groovy script to run a .jar file, I was asking will it have a simpler method to it when it goes alpha.

The whole groovy and java differentiating thing is just really confusing me, like the different syntax from language to language in which groovy does this:
Code:
on([playerJoined]) { type, event ->
I wouldn't know how to do that in java at all.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on July 13, 2013, 12:24:54 AM
Mneh,
Sorry Paul, I mean from a previous thread I talked about getting the groovy script to run a .jar file, I was asking will it have a simpler method to it when it goes alpha.

It's not hard.  Make a lib directory under the scripts directory where your scripts are.  Put the .jar in there.  Call your Java code from groovy.

The whole groovy and java differentiating thing is just really confusing me, like the different syntax from language to language in which groovy does this:
Code:
on([playerJoined]) { type, event ->
I wouldn't know how to do that in java at all.

Code:
EventDispatcher.getInstance().addListener( PlayerEvents.playerJoined, new EventListener<PlayerEvent>() {
        public void newEvent( EventType<PlayerEvent> type, PlayerEvent event ) {
            // do your event handling
        }
    });

...you see why the groovy syntax is preferable.  It hides a lot of stuff and gives you more local context.

But which is it you want, Java or groovy?  Your question was a bit confusing.  And anyway, you can do both.

In groovy:
Code:
on([playerJoined]) { type, event ->
    // call some Java code
    MyClass.doMyStuff(things, my, stuff, needs);
}



Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on July 13, 2013, 12:46:47 AM
Also, I want to mention that this version:
on([playerJoined])

...is really for adding a hook to multiple events at the same time.  This is why it takes a list: [playerJoined]

You can also just call:
on( playerJoined )

...if you only have one event type your are registering for.

This is one part that I've implemented in the new engine and it's still exactly the same.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on July 13, 2013, 10:30:17 AM
Oh thank you Paul, that enlightens me more upon this :)


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on July 21, 2013, 08:49:26 PM
Along with the enlightenment, I now know what "type, event ->" is :P


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 04, 2013, 08:16:25 PM
YES! I finally got a script working in java for a mod!! :D


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 06, 2013, 11:17:30 AM
I really want to work on this plugin I am going to use as a tool for all server owners, and I will continue to update it once it first gets out, but I am doing testing with it, and with this code, ServerEvent is a raw type, and I didn't know what that is. So of course, did some researching, and since <?> is known as a wildcard I tried using it, but it just tells me to change addListener(EventType, EventListener) to removeListener(EventType, EventListener) and I don't know why:
Quote from: code
EventDispatcher.getInstance().addListener(ServerEvents.serverStarted, new EventListener<ServerEvent<?>>() {
   @Override
   public void newEvent(EventType<ServerEvent<?>> type, ServerEvent<?> event) {
      System.out.println("\nServer Startup Test\n");
   }
});

:-\


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on August 06, 2013, 12:36:20 PM
Wildcards were not meant to be used in this way.  Just leave the <?> out completely and it should work, I think.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 06, 2013, 05:52:55 PM
Its working capability is negative..


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on August 06, 2013, 09:56:41 PM
Its working capability is negative..

The latest code and error message look fine from here. ;)


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 06, 2013, 11:02:47 PM
Its working capability is negative..

The latest code and error message look fine from here. ;)
__
. .|
?-?   Paul, I'm reaching out to you :P
Its raw type just doesn't work, I can switch everything over to a playerJoined event, when the player joins I get a message, serverStarted doesn't work, are you running on "latest code" as code that isn't from the 20120627 build?


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 06, 2013, 11:46:00 PM
Also, I was thinking for quite some time, have you implemented configuration files? If you haven't, will you please do to provide users with easily creating a default configuration file and stuff, or at least part-way? I'm not sure if you are spiffy (not sure if that was the best word to use) or not about it because I am not sure how you are exactly going about plugin configurations..

if you are thinking about implementing configuration files, I would like to see some YAML (YAML Ain't Markup Language) put into it. If you aren't sure about how you would process it at all, or if you are too lazy to create your own version, visit the parser that Bukkit made for reference https://github.com/Bukkit/Bukkit/tree/master/src/main/java/org/bukkit/configuration

if you don't plan on adding a default configuration, someone (gara or I, hencing the idea of anyone else :P) will probably make a library for it, or if you already have, GREAT!

@MythrunaGame (https://twitter.com/mythrunagame) please respond.

EDIT: I have been looking over that Bukkit YAML thing because I want to make my own parser because I want a config :P


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on August 07, 2013, 12:47:23 AM
Its working capability is negative..

The latest code and error message look fine from here. ;)
__
. .|
?-?   Paul, I'm reaching out to you :P
Its raw type just doesn't work, I can switch everything over to a playerJoined event, when the player joins I get a message, serverStarted doesn't work, are you running on "latest code" as code that isn't from the 20120627 build?

You totally missed what I was saying.  I cannot possibly ever even hope to debug code that I cannot see.  You've done something wrong with my advice and I can't see what.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on August 07, 2013, 12:48:22 AM
Also, I was thinking for quite some time, have you implemented configuration files? If you haven't, will you please do to provide users with easily creating a default configuration file and stuff, or at least part-way? I'm not sure if you are spiffy (not sure if that was the best word to use) or not about it because I am not sure how you are exactly going about plugin configurations..

if you are thinking about implementing configuration files, I would like to see some YAML (YAML Ain't Markup Language) put into it. If you aren't sure about how you would process it at all, or if you are too lazy to create your own version, visit the parser that Bukkit made for reference https://github.com/Bukkit/Bukkit/tree/master/src/main/java/org/bukkit/configuration

if you don't plan on adding a default configuration, someone (gara or I, hencing the idea of anyone else :P) will probably make a library for it, or if you already have, GREAT!

@MythrunaGame (https://twitter.com/mythrunagame) please respond.

EDIT: I have been looking over that Bukkit YAML thing because I want to make my own parser because I want a config :P

Scripts are configuration files.  So I have no idea what you mean.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 07, 2013, 09:13:43 AM
You totally missed what I was saying.  I cannot possibly ever even hope to debug code that I cannot see.  You've done something wrong with my advice and I can't see what.

This is code that I try to call when the server starts, but doesn't work.
Code:
public static void onServerStart() {
EventDispatcher.getInstance().addListener(ServerEvents.serverStarted, new EventListener<ServerEvent>() {
@Override
public void newEvent(EventType<ServerEvent> type, ServerEvent event) {
System.out.println("SERVER HAS STARTED");
}
});
}

Here is code that I call when a player joins, it works.

Code:
public static void onPlayerJoin() {
EventDispatcher.getInstance().addListener(PlayerEvents.playerJoined, new EventListener<PlayerEvent>() {
@Override
public void newEvent(EventType<PlayerEvent> type, PlayerEvent event) {
System.out.println("A PLAYER HAS JOINED");
}
});
}

I make sure that I am calling the correct method from my groovy runnable script.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 07, 2013, 09:15:44 AM
Scripts are configuration files.  So I have no idea what you mean.
I mean, when you have a plugin and it comes with MANY features, and people don't want all of the features of that plugin enabled, you will give them a configuration file to turn on/off certain features of that plugin, will you have that default for us, or will we have to make it ourselves?


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on August 07, 2013, 09:34:50 AM
Scripts are configuration files.  So I have no idea what you mean.
I mean, when you have a plugin and it comes with MANY features, and people don't want all of the features of that plugin enabled, you will give them a configuration file to turn on/off certain features of that plugin, will you have that default for us, or will we have to make it ourselves?

There will be a user interface for this so that you don't have to teach your "customers" configuration file tweaking.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on August 07, 2013, 09:35:54 AM
This is code that I try to call when the server starts, but doesn't work.
Code:
public static void onServerStart() {
EventDispatcher.getInstance().addListener(ServerEvents.serverStarted, new EventListener<ServerEvent>() {
@Override
public void newEvent(EventType<ServerEvent> type, ServerEvent event) {
System.out.println("SERVER HAS STARTED");
}
});
}

"doesn't work" as in:
-nothing happens?
-crashes your computer?
-crashes the app?
-gives an error message?

...if it's the last one then I need the error message.

Helpful information is helpful. :)


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 07, 2013, 09:58:50 AM
Heh, sorry, its this:
problem[0] = "Nothing Happens";


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on August 07, 2013, 10:07:58 AM
Heh, sorry, its this:
problem[0] = "Nothing Happens";

Then put some printlns in to see if any of the code is even being run.... on the groovy side, on your code that works, on your code that doesn't work, etc... put them all over the place.  But especially in your onServerStart().


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 07, 2013, 10:16:48 AM
This is my groovy class that runs it (Runnable.init.groovy):
Code:
import me.shzylo.<not for you to see>.*

println "<description : NOT FOR YOU TO SEE>"
println "v0.1 @author Shzylo"

on([serverStarted]) {
println "gTest"
<Not for you to see>.onServerStart()
}

and here is my java code:
Code:
@SuppressWarnings("rawtypes")
public static void onServerStart() {
System.out.println("jTest 1");
EventDispatcher.getInstance().addListener(ServerEvents.serverStarted, new EventListener<ServerEvent>() {
@Override
public void newEvent(EventType<ServerEvent> t, ServerEvent e) {
System.out.println("jTest 2");
}
});
}

This is the console:
Quote from: SERVER_CONSOLE
gTest
jTest 1

it stops somewhere within the EventDispatcher, and I put Sysout where ever I was able to.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on August 07, 2013, 12:09:22 PM
Well, you aren't even registering your custom server started listener until the server is already started.

-Server starts.
-your on(serverStarted) code is called
-it calls your java code
-instead of actually doing the server started stuff it registers an event for server started which has already happened


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 07, 2013, 12:21:13 PM
Well, you aren't even registering your custom server started listener until the server is already started.

-Server starts.
-your on(serverStarted) code is called
-it calls your java code
-instead of actually doing the server started stuff it registers an event for server started which has already happened
That's quite strange, because it works in groovy, it should continue to pass it on, no? There are a bunch of things that I am trying to do in java when it will be much easier/possible just to do it in groovy, but I am very arrogant at times :P


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on August 07, 2013, 12:34:55 PM
Well, you aren't even registering your custom server started listener until the server is already started.

-Server starts.
-your on(serverStarted) code is called
-it calls your java code
-instead of actually doing the server started stuff it registers an event for server started which has already happened
That's quite strange, because it works in groovy, it should continue to pass it on, no? There are a bunch of things that I am trying to do in java when it will be much easier/possible just to do it in groovy, but I am very arrogant at times :P

I think you have completely misunderstood what I'm saying and/or your own code.

on( [serverStarted] ) registers a section of code that runs WHEN AN EVENT IS FIRED.  Not during startup.  Not when that script is run.  But when that event happens.  In this case, when the server starts.

EventDispatcher.getInstance().addListener(ServerEvents.serverStarted...) does exactly the same thing.  The code you register as a listener won't be run until the serverStarted event has fired.

So, if you don't register your listener until DURING the server started event then there will never be a serverStarted event after that to cause it to fire.  Plus, it's redundant since you are ALREADY RUNNING in a serverStarted event.

So just do this:
Code:
public static void onServerStart() {
System.out.println("jTest 1");
        System.out.println("jTest 2");
}

Where System.out.println("jTest 2") is the code you actually want to run when the server starts.

Alternately, if you really have your heart set on registering a callback the hard way, you can just stop registering the event on the groovy side and run your code directly.

Code:
import me.shzylo.<not for you to see>.*

println "<description : NOT FOR YOU TO SEE>"
println "v0.1 @author Shzylo"

println "gTest"
<Not for you to see>.onServerStart()

The first way is easier and less boilerplate code for you to write.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on August 07, 2013, 12:37:27 PM
Put another way, you've called the front desk for a wakeup call at 6:30 AM on Wednesday... and then when they call you at 6:30 AM on Wednesday you then call them again for another wakeup call at 6:30 AM on the same Wednesday.

...not very effective.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 07, 2013, 01:06:19 PM
Enlightenment's and more enlightenment's.. thank you for the lessons :)


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 11, 2013, 08:57:03 PM
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 :-\


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on August 11, 2013, 09:11:30 PM
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.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 11, 2013, 09:37:21 PM
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 :))


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on August 11, 2013, 11:30:03 PM
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.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 13, 2013, 11:43:18 AM
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 :-\


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 13, 2013, 11:46:27 AM
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 ;)


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on August 13, 2013, 01:19:28 PM
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.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on August 13, 2013, 01:21:06 PM
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.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on August 13, 2013, 03:12:38 PM
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.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on September 14, 2013, 12:47:58 PM
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 ;)


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on September 14, 2013, 01:04:20 PM
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.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on September 14, 2013, 01:45:48 PM
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));


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on September 14, 2013, 02:02:20 PM
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.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on September 14, 2013, 02:40:44 PM
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();


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on September 14, 2013, 03:28:30 PM
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);


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on September 15, 2013, 06:42:37 AM
Paul, I found your JsonParser class, and I am wondering if you have an javadocs on it, because it's package org.progeeks.json is not located at http://meta-jb.sourceforge.net/javadoc/index.html (http://meta-jb.sourceforge.net/javadoc/index.html); I would also like to state files have been quite a weak point for me for quite some time.. should I learn your parser or go back to the basics of files and learn from there first?


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on September 15, 2013, 11:03:19 AM
There is a javadoc jar here:
https://sourceforge.net/p/meta-jb/svn/HEAD/tree/trunk/dev/m2-repo/org/meta-jb/meta-jb-json/1.0.1/

I don't know if I actually documented the classes, though.  I don't know that I would attempt this at your current skill level.

...and just for the record, it would be superbad to read/write directly from the player .json files.  That's what PlayerData is for.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on September 15, 2013, 11:13:22 AM
...and just for the record, it would be superbad to read/write directly from the player .json files.  That's what PlayerData is for.
My goal with your json parser and reader/writer was to make my own files with (e.g: myfile.json), not to mess with your current ones. I don't know much about how you implemented it, would you rather I not use your json parser?


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on September 15, 2013, 11:19:41 AM
...and just for the record, it would be superbad to read/write directly from the player .json files.  That's what PlayerData is for.
My goal with your json parser and reader/writer was to make my own files with (e.g: myfile.json), not to mess with your current ones. I don't know much about how you implemented it, would you rather I not use your json parser?

My JSON parser is great.  I just foresee a lot of complications for someone still just learning.

What kind of data are you trying to store?


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on September 15, 2013, 12:45:08 PM
...and just for the record, it would be superbad to read/write directly from the player .json files.  That's what PlayerData is for.
My goal with your json parser and reader/writer was to make my own files with (e.g: myfile.json), not to mess with your current ones. I don't know much about how you implemented it, would you rather I not use your json parser?

My JSON parser is great.  I just foresee a lot of complications for someone still just learning.

What kind of data are you trying to store?
I am going to store coordinates, and the syntax I was going to look for is this:

Quote
    "<player name>" : {
        "<home name>" : {
            "x" : <pos>.5,
            "y" : <pos>.0,
            "z" : <pos>.5
        },
        "<second home name>" : {
            "x" : <pos>.5,
            "y" : <pos>.0,
            "z" : <pos>.5
        }
    }

I'm not sure if or when I would enable a second home.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on September 15, 2013, 02:46:08 PM
You can also store data right on the player entity and keep it out of separate files.  (Or you could store it in the playerData easily enough, too.)

playerData.setLocation( "myHome", someLocation )

Storing on an entity is harder in Java but it would then be associated with the character instead of the player... which is probably desirable for the use-cases you talk about.  You can do that in the player data also, but it's a bit more complicated because right now the player data only supports one character and this will eventually be deprecated over using entities.

Hmm... looks like with the generic entity variables thing that I only support int so far.

So, you could do:
playerData.setLocation( "characterInfo.home", someLocation );
(note that if you tried to use the actual home name then you run into problems because a) how would you look it up and b) what if the name changes.  You could use the entity ID but things start to get complicated.)
The above will probably break when I support when I support multiple characters per player.

Or if you want to use the entity variable support (that only supports int right now but that may work for you), you could do something like:
Code:
EntityData ed ...
EntityId playerEntityId ...
LocalVariables vars = new LocalVariables(ed, playerEntityId);
vars.setInt( "home.x", x );
vars.setInt( "home.y", y );

...or something.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on September 15, 2013, 03:22:12 PM
I have been trying to figure out how this is null for quite some time, because I am getting fed up about asking you about every last thing.

Vector3f location = pos.getLocation() is null from this set:
Code:
EntityId playerEntity = player.getPlayer();
GameSystems systems = player.getSystems();
EntityData ed = systems.getEntityData();
Position pos = ed.getComponent(playerEntity, Position.class);
Vector3f location = pos.getLocation();


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on September 15, 2013, 03:53:23 PM
If you get an NPE  on this line:
Vector3f location = pos.getLocation()

then pos is null.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on September 15, 2013, 04:28:45 PM
I knew at least that much, I always say I am not going to rush, but I always end up doing so. I used to actually write my problems descriptively and neatly on the bukkit forums, I don't know where I went wrong.

I see we have taken the PlayerEvent.getContext() into a "player" variable

EntityId playerEntity = player.getPlayer() for the entity, not null
GameSystems systems = player.getSystems() to get the game systems, not null
EntityData ed = systems.getEntityData() to get the entity(player)'s data, not null
Position pos = ed.getComponent(playerEntity, Position.class) takes two parameters, (EntityID, Class), SHOULDN'T be null ~ but is
Vector3f location = pos.getLocation() gets the three floats for the x,y,z; null because pos is null.

Where did we(you) go wrong..?


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on September 15, 2013, 04:35:00 PM
Hmmm... player must not have a position.  I sort of forget the kind of messed up way that players are dealt with differently.

So the real solution is more complicated and will break for sure in the next version.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on September 15, 2013, 04:42:07 PM
Hmmm... player must not have a position.  I sort of forget the kind of messed up way that players are dealt with differently.

So the real solution is more complicated and will break for sure in the next version.
Okay :P; and when I said we(you) I was just messing around, so if I made you upset, sorry about that.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on September 15, 2013, 06:43:22 PM
I do have a question involving the API, compared to the 20120627 build API, about how much better/easier would you say the newest API is, and does it still have the same base functionality (like when you register event types with the EventDispatcher)?


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on September 15, 2013, 08:27:19 PM
I do have a question involving the API, compared to the 20120627 build API, about how much better/easier would you say the newest API is, and does it still have the same base functionality (like when you register event types with the EventDispatcher)?

So far:
-event dispatcher is exactly the same
-entity-related stuff is exactly the same

...pretty much everything else is changed or will be different.  I have better ways of doing stuff now so I get to clean some things up that were convoluted before.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on September 18, 2013, 04:47:16 PM
Closures..
ScriptedAction action = new ScriptedAction(String group, String name, Closure closure);

I have been having the hardest time with this, all I know are closures in groovy for things like files:
Code:
File file = new File("file.txt")
file.eachLine { line -> //Closure initiated.
    //do stuff.
}

Then the definition for closures (computer science):
Quote
In programming languages, a closure (also lexical closure or function closure) is a function or reference to a function together with a referencing environment—a table storing a reference to each of the non-local variables (also called free variables or upvalues) of that function.[1] A closure—unlike a plain function pointer—allows a function to access those non-local variables even when invoked outside its immediate lexical scope.

Basically, it is a method that is in a way "hidden", I believe, since whenever I put a println within the eachLine function in groovy, it doesn't print out, but yet I still get the information from within the eachLine function.

How would I use the Closure for this type?

****EDIT****

This is my current code, and the interface ActionParameter is a completely empty class..
Code:
public void newEvent(EventType<PlayerEvent> type, PlayerEvent e) {
ActionParameter actionPar = new ActionParameter() {
};

ScriptedAction action = new ScriptedAction("testGroup", "testName", (Closure) actionPar);
action.setType(ActionType.Block);

ActionManager actionManager = new ActionManager();
actionManager.addAction(action);
}


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on September 18, 2013, 05:58:54 PM
Scripted actions are for scripts.  If you are not using scripting then you would not use a scripted action.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on September 18, 2013, 06:24:07 PM
Scripted actions are for scripts.  If you are not using scripting then you would not use a scripted action.

Fail :P


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on September 18, 2013, 06:31:54 PM
Okay so anything within the "scripts" package will deal with external scripts, correct? (I just have to make sure)


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on September 18, 2013, 09:00:02 PM
Okay so anything within the "scripts" package will deal with external scripts, correct? (I just have to make sure)

Yes.  I tried to pick a name that made sense.


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: Michael on September 29, 2013, 08:29:41 AM
This has been bothering me for quite some time with getting the location; how is it that with the groovy scripts you can grab the location without the position being null, but yet in java it is null?

Is it just how you set it up within the script package?


Title: Re: Paul, API: Info/Allow Suggestions?
Post by: pspeed on September 29, 2013, 12:02:22 PM
This has been bothering me for quite some time with getting the location; how is it that with the groovy scripts you can grab the location without the position being null, but yet in java it is null?

Is it just how you set it up within the script package?

Since I feel like I kind of said this once already...

The player does not have a Position component.  There is no Position component on the player.  Other entities have Position components but not the player.

That's why the player doesn't have any position.  Players are dealt with differently than other objects in the version you use.

The more complicated solution that breaks for sure with the next version is already embedded in the groovy scripts included with the game... and it is different on single player and multiplayer.  But if you hunt down the getLocation() definitions you can find it.

I have a little trouble dumping support into the Java API because it's not a defined API, will break for certain with the next version, and I spent a lot of time making an easier API already that is less likely to break.