Yes, of course you could edit it outside the game 
This post describes the blueprint data format: RE: Blueprints Format (Unity)
But as mentioned by Yarofey , alternatively you could use BlueLib, made by paulevs , which already does the work for you 
Having something like suction tubes for item transport sounds interesting, we'll definitely take this into consideration when adding electricity 
Water pipes are also on our to-do list, but unfortunately I have no ETA for that yet...
A long time ago there was a suggestion about voxel-based GI SEGI, but it was not compatible with HDRP and M1. Now someone made a similar solution for modern Unity and HDRP - Lumina, probably it can be used as alternative to SEGI?
It looks promising, but unfortunately the asset has a few limitations... it only works with DirectX 12 (according to the author, this is due to a Unity bug, although it seems to be a limitation by design instead), which introduces a few issues (as mentioned above in my 1st response)... I must admit I'm also a bit reluctant to rely on the asset store for this...
However, I'll definitely keep a close eye on this. Maybe we will give it a try after the store page update
Gibt es dann auch Wassertexturen?
Wahrscheinlich nicht, denn Wasser würde voraussichtlich nicht über reguläre Bauelemente umgesetzt, sondern als technische Objekte (ähnlich wie der Rauch in der Java Version). Die wären natürlich auch skalierbar, andockbar usw. Aber es ist so oder so nochmal eine Thematik für sich.
was ich in naher Zukunft noch sehr fein finden würde, wäre wenn man beim Rotieren von langen Elementen (wie wie Geländerstangen) die Möglichkeit hätte erst die Stützpfeiler zu setzen (das macht man ja sowieso als erstes) und anschließend die "Stange" an einem Stützpfosten fixiert und auf den nächsten hinunter/herauf zieht mit der Maus und von dort aus das das gleiche von vorne - das wäre sehr praktisch und würde auch glaube eleganter und schicker aussehen wenn man Pfade auf unebenen Gelände positionieren will - der Boden steigt und fällt ja unterschiedlich stark - das ist derzeit nur fricklig umzusetzen und daher laß ich solche Geländer weg. Wäre auch für den Gehegebau auf unebenem Gelände seeeehr von Vorteil.
Also am ersten Andockpunkt fixieren mit STRG wie bisher und dann die Winkel/Rotation zum nächsten Andockpunkt mit der Maus ziehen.
Wenn ich das richtig verstehe möchtest du effektiv eine Möglichkeit haben, das Bauelement mit der Maus zu drehen? Bspw. so wie auf dem Bild, dass es irgendeinen mit der Maus greifbaren Punkt auf der jeweiligen Fläche des Blocks gibt, womit du ihn anpacken und verschieben kannst (und das Bauteil sich entsprechend ausrichtet)?
Da die derzeitige maximale Elementgröße im Survivalmode auf auf 5x5x5 begrenzt ist habe ich da noch eine Idee. Ob und wie aufwendig das umsetzbar ist kann ich nicht beurteilen: 5 x 5 x 5 ergibt insgesamt 125 1x1x1 Blöcke. Wenn man nun die Größenbegrenzung nicht auf 5 je Achse festlegt sondern in Summe auf 125 (oder einen anderen Wert), so könnte man auch längere Strecken ohne Frickelei überbrücken.
Ja, das ist durchaus nachvollziehbar. Die Begrenzung ist eigentlich nur da, um keinen zu großen Vorteil durch Materialersparnisse zu bekommen... wir haben tatsächlich ursprünglich eine dynamische Größenbeschränkung eingebaut (die dann eher nach Volumen des Blockes ging statt nach festen Werten), doch das war insgesamt etwas irritierend: Angenommen wir haben ein Volumenlimit von 10 "Kubikblöcken"; wenn ein Block nun zB 1 Block breit ist, kann man ihn noch 10 Blöcke lang machen, doch danach kann er nicht mehr verbreitert werden - um ihn zB 2 Blöcke breit zu machen, müsste die Länge erst wieder auf 5 Blöcke reduziert werden. Klingt zwar erstmal nicht so dramatisch, es war allerdings immer wieder mal irritierend, dass ein Block plötzlich nicht mehr skaliert werden konnte (um danach zu realisieren, dass das Volumenlimit erreicht wurde).
Ich weiß nicht, ob es ggf. hilft, wenn dem Spieler zB einfach eine Nachricht angezeigt wird, warum der Block nicht mehr vergrößert werden kann. Oder man ignoriert das Argument mit der Einschränkung der Materialersparnis und erhöht einfach allgemein das Limit im Survival? Ich weiß nicht, wie die meisten Survival-Spieler das so sehen?
Wie wäre es mit einer Zusatzzeile in der Config die die Bau-Begrenzung im Survival aufhebt?
Das könnte man theoretisch machen, nur im Multiplayer würde das nicht gelten bzw. vom Server festgelegt... weiß nicht, ob das ggf. irritierend sein kann, wenn es sich auf jedem Server möglicherweise anders verhält? 
- auch der Befehl size ist auf 32 Limitiert
Tatsächlich handhaben wir 32 als maximale Größe aus einem Grund: Das ist die Breite eines Chunks Bauelemente sind immer chunkgebunden, d.h. erst beim Laden des Chunks werden auch die Bauelemente geladen. Technisch können Bauelemente zwar beliebig groß sein, aber bei großen Bauteilen (zB 100 Blöcke breit) wird das etwas problematisch, denn sie werden trotzdem erst geladen, wenn ihr entsprechender Chunk geladen wird. Das kann dazu führen, dass plötzlich Bauteile direkt vor meiner Nase auftauchen, oder dass ich plötzlich in einem Bauteil drin stehe (weil der zugehörige Chunk u.U. weiter weg liegt, das Bauteil aber durch seine Größe bis in mehrere Nachbarchunks ragen kann). Bei kleinen Sichtweiten ist das besonders problematisch.
Ein anderes Problem ist aber auch die Physik-Engine: Ein Block hat immer die gleiche Anzahl an Polygonen (egal ob 0.01x0.01 oder 100x100 groß). Wenn ein Polygon bzw. Dreieck aber zu groß wird, dann werden Kollisionen nicht mehr zuverlässig erkannt.
Ist das eigentlich gewollt, das es diese Absätze in Höhlen gibt, wo man nur wieder rauskommt, wenn man sie weghaut ?
Was für Absätze meinst du genau? Kannst du davon evtl. einen Screenshot posten? Oder beziehst du dich allgemein darauf, dass manche Höhlenabschnitte so steil sind, dass man buddeln muss, um wieder rauszukommen?
1. suggestion to introduce an undo-tool for placed building elements and objects
There are actually a few additions for the undo tool on our to-do list, including covering of element placement and also an "undo history" (where you can individually select which undo action you want to perform). Unfortunately I have no ETA for that yet 
2. suggestion to be able to delete only specific block ID in the selected area
This would be indeed useful, I'll try to get that ready with the next update
Dann muss sich aber scheinbar etwas in den letzten Tagen geändert haben? Laut deinen letzten Reports dauerte das Laden der Blaupausen zuletzt ca. 3-4 Sekunden. Zumindest ist das die Zeit, die das Spiel unmittelbar benötigt, um die Blaupausen zu laden und die Liste "zusammenzubauen". Danach vergeht noch etwas Zeit, die Unity benötigt, um die UI zu aktualisieren - aber auch das dürfte eigentlich max. genauso lange dauern, also sprich insgesamt sollten in dem Fall nicht mehr als 6-10 Sekunden vergehen. Ist an sich schon recht lange, allerdings bei über 6000 Blaupausen. Kamen in den letzten Tagen denn nochmal bedeutend mehr Blaupausen hinzu?
Grundsätzlich werden die Blaupausen standardmäßig auch nur dann neu geladen, wenn das Betriebssystem eine Änderung am Ordner erkennt (was allerdings auch dann der Fall ist, wenn eine Blaupause gelöscht oder eine neue Blaupause erstellt wurde). Wurde keine Änderung vorgenommen, sollte es bei so vielen Blaupausen max. 1-2 Sekunden dauern, bis das Fenster verfügbar ist.
Wenn ansonsten das Laden nochmal so lange dauert (also bedeutend länger als ein paar Sekunden), sende am besten einen Report (nachdem das Problem aufgetreten ist, also unmittelbar nachdem das Öffnen lange dauerte).
Nur um Missverständnisse zu vermeiden: Du beziehst dich mit "Laden von Blaupausen" auf das Öffnen der Blaupausen-Übersicht (wo eine Blaupause ausgewählt werden kann), oder meinst du damit etwas anderes?
Aber was solls , ich nehme mal an damit das auch sehr realistisch ist mit dem segeln wird es auch noch wellen geben oder ? also so wie in Valheim
Richtige Wellen sind definitiv noch geplant, dafür wird es aber in Zukunft eher ein separates Update geben. Wir haben da schon dran gearbeitet und die ersten Ergebnisse machen m.M.n. auch wirklich was her (deutlich schöner als der bisher sehr stille Ozean), aber in RW ist das leider etwas aufwändiger umzusetzen: In Spielen wie Valheim ist es meist so, dass das Wasser bzw. der Ozean einfach eine feste unendliche Fläche entlang der Karte, sprich überall vorhanden ist (auch unter dem Terrain). Das macht viele Dinge wesentlich simpler, doch RW kann das so leider nicht umsetzen (da es ja Höhlen etc gibt, die tiefer als der Meeresspiegel reichen, außerdem kann Wasser frei platziert und entfernt werden), daher muss Wasser in RW volumetrisch generiert werden. Das erhöht die Komplexität aller Wasser-bezogenen Features leider enorm (=zeitaufwändiger umzusetzen)...
Ich muss aber zugeben, dass richtiger Wellengang gerade i.V.m. dem Segelboot deutlich mehr Spaß macht als ein stiller Ozean. Daher würde ich das in der Priorität wahrscheinlich etwas nach oben setzen^^
Was realistisches Segeln angeht: Es wird durchaus einen gewissen Detailgrad geben, das Segeln ist aber tendenziell bewusst eher im Arcade-Style gehalten. Streng genommen wäre das Segel auf dem Screenshot auf Trello bereits falsch ausgerichtet (auch wenn es intuitiv korrekt aussieht). Ich habe Valheim nie gespielt, aber allgemein streben wir beim Segeln eher ein Verhalten wie in Sea of Thieves an (was m.E. eine sehr tolle Segelmechanik hat, wenn auch unrealistisch).
Wenn aber nach dem Update aus der Community das Feedback kommt, dass lieber ein realistisches Segeln erwünscht ist, können wir das sogar relativ einfach ändern (unsere Segel-Mechanik ist da eigentlich recht flexibel - aufwändiger ist da eher das Modell des Bootes anzupassen)
oder man nimmt sich einen Arduino pro micro, einen oder mehrere Schalter und läßt automatisiert laufen/schwimmen/reiten... hab meine automatisierte Garnproduktion (siehe hier) um nen Schalter und etwas Code erweitertet und bin dann mit dem Pferd automatisiert nach Norden zum nächsten Biom geritten
Ist natürlich eine sehr elegante Lösung, wahrscheinlich aber für den Durchschnittsspieler nicht unbedingt praktikabel
To put it into context: In a world filled with islands it would be absurd not to have a proper sailboat.
I agree that sailboats (and also bigger vessels) are much more important in the new version than in the Java version 
Of course it would have to continue moving forward when under sail (without needing to use keyboard or mouse) until it meets an obstacle or until sail is lowered.
Yes, if the sails are set, you will be able to leave the seat and the boat will still continue to move forward (until you lower/furl the sails again)
Bei dem einen Elefanten ist mir etwas aufgefallen. Dieser hat einen richtigen Knubbel auf der Nase. Der Übergang vom Kopf zum Rüssel beim Elefanten ist fast nahtlos, da gibt's eine kleine Einbuchtung nach hinten, aber einen Knubbel hat ein Elefant da nicht. Screenshots in Steam zeigten den Elefanten in Frontperspektive.
Wir können das momentan aus Zeitgründen leider nicht ändern, aber nach dem Storepage-Update könnten wir uns theoretisch nochmal ransetzen
Wird immernoch an Wölfen, Frau, Klamoten, Segelboot und Karte gearbeitet, oder baut man noch etwas in das Update ein?
Wir arbeiten noch an diversen anderen Sachen (zB Banditen), ich kann aber nicht sagen, was fürs Update genau reinkommt - das hängt davon ab, was rechtzeitig fertig wird Garantiert reinkommen wird die Karte und weibliche Spielerfigur, mit 95% Wahrscheinlichkeit reinkommen werden Wölfe und Terrain-Materialien (wie von Deirdre erwähnt), zu 80% das Segelboot und zu vll 50% Banditen. Ansonsten gibts aber auch eine ganze Reihe an kleineren Änderungen und Neuerungen. Die Plugin API wird haufenweise neue Sachen erhalten (auch wenn das für die meisten Spieler eher weniger relevant ist).
Sorry for my late response! The old Java permissions are indeed no longer compatible with the new version... The server is shipped with an example permission folder ("Permissions.Example"), but if the Java server was installed before, the old Java permissions folder still remains. In this case, it's either recommendable to either delete the server (and all files) first, then re-download the Unity server, or alternatively delete the permissions folder and download new permissions from here: Permissions [New Version]
The linked topic also contains an overview of all permissions for the new version
When it comes to admin permissions, please bear in mind that actual admins (i.e. all admins added to the server.properties file) are not affected by permissions by default (admins always have full permissions by default). To change this behaviour, you have to set Permissions_AdminsFullPermissions to false in the server.properties file (but make sure to assign a proper permission group first, otherwise you may no longer be able to execute commands).
Muss es eigentlich zwingend java sein, oder gehen auch verschiedene c Programmierspachen?
Welchen konkreten Nutzen möchtest du damit verfolgen? Das Spiel selbst besteht in kompilierter Form ausschließlich aus C++ Code, d.h. wir hätten die API statt Java auch in C++ anbieten können, aber das wäre recht unklug gewesen, da C++ einerseits komplexer und weniger verzeihend als Java ist, andererseits C++ Code "gefährlicher" ist (zB kann falscher Memory-Zugriff unvorhergesehene Fehler mit sich bringen, sodass die Fehlersuche wesentlich schwieriger ist). Zudem würde das wahrscheinlich dazu führen, dass noch weniger Leute mit der API arbeiten (durch den allgemein höherene Schwierigkeitsgrad von C++) Vorteile hätte es stattdessen nicht gebracht - zwar ist C++ minimal performanter als Java, aber das fällt in der Praxis nicht wirklich ins Gewicht.
Alternativ wäre noch eine Skriptsprache wie Lua denkbar gewesen. Skriptsprachen sind meist noch "einfacher" als klassische Programmiersprachen (wie zB Java). Hier gibts aber viele Einschränkungen, u.a. in puncto Multithreading, was die Performance des Spiels dann doch zu sehr geschmälert hätte. Python wäre sonst
Ja, das könnte man mit JNI machen.
Das ist tatsächlich die Art und Weise, wie das Spiel mit der API kommuniziert
könntest du den Font-Dialog auch zur Verfügung stellen?
Also den Oberen Block der Schilder
Im Schlimmsten Fall würde mir die Font auswahl reichen
Theoretisch könnten wir die Font-Auswahl einbauen (also als separater Dialog, so wie zB der Colorpicker) Der ganze obere Block der Schilder ist aber leider etwas schwieriger, da das kein einzelnes Element ist, stattdessen sind das mehrere einzelne Elemente...
Wofür ist das Ray Tracing denn gut ?
Der in meinen Augen einzige wirkliche Vorteil von Raytracing ist die Möglichkeit, "Global Illumination" umzusetzen, sprich indirektes Licht. Derzeit ist es so, dass Lichtquellen im Spiel Oberflächen nur direkt anstrahlen können. Der Lichtstrahl wird nicht weiter reflektiert. Theoretisch wären dadurch alle Flächen, die nicht direkt angestrahlt werden, pechschwarz - da sowas aber äußerst bescheiden aussieht, verwendet das Spiel eine Art "Fake" indirektes Licht. Nachteil ist nur, dass dadurch sämtliche Flächen eine Mindesthelligkeit aufweisen - dadurch ist auch ein Raum, der komplett geschlossen ist und kein Fenster hat, nicht komplett dunkel, sondern auch dort gibt es diese Mindesthelligkeit.
Mit Raytracing könnten wir auf das Fake-Licht verzichten und dafür sorgen, dass Lichtstrahlen einigermaßen realistisch von Oberflächen abprallen. Dadurch könnte man wirklich dunkle Räume erzieF"len, aber auch kleinere Details würden zur Geltung kommen (zB würden Leuchtblöcke automatisch die Umgebung ausleuchten).
Nachteil ist, dass spezielle Hardware für Raytracing nötig ist. Und Raytracing ist trotzdem ein recht teurer Effekt, d.h. man wird dafür Performance opfern müssen (umso wichtiger, dass wir gleichzeitig DLSS und FSR anbieten). Andere Engines bieten auch "Global Illumination" an, die nicht auf Raytracing basieren (prominent ist zB "Lumen" in Unreal), doch der Weg bleibt uns leider versperrt: Unity hat auch an sowas gearbeitet, es aber nach einigen Jahren aufgegeben, sodass es bis heute keine adäquate Lösung in Unity dafür gibt.
Es können auch andere Effekte mit Raytracing erzielt werden, zB bessere Schatten. Auch schönere Reflektionen bzw. Spiegelungen sind möglich: Derzeit sind Spiegelungen in RW so, dass nur das gespiegelt werden kann, was auf dem Bildschirm sichtbar ist. Mit Raytracing wäre es möglich, dass auch Dinge in Spiegelungen auftauchen können, die nicht auf dem Bildschirm sichtbar sind. Ist meiner Meinung nach aber kein so gravierender Effekt. Wie gesagt, in meinen Augen ist "Global Illumination" der einzige Effekt, wo man einen wirklich großen Unterschied feststellen wird, der sich auch spielerisch auswirkt
Couldn't you create an alternative to have a satellite view of the map (or a real image from above of all the buildings, similar to JAVA) and convert it into a good resolution image to enter into the game as a poster? It doesn't matter that it is not a real-time image of the game, we will be the players who will have to refresh it manually at will, for me that would be a good solution while a solution for a GPS map with satellite view is found. What I mean is that taking screenshots from above and putting together a map like a puzzle is not the same as having a real view from above as in JAVA
As explained above, unfortunately we hit technical limitations in Unity's HDRP if we want to implement a map like in the Java version 
In Unity's current state, we don't have enough control over the rendering to implement this properly - and in addition to this, it has severe performance implications in Unitys HDRP. This may change in the future, but instead of delaying this feature indefinitely, we decided to focus on the core functionality of a map for now: to serve as a navigation tool. While it doesn't look as nice as the map in the Java version, it's more like an actual map now (and has a few advantages, i.e. being capable of showing the entire island, for example).
If the technical situation changes in the future, we would, however, implement a different item for a "satellite view". The reason is that the current/upcoming map wouldn't really play well with a satellite view, because the current map shows the topology of the entire island - while a map like in the Java version could only render a small portion around the player (basically everything that's visible). So probably it would be better to implement a separate item for this (either another map type, a gps device or something like that).
That would be a camera mode which is something Unity is capable of.
While this is true for the URP and the old built-in renderer, it does not apply to Unity's HDRP unfortunately: While using multiple cameras is still possible in theory, each additional camera has a massive performance overhead in HDRP (roughly a 50% performance loss), so it's unfortunately not a viable solution. The recommended workflow in HDRP is to use so called "Custom Passes", but they're not capable of rendering a proper map view (they're more suited to populate a depth buffer, for example)
Hello, red 51! Is there any information about when the unity version will replace the Java version? Or when can I wait for the next update?
The upcoming update will be the final update before the store page update
You mean an update on Trello (about the current development progress), or an actual update release? It's understandable that you're looking for more updates, but unfortuantely we cannot release a small update now... it sounds weird, but that usually just results in more negative feedback. People usually want frequent updates, but at the same time, many also expect these updates to add a lot of meaningful new content - and a small update which only adds few new things (or cosmetic stuff etc) quickly results in disappointment. In addition to that, the last update now was months ago, so it's even more important to release a big update now (if we release a small update now, people would think that we've spent all the time working on just a few meaningless things).
There is also another big factor which has a considerable impact on this: we have to replace the Java version on the storepage ASAP. There are a few things we really need to get ready before we can finally do that. Frequently releasing small updates would unfortunately slow down the overall progress.
Having said that, after the store page update, it is our intention to put a bigger focus on smaller features.
Tut mir Leid, von dem Absturz zu hören Grundsätzlich ist es so, dass normalerweise eine Anwendung niemals einen Absturz des Rechners verursachen sollte - selbst wenn die Anwendung irgendwas falsch macht oder es einen Bug gibt (schlimmstenfalls darf nur die Anwendung selber abstürzen). D.h. ein Absturz des Rechners deutet immer darauf hin, dass eine Ebene tiefer etwas schiefläuft, also zB auf Treiber- oder Betriebssystem-Ebene. Ein typischer Kandidat dafür ist meist der Grafiktreiber, denn wie jede Software können auch neue Treiberversionen Bugs enthalten (und das passiert leider häufiger als man denkt). Auch der RAM kann theoretisch Ärger machen. Denkbar ist bei Rechnerabstürzen auch ein Temperaturproblem o.ä. (allerdings höchst unwahrscheinlich in diesem Fall, wenn der Absturz schon beim Start auftritt).
Ich würde vll zunächst einmal probieren, den neuesten Grafiktreiber von der NVIDIA Seite herunterzuladen und zu installieren.
Der Vergleich mit anderen Spielen ist in der Situation leider immer etwas schwierig, da diese andere Anforderungen an die Hardware stellen und nicht zwangsläufig dieselben Features der Grafikkarte nutzen wie RW. Erschwerend kommt bei der neuen Version hinzu, dass auch die Engine ein weiterer Faktor ist (zwar verwendet Empyrion von den o.g. Spielen auch Unity, allerdings den alten Built-in-Renderer, während RW die HDRP verwendet - daher ist das leider nicht wirklich vergleichbar).
Wann genau stürzt das Spiel denn ab? Wird das Fenster des Spiels noch angezeigt (bzw. das JIW Logo), oder knallt es vorher schon? Funktioniert es bei einem erneuten Start, oder wirklich erst nach einer Neuinstallation?
Die Log-Datei enthält leider keine weiteren Hinweise auf den Absturz, sondern endet abrupt... auffällig ist lediglich, dass das Datum des Grafiktreibers offenbar nicht ausgelesen werden konnte, was ggf. auch auf ein Windows-Problem deuten kann. RW holt sich diese Info direkt von Windows (via WMIC), tatsächlich gab es in der Vergangenheit schonmal die Situationen, dass bei Problemen in Windows dieser Aufruf zumindest einen Crash verursacht. Falls ein neuer Grafiktreiber wie o.g. nicht hilft, kannst du testweise in der config.properties Datei die Einstellung Game_DisableWMIQuery auf True ändern und schauen, ob das einen Einfluss hat. Wenn das nicht klappt, stelle den Wert am besten wieder zurück auf False.
Komisch, dass eine Neuinstallation einen Einfluss hat. Im entfernteren Sinne könnte ich mir hier ggf. noch ein Antivirenprogramm vorstellen, was irgendwas durcheinander bringt. Es wäre im Zweifelsfall zumindest einen Versuch wert, es einmal testweise zu deaktivieren und zu schauen, ob das Problem damit weiterbesteht.
So we could potentially get the ability to copy each map sector to a poster/decal/wall map so we could build giant map walls, floors, etc. in the future then?
Actually the game is capable of displaying maps as objects in the game world (so a map could be placed in the same way as a poster). Basically it could also display other players and npcs etc dynamically
Unfortunately we haven't implemented the handling for this yet... maybe we still get it ready for the update (or shortly after it).
Alternatively we could provide a way to store the current map view to a screenshot - this could be used for a poster then
red51 Wäre ein Winkelmesser vielleicht auch drin?
Das wäre an sich durchaus sinnvoll, ich habe nur leider noch keine Vorstellung davon, wie das ingame aussehen könnte Gehts dir nur darum, einen Winkel zu messen (quasi eine Darstellung wie beim Maßband, jedoch mit einem Knick drin (an welchem der Winkel dargestellt wird)? Ansonsten wenn du einen Vorschlag dazu hast (ggf. eine Skizze oder so), wäre das schon sehr hilfreich
ich wünsche mir eher ein Kurvenwerkzeug mit Markierung des Start- und Endpunktes sowie der Breite und Dicke mit verschiebbarer Höhe, einstellbarer Breite und Dicke für definierte Bögen einer Hängebrücke als Beispiel
oder noch besser ein Bezier-Kurven-Werkzeug für kurvenreichen Wegebau
Ich habe mal angefangen an sowas zu arbeiten, aber leider auf die Schnelle keine vernünftige Umsetzung gefunden... da müsste man sich etwas intensiver mit auseinandersetzen... momentan würde ein größerer Fokus auf ein reines Bau-Feature aber in der Community leider nicht auf viel Gegenliebe stoßen (nicht solange die Storepage nicht aktualisiert ist und der Survival-Part mehr zu bieten hat)
Ein Bezier-Werkzeug wäre zwar von der Umsetzung her deutlich einfacher, aber derzeit können wir nicht die dafür nötigen Zusatzinformationen für ein Bauelement speichern. Ggf. ändern wir das, aber sowas kann leider nicht passieren bevor nicht die Storepage aktualisiert ist.
Das Maßband ist gut, aber eine mögliche Fixierung wäre besser
Du meinst, dass die Messung (Markierung usw) beim Weglegen des Items sichtbar bleibt?
Hallo red51 Mal eine frage tut das not das es nun ein drittes Boot (Segelboot) geben soll ??
Das Segelboot kommt in erster Linie weil es mehrfach den Wunsch aus der Community dazu gab (insbesondere nach dem Biom-Update). Das Reisen zwischen Inseln ist momentan noch nicht ganz so einfach, da das Ruderboot recht langsam ist (und das dauerhafte Rudern bzw. Drücken von W recht anstrengend werden kann), während das Motorboot keinen Platz in einem mittelalterlichen Setting findet. Ein Boot, welches von alleine fahren kann (man also W nicht gedrückt halten muss) und nicht exklusiv nur in der Moderne Platz findet ist daher an sich schon nicht ganz verkehrt
ich wäre mal endlich für ein PKW oder einfach mal nur ein Fahrrad um die Stadt zu erkunden .
Ein PKW wäre nicht schlecht, ist aber leider nochmal aufwändiger in der Umsetzung... denn einerseits existiert noch kein Fahrverhalten für Landfahrzeuge, andererseits benötigt das auch einen speziellen Crafting-Prozess (zumindest wenn wir das einigermaßen vernünfig umsetzen wollen).
Landfahrzeuge werden daher wohl erst nach dem Storepage-Update kommen können
leider wirkt das gezeigte Modell in Trello wie das Boot aus einem ganz einfachen Survivalspiel mit so la la Grafik
Was ist denn mit dem Segelboot nicht in Ordnung bzw. was stimmt optisch nicht damit?
nicht besonders modern und zu klein, um als Santa Maria durchzugehen
Ein modernes Segelboot wäre für Spieler oder Server, die sich auf ein mittelalterliches Setting konzentrieren wollen, leider ungeeignet. Hingegen ist das Segelboot, welches in Arbeit ist, durchaus mit so einem Setting kompatibel (gleichzeitig aber auch in einem modernen Setting nicht unangebracht).
Es war nicht als großes Segelschiff gedacht. Sowas ist zwar auch langfristig geplant, aber das ist nochmal ein ganz eigenständiges Thema für sich (und von der Umsetzung her noch aufwändiger)...
red51 ist das Absicht das ich den Vector3f nicht Clonen kann?
Es gibt leider tatsächlich keine clone() Methode für Vector3f (oder auch andere API-Objekte). Was du da siehst ist die clone() Methode die von "Object" bereitgestellt wird, also direkt von Java (und die ist nicht public).
Klonen (über die clone()-Methode) ist in Java nicht gut umgesetzt, weshalb wir es generell in der API vermieden haben (keine unserer Klassen implementiert die clone() Methode). Es wird im Java-Umfeld allgemein eher abgeraten, clone() zu verwenden...
Die Vector3f Klasse bietet daher stattdessen eine copy() Methode an, die quasi genau das macht, was du suchst: Vector3f currentPoint = startPoint.copy();
Oder alternativ direkt einen neuen Vektor erzeugen und den alten als Parameter dem Konstruktur übergeben, wie du es in deinem Beispiel auch getan hast
Wenn du den Vektor für eine Addition oder Multiplikation o.ä. benötigst, dann kannst du auch die add(), mult() etc. Methoden ohne "Local"-Suffix benutzen - die erstellen immer einen neuen Vektor (während alle "Local" Methoden die bestehende Instanz verändern, ohne einen neuen Vektor zu erstellen). D.h. zB Vector3f result = startPoint.add(4f, 5f, 0f); gibt einen neuen Vektor zurück (und "startPoint" bleibt unverändert), während startPoint.addLocal(4f, 5f, 0f); direkt "startPoint" verändert und keinen neuen Vektor erstellt.
Okay I owe you an apology. Looking at this preview picture compared to the other one it was the way the one wolf was standing that was making it look like the fur was flatter looking that what it actually is. I do sincerely apologize and hope my original comment didn't offend.
Oh, don't worry, I definitely did not consider your post offensive You still brought up a completely valid point (and we indeed have plans to improve fur rendering in the future, as mentioned above)
Yes and I only see wolves. But it's fine, still excite to hear there's been development!
If the link to the Activity List doesn't work, here are the direct links to all updated cards instead
https://trello.com/c/VShc7WPV/174-animals
https://trello.com/c/H2oLJHLG/168-boats-and-ships
https://trello.com/c/RvWiETl5/182-ingame-map
https://trello.com/c/vI5vXetb/129-player-model
A question about the dhows: What is the width and the air draft ? It's better to anticipate to build bridges at the good size.
The air draft is roughly 7-8 blocks. The total length is almost 9 blocks and the width (including sails) is around 7 blocks
But please bear in mind that this may still change a bit. Also, there will be bigger vessels in the future
Wir haben jetzt zwar Glastüren. aber als Eingangstür sind die eher für einen Shop geeignet, denn wer möchte in seinem Haus eine durchsichtige Eingangstür haben, durch die alles im Inneren zu dmsehen ist. Es gibt so schöne Türen da ist oben Glas und nicht die ganze Front verglast. Unsere Türen kann man nicht durchsichtig machen, leider. Ich muss ehrlich gestehen, dass diese Glastüren eher als Balkontüren denn als Eingangstür geeignet sind. Die vorhandenen Modelle sind leider nicht wirklich schick.
Bis auf die beiden Eingangstüren (die tatsächlich eher für einen Shop o.ä sind) waren die anderen Glastüren eher weniger als Haustüren gedacht, sondern eher als Innentüren oder ggf. tatsächlich auch Balkontüren o.ä. (oder mit etwas Fantasie evtl. auch für eine Duschkabine oder dergleichen).
Du kannst aber bzgl. Türen gerne jederzeit Vorschläge posten (idealerweise mit Bild)
Fragt sich nur wann?
Ich würde mich am liebsten sofort an bewegl. Strukturen ransetzen (weil das ein wirklich interessantes Thema wäre), ist aber leider nicht drin bevor wir nicht die Storepage aktualisiert haben
