Posts by red51

Quote from zfoxfire

If we have access in the API to apply a screen filter then one could be blinded or poisoned by such a plant

Basically you can indeed achieve this by using gui elements. You could create a colored panel which has the same size as the screen. By changing the alpha value you can also have transparency etc

Quote from zfoxfire

I'm thinking about a filter applied to the main viewing area (actual rendered 3d content, seperate from the UI)

Maybe it's worth to consider adding access to various filter effects... but I guess that's something for the long run^^

Quote from Carm3D

I think what I would have to do is make a test model and send it to someone as an .obj or something and then they can walk me though how I would implement it... if that works I would make something more elaborate.

If you have a model ready just let us know, creating a small plugin which loads custom models isn't a big deal Basically even the small example above should work (of course pathes etc. need to be adjusted).

Quote from Miwarre

I am worried! Do you never sleep?

Hehe, sleep is overrated But thanks for caring about me

Quote from Miwarre

But not all plug-in GUI interaction with users needs to be modal; in fact, most of the applications I have in mind would work equally well (some even better) with modeless "dialogue boxes" (well, kind of...).

At least if mouse input is required a modal element would be useful. So the player can't mess up the gui by opening up the inventory at the same time etc.^^ But of course it's also possible (basically that's already possible, with the exception that you can't disable keys yet) to just have a panel which displays some options or instructions (i.e. "Press E to enable the elevator"). In this case it would be up to the plugin to decide when a key input actually has an effect (i.e. only when standing at a certain position).

I've uploaded a new version of the API which provides proper access to the WorldElements, GuiElements and the Timer
The download link is the same, the online javadoc has also been updated.

@Garfield: Das hatte ich mir gedacht, allerdings ist das wie gesagt leider erst bald möglich.

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

Es ist übrigens eine neue Version der API verfügbar, welche nun korrekten Zugriff auf WorldElements, GuiElements und dem Timer bietet
Der Download Link ist der selbe, die online Dokumentation wurde ebenfalls geupdated.

Authentication should work now, sorry again for the inconvenience. If you still run into any problems, please let us know

Unfortunately we are having a problem with the hive server right now. Account creation and login should work again (theoretically), please try again, if it still does not work, please let us know

Es gibt gerade leider ein kleines Problem mit dem Hive Server, wir arbeiten daran. Accounterstellung und Login sollte jetzt aber wieder funktionieren (eigentlich), falls nicht, sag bitte nochmal Bescheid

That's our fault, I'm sorry about that, we are currently working on a solution, should be fixed soon

Bei Java SE handelt es sich um die Standard-Edition, bei Java EE um die Enterprise-Edition. Letztere brauchst du im Grunde nicht, zumindestens nicht wenn du nur normale Java Anwendungen erstellen möchtest oder insbesondere Plugins für Rising World. D.h. in dem Fall ist NetBeans Java SE die richtige Wahl

Quote from Carm3D

How does one go about adding custom objects?

