Posts by red51

Das ist leider noch ein kleiner Bug, meistens passiert das, wenn ein Item bereits ausgerüstet ist, und dann direkt aus dem Inventar heraus ein gleichartiges Item direkt ausgerüstet wird... das werden wir auf jeden Fall noch beheben

Unity ist mittlerweile zurückgerudert und sie haben ihre "Runtime Fee" entschärft. Der neue Ansatz ist deutlich vernünftiger - hätte Unity das von Anfang an so gemacht, hätte es wohl kaum einen solchen Shitstorm gegeben... Unity kündigte an, dass man nun wahlweise entweder 2,5% des Umsatzes zahlen könne, oder eine fixe Gebühr pro neuem Spieler. Außerdem soll das neuerdings erst ab 1 Mio Umsatz greifen, wovon wir eh meilenweit entfernt sind.

Für RW ändert sich so oder so nichts Die Änderung ist beruhigend, aber auch sonst hätten wir das Projekt fortgeführt. Der nächste Meilenstein wird der Austausch der Java-Version sein, von welchem wir nicht mehr unendlich weit entfernt sind. Und danach werden wir definitiv die 1.0 anpeilen, egal wie steinig der Weg dorthin noch wird (so kurz vorm Ziel aufzugeben wäre ohnehin keine Option)

Ein weiterer Engine-Wechsel ist leider nicht mehr drin, wie Yarofey schon sagt Dafür fehlen uns einfach die finanziellen Mittel, und ich fürchte auch, dass nicht jeder in der Community happy darüber wäre... wir müssen das mit der neuen Version jetzt so durchziehen. Zumal wir jetzt bereits so kurz vorm Ziel sind.

Mal abwarten, was jetzt wirklich bei rumkommt. Die Ankündigung durch Unity hat enorm hohe Wellen geschlagen. Manche langjährigen Unity-Mitarbeiter haben daraufhin gekündigt, ein Unity-Angestellter hat gar eine Morddrohung gegen die Führungsriege ausgesprochen Mal sehen, wie es jetzt weitergeht.

Quote from SonoBionda

Es ist ja auch nicht gesagt, dass andere Engine Betreiber nicht auch irgendwann auf blöde Abzocke Ideen kommen.

Das könnten zwar grundsätzlich auch andere Engines so machen, aber zumindest Unreal hat seine TOS so ausgestaltet, dass sie nicht rückwirkend geändert werden können. D.h. wenn Epic so eine Änderung durchdrücken würde (was sehr untypisch für Epic wäre), dann könnte man einfach bei der aktuellen Engine-Version bleiben und würde dann noch unter die alte TOS fallen.

Das perfide bei Unity ist ja, dass die Änderung rückwirkend gilt. Selbst wenn man also eine alte Engine-Version verwendet, werden die neuen TOS gültig

Quote from SonoBionda

Naja, ich hätte da mal ne andere Frage noch: würde es die Updates evtl. schneller machen, wenn es einen "UpdateBranch" gibt und wir helfen könnten Fehler zu finden bevor es an die "Masse" geht?

Ich denke schon, dass hier gerne einige erfahrene Spieler helfen möchten und dies ein Zeitgewinn sein könnte.

Tatsächlich ist genau das unsere Absicht sobald die Java Version durch die neue Version ersetzt wurde Es wird dann voraussichtlich einen neuen Branch geben, in welchen Updates zuerst veröffentlicht werden. Erst nach ein paar Tagen bzw. wenn die gröbsten Bugs behoben sind geht das Update dann in den public Branch.

Der Grund ist, dass wir bei der neuen Version leider nicht mehr "mal eben so" einen Hotfix rausbringen können Bei der Java Version hat das Kompilieren ca. 10 Minuten gedauert, in Unity hingegen dauert es zwischen 1-4 Stunden.

Updates werden damit aber insgesamt leider wohl nicht wirklich schneller... es geht nur darum, Stress und Ärger zu reduzieren.

Quote from Deirdre

red51 Könnte man bei Postern , wie in der Java-Vesion, den Logartithbuffer einbauen?

Nein, das ist technisch leider nicht möglich, würde allerdings auch nicht viel bringen. Die neue Version hat bereits einen Tiefenbuffer mit hoher Präzision. Wenn sich zwei Oberflächen an exakt derselben Position befinden, dann flackern diese immer (sog. "Z-Fighting"), da bringt auch die höchste Präzision nichts. Das Spiel verhindert das Flackern nur, indem jedes Bauteil minimal versetzt wird.

Inwiefern flackern die Poster denn? Flackern sie mit dem dahinterliegenden Bauteil (also die Wand wird zwischenzeitlich sichtbar), oder flackern mehrere übereinanderlappende Poster?

Quote from Deirdre

Der weiße Rand auf dem Bild ist im Original nicht zu sehen

