Posts by red51

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

    Wie es aussieht handelt es dabei um einen Converter zwischen Lua und Javascript. Bitte Javascript nicht mit Java verwechseln, auch wenn der Name ähnlich ist, sind das zwei gänzlich verschiedene Dinge ;)
    Aber selbst wenn es einen Converter für Lua zu Java gibt: Das bringt einen kaum weiter, da dieser Konverter ja explizit auf Rising World zugeschnitten sein müsste. Irgendwo müsste genauestens definiert sein, welche Lua Funktion nun wie in Java heißt. Wir haben uns bei der Gestaltung der API aber weitgehend an der alten Lua API orientiert, sodass es weiterhin starke Ähnlichkeiten gibt.


    Grundsätzlich unterscheidet sich die Programmierung eines Plugins mit der neuen API nur unwesentlich von der Erstellung eines Scripts für Lua. Es sind eher kleinere syntaktische Dinge, auf die man achten muss, die in Java anders gemacht werden. Beispiele:


    • Bei Lua gab es keine Typisierung, man konnte einer Variable nicht ansehen, um was für einen Typ es sich handelt. Man schrieb einfach nur local meineVariable = ..., was einerseits bequem ist, aber wie gesagt, keine Info darüber gibt ob in dieser Variable nun ein Text, eine Zahl oder ein Objekt gespeichert ist. Bei Java muss explizit angegeben werden, um was für einen Typ es sich handelt. Die "primitiven" Datentypen auf die man sich bei der RW Programmierung konzentrieren muss sind int (ganze Zahlen), float (Kommazahlen) und stellenweise auch byte (ganze Zahlen, die aber nicht kleiner als -128 und 127 sein können) und short (ebenfalls ganze Zahlen, diesmal ist die höchste repräsentierbare Zahl 32767). Darüberhinaus gibt es noch String, was Zeichenketten, also Texte repräsentiert. Es gibt zwar noch ein paar weitere primitive Datentypen, nämlich char, double und long, diese sind fürs Erste aber nicht relevant.
      Natürlich gibt es dann noch eine Reihe Objekte, zB das Player Objekt (was einen Spieler repräsentiert). Das war bei Lua im Prinzip dasselbe, aber man konnte es nicht sehen, da alles von dem universellen "local" verschlungen wurde.
      Bei Java sieht die Deklarierung einer Variable also zB so aus: int meineZahl = 42; oder float meineKommazahl = 42.12345f; (floats haben immer kleines f am Ende) oder String meinText = "Hallo Welt"; oder Player meinSpieler = Plugin.getServer().getPlayer("lenko");.
      Man muss sich merken, dass sich der Variablentyp bei Java niemals ändern kann, d.h. ich kann einer int-Variable niemals einen Text zuweisen, das geht nicht. Ich kann zwar jederzeit einen anderen Wert vom gleichen Typ zuweisen (d.h. der "meineZahl" Variablen kann man ohne Probleme statt der 42 auch jederzeit ein 0, eine -41231, eine 200 oder eine 1 zuweisen), aber niemals ein anderer Typ (int meineZahl = "Test"; führt also unweigerlich zu einem Fehler).
    • Bei Java wird eine Zeile immer mit einem Semikolon beendet, bei Lua ist das optional
    • Wenn man auf ein Array zugreifen möchte, ist der erste Index darin die 0 (beispiel: int ersterWert = meinZahlenArray[0];, nicht 1 wie bei Lua



    I AM using netbeans, I did the setup and I copied and pasted Red's Example and it spit out errors

    The "not a statement" message indicates that there is a syntax error, i.e. something is there that does not belong to the code, or invalid Java code. In your case you copied the line numbers accidentally (1., 2., 3. etc), this just confuses Java. Make sure you don't copy them.


    And If you Don't want to Help DON'T, helping is NOT being a Pompous Ass And telling me to things I've already done.

    Wow.. Please watch your language. Nobody here said anything offensive, and @yahgiggle and @SilverSatin just wanted to help. Of course they can't know what you've already tried and what not (especially since you provided no information about that).

    Könnte man den Server nicht simulieren, so das man die Plugins testen kann, ohne sie hochladen zu müssen ?

    Was bedeutet "Plugins testen [...] ohne sie hochladen zu müssen"?


    Also die jetzige API ist ausschließlich für die, die anfangen wollen neue Scripte zu erstellen

    Genau, wobei der Begriff "Script" eigentlich bei Java nicht mehr passend ist, sondern eher die Rede von "Plugin" sein müsste. Wir haben die API jetzt veröffentlicht damit jeder, der damit arbeiten möchte, sich damit vertraut machen kann und prinzipiell auch mit der Entwicklung seines Plugins loslegen kann. Dadurch, dass direkt eine Dokumentation vorhanden ist, ist der Einstieg deutlich leichter als in die Lua API. In der Theorie können jetzt schon vollwertige Plugins geschrieben werden, die mit dem Serverupdate sofort einsatzfähig wären (natürlich wird in der Praxis ausgiebiges Testen notwendig).


    Red hat sicherlich nicht die Zeit und die Muße uns die neue API zu erklären und ohne spezielle Vorkenntnisse, denke ich, macht das auch wenig Sinn

    Doch klar, hier findet sich eine ausführliche Dokumentation zur API: https://javadoc.rising-world.net/
    Dort sind nahezu alle Klassen und Funktionen beschrieben, in vielen Fällen gibt es auch direkt Beispiele.


    "Die Server werden in den nächsten Wochen aktualisiert"

    Genau, in den nächsten Wochen gibt es erst die Aktualisierung.


    Unser Server
    läuft mit Teleportscripts usw.. Wenn diese nicht mehr funktionieren, kann man den Server eigentlich schließen.

    Keine Sorge, kein Server wird im Regen stehengelassen ;) Besonders Teleportieren gehört zu den einfachen Dingen, ich bin felsenfest davon überzeugt dass es da eine Lösung geben wird.

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

    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.


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


    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

    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.


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


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


    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.

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

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


    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"?

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

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

    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.

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


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

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


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


    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:

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

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


    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.


    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? 8|


    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