It would be necessary to create a small plugin which loads the model. A simple plugin which creates a custom model at a certain position could look like this (note: currently this code would throw errors, but there will be a minor update for the api in a few hours

package <yourpackage>;


import java.io.IOException;
import net.risingworld.api.Plugin;
import net.risingworld.api.events.EventMethod;
import net.risingworld.api.events.Listener;
import net.risingworld.api.events.player.PlayerSpawnEvent;
import net.risingworld.api.objects.Player;
import net.risingworld.api.utils.ImageInformation;
import net.risingworld.api.utils.ModelInformation;
import net.risingworld.api.worldelements.World3DModel;


public class LoadModel extends Plugin implements Listener{


    //this object holds the information about the model
    private ModelInformation modelInfo;


    //this object holds the texture of the model
    private ImageInformation texture;


    //this is the actual model which will be placed in the world
    private World3DModel model;


    @Override
    public void onEnable(){
        //register this plugin as event listener, so it listens
        //for the "PlayerSpawnEvent" (see below)
        Plugin.registerEventListener(this);


        //the next statements need to be surrounded by a try-catch-block,
        //since the model loading may throw an io exception (file not found etc)
        try{
            //load your model from a path on your harddrive
            modelInfo = new ModelInformation("...somepath/models/myModel.obj");


            //load the texture from your harddrive, dds format is most preferable
            texture = new ImageInformation("...somepath/models/myModel_texture.dds");


            //create the actual 3d model object
            model = new World3DModel(modelInfo, texture);


            //set the world position of the 3d model, in this
            //case we place it at 0 50 0 (x y z)
            model.setPosition(0, 50, 0);
        }
        catch(IOException e){
            //this is executed if the model was not found,
            //or if the harddrive could not be accessed etc.
            //Do some error handling here, in this example,
            //we simply print the stack trace
            e.printStackTrace();
        }
    }


    @Override
    public void onDisable(){
        //...
    }


    //this event is triggered when a player spawns for
    //the first time after connecting
    @EventMethod
    public void onPlayerSpawn(PlayerSpawnEvent event){
        //this is the player we're talking about
        //(the one who triggered the event)
        Player player = event.getPlayer();


        //attach the model to the players game world
        player.addWorldElement(model);
    }


}

Of course this is only a basic example. One could create much more powerful plugins, e.g. a plugin which allows the player to place the model in the world (after typing a command or pressing some keys or whatever)

Quote from Carm3D

I hope I don't have to limit myself to working with small blocks. I would prefer to use more traditional models with a UV-mapped texture.

Hehe, of course not Actually creating a model with a proper uv mapped texture is definitely the best approach.

By the way, your videos are awesome!

Not sure if I know exactly what you mean... there is only one single main class (subclass of net.risingworld.api.Plugin). It doesn't matter if you create several other classes in your plugin which are also derived from net.risingworld.api.Plugin for example, only the "main class" (which needs to be defined somewhere) will be instantiated by the server. Even if you create new instances of your main class somewhere, it's up to you what you do with them (the server doesn't care about them).
Is there something specific you want to achieve, or is this just out of curiosity?

Quote from Miwarre

However, dealing with keystrokes in some specific / special way from within plug-ins might be rather important and it seems reasonable to get as right as possible since the beginning

In general the only options are indeed either clientside scripts, or the client has to ask the server first every time it wants to process a key input. While the first one isn't an option right now, the second one is unfortunately never an option...

Quote from Miwarre

GuiElements might be a primary way to display choices and actions to the player and collect selections from him, replacing the chat command system, which was a God sent so far, but it is a bit clumsy and requires the player to know what to type. As normally there is no mouse cursor in RW, selection in a GUIPanel can only be carried out with keystrokes, which however, when directed to the GUIPanel, should not trigger the 'usual' action (selecting a "{S}ave" button in the panel with {S} should not move backward).

Right now you can't create "modal" gui elements (so any panel, label or image you create will simply be attached to the hud, without an option to interact with it). However, it's our intention to create something like a "modal window" element, once it's displayed on the player's screen, he is forced to interact with it. At the same time no other keys will work (with the exception of the ESC key), but the PlayerKeyEvent will still be triggered (and since the API has full control over the window, you could listen to any key you want, and close the windows whenever you want).
Of course it will also be possible to enable the mouse cursor then, so it's up to you to decide if the player has to interact with the window by pressing certain keys, or if he can actually press buttons or any elements on the window.
Modal windows will be implemented in the medium run, they're not too far away, but right now we need to concentrate on other things first

Quote from Miwarre

Customised key bindings does not seem to me an issue

Yeah, my mistake, of course you define a certain key in your plugin (e.g. key E or Enter or whatever) and it doesn't matter what keybindings the player has, you simply want to disable key E or Enter etc, no matter if it's used for something else or not.

Quote from Miwarre

what about the [MOVE_FORWARD] being kept pressed for 5 secs? How many individual [MOVE_FORWARD] key presses this implies?

If the API listens for the "move forward" key (it can't listen for certain keybindings, just for explicit keys, so in this case probably the W key), the PlayerKeyEvent will be called twice: the first time the isPressed() function returns true, the second time (after 5 seconds) it returns false

Hmm.. what do you mean exactly with "handle several instances of itself running"? The server only loads the plugin once, but of course you can create as many threads as you want (as @zfoxfire mentioned), or use an executor / scheduler, or the "out-of-the-box" Timer class (although it does not provide any kind of parallelism). You can also define your events to be called in a separate thread (by defining the threading type in the @EventMethod annotation).
But something tells me you mean something else?

Ich kann zwar nicht all zu viel zu Eclipse sagen, aber die derzeit (2016) neueste Version ist "Neon" (der Name wechselt jedes Jahr). Hier ist die Downloadseite: http://www.eclipse.org/downloads/packages/
Du benötigst "Eclipse IDE for Java Developers" als 64 Bit Variante für Windows (hier ein Direktlink, sofern dieser funktioniert).

No problem, no requirements to the package name
Actually there might be problems if two different plugins use exactly the same names for their classes and their packages, but I guess there is just a small chance that this happens.

Quote from Miwarre

If this is not set in stone yet, I would speculate that option 2. would allow some better optimisation

Yeah I guess that's probably the best approach.

Quote from Miwarre

(even at the expense of some duplicate call: getChunk() first and then createChunk() if necessary)

That's true, maybe in favor of performance we can add an additional getChunk() method which also takes a boolean parameter which indicates it a new chunk should be created automatically. So in the end, there would be these methods:

//returns null if no chunk exists
getChunk(int x, int y, int z);


//creates a new chunk if necessary, never returns null
getChunk(int x, int y, int z, boolean createChunk); 


//creates a new chunk, maybe even overrides an existing chunk?
createChunk(int x, int y, int z);

Quote from Miwarre

I think @zfoxfire is concerned by the 'airy' appearance of the space between the surface and the cave boundary when you fly in it. But all those in-between block are actually solid, aren't they?

Oh okay, yeah that may be confusing indeed. The game only renders the "transition" between solid and air blocks, that's why the world appears to be "hollow" Actually the hollow space still contains block data (solid rock).

Quote from Miwarre

I am a bit surprised about the need to fix the imports with NetBeans, Eclipse manages them automatically, or suggests the proper import, as soon as you use the implements keyword.

NetBeans also suggests proper imports, if you select a class from the code completion selection, it also adds the proper imports. Alternatively one can use a keyboard shortcut (Ctrl + Space), click on the small lightbulb on the left side (as mentioned above), or use another method. Here is an useful overview of imports in NetBeans: https://netbeans.org/kb/73/jav…odereference.html#imports

Quote from Miwarre

For what is worth, I would greatly prefer a separate sub-directory for each plug-in to be a requirement (with only second-level directories scanned for plug-ins). It avoids any file name clash between the contents of different packages, simplifies the distribution (the distribution ZIP can already include the sub-directory to be directly expanded in the plug-in directory), without any noticeable inconvenient.

Thanks for your feedback! It's true, even to avoid a file name clash it's necessary to have sub directories. Guess it will be similar to the Lua plugins, so there will also be a configuration file. In addition, we could add support for zip files (so people don't have to extract them [of course they can do this optionally], but simply put the zip file into the plugin folder.

Quote from Miwarre

You probably already thought of this: I would suggest using a directory other than scripts for Java plug-ins, to keep the two worlds separate and simplify the transition (and the final clean-up, once the LUA framework will be phased out).

Yeah, there will be definitely a different directory for Java plugins, most likely a folder called "plugins" Especially since the Java plugins can't be considered as "scripts" anymore, so having to put them into a "scripts" folder is a little bit awkward^^

Quote from zfoxfire

Finally got it to compile!

Great, congratulations!

Quote from zfoxfire

one thing missing from the examples that Red posted include was how to set up the import statements for Listener

Yeah the examples don't include the imports. The easiest way to import the necessary classes is to let the IDE handle it (e.g. in NetBeans, when it complains about missing imports, you can click the small light bulb on the left and hit "Add import for net.risingworld.api...." (sometimes other default java packages have classes with the same name, make sure to always choose from the "net.risingworld.api..." packages).
Maybe it makes sense to add the imports to the examples, however, I hope it does not give the impression that exactly these imports are always required

Quote from zfoxfire

its better to select "Java Class" as your project type, not "Java Application"

Bascially that's true, but what do you refer to exactly, the "Java Class Library"? When it gets created it does not contain a class at all, so I thought it's more convenient if there is already a class (optionally you can just remove the main method).

Quote from zfoxfire

Red51 said your probably just drop a jar into scripts or plugins

Yes, probably every plugin will have a separate subfolder, can't say for sure. Of course we're always open for suggestions^^

Quote from Bogus

Mit testen meinte ich, das man die Plugins auf Fehler untersuchen kann. Da dachte ich, man könnte ein Serverumgebung simulieren, also praktisch nur um den Code zu testen ;D

Achso Also Syntaxfehler wird dir die IDE natürlich direkt schon anzeigen, d.h. wenn irgendwo eine Klammer oder ein Semikolon fehlt, oder du irgendwas machst was Java nicht mag (einen Text einer Zahl zuweisen o.ä). Zumindestens NetBeans (wobei ich denke dass Eclipse und Konsorten sowa eventuell auch machen) gibt auch in eingeschränktem Umfang Hinweise, wenn irgendein Aufruf zu einer NullPointerException führen könnte (d.h. wenn du auf eine Variable zugreifen möchtest, die Null ist).

Auf Logik hin kannst du das Plugin natürlich erst prüfen, wenn du es wirklich auf den Server ausführst. Das wird leider bald erst möglich sein

Quote from Miwarre

Not so sure about the "PlayerKeyEvent", though. Of course, it may happen only after the key is pressed, as all events are triggered after the event took place, but what about being handled before the consequent action is carried out?

I know what you mean, but the "PlayerKeyEvent" is an API exclusive event, so nothing happens after this event was called. Unfortunately it is not possible to "cancel" any clientside processing of the keys. Since the API still works serverside, it would require the client to send all key inputs to the server first, and wait for the response. The result would be a very clunky and irresponsive behaviour of the game (for example, every movement key would have a delay depending on your ping, but even a 0.5 seconds delay would make the game more or less "unplayable")

This "player has to send a packet to the server first and wait for the response before processing the input" problem can be avoided once clientside plugins are possible. However, this has a very low priority at the moment, and we're not even sure if we really implement something like this in the long run (since clientside plugins are executed on the client, a malicious plugin could cause a lot of harm)...

Quote from Miwarre

A practical example could be an elevator plug-in I'm porting from my existing LUA script: I would like to use the number keys [0]-[9] to select the destination floor (at least for the first 10 floors) but, after processing the key, if the user is found to be in an elevator, I would like to block the usual behaviour of keys [1]-[5] (quick slot change)

Probably it makes sense to have a method to "block" certain key inputs. Of course the "PlayerKeyEvent" would still be called, but the default clientside key inputs won't be processed anymore. Maybe something like player.disableClientsideKeys(KeyInput.KEY_1, KeyInput.KEY_2, KeyInput.KEY_3, KeyInput.KEY_4, KeyInput.KEY_5);.
This approach unfortunately does not take possible clientside changes of the keybindings into account, so maybe it could use the keybinding from the config.properties file, i.e. something like: player.disableClientsideInput("input_1", "input_2", "input_3", "input_4", "input_5");
Need some time to think about it

More specifically your elevator plugin could block/disable the clientside input (for keys 1-5) when stepping into the elevator (and just listen for the PlayerKeyEvent, which will still be processed), and re-enable the input when the player leaves the elevator (or even while the elevator is moving).

PS: When it comes to the elevator plugin, I highly recommend to have a look at the player.moveTo() method (a similar method will be added for world elements, like models btw)