Posts by red51

    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 :)

    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 ;)

    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):


    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) ^^


    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! :thumbup:

    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?

    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... :(


    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 ^^


    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.


    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? ;)

    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.

    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.


    (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:

    Java
    //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);

    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).

    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


    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.


    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^^

    Finally got it to compile!

    Great, congratulations! :thumbup:


    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 ^^


    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).


    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^^

    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 :|

    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") :S


    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)...


    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 :D


    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) ;)

    and all i got was errors

    Errors always have a reason, in this case it was caused by the line numbers which don't belong to the code, as mentioned before.


    Do I really need a main method for this?

    It's better to create a separate topic for these things ;) However, a main method is not needed, unless you want to execute your plugin directly (for testing purposes, for example).


    I guess the next question is... how do i install a plugin once i compile? Do I have to create a individual folder under scripts containing a class or jar file and a configuration xml like the way LUA works? I don't think this was properly explained yesterday

    This wasn't explained yet this we are not 100% sure how the layout for this will be. Basically you just have to put the compiled .jar file into the scripts folder (or more appropriately, into a "plugins" folder). Probably a separate folder will be needed with a configuration file (like the lua scripts), but I can tell you more about this in the next weeks^^

    when in the work-flow event handlers are called? Even assuming somewhere along the flow there is difference between events started server-side (e.g., an NPC spawn) and events started client-side (e.g.: opening a door), are the handler called before the action is carried out, after it or independently (i.e. asynchronously / in different threads)?

    Only serverside events are taken into account. Some clientside interactions like opening the crafting menu, for example, have no communication with the server. Usually the communication only happens when the player actually wants to change something in the world (open a door), or does something that the server has to check (craft an item), or does anything that has an visual effect for other players (change the item in your hands).


    Usually the API events are called before the actual action, so it's possible to cancel the event. Sometimes events can't be cancelled: Some events can't be cancelled for logical reasons (obviously cancelling the "PlayerDisconnectEvent" is not possible), some other events can't be cancelled since they event is called after the actual action (e.g. the new "PlayerKeyEvent").


    The old PlayerQuickslotChange event in the Lua API was an exception: The player does not send a notification to the server when he changes his quickslot (i.e. scrolls with the mouse), otherwise a player could spam the server with packets by torturing his mouse wheel.
    Actually the quickslot is updated with every player sync packet, and if the server sees a difference to the previous state, the event is triggered (of course no chance to cancel it). In this case the event just serves as a "notification".
    If the event would be cancellable (i.e. the player sends a message to the server when he changes the quickslot), the player actually has to wait for the response of the server. This delays the scrolling (e.g. player scrolls but the game only reacts after 0.5 seconds)...
    Is this event needed? Since it steps out of line I would remove it eventually (unless someone needs it).


    Right now every event offers the setCancelled(boolean); method, but I guess it's more convenient to have an interface which is only implemented by certain events (by all events that are actually cancellable). This way you can see if the event it cancellable or not ;)

    There's a tree called a Sakura and I would like to add it to Rising World as a very tiny mod to help me get started on understanding on how to write mods or in this case we call them plug-ins

    Basically this is possible, by "abusing" the custom 3d model feature for this (so as a result, the tree would not behave like other trees, and it's also necessary to place it manually [i.e. provide or calculate coordinates for every tree]), but there is at least no easy way like "editing the biomes definition so it spawns the new trees automatically" :|
    Also creating a new biome is basically possible (you could go through the chunks and replace the terrain, i.e. replace sand in deserts by mud etc), but right now there is no way to "hook" into the existing pipeline.


    However, I do not know if you can register a custom Inventory item (only in-game items are available without hacking) or modify crafting bench items

    Right now this is not possible. It's planned in the long run, but I have no ETA for that unfortunately. It's our intention to have a way to replace existing items and recipes (by new models etc), but also to create own custom items.

    DE: Genau, wir werden eine neue Version des AreaProtection Skripts erstellen. Und natürlich wird auch dieses mal der Sourcecode wieder verfügbar sein, sodass Leute dieses Plugin als "Beispiel Plugin" betrachten können.
    Ich bin mir sicher dass auch ein World Edit Plugin verfügbar sein wird, natürlich kann ich nicht viel zu den anderen Scripts/Plugins sagen, aber ich bin mir sicher dass es mittelfristig auch dafür passende Plugins geben wird (und vermutlich sogar schicker als die alten Lua Scripts) ;)


    EN: Exactly, we will create a new version of the AreaProtection script. And of course the source code of this plugin will be available, so people could use it as an "example plugin".
    I'm sure a World Edit plugin will also be available, of course I can't say much about the the other scripts/plugins, but I'm confident there will be suitable plugins for this in the medium run (and probably even more fancy than the old Lua scripts) ;)