Posts by red51

If a user has the "UnkownPlayer" name, it indicates that no connection to the HIVE server was possible (in this case the game runs in "offline mode"). In most cases a firewall or antivirus program is blocking the connection, what firewall/antivirus program do your friend use exactly? She should try to put Rising World (the "risingworldx64.exe" in steam/steamapps/common/Rising World and the "java.exe" in steam/steamapps/common/Rising World/java/bin) on the exception list

Quote from Miwarre

At the very minimum, I would qualify as a cave anything which has air block(s) below solid blocks

That would work - as long as this definition of a cave is sufficient.

Quote from Miwarre

If you want to stick to a more strict definition, which requires no openings, then some 'winding' algorithm is probably needed to detect the closure, which, in 3D is not simple

One could calculate the gradient at a certain position. This way one could detect at least steep caves (as long as it's not getting confused with mountain walls).

Quote from Miwarre

I suspect only the visible/nearby chunks are normally generated, not subterranean chunks (until someone digs or flies to them)

Every chunk that has been modified will be generated, so even if no player is nearby, the world.getChunk(x, y, z) method will return a chunk object (or null if no chunk was generated). Basically the server is able to generate a chunk at any position (independent of the players), we just need a convenient way to do that.
We can either:

• change the world.getChunk(x, y, z); method, so it always returns a chunk, even if it's necessary to create a new chunk
• add a new world.createChunk(x, y, z); method which creates a new chunk and returns the newly created chunk

Quote from zfoxfire

a cave would be anywhere your position is below the known surface level of that postion and chunk

That would also work of course The surface is basically what you see in the distance (the LOD chunks). So indeed, an opening in the terrain or a ravine isn't necessarily below the surface.

Quote from zfoxfire

assuming the id values behind the cave wall are actually air

Hmm... what do you mean exactly? Of course the inside of a cave is filled with air, but everything else (below the surface and behind cave walls) is solid rock

It's not less secure, a plugin can at least cause no harm this way. It's just a little bit awkward
And it may be spooky for the player, since it would be handled as a regular command input. If the API sends an invalid command, the player will see the "Command not found" output in the console (if the API sends several invalid commands to the player, the player may be confused about all the "Command not found" outputs, or even all the "ghost" confirmation outputs).

But if this feature is required, we can implement it of course I just thought the approach with the enumeration (I've mentioned at the end of the post) might be more suitable (it would be the same effort to implement it).

It's fine to create a single topic for these two points

Quote from Miwarre

a World3DModel::SetInteracts(boolean) method to activate the possibility to interact with a custom 3D model

Something similar was actually planned, it will be added soon

Quote from Miwarre

a PlayerInteractsEvent to be fired when the player interacts with some object ([F] key)

A "PlayerInteractEvent" will be introduced at least for the custom models. Not sure about regular objects, right now opening up the crafting menu at a workbench is handled clientside. It would be possible to trigger such an event, but it would not be possible to cancel the event (i.e. prevent the player from accessing the workbench)
But if it is really required we could change this behaviour.

Quote from Miwarre

Still, many objects have an inherent size: a Citroën C3 has a definite length/width/height, a table is usually 90-110 cm high, a violin is 56-58 cm long...

At least the scale is always the same for all models: If you create a truck with a length of 8 meters and a compact car with a length of 4 meters, and you import them into the game, the compact car will be half the length of the truck.

There shouldn't be differences between the different file formats, unless a model was exported with a different scale. If you can provide a model I can tell you how much the size differs

Quote from Captian_Cornball

I don't even know what to name the files so the game can read them

Here you find some instructions about how to start: Create a Plugin

And if necessary, here is a description about how to setup your workspace: Getting started

Was ist bei dir denn im Verzeichnis C:\Program Files\Java\jre1.8.0_92\bin? Hast du die 64 Bit Version des JDK und auch der JRE installiert? Lade sonst im Zweifel auch einmal das JRE herunter: http://www.java.com/de/download/manual.jsp (unter 64 Bit musst du "Windows Offline (64-Bit)" herunterladen)

Console commands work this way: There is a set of prepared commands (i.e. "SetTime", "Kick", "Ban" etc., every command has an ID), and every command expects a various amount of arguments ("SetTime" just the hours and minutes, "Ban" the target player, duration and reason etc).
When the player enters a command, the input will be checked (check plausibility, permission etc) and "converted" into an actual command on the clientside and send to the server (i.e. instead of sending something like "goto..." to the server, just a single ID which describes the "TeleportPlayerToPosition" command will be send). Of course the server also does some plausibility checks and also checks the permissions, and if everything is fine, the command will be executed.
There are also several "synonyms" on the clientside (teleporting - for example - can be done by typing "goto", "setpos", "setposition", "teleport"), but the server does not know anything about these synonyms. It just accepts a valid command ID (one of the predefined commands).

Having some behaviour like a real console in the API is a little bit complicated, e.g. a method like Plugin.executeCommand(player, "setplayergroup red51 noob");. To make sure it behaves exactly as the ingame console, it would be necessary to send the command to the clientside, let the client console process the command, and send it to the server accordingly, which is a little bit awkward

Actually it would be better to give access to the predefined set of commands. Maybe an enumeration holding these commands. The function could look like Plugin.executeCommand(Player, Command, String...);, so for example: Plugin.executeCommand(player, Command.SetTime, "9", "30"); //change time to 9:30 a.m
Downside of this approach is the fact that you have to make sure to use the correct arguments
Maybe it also makes sense to move this method to the player, since the server always expects a player to execute a command (would look like player.executeCommand(Command.SetTime, "9", "30"); then). Is this something you're looking for?

What do you mean exactly with "The goal is to support commands which are not possible"?

Quote from PatrickBronke

Super! Aber es wäre auch schön, wenn es auch eine deutsche Erklärung zu den API geben würde, in der JAVADOC! Dann könnte man es auch besser verstehen.

Absolut verständlich, leider ist das aus Zeitgründen nicht möglich. Die Dokumentation wird direkt im Code angelegt, Javadoc sieht allerdings keine Mehrsprachigkeit vor (was auch verständlich ist, sonst würde der code sehr unübersichtlich werden). Vorgesehen ist also, die fertigen Javadoc HTML Dateien zu übersetzen. Wenn wir das machen, kommen wir leider gar nicht mehr voran Es ist ja leider auch keine einmalige Übersetzung, sondern müsste bei jeder Aktualisierung der API bzw. der Dokumentation ebenfalls wieder angepasst werden...

Du musst das Java Development Kit (JDK) installieren, das wird grundsätzlich benötigt um irgendeine Java Anwendung zu schreiben Hier kannst du die neueste Version herunterladen: http://www.oracle.com/technetw…k8-downloads-2133151.html (der Download "jdk-8u101-windows-x64.exe" wenn du 64 Bit Windows hast)

Das kommt in Kürze, das Geschreibe ist nur so enorm zeitaufwändig, darum gibts noch keine dt. Version Vll gibt es in der Zwischenzeit ja einen Freiwilligen der die Übersetzung vornehmen möchte

Actually as @Miwarre suspected, the terrainData array in the Chunk class contains all necessary information to get the terrain id from a certain position (air is always 0). You could also use the surface array in the ChunkLOD class, although it's difficult to find out this way if there is really a cave or not. Here is the question: What is a cave? Or how do you find out that there is a cave? What's the difference between a cave or a hole in the ground, or a ravine for example?

DE: Ich hab das mal in den Diskussionsbereich verschoben, da dies ja eher Wünsche für bestimmte Plugins sind, keine Feature- oder Funktionswünsche
Zumindestens das AreaProtection Skript werden wir als Java Plugin anbieten, sobald die Plugin API für den Server verfügbar ist.

EN: I've moved the topic into the discussion section, since the request section is mainly intended for feature or function requests, not for certain plugin requests
We will at least offer the AreaProtection script as a Java Plugin, as soon as the plugin API is available for the server.

Quote from Miwarre

Assuming the events present in the old LUA framework and currently absent in this preliminary version will be added

Yes, exactly, those events will be added very soon

Quote from Miwarre

There are functions to load a 3D model from disk, which return a ModelInformation object, but no obvious way to place the model itself in the world: did I overlook something?

The ModelInformation object is basically just the reference to the 3D model. The class to create a model in the world is the World3DModel (just like 3D texts etc), you can assign the ModelInformation to it by calling the setModel(ModelInformation) method. Unfortuntely there is a small mistake in the current API: All world elements are just interfaces, that's not intended, they will be converted to classes (so you can create a new instance directly)... this will be changed shortly!
After the change it will probably look like (maybe it will look a little bit different):

//This is only "meta data"
ModelInformation modelinfo = new ModelInformation("C:/Plugin/testmodel.obj");


//Actual world element
World3DModel model = new World3DModel(modelinfo);
model.setScale(2f);  //resize for example
model.setPosition(150f, 42f, 365.25f);  //set to position 150|42|365.25


//Attach to player
Player player = Plugin.getServer().getPlayer("Miwarre");
player.addWorldElement(model);

Quote from Miwarre

Question: if I am not mistaken, it seems the current concept of a script-relative database no longer exists

Oh, that's also something that will be added soon

Quote from Miwarre

A way to issue a console command from a script

That could be added. Maybe create a new topic about that in the plugin section, so this suggestion does not get lost

Quote from Miwarre

The use case is to support commands like setplayergroup which are not possible (yet?) via the regular framework

If it's explicitly about changing the playergroup, that can be done this way:

Player player = Plugin.getServer().getPlayer("Miwarre");
player.setPermissionGroup("moderator");

Quote from Miwarre

1) Which will be the the default scaling factor for custom 3D objects? In other words, a size of 1 object unit, scaled at 1:1, will correspond to which RW world size?

Well, this depends on your modeling program. It's probably not possible to have a 1:1 scale, but the API offers a setScale(float) method to change the size of the model (you can even change the size on the fly, i.e. players will instantly see the change)

Quote from Miwarre

2) There will be some "grace period" for the replacement of LUA scripts with Java scripts? Either a period of coexistence of both frameworks or a period of during which programmers have enough documentation to convert existing scripts before they stop working?

