Hier ist die Frage, warum Spieler diese Permission haben. Welche Änderungen habt ihr an den Permissions vorgenommen? Das Beste wäre vermutlich, wenn du mir ggf. einmal den kompletten "permissions" Ordner (aus dem Serververzeichnis) zukommen lässt (ruhig auch per PN, falls du das nicht öffentlich posten möchtest) 
Wichtig wäre ggf. noch zu wissen, ob ihr in der server.properties Datei den Wert von settings_default_newplayer_group geändert habt.
Do you live in the same household? Or do you want to play via internet?
First of all: Starting the "server.jar" directly causes the server to run in the background, this prevents you from starting it up again (since the port is now already occupied). So before doing anything else, please have a look in your taskmanager in the "Processes" tab and kill any "java.exe" or "javaw.exe" processes you can find
Tatsächlich investieren wir momentan etwas Zeit in die Tiere, damit die gröbsten Schnitzer usw. behoben werden. Das ist sogar notwendig und wird für die Dungeons benötigt, da diese einen neuen Bewohner beherbergen werden (beim jetzigen Tierverhalten wäre das aber nicht realisierbar) Ich möchte natürlich nichts beschwören und auch keine Aussage darüber treffen, ob diese Probleme tatsächlich damit bereits behoben werden oder nicht, das wird sich zeigen.
Milch wird aber später erst dazukommen. Vermutlich auch erst nach der neuen Spielerfigur^^
Überschrieben wird ja im Grunde nichts, da der Name aus der Blueprint-Datei ausgelesen wird. Der Dateiname selbst ist da eher zweitrangig (enthält aber einen timestamp, um identische Dateinamen weitestgehend zu verhindern) 
@red51 Weiss nicht, bin halt kein Entwickler, aber ich bin sehr oft auf Github unterwegens. Bei Github sind sehr viele bekannte Projekte, wenn ihr da ein offiziellen Rep hab, könnte man das ganze auch als Werbung für euch benutzen ;D
Also vermutlich würde Github nicht viel Sinn machen (zumal die Dokumentation ja eh bereits als Javadoc vorliegt), da der Sourcecode der API ja auch nicht öffentlich ist (würde auch nichts bringen, da alle Features der API mit dem Server verwurzelt sind, d.h. wenn jemand die API erweitern wollte, müsste er auch den Server abändern)... Wir bereiten aber ein eigenes Git auf unserem Server vor, sodass Leute wunschweise ihre Plugins dort hochladen können.
Vielleicht kann man ja nachher die Plugins in die Steam Workshop "stopfen"
Workshop Support ist auf jeden Fall geplant, kann leider nur noch nicht sagen, wann das genau kommen wird. Allerdings werden die Plugins trotzdem ganz regulär auch im Forum erhältlich sein ( @Deirdre)
Hmm... also grundsätzlich sind gleiche Namen bei den Bauplänen ja erlaubt, beim Löschen sollte normalerweise nur der ausgewählte Bauplan gelöscht werden. Ich habe es nochmal im Singleplayer ausprobiert (also zwei Baupläne mit gleichem Namen erzeugt und anschließend einen davon gelöscht), da funktionierte es eigentlich. Wie ist denn das genaue Vorgehen, um den Fehler zu reproduzieren?
The easiest way is if both of you already have an IPv6 address. Then you can connect to each other without any port forwarding (but both of you have to enter "+ipv6" as launch option for Rising World in Steam). You can find out if you already have an IPv6 address (it's a long address separated by colons) by visiting this page: http://ipv6.whatismyv6.com/
If you don't have an IPv6 address yet, it's indeed necessary to forward your ports (or alternatively use a software like Tunngle or Hamachi). Unfortunately I can't say much about the Netgear Nighthawk router, I found this tutorial, does this work for you? http://kb.netgear.com/app/answ…0NDI2L3NpZC9DWkJqd3hZbQ==
There you have to make sure to forward ports 4254, 4255, 4256, 4257, 4258 and 4259 TCP and UDP. Just enter 4254 as "External Starting Port" and 4259 as "External Ending Port", also make sure that "Use the same port range for internal port" is checked (alternatively enter the same port ranges into the internal fields).
That should do the trick 
I've moved your post to a separate topic (since it's not related to the original topic)
Your server ran out of memory, when starting the server, you will see the amount of memory that's currently assigned to the server in the second line at the beginning of the log/output, it looks like this for example:
Also make sure the 64 bit version of Java is installed. Maybe simply post the full serverlog here, just to make sure^^
You can assign more memory to the server either by changing the "server_memory" value (MB) in the server.properties file (but this only works when starting the server by using one of the startscripts), or by providing the -Xmx memory argument to the java command when starting the server (java -Xmx4096m -jar server.jar to start the server with 4 GB).
Right now there is unfortunately no way to test it 
Currently it's basically just a pre-release, so people can get used to the new API and check out how it works and maybe have a look at the documentation.
But server support (so you can load the plugins into your server) will be available in the next weeks, it won't take too long until it's finally available
I don't recommend spending too much time on Lua, once the new API is fully released, the old Lua API will be discarded after a few weeks. However, if you need something for your server now, and if it's not too extensive, you could simply create a script in Lua. There are some similarities between the Java API and the Lua API, so if you created a working Lua script, converting it to Java won't be that complicated (of course you have to rewrite it, but many functions [e.g. player functions or server functions] are still available in the Java API, and of course the "logic" will still be the same (mostly)^^
Das Problem ist, dass die Sichtbarkeit durch das Wasser abhängig von der Wassertiefe ist. Nach wenigen Metern ist bereits Schluss und es wird nur noch die Umgebung reflektiert. Ich denke da brauchen wir mittelfristig einen besseren Ansatz...
Kurzfristig kannst du die Transparenz des Wassers in der config.properties Datei einstellen. Dazu einfach den Wert "graphic_water_transparency" etwas höher setzen (zB 10.0 oder 15.0).
Jetzt ist es aber langsam auch mal an der Zeit, diesen doofen, nervigen und unnötigen Bug zu beheben 
@zfoxfire: Afaik you can't move your own posts, either tell me which posts you want to move, or simply delete them
@red51 könnte man die Doku nicht in eine git rep stecken dann als offizielle Github rep machen ? Weiss nicht, ob wie viele hier schon mit Github gearbeitet haben, aber denke ist doch die leichteste Option die Doku auch zu akualisieren und man sie auch als Paket downloaden ;D
Also theoretisch wäre das möglich (ein Repository für Plugins ist aber sowieso geplant und auch in Arbeit), aber zumindestens für uns ergibt sich daraus kein direkter Vorteil beim Aktualisieren (wird eh zusammen mit dem Plugin ausgeliefert), auch beim User sehe ich noch keinen richtigen Vorteil ggü. der jetzigen Variante. Aber vll bin ich blind
i wanted to bring this up again ... a git repository would be great for modders have a place to store Their work.
A git repository for modders is in the works, we just don't want to make any changes on our servers while the game is in sale on Steam Probably a git repository may go online next week.
As for the api jar, a maven repository would be better than git
We will think about a maven repository^^
Was ich total hasse wenn ich oben auf Deutsch klicke dann sollte auch alles auf Deutsch erscheinen
Möglicherweise ist bei dir die Sprache noch auf Englisch gestellt? Beim Forenupdate vor wenigen Wochen sind leider einige Benutzereinstellungen auf den Standardwert zurückgesetzt worden, dazu gehört auch die Spracheinstellung. Wie @Skarafass schon sagt, du kannst das in deinem Profil anpassen. Gehe dazu hier hin, klicke auf die Englandflagge, wähle dort Deutsch aus, und drücke unten die grüne "Submit" Schaltfläche, das ändert die Sprache wieder auf Deutsch.
Red51 bitte gebe mir Schritt für Schritt an wie ich das Plugin bearbeiten soll.
Sofern du kein eigenes Plugin programmieren möchtest, ist diese Update erstmal nicht von Relevanz, wie @Garfield schon erwähnte
I agree that it, in the specific case of single-file plug-ins, placing the file in the main "plugins" directory would be easier
That's true. Originally I wasn't sure if this may cause some problems, especially if the plugin ships with some assets or third party libraries. However, I guess it doesn't matter. For assets, it might be a requirement to put them into the jar file. For third party libs, I guess it's no problem if they're in the "plugins" folder, or maybe we add a specal "libs" folder or something like that.
whether to natively support ZIP files or not [...] The ZIP file has to be expanded, sooner or later
Well, basically ZIP support isn't necessary. And yeah, the server has to unzip it anyway. Plus there won't be any advantages in terms of disk space usage. Originally it was intended to just have an easier way to "install" a plugin in singleplayer. Some people struggle to unzip a ZIP file (this happened several times in the past), so it would be easier for them if they move the ZIP file (it's still better to upload plugins in a ZIP file) into the plugins folder. But I guess it would be more preferable to have an installer for that...
the first time the application finds a "new" plug-in ZIP in the standard "plugins" directory, extracting into a specialized destination directory. This raises some issues as well, though.
Yeah that's true. I guess having an "auto-unzip" feature may cause more problems than benefits.
------------------------------
So to recapitulate this, I *guess* the best approach is having all plugin jars just into one single folder (the "plugins" folder), third party libs (I think most plugins don't use any third party libs at all) may go to a "libs" folder, and ZIP file support will be discarded (maybe we could put an installer on our todo-list).
if a plug-in needs to monitor a certain set of keys for its own purposes, it is practically certain that those keys should not carry out the in-game actions bound to them.
No doubt, but it's important to have an efficient way to do that without too many disadvantages (or uncomfortable behaviour for the player).
Is this what you mean by Player.disableClientSideKeys() ?
Yes, exactly. For example, if you call player.disableClientSideKeys(KeyInput.KEY_W, KeyInput.KEY_A, KeyInput.KEY_S, KeyInput.KEY_D), the W, A, S and D keys will be disabled on the clientside (probably most people use these keys for player movement, so in this case, the player would be unable to move his character anymore). Or if you call player.disableClientSideKeys(KeyInput.KEY_I), the player can't press I anymore (or more precisely, it has no effect, e.g. if the player uses this key to bring up his inventory, he can't do that anymore). This state lasts until you call player.enableClientsideKeys() or something like that.
However, the "PlayerKeyEvent" in the API will always be called, there is no way to disable that (with the exception of unregistering keys, or by setting the "listenForKeyInput" to false).
This would both avoid any unnecessary forwarding (less traffic)
I guess this way we can already expect the least amount of traffic. Calling player.setListenForKeyInput() is very "cheap" (just a few bytes the server has to send to the client), however, it's not necessary at all. It is only useful if your plugin registers a lot of keys (or some keys which are frequently pressed, like WASD etc), but only need them in certain situations - this way you can enable or disable the "listenForKeyInput" when needed, so the player does not always spam the server with his key inputs (every single key input is more "expensive" [still quite cheap] than a "setListenForKeyInput" packet)
I can speculate that, normally, listening is off and key strokes can only be examined after the fact and not cancelled; while, by turning listening on, once key strokes are forwarded to the server, they can be cancelled at the expenses of a slower reaction time. Near?
It just determines if key inputs (only keys which were registered by calling Player.registerKeys(int... keys)) should be forwarded to the server or not. This way you can register all keys your plugin needs on startup, and enable/disable listening only when needed (in order to save some traffic, so the player does not send any unnecessary key input packets to the server).
Having the ability to cancel key inputs (i.e. as mentioned before, each input has to be verified by the server first) is unfortunately no option. Of course one could say "let the plugin decided", but even on a fast server with a good ping you get a noticeable delay (especially the input the player expects a direct response, like movement, scrolling etc). In the end, players will blame us and complain about "all my input is delayed" 
The most performant option is probably indeed an Player.disableClientsideKeys() method^^
Why do I get this when I google "red51"?? 
Do you access the side door/hatch? Not the hatch on the back (this one does not work). When looking at the small hatch, your crosshair will turn into a chest icon. Pressing your interaction key (by default key F) opens the hatch, now you can place coal or lumber in it (hold it in your hand while looking at the hatch/hole, then press the secondary mouse button).
Theoretically: Yes. Practically: I recommend to look out for other models These models were obviously never designed for games, they have way too many polygons. The trees have between 70,000 and 90,000 triangles, the ivy even has more than 900,000 triangles 
This is way too much for a game, or more precisely, way too much for a single plant in a game. Just as an example, the trees in Rising World have between 1000 and 7000 triangles.
Most of the online 3d pages offer models which are mainly designed for rendering purposes (so they often have many polygons). When rendering a video or a screenshot, it does not really matter how many polygons the scene has, even if the rendering process takes a whole day (remember that the game has to render the scene multiple times per second, if you have 60 fps ingame, the scene is rendered 60 times a second).
