Posts by red51

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)

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