Yes, once the Plugin API is fully available for the server (i.e. once you can load your plugins), the old Lua API will still be supported for ~ 4-6 weeks until it will be removed.
If someone does not get his new Plugin ready in time, just let us know, I'm sure we will find a solution, and we will also help people as much as possible about their plugins.

Quote from Trillnar

I have learned that when Red says "Soon" the update is 3-6 months away

Wow, up to 6 months, where did you get that from?

Quote from zfoxfire

The core of dungeons is structure generation which could take many forms including villages

That's true! Actually the structure generation will be expandable, so new types of "dungeons" can be added in the future. The first release will not contain villages though, but abandoned shacks in the woods, for example

Hi folks!

A preview version of the new Plugin API is now available. You can get an impression on what is possible with the API, and you can also start working on your first plugins.
You find a new section in the forum now, which is dedicated to the Plugin API. You can ask questions or discuss any API related things there, or request new features in the Feature Requests section.

In contrary to the Lua API, a documentation (JavaDoc, which also contains some examples) is also available. In can be downloaded with the Plugin API (you can load it in your IDE and access it while coding), or alternatively you can watch the online version here: https://javadoc.rising-world.net/

Unfortunately you can't add the plugins to your server yet. The servers will be updated within the next weeks, you can take advantage of the time to get used to the new API, or to prepare your plugins. Once the servers have been updated, the old Lua API will still be supported for ~ 4-8 weeks until it will be removed.