Kannst du das Bild evtl. einmal hier hochladen oder mir per PN senden? Haben alle Instanzen dieses Bildes den weißen Rand, oder nur dieses eine Poster?

Quote from TheKing

Hallo red51 Ich habe da auch ein kleines Problem mit dem Poster.
Und zwar habe ich einen Vorhang, den ich vor das Fenster machen möchte.
Nur ist es so das es von vorne richtig zu sehen ist, aber von der anderen Seite leider nicht.
Ich habe den Vorhang gespiegelt, falls das eine Rolle spielt.

Besteht das Bild aus dem ganzen Vorhang, oder ist das Poster jeweils nur eine Seite bzw. die Hälfte des Vorhangs?

Das Problem ist leider, dass die Rückseite des Posters nicht gespiegelt ist... d.h. wenn zB ein Schriftzug platziert wird, dann ist der Schriftzug auch von der Rückseite lesbar (statt dort dann gespiegelt).

Evtl. macht es Sinn, wenn wir das ändern Das Problem könnte nur sein, dass bestehende Poster evtl. dann gespiegelt erscheinen (falls Leute sie bereits so platziert haben, dass nur die Rückseite sichtbar ist)...

Yes, this is correct Once custom asset bundle loading is implemented (basically there isn't too much work involved to get that ready), you could indeed easily replace a sword with a baguette (it would then still behave like a sword) and you could even adjust the amount of damage the baguette deals per hit (this is defined in the definitions.db)

We'll provide more information about that in the future^^

Danke für das Video! Das ist wirklich eigenartig... der Log wäre auf jeden Fall hilfreich, und falls du mir die Plugins auch zusenden kannst, mit welchen sich das Problem reproduzieren lässt, wäre das natürlich super!

Quote from Sandboxgamer

Eine Weitere Bitte: Wenn man den Server herunterfährt, werden die onDisable() nicht ausgeführt. Ich scheibe in jedes onDisable() ein System.out.print("[Pluginname] Disabled"), was aber nicht in der Konsole oder im "normalen" Log unter "Logs" auftaucht. Dies ist aber nötig, da bei manchen Plugins z.B. Datenbanken gespeichert werden und wenn da ein Fehler kommt, kann man kein Debug machen, da nichts angezeigt wird.

Doch, onDisable() sollte eigentlich ausgeführt werden. Beim Herunterfahren des Servers werden aber zum Schluss nicht mehr alle Ausgaben in den Log geschrieben (da der File-Stream dann bereits geschlossen wird).

Du kannst aber verifizieren, dass onDisable() ausgeführt wird, indem du die exe des Servers über die Eingabeaufforderung startest (denn dann landen automatisch alle Ausgaben in der Konsole und das Fenster bleibt nach Herunterfahren aktiv)

Quote from reydelreyes

Egal wie die zurückrudern, allein diese dreiste idee in die Welt zu setzen sollte Arbeitslosigkeit und enteignung nach sich ziehen.

Der Schaden ist definitiv angerichtet, selbst wenn sie zurückrudern... und langsam glaube ich, dass da nicht mehr viel zurückgerudert wird. Frei nach dem Motto "Ist der Ruf erst ruiniert, lebt es sich ganz ungeniert"

Wenn wir in Zukunft nochmal ein anderes Spiel machen würden, werden wir einen großen Bogen um Unity machen. Die letzten Jahre ist kaum etwas bei Unity passiert, und "Gaming" ist dort generell immer weiter in den Hintergrund gerückt, während die Unreal Engine ein dickes Feature nach dem anderen bekam. Selbst bei Godot ist wesentlich mehr in den letzten Jahren passiert. Diese Lizenzänderung ist natürlich mit Abstand die Krönung...

Quote from Arakara

Frage an red51 wie nah oder fern ist Rising World von den verdient-Grenzen (vor Steuern oder nach Steuern weiß wahrscheinlich auch keiner)? Und auf wieviele lebenslange-Installationen kam RW bisher?

Die Verdienst-Grenzen sind üblicherweise der Bruttoumsatz des Spiels, d.h. einerseits enthalten sie noch MwSt, andererseits auch noch die 30% von Steam. Die 200K $ Grenze bedeutet also effektiv, dass "nur" ca. 110K EUR bei uns ankommen. Davon müssen dann noch alle Firmenkosten (Serverkosten, Lizenzkosten usw) sowie Steuern bezahlt werden.

Derzeit sind wir zwar tatsächlich weit von der Grenze entfernt, allerdings decken die Einnahmen momentan auch bei weitem nicht unsere mtl. Kosten. Der Zustand muss sich dringend ändern.

Die Gesamtzahl an Installation kennen selbst wir übrigens nicht Es gibt aber über 200K RW Besitzer.

Quote from SonoBionda

Wenn ich das richtig verstehe, dann wäre es jetzt zunächst einmal wichtig, dass alle Java Spieler auch direkt mal die UnityVersion vor dem 01.01. installieren, sofern noch nicht geschehen

Grundsätzlich ja, für den Gesamtschwellenwert berücksichtigt Unity aber sämtliche Installationen, auch rückwirkend.

Quote from SonoBionda

Ich bin jetzt nicht son TechnikFreak ... aber woher wollen die bitte wissen, wie oft oder wann ich etwas installiere? Ich würde jetzt mal annehmen, dass die Engine bereits in dem Spiel ist (von den Entwicklern dort reingepackt) ... oder kommt man beim Installieren eines Spiels mit dem Engine Betreiber in Kontakt? Oder verlangen sie Daten/Mitarbeit von Steam? Wie ginge das dann mit einer Standalone?

Auch das verrät Unity leider nicht. Selbst wir wissen nicht, wieviele Installationen es jemals gab. Unity sagt, sie verwenden ein "proprietäres Modell" um die Installationen zu ermitteln, zu dem sie keine weiteren Infos geben wollen. Lt. ihrer Aussage wird die Installationsanzahl wohl effektiv nur geschätzt. Mit anderen Worten: Ihre Quelle ist "Trust me, Bro"

Quote from SonoBionda

Und was ist überhaupt mit Servern (die doch gerne mal neu aufgelegt werden) ?

Tja, momentan sieht es noch so aus, dass auch eine Serverinstallation die Kasse bei Unity klingeln lässt Was natürlich besonders toll ist, da unser Server kostenlos verfügbar ist und von jedem heruntergeladen werden kann...

Quote from SonoBionda

Wie dem auch sei ... wenn die Unity irgendwann auch als Standalone erscheinen wird, möchte ich einen Key dafür kaufen (und nicht installieren)

Grundsätzlich ist die Unity Version auch bereits als Standalone verfügbar Es handelt sich dabei um einen separaten Launcher.

Quote from Ludy

das schlimmst ist man könnet Installier-Bot-Farmen bauen und dardurch leute wie red finanizel töten

Diese Sorge steht tatsächlich im Raum (nicht nur auf RW bezogen). Neben "Review-Bombing" könnte sich auch "Install-Bombing" etablieren. Unity sagt zwar, dass Mehrfachinstallationen auf demselben Rechner nicht zählen, definitiv aber Installationen auf neuen Geräten (zB auf einem 2. PC).

Es steckt nur minimaler Aufwand dahinter, ein Script zu schreiben, welches jedesmal automatisiert eine neue virtuelle Maschine erstellt (= neues Gerät), das Spiel darauf installiert, eine neue virtuelle Maschine erstellt (= wieder neues Gerät), erneut das Spiel installiert usw.

Unitys Aussage dazu ist dieselbe wie bei Raubkopien: Wenn sowas passiert, solle man sich an Unitys Support wenden. Das ist absolut realitätsfremd, denn wir wissen selber nicht, wenn sowas passiert, geschweige denn, dass wir es irgendwie beweisen könnten. Vor allem hat man auch besseres zutun, als jeden Monat mit Unity zu diskutieren, wo die Installationen herkommen (und effektiv kommt es dabei dann letztenendes nur auf Unitys Gnade oder Ungnade an)

Quote from Desmagu

Am Ende werden Entwickler noch gezwungen lootboxen in Spiele einzubauen damit nicht die Entwickler sondern der CEO von Unity Geld kassiert

Der Unity CEO hat noch letztes Jahr alle Entwickler, die sich gegen Monetarisierung in ihrem Spiel entscheiden, als (wörtlich) "biggest fucking idiots" bezeichnet

Quote from Desmagu

Ich dachte ich wäre durch EA und R* abgehärtet aber die Verantwortlichen von Unity haben es tatsächlich geschafft, dass ich wieder entsetzt bin.

Naja, der jetzige CEO von Unity (John Riccitiello) war zuvor CEO bei EA, also passt ja irgendwie wieder zusammen

Quote from Deirdre

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)

Quote from Desmagu

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

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

Quote from Hintzi

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

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)

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

Quote from Ludy

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

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

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:

$min = 1271.881592
$max = 4896.146484

echo nl2br(getCoordinate($min, $min, $max) . "\r\n");
echo nl2br(getCoordinate($max, $min, $max) . "\r\n");
echo nl2br(getCoordinate($min + ($max - $min) * 0.5, $min, $max) . "\r\n");

//AUSGABE:
//0
//999
//499.5

Ich bin mir nicht sicher, ob ich die Problematik richtig verstanden habe 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?

Sorry für die späte Antwort, wollte mich schon früher melden 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:

//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");

Quote from noci

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 Wir machen uns dazu mal Gedanken

Quote from noci

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 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.

Quote from noci

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%,

Ich meinte den Multiplikator

Achso 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

Quote from noci

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...

Quote from noci

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

Ja, das können wir grundsätzlich einbauen

Quote from der_run

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

Quote from der_run

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:

"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)