Eigentlich Manuelles platzieren.Oder? Beides?
Bin mir da auch nicht so sicher 
Beim manuellen Platzieren ist etwas mehr Arbeit erforderlich (den Npc in die richtige Position zu bringen), dafür kann man ihn komplett frei platzieren und ihn überall sitzen lassen... 
Hallo red51 kann man die Npc,s vielleicht mal so spawnen lassen das sie sitzen oder liegen ?? das wäre mal eine gute Sache
Sowas in der Art habe ich tatsächlich schonmal vorbereitet und könnte vielleicht noch ins Update kommen 
Da hätte ich allerdings noch eine Frage an alle, die sich für so ein Feature interessieren würden: Wäre es besser, wenn ein Npc sich automatisch auf den nächstgelegenen Stuhl setzt oder ins nächste Bett legt? Oder soll der Npc nur die Sitzen- oder Liegen-Animation abspielen und man platziert ihn manuell (mit dem Bewegungswerkzeug) zur gewünschten Position? Die erste Variante wäre einfacher zu bedienen, die zweite Variante hingegen würde deutlich mehr Flexibilität bieten (Npc könnte zB überall sitzen, individuellere Sitzposition haben usw) 
Und Wann gibts endlich Spinnen und Schlangenfleisch. Ich würd auch Skorpione essen.
Hehe, Schlangenfleisch könnte es evtl. auch noch ins Update schaffen Was Spinnen angeht, es gibt im Prinzip ein entsprechendes Item (Spinnenbeine), da waren die Pläne aber eher in Richtung Alchemie o.ä.... das wird also leider noch nicht kommen... Für Skorpione habe ich leider noch nichts vorbereitet 
Yes, there is indeed a hard-coded minimum size of 0.01 for construction elements... but I can change it to 0.001 with the next update 
However, if possible, I would recommend using a pane when working with such small widths (a pane provides better performance compared to a block)
So if you do a clean, fresh. totally wipe the server does that give you a new seed?
It depends on whether or not you delete the "Worlds" folder (in the server directory). If you delete it, the server will create a new world based on the seed provided in the server.properties file (the setting called "World_Seed"). If this entry is blank (default), it will create a world with a random seed.
Hey, sorry for my late response! Adding a proper way to add custom items and recipes is definitely still on my radar... but unfortunately I can't say for sure when this will be ready 
But I'll try to put a bigger focus on that soon. The first step will be to sync definitions between server and client, so a server (or a plugin) could at least modify existing definitions (like crafting recipes etc). The next step then would be to add a way to load custom models (and define animations for them etc, which would be probably the trickiest part)
The seed is stored per world. If you reinstall the server, it depends on whether the "Worlds" folder (and the server.properties file) were deleted. The active world is determined by the server.properties file (it's the "World_Name" entry). If that world still exists in the "Worlds" folder, it will still be loaded when starting the server.
If the server.properties file was deleted but the world is still there, just enter the world name there to instruct the server to load it 
Thanks for letting me know! This seems to be indeed a bug 
And it's indeed a bit problematic if players cannot remove the empty item from their inventory again... the only way right now would be to use the "clearinventory" command (if it's not allowed in the permissions you could basically change that, because players could only clear their own inventory anyway)... but maybe I can find another way for the game to fix this automatically
Is it a problem with how Unity Engine works or with how the blocks work in RW ?
The engine does not offer a solution for this (but this isn't specific to Unity), so this is something that needs to be implemented by the game anyway
The problem is that each construction element in RW can have an arbitrary size, position and rotation. If you have a block world like in Minecraft, for example, it's relatively easy to calculate collision for water: a water block can only have 6 neighbour blocks, and they always have a fixed rotation and size (with very few exceptions, e.g things like fence blocks etc). It's also very easy to find out their position because each block always has a fixed position in a grid. In other words, it's blazingly fast to calculate water collisions.
However, calculating collisions with arbitrary volumes (=blocks, spheres, cylinders etc) is mathematically much more complex, especially if these volumes are not axis-aligned, i.e if they have an arbitrary rotation. And if there are thousands or hundreds of thousands of blocks in a chunk, this gets quite expensive.
ok ... hm ... was ist ein kleines bisschen?
Sorry für die späte Rückmeldung, aber das Update kommt auf jeden Fall im April (und das werde ich nicht nochmal verschieben)
Does that mean you want to join a friends game (who owns the Steam version)? Or do you want your player data to be linked to your Steam account, so when joining a server, both the Steam and Standalone version use the same player data?
If it's only happening in multiplayer, it indicates that the server maybe uses a plugin which suppresses this key input Input handling in singleplayer and multiplayer is identical, so if the game properly recognizes the input in singleplayer, it's unlikely that there is a technical issue. Maybe try to join a different multiplayer server (for testing purposes) and see if the key input works properly there
Besser wäre wahrscheinlich sowas wie LowStamina oder CriticalStamina Events bei <25% / <10%, aber ja die Frage wofür ist da berechtigt
Das wäre evtl. denkbar, allerdings auch schwierig, hier passende Grenzen zu ziehen (wenn es bei 25% und 10% ein Event gibt, dann benötigt aber evtl. jemand auch bei 20% oder 50% ein Event usw)
Andere Idee: Wie wäre es mit einer Methode, wo man den Verbrauch deaktivieren und aktivieren kann (Nicht nur für Ausdauer, sondern für jedes einzelne). Vielleicht ist das die bessere Variante.
Das würde auch viele Events vermeiden.
Achso, also das ist grundsätzlich sogar schon möglich (zumindest für Stamina) Mit Player.setMaxStamina() kannst du den Maximalwert an Stamina verändert (Standardwert ist 100). Wenn du das auf einen absurd hohen Wert setzt, dann kommt das einem Deaktivieren gleich. Setze es idealerweise einfach auf Integer.MAX_VALUE. Denke auch daran, zusätzlich noch Player.setStamina() auf denselben hohen Wert zu setzen:
Zwar verbraucht der Spieler weiterhin Stamina, aber er müsste viele Jahre ununterbrochen durchsprinten, damit sein Stamina aufgebraucht wird
Hey, grundsätzlich wäre das möglich, das Problem ist leider nur, dass sich das Stamina sehr häufig ändert... immer wenn man rennt (und auch danach, wenn es sich regeneriert). Das Event würde also extrem häufig getriggert 
Das Spiel kann auch nicht prüfen, ob ein Plugin überhaupt diese Info benötigt (es kann nur geprüft werden, ob zB generell PlayerUpdateStatusEvent verwendet wird, d.h. der Overhead dafür wäre immer da...
Wofür genau benötigst du diese Info bzw. den Änderungshinweis denn? Wahrscheinlich wäre es sonst günstiger, einfach selbst das Stamina auszulesen (Player.getStamina()), evtl. zusammen mit Player.isSprinting() (das kannst du zB mit einem Timer, oder einem weiteren Thread, oder mit dem UpdateEvent machen)
It's difficult to tell what's going on there, but please send a report after loading the world (i.e right when you experience the low fps), maybe it contains more information about what's going on there To send a report, just press ESC and hit the red report button in the lower right corner (maybe also add a brief description like "low fps in old world").
Mit März wird es leider etwas knapp, daher wird das Update ein kleines bisschen nach hinten rutschen.... sorry! 
Denn erst nach der 1.0 kann man Neues einbauen, was zu mehr Verkäufen führt. Die 3rd Person Ansicht ist, wenn ich meine Spielesammlung so ansehe die bessere Wahl als die Ego Perspektive als Fokus auf das Spiel.
Naja, eigentlich können wir auch vor der 1.0 neue Sachen einbauen (und haben wir ja auch gemacht) Was aber eine 3rd Person Ansicht angeht: Ich weiß nicht, wie hoch die Nachfrage danach heute tatsächlich ist. In der Umfrage vor einigen Jahren war die Nachfrage eher so mittelmäßig, aber das kann sich mittlerweile natürlich auch schon geändert haben... eine 3rd Person Ansicht ist aber weiterhin geplant (natürlich optional, d.h. die bisherige Ego-Perspektive bleibt)
Ich muss aber dazu sagen, dass RW als 1st Person Spiel konzipiert ist. D.h. alle Animationen etc. sind mit Fokus darauf erstellt worden. Eine 3rd Person Ansicht wird nicht ganz so perfekt sein wie in einem Spiel, welches von vornherein auf 3rd Person ausgelegt ist (genauso wie in Spielen, die als 3rd Person Game ausgelegt sind, die 1st Person Ansicht meist nicht optimal ist).
Habe ich jetzt irgendwas verpasst?
Gibt es neue Infos zum Update?
Vor kurzem gab es ein kleines Update auf der Roadmap Der wichtigste neue Punkt ist eigentlich der hier (das dauerhafte Platzieren von Items in der Welt, d.h. ohne, dass sie despawnen): https://trello.com/c/vM28SwYs/194-persistent-items
Was definitiv im Update sein wird:
Ein etwas weniger aufregendes Feature wird ein Reparatur-Tool für defekte Welten sein (falls die Welt-Daten zB durch Steam Cloud o.ä zerschossen wurden und nicht mehr vom Spiel geladen werden können). Evtl. wird im Update auch eine testweise Möglichkeit zum Ersetzen von Spieltexturen sein (so ähnlich wie die Texturepacks der Java-Version).
offentlich lassen sich auch alle Gegenstände dann frei platzieren , damit gerade Leute die im Mittelalter spielen auch die Werkzeuge und Waffen an einem Verkaufsstand präsentieren können.
Ja, man wird sämtliche Gegenstände frei platzieren können Im Grunde wird es so ähnlich sein wie wenn man das Item wegwirft, nur mit den Unterschieden, dass das Item einerseits nicht despawnt (und nach dem Neuladen der Welt vorhanden bleibt), und andererseits man es auch richtig platzieren können wird (so wie man jetzt auch ein Objekt oder einen Block platzieren kann).
I hope there will be a feature for water colliding with blocks and a feature for smoke colliding with blocks as well, so we can build chimneys for houses and have waterfalls. The only feature I'm eagerly awaiting is railways and trains.
Unfortunately I have no ETA for water-block-collision... it's a problematic feature anyway... blocks can be freely placed (with arbitrary size and rotation), and there is also no limit to the number of blocks that can be placed, making water collision calculations way too expensive. But it is our intention to make water collide at least with 1x1x1 sized blocks placed in a grid.
Placeable smoke, however, will probably be part of one of the next updates
Dass die Permission beim Verlassen der Area nicht aktualisiert wird ist merkwürdig, evtl. ist das aber auch bereits behoben Ansonsten am besten nach dem Update nochmal melden, falls das weiterhin auftreten sollte.
Das Problem mit Player.getCurrentArea() kann ich aber bestätigen, das sollte mit dem nächsten Update behoben sein
Was zumindest geplant ist ist die Möglichkeit, Schnee über Feuer (in einem Topf o.ä) zu schmelzen, um Süßwasser zu erhalten. An die Tonnen habe ich hingegen noch gar nicht gedacht... hier wäre vll denkbar, dass ein Feuer in der Nähe stehen muss o.ä, damit Schnee/Eis darin auftaut. Ich packe das auf jeden Fall mal auf die Liste
Ja, das würde grundsätzlich auch gehen. Ich könnte einen weiteren Parameter zur Funktion hinzufügen, womit man dann angeben kann, ob nur freigeschaltete Items angezeigt werden sollen. Momentan hat das Spiel das Konzept des "Freischaltens" aber nur für Crafting-Rezepte, die Item-Auswahl hingegen beinhaltet ja alle Items (also auch die, die man nicht craften kann). Wahrscheinlich wäre es dann am konsistentesten, wenn solche Items nur als "freigeschaltet" gelten, wenn der Spieler so eines zuvor schonmal aufgehoben hat?
In Zukunft wäre vll auch denkbar, dass man selbst genau definieren kann, welches Item darin auftauchen würde. Anders als oben beschrieben würde ich vmtl. dann fürs Callback nicht einfach ein Item zurückgeben, sondern eine Art Datencontainer, zB "ItemData" oder "ItemInformation" o.ä (damit man dann später auch dasselbe Objekt als Parameter verwenden kann).
Es wäre auch allgemein sehr schön, wenn es auch eine Methode geben würde, wo man prüfen könnte, welches Item der Spieler freigeschalten hat.
Ja, das wäre sinnvoll Das würde dann eine neue Player.isRecipeUnlocked() Funktion sein (was den Rezept-Status prüft) bzw. alternativ auch Player.isItemUnlocked() (was dann wie bei der Item-Auswahl entweder das Rezept prüft, oder - wenn kein Rezept vorhanden - prüft, ob das Item schonmal aufgehoben wurde.
Sorry für die späte Antwort, aber das kann ich auf jeden Fall mit dem nächsten Update einbauen Man wird dann separat angeben können ob reguläre Items angezeigt werden sollen, und/oder Objekte und/oder Kleidungsstücke.
Für das Callback wäre vmtl. am einfachsten, wenn das Spiel eine temporäre "Item" Instanz übergibt. Daraus würde man dann alle notwendigen Infos auslesen können