Please note that a few events and functions are still missing, they will be added soon. If there is something wrong with the new API, or you have any questions or suggestions, feel free to leave your feedback

Download link: https://download.rising-world.net/api/Pre-PluginAPI.zip

Getting started: Getting started
First steps: Create a Plugin

Hallo Leute!

Eine Vorab-Version der neuen Plugin API ist nun verfügbar. Damit kann man einen Eindruck gewinnen, was mit der neuen API möglich ist, und man kann außerdem mit der Entwicklung der eigenen Plugins loslegen.
Im Forum findet sich nun eine neue Sektion, welche der API gewidmet ist. Darin können Fragen gestellt und API bezogene Themen besprochen werden, oder im Feature Wünsche Bereich neue Features angefordert werden.

Im Gegensatz zur Lua API ist eine Dokumentation vorhanden (JavaDoc, welche auch ein paar Beispiele enthält). Diese kann zusammen mit der Plugin API heruntergeladen (und in die IDE eingebunden werden, sodass sie während des Programmierens angezeigt werden kann), oder alternativ kann hier eine online Version aufgerufen werden: https://javadoc.rising-world.net/

Leider können die Plugins noch nicht im Server eingebunden werden. Die Server werden in den nächsten Wochen aktualisiert, bis dahin kann man die Zeit nutzen um sich an die neue API zu gewöhnen, oder mit den ersten eigenen Plugins zu beginnen. Sobald die Server aktualisiert wurden, wird die alte Lua API noch für ungefähr 4-8 Wochen unterstüzt, bevor sie entfernt wird.

Bitte bedenkt dass ein paar Events und Funktionen noch fehlen, diese werden bald hinzugefügt. Wenn irgendwas mit der neuen API nicht stimmen sollte, oder wenn ihr Fragen oder Vorschläge habt, hinterlasst gerne euer Feedback

