Ich hab das auch gelesen
... naja gut ... da steht ja auch ein "Probably"
Stimmt 
Sorry, habe ich glatt vergessen 
Es sind zwischenzeitlich ein paar andere Themen dazugerutscht, die eigentlich etwas unerwartet waren... aber gut, vielleicht wird Juli noch was (wenn dann eher in den nächsten 1-2 Wochen), sonst August.
aso, ich meinte Unity Komponenten aufzulisten die schon auf GameObject oder prefab drauf sind. !
NICHT alle die Unity so hat ... uff
Unteranderem will ich wisse ob z.B.: addComponent erfolgreich war, oder welche Komponente kann ich mit setComponentProperty glücklich machen
Achso, das habe ich falsch verstanden So macht das auf jeden Fall mehr Sinn. D.h. du möchtest eine Liste aller Components, die auf dem geladenen Prefab vorhanden sind? Im Falle des Basis-GameObject hingegen wäre es dann meist wahrscheinlich Transform, MeshFilter und MeshRenderer, bei Prefab hingegen dann ggf. noch die vom User im Editor erstellten Components.
Ich muss nur mal schauen, wie wir das am besten umsetzen... der Server lädt normalerweise gar keine Assetbundles, sondern nur der Client. Es gibt bereits eine Ausnahme (getAllAssetNames()), aber für Components müssten die ganzen Prefabs geladen werden (samt Texturen usw). Vmtl. wäre hier ein Cachen zwingend erforderlich, damit Mehrfachaufrufe nicht den Server zuballern... ich schaue mir das auf jeden Fall mal genauer an 
Also ist meine Vermutung mit dem Winkel falsch?
Generell oder nur für das Abfallen der Objekte bei BP's?
Weder noch, der Winkel kann dabei durchaus eine Rolle spielen 
Ebenso die Skalierung. Es hängt tatsächlich von mehreren Faktoren ab, kann aber auch rein zufällig passieren. In Fällen, wo ohnehin keine Verbindung besteht, fallen Elemente aber natürlich ebenfalls ab.
Da du es in deinem Beitrag explizit erwähntest: Zusätzlich zu undo gibt es auch noch undobp, womit die letzte platzierte Blaupause zurückgesetzt wird (dann muss man sich nicht schrittweise durch die letzten Änderungen wühlen) Aber eine richtige Undo-Liste ist auch noch in Arbeit, vll schafft sie es ins nächste oder übernächste Update.
red51 kannst du bitte API Methoden einbauen die Unity Komponenten aufzulisten.
Jein... also grundsätzlich wäre das möglich, aber das Problem ist, dass es in Unity so unendlich viele Komponenten gibt, ein nicht unwesentlicher Teil davon aber entweder veraltet, inkompatibel oder nicht für die HDRP geeignet ist 
Um wirklich alle kompatiblen bzw. sinnvoll einsetzbaren Komponenten zu erhalten müssten wir eigentlich von Hand eine Liste anlegen... wofür würdest du die Liste denn benötigen? Für ein konkretes Plugin, oder für eine allgemeine Übersicht (zB im Wiki)?
inklusive einer Klasse in der API die UnityComponent repräsentiert mit 3,4 Infos mehr und Methoden wie string getName()
List<UnityComponent> getAllUnityComponents()
Schön wäre es wahrscheinlich, aber so ein 1:1 Mapping ist auch manchmal unerwartet viel Arbeit (besonders wenn es von der allgemeinen Grundklasse "Component" ausgeht)... und würde wahrscheinlich ein umfangreiches und sauberes Planen erfordern (unzureichend durchdachte Design-Entscheidungen in der API sind immer doof, da wir das dann meist nicht mehr so einfach ändern können)
Sinnvoll wäre das aber wahrscheinlich auch erst dann, wenn es in der API auch wirklich entsprechende Repräsentationen jeweiliger Components geben würde (zB Rigidbody, VisualEffect usw). Andererseits gibts aber bereits zB "Collider" usw, d.h. hier müsste eigentlich alles zu diesem eher universelleren System zusammengeführt werden... unter der Haube wiederum ist es aber oft kein 1:1 Mapping, da auf dem Server ohnehin keine Unity-GameObjects o.ä vorliegen, sondern das ganze nur abstrakt repräsentiert ist... und manche Quirks der Unity HDRP von der API ohnehin ausgeblendet werden (zB dass eine Light-Component alleine nicht ausreicht, sondern ebenfalls eine HDAdditionalLightData-Component erforderlich ist, gleichzeitig aber nur die Hälfte der Light-Component-Properties funktionieren, während die andere Hälfte als gleichnamige Methode in HDAdditionalLightData zu finden ist usw).
Unterm Strich leider wahrscheinlich wirklich einiges an Aufwand 
eine API Methode die Unity MonoBehaviour Methoden per Reflection aufrufen kann
z.B.: invokeMonoBehaviourMethod() oder so
Theoretisch müsste das eigentlich auch mit invokeComponentMethod() funktionieren (da MonoBehaviour von Behaviour abgeleitet ist, welches wiederum eine Component ist) Welche Methode von Behaviour/MonoBehaviour würdest du denn auf dem Wege aufrufen wollen?
Ich kann bestätigen, dass das leider ein Bug ist: Beim Platzieren von Blaupausen wird die Schwerkraft-Berechnung (effektiv ist die dafür da, alle Objekte und Pflanzen zu zerstören, die keinen Kontakt zum Boden oder einer Wand haben) manchmal zu früh durchgeführt, bevor also die restlichen Elemente platziert sind. Ich werde das mit dem nächsten Update korrigieren
Aber bis dahin sollte das Ausschalten der Optionen Abhilfe schaffen.
Das Spiel bzw. genau genommen die Plugin API bietet tatsächlich eigentlich schon alle notwendigen Werkzeuge für sowas Areas wären gut geeignet als Trigger Volume, es gibt OnEnter/OnLeave Events, und natürlich ebenfalls eine unendlich lange Liste an Dingen, die dann ausgelöst oder gemacht werden könnten.
Die wahre Kunst besteht nun darin, sowas im Spiel verfügbar zu machen (also damit man nicht gleich ein Plugin schreiben muss, was für die meisten User ohnehin keine Option ist). Effektiv sehe ich da zwei Möglichkeiten:
1. Entweder ein User hat Bock ein Plugin zu schreiben, was genau diese Events und Methoden ins Spiel trägt und dort bequem über eine UI o.ä. verfügbar macht (so wie noci auch schon andeutet)
2. Das Spiel macht alle Plugin Events und Methoden leichter zugänglich, d.h. ohne Notwendigkeit, ein Plugin zu schreiben (effektiv das, was 1 liefern würde, nur halt als Bestandteil des Vanilla-Spiels)
Auf 1 haben wir natürlich keinen direkten Einfluss. Aber zu 2 gab es damals schonmal Überlegungen, sowas teilweise über den Creative-Modus zugänglich zu machen. Ist natürlich nicht wenig Arbeit... aber wäre im Gegenzug auch ein extrem mächtiges Werkzeug und ich denke, dass so einige Spieler davon profitieren könnten. Es ist irgendwo (in Klammern geschrieben) auf der Todo-List, aber weniger als "das-wird-bald-kommen"-Feature, sondern eher als "really-nice-to-have-aber-kA-wann-es-wirklich-kommt"-Feature 
Aber vll ist ein Plugin-Ersteller ja schneller 
Der Flugmodus hat standardmäßig eine vereinfachte Steuerung, d.h. beim Drücken von Shift (Taste für Sprinten) fliegst du schneller, beim Drücken von Alt (Taste für langsames Gehen) fliegst du langsamer.
Wenn du die Fluggeschwindigkeit einstellbar haben möchtest (wie in der Java Version), d.h. mit Shift + Mausrad, dann musst du in den Einstellungen unter "Verschiedenes" die Einstellung Flugmodus Geschwindigkeit auf Fortgeschrittener Modus stellen
## Rising World - Dedicated Server Version 0.9.1 (15) Settings ##
If you're using SteamCMD, this topic contains more information about installing or updating the server Dedicated Server Setup [New Version]
In short, you need to execute app_update 339010 validate to update the server to the latest version.
So, what's new in 0.9.2?
You can find the changelog in the latest news post (just scroll a bit down to find the changelog): Update 0.9.2: Animal Breeding, Item Placement, better Controller Support [EN]
Apropos, gibt es schon einen ungefähren ETA für das nächste Update?
Vermutlich diesen oder nächsten Monat
Viel cooler wäre wenn man die Schiffe irgendwann selber bauen könnte
Der Wunsch wurde immer wieder mal geäußert (vor allem auch auf Fahrzeuge bezogen)... was zumindest geplant ist ist die Möglichkeit, größere Schiffe zu bebauen. Um vll den Spagat Richtung "selbstgebaute Schiffe" hinzubekommen wäre die sinnvollste Lösung wahrscheinlich ein Grundgerüst pro Fahrzeug-Typ zu haben, welches man dann bebauen könnte. Bei Booten/Schiffen wäre das vll ein Floß
Ich dachte jetzt ,man hätt die Sturm dynamik auf dem wasser noch mal erhöht.
Tatsächlich ist der Sturm selber gar nicht anders, neu sind bei dem Bild eigentlich nur die Wellen Derzeit gibt es keine richtigen Wellen auf dem Ozean, zwar stellt das Spiel das Wasser so dar, dass es eine gewisse Struktur hat, aber effektiv ist das Wasser immer platt bzw. flach. Mit dem Update würden richtige 3D Wellen dazukommen (und natürlich dabei auch das Bootsverhalten spürbar ändern), besonders bei Unwetter werden es auch entsprechend stärkere Wellen.
Ich hätte gerne das ein Plugin-Ordner genauer Untersucht wird
und hier auch weitere *.jar mit in die Ladeliste einbaut.
Grund: Durch meine Spielerein ist die ToolsAPI auf ca. 20Mb gewachsen. Ich habe da einige Libs und möchte die in einer Separaten Datei/Plugin auslagern. Es würde Sinn mache die beiden in einem Plugin-Ordner abzulegen.
Aber dann gewinnt das Alphabetische Plugin im Ordner, aus dem dann die plugin.yml herangezogen wird für die Prio und so. Ich glaube die weiteren werden dann nicht mehr geladen.
Theoretisch müsste das bereits möglich sein Standardmäßig prüft das Spiel, ob es einen "lib" Ordner gibt (innerhalb eines Plugins) und lädt die .jars darin dann als Abhängigkeit. Wenn hingegen ein Plugin als Lib für andere Plugins dienen soll, musst du die loadorder in der plugin.yml anpassen, wie Devidian schon sagt. Das Spiel lädt Plugins in der Reihenfolge abhängig ihrer loadorder (bei gleicher loadorder dann hingegen alphabetisch). Für ein Plugin, was als Dependency eines anderen Plugins dient, müsstest du entsprechend eine niedrige loadorder wählen (zB die vorgeschlagenen -999)
Algemein, wenn der WorkShop kommt, hat der auch eine Größenbeschränkung? Müsste ich mir dann noch gedanke über die Plugin Größe machen?
Bei Steam gab es damals mal eine Größenbeschränkung, aber meines Wissens nach gibt es die nicht mehr (d.h. kein Limit mehr). Ich würde dennoch versuchen, Plugins und Mods so klein wie möglich zu halten, da die Downloadgeschwindigkeiten in Steam manchmal deutlich schwanken können...
Ansonsten scheint es aber bei mod.io ein Limit zu geben. Online finde ich 8 GB, weiß aber nicht, ob das wirklich noch aktuell ist (ist schon ein paar Jährchen alt). So 100% steht noch nicht fest, ob wir lieber zu Workshop oder mod.io gehen (Steam würde die breitere Masse erreichen, mod.io hingegen plattformunabhängig sein und auch für nicht-Steam Versionen funktionieren) 
Ich wollte mal einfach fragen, wann ein neues Update in Planung ist und evtl was drin ist?
Voraussichtlich diesen oder nächsten Monat, aber leider kann ich noch nicht 100% sagen, was alles seinen Weg ins Update finden wird Kommt ein wenig darauf an, ob das Update noch im Juli oder eher im August erscheint.
Die gute Nachricht: Wir haben mit der Arbeit an einigen großen, wichtigen Features begonnen (bewegliche Teile, bessere Höhlen, besseres NPC Pathfinding usw), die werden aber nicht im kommenden Update reinkommen.
Ausnahme könnten die Höhlen sein: Aber hier würde ich das vll erstmal als "experimentelles Feature" reinbringen, d.h. man kann sie für neue Welten testweise aktivieren. Würde da gerne etwas Feedback sammeln und wenn alles passt, würde ich sie für alte Welten rückportieren.
(das Problem ist nämlich, dass die Integration in Bestandswelten immer etwas heikel ist, vor allem aber wenn die Höhlengenerierung Probleme macht oder wir doch nochmal ändern wollen, das wirklich unheimlich viel Aufwand ist... daher lieber erst etwas Feedback sammeln)
Das nächste Update wird in erster Linie die oben gezeigten Ozeanwellen reinbringen (mit neuer Bootsphysik etc) und das Wasser wurde generell angepasst (Fließverhalten usw). Außerdem sind viele Altlasten behoben, die schon ewig Probleme machten (zB "Geisterblöcke" die bei Terrainbearbeitung übrig blieben und im LOD zu Spitzen führten, Harke kann Terrain nun weicher gestalten usw), und generell eine Reihe Bugs behoben. Die Änderungen in der Plugin API sind auch umfangreich (auch wenn das für viele Spieler natürlich auf Anhieb erstmal nicht so relevant ist).
Alles andere, woran wir momentan noch arbeiten (zB Items beim Reiten benutzen) ist noch unfertig, da kommts ein wenig darauf an, ob es in den nächsten 1-2 Wochen fertig wird oder nicht
Auf Steam wurde geschrieben, dass du Ende diesen Monats, damit rechnen kannst.
Die Info ist zwar nicht komplett falsch, aber wo genau hast du die her? Oder wer hat das gesagt? Ich kann mich eigentlich nicht erinnern, mich verplappert zu haben (zumal ich wirklich nicht 100% sicher bin, ob es wirklich diesen Monat kommt)
Danke für die Info! Dass Umbruch manchmal fehlerhaft durchgeführt wird ist mir auch schon aufgefallen, doch dass Rich Tags auch zerstört werden können wusste ich noch nicht Jedenfalls sollten beide Probleme mit dem nächsten Update endlich behoben sein
Ja, das macht auf jeden Fall Sinn Ich packe es mal auf unsere Liste
Könnte man ein Poster in das Maßband laden und das Verhalten von Postern übernehmen um die gelben Punkte zu ersetzen? Das wäre 5 Sterne
Wie meinst du das genau? Soll das Poster dann anstelle des Markers angezeigt werden?
Ich wünsche mir seit langem die Möglichkeit der Fixierung des Maßbandes, als ob ich einen Zollstock auf den Boden legen könnte.
Wie Nebeltrinker schon sagt, die Funktion gibts tatsächlich schon seit einer Weile
red51 Bekommen wir auch große Schiffe (zB. Galeone)?
Große Schiffe sind auf jeden Fall geplant, aber leider nicht mit dem kommenden Update 
Dafür könnte man ja ein exposePlugins in die server.properties einfügen was per default false ist. Wenn ich meine Plugins dann entsprechend anpasse, werde ich genau so vorgehen, so war der plan.
Ja, das wäre natürlich möglich Würde das dann aber standardmäßig vmtl. deaktivieren, d.h. ein Admin müsste die Einstellung explizit auf true setzen, damit es funktioniert. Wahrscheinlich würde ich sie dann Plugins_ExposePlugins oder ggf. Server_WebserverExposePlugins nennen. Ich kann das mit dem nächsten Update reinpacken
red51 Gibt es mehr solche versteckten Einstellungen und/oder Konsolenbefehle für Blaupausen?
ich frage für unsere Wiki
Im Prinzip alle Optionen, die in der config.properties sichtbar sind (beginnend mit Game_Blueprints*) Die einzige versteckte Option ist Game_BlueprintsPlaceDelay, womit festgelegt werden kann, wie lange es dauert, bis eine Blaupause platziert ist.
Ansonsten greifen bei Konsolenbefehle diverse Baubefehle (setl, setr, setp, size, gridrotation etc). Spezifische Blaupausen-Befehle sind eigentlich nur blueprints (zum Öffnen der Blaupausen-Übersicht), blueprintinfo <datei> (um Infos zu einer Blaupause anzuzeigen) und undoblueprint (um explizit das letzte Platzieren einer Blaupause rückgängig zu machen). Ggf. könnte man hier noch gamedir blueprints miteinbeziehen, was direkt den Blaupausen-Ordner auf der Festplatte öffnet
Dem Video ist eigentlich ganz gut zu entnehmen, dass ich im Singleplayer spiele.👉👈
Stimmt, sorry, dumme Frage, mein Fehler 
Sie landen halt immer da, wo Sie auch gespawnt sind.
Achso, also ist das immer ihr originaler Spawnpunkt, d.h. kein zufälliger Punkt o.ä? Wie ist das mit dem refreshnpcs Befehl? Im Video hast du ihn zwar eingegeben, aber zu dem Zeitpunkt hatten sie bereits ihre fehlerhafte Position bzw. sie einfach beibehalten (was tatsächlich zu erwarten war). Aber wie ist es, wenn sie an einer Position sind, die nach einem Neuladen der Welt wahrscheinlich wieder zurückgesetzt wird? Wenn du dann den Befehl eingibst, landen sie dann auch wieder an der Spawnposition, oder behalten sie dann erstmal ihre Position bei (die dann erst beim Neuladen zurückgesetzt wird)? Das würde helfen herauszufinden, ob der "Server" (auch im SP läuft quasi ein Server, nur ohne Netzwerk und so) denn die korrekte Position hat, sie nur nicht oder falsch in die Welt-Datenbank geschrieben wird, oder ob es zw. Client und Server eine Abweichung gibt
Kryssi_79 Habe dir per PN geantwortet
Irgendwo bei 8.5+ fiel mir auf, dass die Zeit in einem Intervall von etwa 5 Ingameminuten einen Rücksprung macht und sich dann wieder nach vorne dreht, bis sich der Vorgang wiederholte
Diese Rücksprünge treten auf, wenn die Zeit zwischen Client und Server zu stark abweicht. Bis zu einem kleinen Maß toleriert das Spiel eine Abweichung (und versucht sie langsam auszugleichen), aber wenn sie zu groß wird, gibts den harten Sprung...
Woher das jedoch genau kommt bzw. in dem Fall kam ist schwer zu sagen... vielleicht war damals auch ein Bug, der das begünstig hat, bin mir da leider nicht mehr sicher
Nun, wenn ich es über die Konsole mit settimespeed hochschraube wird der Befehl zwar angenommen, jedoch nach einem Relog bzw. längerer Offlinedauer trotz dass der Server noch nicht neugestartet hat wieder auf 60 gesetzt
Ja, der Konsolenbefehl ist leider nur für die Session gültig, d.h. nach einem Neustart des Servers ist es wieder zurückgesetzt
Irgendwas um den Dreh bei 50000-60000 rum wurden wieder die 60 genommen, aber die 50000 blieben eingetragen. Alles unter ~50000 ging, aber nach einigen Sessions waren nach jedem Serverneustart wieder die 60 aktiv, ich glaube es gab dazwischen keinen Fix oder Patch.
Also der theoretisch höchstmögliche Wert wäre 2147483647 (max. Wert eines vorzeichenbehafteten ints)... das Spiel setzt an der Stelle auch keinen künstlichen Höchstwert an. Bei so dermaßen hohen Werten kann es aber sein, dass die Zeit effektiv nicht voranschreitet (aufgrund von Rundungsfehlern). Da ist es dann sinnvoll, die Zeit generell auszuschalten (einfach Wert 0 eintragen)... allerdings bleibt sie dann auch wirklich stehen.
Für Realtime wäre der sauberste Weg wirklich 1440 einzutragen. Nur leider bedeutet das wirklich nur, dass ein Ingame-Tag 24 Stunden dauert. Damit wird die Zeit nicht automatisch an die Systemzeit angepasst (dafür wäre wiederum ein Plugin nötig).
Funktioniert das denn weiterhin nicht, wenn du diesen Wert in die server.properties einträgst? Bzw. gibt es in dem Fall weiterhin Probleme mit springenden Schatten o.ä?
Vielen Dank für das Video! Also das ist ja ein merkwürdiges Phänomen 
Ist das im Multiplayer oder Singleplayer? Verwendest du Plugins?
Ich konnte es bei mir leider bisher nicht reproduzieren... hast du von deiner Seite einen Weg das zu reproduzieren bzw. ist dir etwas aufgefallen, unter welchen Umständen die Npcs ihre Position verlieren?
Alles klar! Die Plugin-Klasse selbst erhält dann die Möglichkeit eine Route zu registrieren (zB registerWebserverHandler()), bei welcher der Pfad angegeben werden kann sowie optional auch ein Handler für die Requests. Die Route wird dann (um Kollisionen zu vermeiden) immer "/plugins/pluginname/<pfad>" sein. Zusätzlich zum Handler gibts aber dann auch ein neues HttpRequestEvent, aus welchem du die Http-Methode (GET, POST, PUT etc), den Pfad, Query Parameter, Header, Body (byte[] sowie String) und Remote-Adresse erhalten kannst. Für die Response kannst du dann den Response-Code, ContentType, Response-Header sowie -Body setzen
vielleicht könntest du auch noch eine route integrieren die auch ohne plugins funktioniert /pluginlist die eine liste der installierten plugins + version zurück gibt? Das würde nativ wahrscheinlich mehr sinn machen, könnte man auch für andere consumer verwenden.
Sowas war mal vorgesehen, allerdings haben wir das erstmal nicht reingepackt, damit von außen nicht ersichtlich ist, welche Plugins ein Server explizit verwendet... kA ob es überhaupt sinnvoll ist, aus sowas ein Geheimnis zu machen, bzw. ob manche Server-Admins evtl. nicht wollen, dass ihre Plugins preisgegeben werden?
Sorry for my late response, but yes, the Player has a method setInvisible() that should make him invisible for other players
But unfortunately there is no direct way to load a custom model for the player... only thing you could do is load a custom Prefab and sync it manually with the player position. That should work well enough for other players.
