Posts by red51

Quote from Captian_Cornball

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.

Quote from zfoxfire

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

Quote from zfoxfire

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

Quote from Miwarre

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

Hehe no problem Let's shelve this until someone needs this feature^^

Quote from ArcaneDesmond

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.

Quote from zfoxfire

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)

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
  

  
  

  
  

Quote from Captian_Cornball

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.

Quote from Captian_Cornball

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

Quote from Bogus

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

Quote from lenko

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

Quote from Deirdre

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.

Quote from TheMrMik

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

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

Quote from Deirdre

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

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?