Download link: https://download.rising-world.net/api/Pre-PluginAPI.zip

Wenn das Spiel abstürzt, muss i.d.R. im Spielverzeichnis eine "errorlog" oder "hs_err_pid" Datei sein, nur diese können Aufschluss oder zumindstens einen groben Anhaltspunkt geben was da genau vor sich geht. Wenn das Spiel hingegen einfriert (oder sogar der ganze Rechner davon betroffen ist), ist die Ursache ganz woanders zu suchen: Hier können verschiedene Dinge verantwortlich sein, es kann ein Temperaturproblem sein (Rechner überhitzt, vll sicherheitshalber mal Temperatur im Auge behalten), ein Treiberproblem (da dein Grafiktreiber aber aktuell ist könnte es ein anderer Systemtreiber sein, zB der Chipsatztreiber), ein Windows-Problem (...wo soll ich da nur anfangen?^^) oder ein Hardwaredefekt (der Extremfall, natürlich weit hergeholt, aber nicht auszuschließen).

Wenn das Problem auch bei anderen Spielen auftritt, würde das einen solchen Verdacht erhärten. Wenn es nur bei OpenGL Spielen auftritt (zB Minecraft), wäre ein Treiberproblem naheliegend, oder eben ein Windows-Problem.
Ggf. kann die Ereignisanzeige in der Windows-Systemsteuerung einen Hinweis darauf geben, ob evtl. während der Zeit, wenn das Spiel oder der Rechner sich aufgehängt haben, irgendein Fehler aufgetreten ist. Um dorthin zu gelangen, gehe in der Systemsteuerung auf "System und Sicherheit" -> "Ereignisprotokolle anzeigen" unter "Verwaltung" -> Links unter "Benutzerdefinierte Ansichten" auf "Administrative Ereignisse"

Falls du übrigens dem Spiel noch mehr RAM zuweisen möchtest, wie @Deirdre vorgeschlagen hast, kannst du als Start Option in Steam (Rechtsklick auf RW in deiner Steam Bibliothek -> Eigenschaften -> Start Optionen festlegen) "+memory 4096 4096" eingeben (damit werden 4GB Direct- und 4GB Heap-memory zugewiesen).

How do you want to play exactly? Via LAN, i.e. you and your friends are in the same local network, or in other words, live in the same household, or via Internet?

Base class: Plugin

All plugins you are going to create for Rising World have one thing in common: They contain a class which extends the base Plugin class. Usually this is the first step in order to create a plugin.

When extending the Plugin class, you have to override the onEnable() and onDisable() methods. These methods will be called once the plugin has been enabled or disabled. It doesn't matter what code you put into these methods, depending on the structure of your plugin, you can initialize some variables there. It also makes sense to register all events in the onEnable() method (note: it is not necessary to unregister any events in the onDisable(), in general you don't have to care about any kind of "clean up").

Register events

If you want to listen to an event, you have to register it. It's recommendable to register all events you are going to need in the onEnable() method. The Plugin class has a registerEventListener(Listener) method, which expects a Listener. Every event listener has to implement this interface. It is up to you if you want to create separate event listener classes, or simply implement the Listener interface in your main plugin class.

The particular event methods in your listener are determined by its parameter. It is important that your event methods only have a single parameter, and this parameter must be any event object. The name of your method does not matter. Your event methods also need an "@EventMethod" annotation. Like any other annotations you have to put it above your method.

Example:

import net.risingworld.api.Plugin;
import net.risingworld.api.events.EventMethod;
import net.risingworld.api.events.Listener;
import net.risingworld.api.events.player.PlayerCommandEvent;

public class MyPlugin extends Plugin implements Listener {

    @Override
    public void onEnable() {
        //Register event listener
        registerEventListener(this);
    }

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

    @EventMethod
    public void onPlayerCommand(PlayerCommandEvent event) {
        //this method will be called when the "PlayerCommandEvent" 
        //triggers, i.e. when a player enters a command into chat.
    }

}

The "@EventMethod" annotation can take a threading parameter, which determines how the event method will be called:

Let the party begin

You are able to listen for events now, but the real action takes place when accessing the various server, world or player functions. Both Server and World are static class, providing various static methods.
Here is an simple example which outputs the server name, seed and world name once the server is started:

import net.risingworld.api.Plugin;
import net.risingworld.api.Server;
import net.risingworld.api.World;

public class MyPlugin extends Plugin {

