Posts by red51

    Leider fehlt noch eine setEquippedItem() Methode bei NPCs, ich kann die aber mit dem nächsten Update noch reinpacken ^^


    Was den Modifier oder die Durability angeht, die werden beim Droppen dummerweise fest verdrahtet (daher ignoriert das deine Änderungen)... das muss aber nicht sein, daher kann ich das auch mit dem nächsten Update anpassen. Leider gibts aktuell keinen direkten Workaround (außer höchstens "Settings_NpcDropEquippedItem" in der server.properties zu deaktivieren und stattdessen selbst das Item zu spawnen beim Tod es Npc) :thinking:

    Danke für den Hinweis! Die Methode ist leider nicht korrekt verdrahtet, daher funktioniert sie nicht (ist also tatsächlich ein Bug) :/ Ich werde das aber mit dem nächsten Update beheben! Ich werde auch nochmal andere API-Funktionen durchgehen und schauen, ob da irgendwas schief sitzt.

    Danke für die Permissions! Sorry dass es etwas länger dauerte, aber ich kann bestätigen, dass hier etwas faul ist :wat: Es gibt manche Prüfungen, bei denen die Area-Permission tatsächlich auf die default.json zurückfällt. Das betrifft zwar nicht den Spieler direkt, d.h. beim direkten Setzen der Spielerpermission wird das korrekt übernommen, aber bei positionsbezogenen Prüfungen ist das problematisch (zumindest bei manchen Permissions).


    Mir ist das vorher leider nicht aufgefallen, da Fliegen davon nicht betroffen ist, und bei den Vehicle-Permissions muss ich editownvehicles wohl doch übersehen haben (obwohl ich das ja extra erwähnte), sodass ich mein Fahrzeug trotzdem editieren konnte :/ Clientseitig werden die Permissions übrigens korrekt gesetzt (deshalb tauchen sie in der Permission-Liste als positiv auf), aber die Entscheidungen werden in den meisten Fällen vom Server getroffen, wodurch der Bug verschleiert blieb.


    Ich werde das mit dem nächsten Update beheben, danke nochmal fürs Nachhaken! :) Als schnelle Lösung könntest du entweder die gewünschten Werte direkt in der Area-Permission setzen (diese Problematik taucht nur bei den Permissions auf, die nicht von der Area-Permission überschrieben werden), oder alternativ (um zumindest die Fahrzeug-Problematik zu beheben) in der default.json editownvehicles löschen (der Standardwert dafür ist ohnehin true, d.h. der Spieler wird dann seine eigenen Vehicles weiterhin bearbeiten können).


    was ich grad nicht schnalle - bezieht sich das wirklich auf eine Gruppenberechtigung, oder ist das im Grunde nicht nur eine umbenannte Standardberechtigung die ebenfalls im Hauptordner liegt?

    Ja, das ist eine Gruppenberechtigung, d.h. neue Spieler werden automatisch dieser Gruppe zugewiesen. Prinzipiell dasselbe als wäre der Admin immer da und würde den neuen Spieler manuell der Gruppe zuweisen ^^

    Die default.json bleibt davon unberührt.

    ok aber wenn ich dich richtig verstehe müsste dann doch wenn ich in default.json *vehicles: false habe in der gruppen.json *vehicles: true und in allen area.json diese werte NICHt gesetzt habe doch der wert true sein oder? das ist aber nicht der fall. Sobald ein spieler eine area betritt scheint nur noch default.json < area permission zu gelten, ohne gruppen permission zu beachten.

    Ja, wenn in der Area-Permission dieser Wert nicht gesetzt ist, dann sollte der Wert der Gruppenpermission weiterhin gelten (sofern der Spieler in der Gruppe ist).


    Ich habs bei mir auf einem lokalen Server einmal kurz probiert: In der default.json ist zB Fliegen nicht erlaubt. In der Gruppen-Permission ist es explizit erlaubt. In der Area-Permission ist es gar nicht definiert. Innerhalb der Area kann der Spieler weiterhin fliegen (die Area-Permission wird aber gesetzt und überschreibt alles, was darin definiert war, zB Chat)...

    Habe testweise auch die editvehicles und editownvehicles Permissions getestet (d.h. in default.json false, in Gruppen-Permission true, in Area-Permission nicht definiert). Auch das funktionierte :wat:


    Andererseits will ich meine Klappe auch nicht zu weit aufreißen, da du (und SonoBionda) ja schon einige Area-/Permission-bezogene Probleme gefunden habt, die ich auf Anhieb nicht reproduzieren konnte :drunk: :saint: Daher sende mir vll am besten mal die Permissions zu, damit ich sie mir genau anschauen kann (oder nenne mir die genauen Permissions, die nicht funktionieren)

    Leider stehen die Biome bzw. neue Regionen momentan noch etwas weiter hinten an :( Das Problem ist, dass dafür einiges an neuer Vegetation nötig ist (das aber leider auch recht zeitaufwändig ist)... das ist momentan der größte Blocker bei diesem Thema.


    Momentan liegt der Fokus (hinsichtlich der "größeren Features") erstmal bei überarbeiteten Höhlen, Höhlen-POIs und auch Dungeons. Außerdem sind die NPCs noch ein wichtiges Thema (leider zu lange vernachlässigt), vor allem deren Pathfinding/Wegfindung. Die Überarbeitung der NPCs ist momentan im vollem Gange (ebenso wie Höhlen). Wenn das durch ist, können wir auch endlich Meeresbewohner reinbringen.


    Danach würde ich eigentlich ganz gerne bewegliche Bauteile in Angriff nehmen. Und wir kommen an einen Punkt, ab welchem ich auch langsam gerne in die letzten großen "Klopperthemen" Züge und Elektrizität reinluschern würde (um wenigstens schonmal ein paar Grundlagen zu schaffen).


    Einzelne "Spezial-Biome" (wahrscheinlich unter der Haube als POI umgesetzt) könnte ich mir aber durchaus schon früher vorstellen. Das wären zB Oasen in der Wüste, ggf. auch Vulkane (mit Tessellation verspüre ich einen Drang, Vulkangestein endlich natürlich spawnen zu lassen :D). Aber ich finde auch den Vorschlag von Devidian zu Krater-Biomen bzw. Meteroiteneinschlägen sehr interessant! Ich müsste mir mal Gedanken machen, ob die bisherige POI-Logik für diese Spezial-Biome wirklich sinnvoll ist, oder ob das noch ein besonderer Untertyp wird :thinking:


    Ich würde aber auch weitere Biom-Vorschläge begrüßen, vor allem auch was solche Spezial-Biome angeht!


    Außerdem ist das gemäßigte Biom weniger komplex als die anderen beiden. Sind Änderungen geplant?

    Wie genau meinst du das? Wünschst du dir mehr Wälder und Sub-Biome im gemäßigten Gebiet? Oder noch weitere Sub-Biome dafür? Wenn du Vorschläge hast bin ich offen dafür :)

    Tatsächlich ist es so, dass Area-Permissions bzw. spielerbezogene Area-Permissions eigentlich nicht von der Standard-Area-Permission erbt. Area-Permissions sind etwas spezieller, sie sind quasi eher als "Patch" zu verstehen statt reine Vererbung. D.h. es werden nur die Werte überschrieben, die in der Area-Permission definiert sind. Prinzipiell ist es beim Betreten einer Area so, dass die aktuelle Permission des Spielers (default.json oder Gruppen-Permission) temporär die Area-Permission erbt (und nur die Werte überschrieben werden, die in der Area-Permission explizit gesetzt sind).

    Als Area-Permission wird entweder eine spielerbezogene Area-Permission genommen (falls gesetzt), oder die Standard-Area-Permission. Beide haben nichts miteinander zutun, d.h. eine spielerbezogene Area-Permission ersetzt für diesen Spieler die Standard-Area-Permission, erbt aber nichts von ihr.


    Wenn die default.json nicht existiert, dann werden dort einfach die Standardwerte, die vom Spiel aus definiert sind, genommen (im MP sind die Werte für Spieler so gewählt, dass ein Spieler fast nichts darf). Wenn der Spieler einer Gruppe zugewiesen wird spielt das aber keine Rolle (lediglich für die Keys, die nicht in der Gruppen-Permission gesetzt sind, denn die stammen dann weiterhin aus der default.json).


    Die Prioritätskette ist also: default.json < Gruppen-Permission < server.properties-Overrides (optional) < Area-Permission (Default oder spielerspezifisch)


    Zum Fliegen-Beispiel: Wenn in default.json Fliegen nicht erlaubt ist, in der Gruppen-Permission jedoch schon, dann sollte der Spieler eigentlich auch in der Area fliegen dürfen - außer die Area-Permission sagt explizit Nein zum Fliegen. Wenn du hingegen Fliegen nur in der Area erlauben willst, reicht es, in der Area-Permission Fliegen zu erlauben.

    Sorry for the late response! If you don't get a reply within a few days or a week, it's totally fine to bump the topic. Unfortunately I also tend to lose track of the Java sections of the forum (this isn't your fault, it's my fault, restructuring the forum is still on my to-do list).


    However, unfortunately the log files only cover the most recent and previous game session, so they are only helpful immediately after such a problem occurs. Ideally send a report from the game right when you notice that something is missing or weird, this will automatically attach the log files. It's basically the only way to find out what's really happening.


    There is a bug that objects and plants sometimes don't get loaded properly on clientside, but this is typically fixed by reloading the chunk (either by moving away or by reloading the world). Losing objects permanently for no reason is that seems to happen extremely rarely... if someone ran into such an issue before, it was typically related to "Gravity", i.e the objects did break because they had no contact to the ground.


    However, recently I found a bug that caused gravity to break objects in rare cases, even if they had contact to the ground or something solid (originally this issue was raised in connection with blueprints). This might be responsible for the objects to disappear in your case.


    I've also expanded the logging to the "Events.db", so whenever an object is deleted, it will be tracked. When sending a report after the next update, a dump of this file will be attached automatically (this should make it easier to find out why a particular object disappeared).

    But as a quick fix in the meantime, you can turn off Gravity for objects (and plants) in the game settings. That should prevent objects from breaking.

    Can anyone launch fireworks after last update? I've just found that I can't. After I ignite a firework rocket, sparks keep bursting from it for seconds, minutes, tens of minutes... but the rocket doesn't go up. Maybe it's caused by the item placement, that it sticks too strong to the ground?

    Unfortunately it's indeed a bug, as mentioned by LoneRanger :| It affects fireworks, but also dynamite and grenades... but it will be fixed with the next update :)

    This is unfortunately a bug, caused by the gravity checks for objects (and plants) :hushed: If gravity checks are enabled, the game checks if an object/plant has contact to the ground (or a wall), and if there is no contact, the object breaks (if it was just created a few moments ago, the game spawns the object as item instead of breaking it). When placing a blueprint, this check is sometimes executed too early (before the full collision is actually built), so the game thinks the object has no contact to the ground or walls.


    I will try to get this fixed with the next update. But in the meantime you can also disable gravity checks in the game settings (turn off "Enable Gravity for Objects" in the Miscellaneous settings), that should prevent the objects from breaking :)

    Ja, theoretisch können wir das via Permissions auch für den Survival ermöglichen :)


    Du möchtest also in Areas das Teleportieren (überall hin) erlauben und außerhalb der Areas nicht, ist das richtig?


    In dem zusammenhang wehre es nicht Schlecht wenn mann auch nur in Areas hinein Teleportieren könnte. Also von Stadt zu Stadt.

    Das ist wahrscheinlich etwas schwieriger umsetzbar, da Areas auf der Karte nicht angezeigt werden bzw. dort bisher noch nicht berücksichtigt werden... wäre aber trotzdem ein interessantes Feature! Ich packe es auf jeden Fall mal auf die Liste (wirds aber leider nicht mehr ins nächste Update schaffen) :saint:


    Aktuell ist es mit Plugins noch nicht möglich, Karten Interaktionen abzufangen.

    Es wäre wahrscheinlich auch sinnvoll, das in dem Zuge direkt umzusetzen bzw. die nötigen Events (und Kartenzugriff) für die API bereitzustellen :D


    Aber bei beiden Varianten müsste mann noch überlegen, wie mann das auf der Karte Visualisieren kann, das in bestimmte bereiche hinein Teleportiert werden kann.

    Es ist geplant, dass mehr auf der Karte visualisiert bzw. gezeichnet werden kann (Linien, Bereiche usw), damit könnte man dann auch grundsätzlich Areas darstellen ^^


    Generell sollte es eine Teleportmöglichkeit durch das Spiel geben.

    Ein Teleport-System, mit welchem man mehrere Teleportpunkte (dauerhaft) festlegen und bei Bedarf immer wieder dorthin teleportieren kann wird es möglicherweise noch ins nächste Update reinschaffen (sonst spätestens ins Update danach) ;)

    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 :saint: 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 :dizzy:


    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) :saint:


    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 :drunk:

    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]