Posts by red51

    Die Biome ändern im Grunde ja alles bisherige, d. h. alles Terrain geformte und mühsam etstellten eigenen Biome wären nicht mehr zu verwenden. ;(

    Nein, die bestehende Insel bzw. bebaute Inseln bleiben unberührt von der Änderung, d.h. dort bleibt alles wie gewohnt. Neue Biome generieren nur auf neuen, unberührten Inseln. Was allerdings noch fehlt ist eine Option, womit ganze Inseln manuell gelöscht werden können... damit könnte man zB festlegen, dass nur die Startinsel bestehen bleibt und andere Inseln (wo man vll mal einen Block platziert hat) wieder zurückgesetzt werden ^^

    Hey, do you refer to the new version, or the Java version? Basically the game stores all definitions in the "definitions.db" database file (for the new version, it's located in Data/StreamingAssets/). It can be opened with an SQLite editor (e.g. DB Browser). It contains a table called "items" which contains all item definitions, including the path to the model.


    In the Java version, you could basically just replace the model with a new model (but it has to use JMonkey's .j3o file format). For the new version, however, it's a bit more tricky, because the data is stored in a Unity "asset bundle". It's not impossible, but you can't just replace an individual model file in that bundle, instead you would have to extract and repack the whole asset bundle.


    However, it's our intention to make this a bit easier in the near future, so you could load prefabs from a separate asset bundle easily. That way you could pack your custom model in a separate asset bundle and place this bundle in the game folder, then provide the path to that asset in the definitions file (and the game would load it from the new bundle automatically, instead of having to modify existing bundles) :)

    Was passiert, wenn ich den Rechner neu einrichte und das Spiel noch mal installiere? Erheben die dann auch eine Gebühr? Es ist einfach dreist und unverschämt die Nutzungsbedingungen ständig zu ändern. Ich finde es sollten immer die Nutzungsbedingungen gelten, denen man beim Kauf (oder wie in deinem Fall Umstieg auf diese Engine) zugestimmt hat.

    Schwer zu sagen, nach ihrer ursprünglichen Definition ja (da wurde im FAQ jede Neuinstallation explizit als eigenständige Installation genannt). Zwischenzeitlich sind sie etwas zurückgerudet und haben zumindest auf Xwitter geschrieben, dass "nur" noch Installationen auf separaten Geräten zählen. Als Beispiel nannten Sie die Installation auf einem PC und auf einem Steam Deck, was dann als 2 Installationen zählt.


    Wenn du also auf einem neuen Rechner (oder geänderter Hardware) neuinstallierst, dann wäre das eine neue Installation, sonst wohl nicht. Wie genau die das ermitteln oder auseinanderhalten wird aber nicht erläutert X( Generell herrscht viel Ungewissheit, und selbst einige Unity-Devs (also die Angestellten bei Unity) sind offenbar überrascht von der Änderung und wissen kaum nähere Details.


    Das rückwirkende Ändern der TOS ist an Dreistigkeit tatsächlich nicht zu überbieten. Ein "nicht-Zustimmen" ist nicht möglich, selbst wenn man bei einer alten Engine-Version bleibt (da bliebe nur den Verkauf einzustellen)... vor allem hindert niemand Unity daran, die Bedingungen jederzeit in Zukunft weiter zum Nachteil der Entwickler zu ändern.

    Ja, es gibt durchaus einen negativen Bereich ;) Das Spiel bzw. Unity verwendet ein linkshändiges Koordinatensystem: Die X-Achse zeigt also nach rechts bzw. Osten, die Z-Achse zeigt nach vorne bzw. Norden und die Y-Achse zeigt nach oben (also die Höhe). Auf ein Bild übertragen wäre der Nullpunkt also unten links. Die X-Koordinaten sind also dann nach rechts anzuwenden (bzw. nach links wenn der Wert negativ ist) und die Z-Koordinaten nach oben (bzw. unten wenn negativ).

    Ich habe den Beitrag mal in die Plugin-Sektion verschoben :saint:


    Das Problem ist also wenn ich das richtig verstanden habe, dass der Server nicht mehr richtig herunterfährt oder neustartet sobald das InputEvent verwendet wird? Ich konnte das Problem soweit leider nicht bei mir reproduzieren, zumindest unter Windows :wat: Der Server sollte also weiterhin regulär neustarten, außer im InputEvent wird irgendwas gemacht, was das verhindert oder blockiert... leider kann ich das momentan nicht unter Linux testen.


    Handelt es sich bei dir denn um einen Linux oder Windows Server? Ggf. wäre ein vollständiger Log hilfreich... unter Windows kannst du den bekommen, wenn du die RisingWorldServer.exe zB mit diesem Befehl startest: RisingWorldServer.exe 1> serverlog.log 2>&1 - dann sollte eine serverlog.log angelegt werden. Starte den Server dann mit dem "restart" Befehl neu, und wenn das nicht funktioniert, sende mir bitte einmal diese Log-Datei :)

    Hey red51, wann können wir mit dem nächsten Update etwa rechnen? :P In ein, zwei, drei, sechs Monaten? :D

    Schwer zu sagen, wann das Update genau kommt... grundsätzlich sind die Reittiere quasi fertig, aber wir arbeiten momentan noch an den Biomen & Höhlen. Letzteres ist zwar ursprünglich als separates Update geplant gewesen, aber das Problem ist, dass wenn wir jetzt die Reittiere veröffentlichen, wir erstmal für ca. 2-3 Wochen nicht mehr weiter an Biomen und Höhlen arbeiten können (denn in der Zeit würde das Reittier-Update in den Vordergrund rücken, d.h. zusätzlicher Aufwand für Hotfixes usw).


    Entweder wir finden in Kürze einen guten Punkt, an dem wir die Arbeit an Biomen & Höhlen erstmal unterbrechen können (damit das Reittier-Update raus kann), oder wir packen es doch zu einem großen Update zusammen... mal sehen...


    Unser oberstes Ziel ist natürlich der Austausch der Java Version, alleine auch aus finanzieller Sicht. Denn im Grunde haben wir an den letzten Updates ja kein Geld verdient, da die Updates in erster Linie an die Bestandscommunity gerichtet waren. Das ist auch wichtig und wir fühlen uns dem verpflichtet, doch langsam drückt auch der Schuh, dass endlich die neue Version auf der Storepage erscheinen kann (und hoffentlich auch ein paar neue Verkäufe generiert) :saint:

    Je mehr Updates es bis zu diesem Zeitpunkt gibt, desto weiter verschiebt sich das ganze leider (da wie gesagt, jedes Update für sich Arbeit erfordert). Natürlich ist es auch doof, wenn ewig kein Update kommt (und wenn Updates zu riesig werden, dann ist das Beheben von Bugs usw umso aufwändiger), daher müssen wir da den passenden Mittelweg finden.


    Nachdem die Java Version endlich ersetzt wurde können wir uns aber auch wieder kleineren (und damit häufigeren) Updates widmen :)


    Red hat sicher gerade ganz andere sorgen
    der kann auf hören wenn Unity das wirklich umsetzt

    ich drück dir alle daume das sie es nicht um setzten Red

    Vielen Dank! Diese Änderungen sind tatsächlich der purste Irrsinn :wat: Da Unity künftig jedes Mal eine Gebühr haben möchte, wenn ein Spieler das Spiel installiert, und diese Änderung auch rückwirkend gilt, bedeutet das, dass Unity auch für alle Java-Verkäufe aus der Vergangenheit kassieren wird (obwohl wir ja damit kein zusätzliches Geld einnehmen). Gleichzeitig würde die Gebühr fällig, wenn ein neuer Kunde das Spiel refunded (wir also gar kein Geld verdienen) oder kostenlos über Family Sharing spielt. Und selbst wenn jemand das Spiel illegal runterlädt und crackt müssten wir zahlen, was an Lächerlichkeit nicht mehr zu überbieten ist.


    Diese Änderung führt in der jetzigen Form zu unvorhersehbaren Kosten. Man muss mal abwarten, was letztenendes nun wirklich dabei herumkommt und ob Unity ggf. zurückrudert. Die Ankündigung hat jedenfalls bereits einen massiven Sh*tstorm ausgelöst (nachvollziehbar), und es sind auch haufenweise Spiele davon betroffen (Rust, 7d2d, VRChat, BattleBit usw) :thinking:

    Spieler mit identischem Namen sollte es auf einem Server nicht geben, d.h. wenn mehrere Spieler mit gleichem Namen connecten, dann werden die Namen durchnummeriert (mit vorangehendem Unterstrich) ;) Also der erste Spieler heißt noch "Musterspieler", der 2. Spieler heißt dann "Musterspieler_1", dann "Musterspieler_2" usw.

    Auf diese Art wird der Spieler in den Konsolenbefehlen auch angesteuert, also zB "kick musterspieler_2". Alternativ kann ansonsten in nahezu allen Konsolenbefehlen auch die eindeutige UID des Spielers verwendet werden (diese kann zB aus der Spielerliste heraus kopiert werden).


    Als Serveradmin kannst du übrigens auch Namen reservieren, d.h. an eine bestimmte UID binden. Dazu kann im Serververzeichnis eine Datei "reservednames.txt" angelegt werden und dort pro Zeile Name : UID angegeben werden. Beispiel: Musterspieler : 76561197960265728 würde dafür sorgen, dass nur noch der User mit der UID 76561197960265728 den Namen "Musterspieler" benutzen kann (dann gibt es auch kein "Musterspieler_2" usw mehr).


    Nicknames sind leider nicht möglich... das würde vmtl. auch ein paar Fragen aufwerfen, zB was passiert, wenn "Musterspieler" der Nickname "Dude" gegeben wird, aber es auch einen anderen Spieler gibt, der bereits "Dude" heißt? Bei Serveradmins (oder auch Stammspielern) ist es ggf. überlegenswert, sich den Namen stattdessen auf o.g. Weg zu reservieren ^^

    Oh achso :saint: D.h. dein neuer Minimalwert (im obigen Beispiel) soll dann 1271.881592 sein (das ist also die neue "0") und der Maximalwert 4896.146484 (die neue "999")? Bzw anders gesagt, du möchtest 1271 bis 4896 in den Bereich 0 bis 999 bringen?


    Gehen wir davon aus wir speichern unseren erlaubten Wertebereich (0-999) als Konstanten (MIN und MAX). Unsere Koordinate 1271.881592 speichern wir als $min und 4896.146484 als $max. Wir würden nun erstmal die Differenz zwischen $min und $max berechnen ($max - $min). Anschließend ziehen wir $min noch von unserem Eingabewert (nennen wir ihn $value, also die Koordinate, die du in den Bereich 0-999 bringen willst) ab und teilen das dann durch unsere neu berechnete Differenz: ($value - $min) / ($max - $min). Das ergibt einen Wert zw. 0 und 1. Fügen wir nun noch MIN und MAX hinzu, erhalten wir den Wert zwischen 0 und 999 (MIN + (MAX - MIN) * $value). In eine Funktion gepackt könnte das in PHP so aussehen:


    Code
    define("MIN", 0);
    define("MAX", 999);
    function getCoordinate(float $value, float $min, float $max) {
    //Wert in Bereich 0-1 umrechnen
    $value = ($value - $min) / ($max - $min);
    //Wert in Bereich zwischen MIN und MAX umrechnen
    return MIN + (MAX - MIN) * $value;
    }


    Beispielausgaben:

    Ich bin mir nicht sicher, ob ich die Problematik richtig verstanden habe :saint: Heißt das, du möchtest eine Weltkoordinate des Spiels auf den entsprechenden Map-Tile umrechnen (d.h. in dem Fall immer in den Bereich von 0-999 bringen)? In dem Fall ist der Modulus bzw. Modulo hilfreich: In den meisten Sprachen (einschl. PHP) ist das der % Operator. Bei einer Tile-Größe von 1000x1000 würde das zB so aussehen: 1271 % 1000 ergäbe 271, 4896 % 1000 ergäbe 896 usw (also immer einen Wert zw. 0 und 999).


    Wenn du auch den "Offset" des Map-Tiles möchtest (1271 wäre ja zB im 2. Tile, während 4896 im 5. Tile wäre etc) kannst du einfach eine Ganzzahldivision durchführen (in PHP könntest du dafür intdiv() verwenden). Beispiel: intdiv(1271, 1000) ergäbe 1 (also der 2. Map-Tile, wenn man bei 0 anfängt zu zählen), intdiv(4896, 1000) ergäbe 4 (also Map-Tile 5) usw ;)


    Oder habe ich das falsch verstanden und stattdessen möchtest du in deinem Beispiel, dass 1271.881592 = 0 entspricht und 4896.146484 = 999? Oder bin ich vll komplett auf dem Holzweg? :drunk:

    Sorry für die späte Antwort, wollte mich schon früher melden :drunk: Ich habe mir aber mal das Problem mit den Animatoren genauer angeschaut: Wenn du über einen Animator eine Material-Eigenschaft änderst, dann fügt Unity unter der Haube einen sog. MaterialPropertyBlock hinzu (was die normalen Material-Eigenschaften überschreibt). D.h. reguläre Änderungen über setMaterialParameter() haben keinen Effekt mehr (bis der Animator gelöscht wird).


    Leider bleibt der MaterialPropertyBlock auch nach dem Deaktivieren des Animators aktiv. Wir werden mit dem nächsten Update aber eine neue Funktion clearMaterialPropertyBlock() einbauen, mit welcher du den MaterialPropertyBlock löschen kannst ;) Das funktioniert aber nur, wenn der Animator deaktiviert wird (sonst fügt Unity sofort wieder einen neuen hinzu). Das könnte in deinem Fall dann zB so aussehen:

    Java
    //Disable component on main prefab element
    prefab.setComponentEnabled(null, "Animator", false);
    //Remove material property blocks from child element (first mat)
    prefab.clearMaterialPropertyBlock("Neu_Mimic_gehen/Cylinder.002", 0);


    Bis dahin wäre aktuell der einzige Workaround, den Animator zu löschen (danach kannst du ihn aber logischerweise nicht mehr verwenden). Das ist also nur sinnvoll, wenn du den Animator nicht mehr brauchst... Löschen kannst du ihn via Prefab.removeComponent() , also zB prefab.removeComponent(null, "Animator");


    Bis zu den Animationen hatte ich noch nicht gedacht, aber ja, hier wehre es interresannt ein Objeckt an einen Bone zu Befestiegen (Sowas wie Waffe oder Hut). Das sollte dann aber schon, irgendwie mit dem Client Verbunden sein. Also das mann ein ChildObject an einen Bone Binden kann, das ChildObject könnte man Ein/Aus Blenden

    Meinst du ein Hinzufügen an Bones bzw. Childs eines Prefabs, oder an beliebige Elemente im Spiel (zB Hände des Spielers oder eines NPCs)? Grundsätzlich wäre das möglich (und auch praktisch), das Problem ist nur, dass ein Löschen des Parents (zB wenn der NPC stirbt) automatisch das Prefab löschen würde... wir müssen mal schauen, dass wir das entsprechend abfangen :thinking: Wir machen uns dazu mal Gedanken ^^


    ^^ Ja, wie machst du das mit dem Schatten/der Schatten Seite?
    Deine Objecte sind niemals Schwarz solange Licht in der nähe ist ^^. Benutzt du den Standard Lit Shader?

    Aber wenn das zu den Geheimnissen gehört ist auch gut ;)

    Wir verwenden zwar einen eigenen Shader, allerdings sollte das keine große Rolle spielen :wat: Ich konnte das Problem tatsächlich mit deinen Prefabs reproduzieren... es scheint so, dass die Prefabs kein indirektes Licht erhalten. Offenbar schmeißt Unity beim Builden des Asset-Bundles die notwendigen Shader-Varianten raus ||


    Ich muss mal schauen, wie man das am besten verhindern kann! Ich melde mich nochmal, wenn ich weitere Infos habe.


    In Unity gibt es doch für Color den Default Mode und den HDR Mode, bei dem kann noch die Intensity eingestellt werden, wo die Farbe zu Leuchten begint.
    Ähnlich wie setMaterialParameter("", "Color", new Vector4f(1, 1, 5, 1));, da sehe ich gerade das ColorRGBA ja nur 0-100% kann und das bräuchte ein bereich von 0-100%+x%, :lol:

    Ich meinte den Multiplikator

    Achso :D Also grundsätzlich kann das ColorRGBA beliebige Farben repräsentieren (da die einzelnen Farbwerte als float gespeichert werden), d.h. auch Bereiche außerhalb von 0-1 sind möglich. Das Problem ist nur, dass so eine Farbe nicht mehr als int repräsentiert werden kann. Die API verwendet leider an vielen Stellen nur ints für die Farben.


    Da aber das Spiel bisher aber beim Colorpicker keine Intensität benötigte, fehlt diese Funktionalität... ich schaue mal, was wir da am besten machen könnten :thinking:


    Kann der ColorPicker in eine UI eingebaut werden?

    Leider ist das momentan nicht vorgesehen, da der ColorPicker bislang als eigenständige Message Box konzipiert ist...


    Ginge das auch für "GameObject" und "UIElement" :D

    Ja, das können wir grundsätzlich einbauen ;)

    1. Wenn 2 Personen in einer Truhe sind und einer von beiden raus geht wird der andere auch aus der Truhe geworfen und dabei ist es egal in welcher Truhe man ist. Das gleiche passiert auch wenn

    einer von beiden im Inventar ist, sobald einer aus eine Truhe geht wird der andere aus dem Menü geworfen.

    Das ist leider ein Bug, wie noci schon sagt. Der Bug hat sogar eine relativ banale Ursache: Wenn ein Spieler sein Inventar schließt, schließt das Spiel auch automatisch die Kiste. Das wiederum schließt das Inventar aller anderen Spieler, die ebenfalls auf diese Kiste zugreifen. Das werden wir noch beheben ;)


    Grundsätzlich unterstützt das Spiel aber den gleichzeitigen Zugriff mehrerer Spieler auf eine Truhe ^^


    2. hatte mein Mitspieler das Problem wenn er im Berg graben war das die Welt auf reist (nicht richtig ladet) sie Bilder

    Hmm... probiere am besten mal, die Welt neuzuladen, wie noci vorschlägt. Bestehen die Risse danach immernoch?

    Unfortunately your permissions don't contain any settings for images. It just works for you because permissions are ignored for server admins by default (you can disable this behaviour by setting "Permissions_AdminsFullPermissions" to False in the server.properties file btw).


    To define the image limit in the permissions, you have to set maxamount in the image category. If you want all players to be affected, it's sufficient to just change that in the default.json file (all group permissions inherit their permissions from that file). This is how image permissions could look like:

    JSON
    "image": {
    "maxamount": -1,
    "maxresolution": 512,
    "delete": false,
    "deleteown": true
    }


    This post also contains an overview of all permissions (including a description and examples): RE: Permissions [New Version]


    I've updated your default.json file, please find it attached (you can find the added "image" part after the "blueprint" part) ;)

    Files

    • default.json

      (3.42 kB, downloaded 364 times, last: )

    The problem indeed appears to be happening in the Portals plugin, as mentioned by yahwho , but in fact that seems to be just a follow-up error :thinking: According to the report you've sent, there is an error in the UnityBundleLoader plugin. This apparently causes issues when using the reloadplugins command.


    According to the log, an old version of the UnityBundleLoader plugin was used (0.0.1). I was able to reproduce the issue with that version, but it seems to be fixed with the latest version (0.0.2), so I would recommend to install the latest version of that plugin ;)

    Resetting the gap to zero by a command would be really helpful :D

    We could add a gap command to set an arbitrary gap for the currently active element directly (you could then just pass 0 to reset the gap) ;)

    No precision, that's right, but a way to switch to normal with backspace. in the unity-version it's like yahwho mentioned, very very unfriendly to set the gap distance to 0.

    So this means you want the precision to be removed and a hard-coded value to be used instead? Idk if that's really an improvement.


    The Java version didn't have a way to set the gap size to 0 either, and binding it to backspace may be a bit confusing (considering backspace already resets the rotation/scale).

    Grundsätzlich wäre das möglich, nur leider ist es schwierig, das als Option anzubieten... denn einerseits bestimmen diese Zusatzdaten, wie die Items im Inventar gespeichert bzw. serialisiert werden. Andererseits wird das Inventar immer serverseitig bestimmt, sodass zumindest im MP bei Clients abweichende Einstellungen auf Ecken und Kanten stoßen würden :/ Das umzusetzen wäre zwar kein Ding der Unmöglichkeit, dazu müssten wir uns aber mal Gedanken machen :thinking:


    Oder man legt das direkt als Standardverhalten fest, allerdings weiß ich nicht, ob das wirklich immer sinnvoll ist :monocle: Es gibt vmtl. auch Situationen, wo geringfügige Abweichungen in der Größe dazu führen, dass Blöcke im Inventar nicht mehr gestapelt werden (was das Inventar dann generell spürbar voller machen könnte)... das könnte ggf. ungewollt sein.

    Thanks for the log! As mentioned by noci , it's caused by an incompatible version of the "ToolsAPI" plugin. Replacing it with the latest version of that plugin should do the trick ;)

    Sorry for my late response, unfortunately I missed your initial post :/ But I'm glad to hear you managed to solve the problem :)


    As for the scheduler for the server........ god knows why its non functional.. I will get to the bottom of it eventually

    Hmm... if the scheduler contains any errors, the log usually provides more information about that :thinking: Do you mind sending me the scheduler file, so I can take a closer look at it? You can either upload it here or send it via PM to me :)