    @Override
    public void onEnable() {
        //Show server name
        System.out.println("Server name: " + Server.getName());

        //Show world name and seed
        System.out.println("World name: " + World.getName() + "  seed: " + World.getSeed());
    }

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

}

Here is a more complex Plugin-class which listens for the PlayerCommandEvent (when a player enters a command) as well as the PlayerChatEvent (when a player writes a chat message):

import net.risingworld.api.Plugin;
import net.risingworld.api.events.EventMethod;
import net.risingworld.api.events.Listener;
import net.risingworld.api.events.player.PlayerChatEvent;
import net.risingworld.api.events.player.PlayerCommandEvent;
import net.risingworld.api.objects.Player;

public class MyPlugin extends Plugin implements Listener {

    @Override
    public void onEnable() {
        //Register event listener
        registerEventListener(this);
    }

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

    @EventMethod
    public void onCommand(PlayerCommandEvent event) {
        Player player = event.getPlayer();
        String command = event.getCommand();

        //split the command
        String[] cmd = command.split(" ");

        //check the command, example: teleport command
        if (cmd[0].equals("/teleport")) {
            //check if player provided coordinates
            if (cmd.length == 4) {
                float x = Float.parseFloat(cmd[1]);
                float y = Float.parseFloat(cmd[2]);
                float z = Float.parseFloat(cmd[3]);
                //teleport player
                player.setPosition(x, y, z);
                //send message to player
                player.sendTextMessage("[FFFF00]Teleported to " + x + ", " + y + ", " + z);
            }
            else {
                //inform player that he has to enter coordinates
                player.sendTextMessage("[#FF0000]You have to provide coordinates!");
                player.sendTextMessage("[#FF0000]USAGE: /tp x y z");
            }
        }
        //Exampe: send admin message command
        else if (cmd[0].equals("/adminmessage")) {
            if (cmd.length > 1) {
                //get the rest of the message
                String message = command.substring(14);  //remove the first 14 characters

                //send to all admins, check all players if they are admins
                for (Player p : Server.getAllPlayers()) {
                    if (p.isAdmin()) {
                        p.sendTextMessage("[#FF0000]" + player.getName() + ": " + message);
                    }
                }
            }
            else {
                //inform player that he has to provide a message
                player.sendTextMessage("[#FF0000]You have to provide a message");
                player.sendTextMessage("[#FF0000]USAGE /adminmessage message");
            }
        }


    }


    @EventMethod
    public void onChat(PlayerChatEvent event) {
        Player player = event.getPlayer();
        String message = event.getChatMessage();

        //cancel the event, so the chat message does not show up
        event.setCancelled(true);

        //send your own custom chat message
        Server.broadcastTextMessage("[#4110DD]" + player.getName() + " said: [#FFFFFF]" + message);
    }


}

Final steps

Every plugin needs a definition file. It has to be called "plugin.yml" and belongs into a "resources" folder in your source directory (once you build your plugin, the resource folder will be added to the resulting jar automatically.

Here is an example "plugin.yml" definitions file:

name: MyPlugin
main: net.mypackage.myplugin.MyPlugin
version: 1.0.0
author: <your name>
team: <your team, optional>
description: "Put your description here"
loadorder: 0
license: MIT
website: http://www.myhomepage.com

The most important values are basically the name (the name of your plugin), the main (the path to your main class, including the full package name), the version (it's up to you to choose a version number) and the author (your name or your nickname).

One special setting is the loadorder: It can be used to determine the load order for your plugin. By default, the load order is 0. If all plugins have a load order of 0, they will be loaded alphabetically (so a plugin called "Library" will be loaded before a plugin called "Worldplugin"). If a plugin has a negative load order, it will be loaded earlier (so if "Worldplugin" has a load order of -100, and "Library" has a load order of 0, the game will first load the "Worldplugin"). If a plugin has a positive load order, it will be loaded later. This can be useful if your plugin depends on other plugins and you want to make sure the other plugin is loaded first before. If your plugin acts as a library or framework, it's usually recommendable to set a very low negative load order.

All other values are optional.

To release your plugin, you have to compile it (in Netbeans, for example, you can rightclick on your project and select "Clean and Build" to compile your plugin). The resulting jar file is basically your plugin (you can rename it if you want). Just put the jar file into a separate folder (e.g. you can call your jar file "MyPlugin.jar", and the folder "MyPlugin" accordingly), and move this folder into the "plugins" subfolder in your game or server directory (if there is no such folder yet, just create it). Now start your server or the game, and your plugin should be loaded.