Posts by red51

Quote from Deirdre

Der Text auf den Schilder ist zu dunkel, ohne Hilflicht fast nicht lesbar

Naja, die Java Version hatte als vorgegebene Farben quasi nur Neonfarben Das vordefinierte Rot in der Java Version hatte den Farbcode #FF0000, das vordefinierte Blau war #0000FF, das Grün war #00FF00, Gelb war #FFFF00, das Weiß war #FFFFFF usw. Wenn ich genau diese Farben in der neuen Version verwende, dann sind die Farben ebenfalls sehr hell:

Selbst bei Dämmerung, also bei schlechteren Lichtverhältnissen, ist die Schrift dann gut zu lesen:

Wie gesagt, das sind exakt die Farben, die die Java Version vorgegeben hat. Wenn zB eine dunklere Farbe gewählt wird, dann erscheint sie natürlich auch entsprechend dunkler.

Quote from Deirdre

Den Sinn des Pfeils nach rechts -> konnte ich nicht ergründen.

Das ist, wie room6675 schon sagt, ein Art "Vorschau-Button": Die Texte der Schilder unterstützen sog. Rich Text, d.h. du kannst Teile der Schrift zB anders einfärben, durchstreichen, unterstreichen, hochstellen, die Größe anpassen usw. Wenn der Vorschau-Button dann gedrückt gehalten wird, kann man den fertigten Text betrachten (und ggf. mit den Schildrändern abstimmen).

Beispiel: Wenn du zB Hallo <color=red>Welt</color> schreibst, dann wird "Welt" rot eingefärbt. Hier ein Beispiel verschiedener Formatierungen:

Hier der Text dazu:

Das ist ein <u>Beispiel</u>
für <color=red>RichText</color>
Gerne <color=yellow>gelb</color> oder <i>kursiv</i> 
oder <size=200%>Groß</size>...

Langfristig können wir diese Sachen generell in den Texteditor integrieren, damit man quasi wie in einem klassischen Texteditor (wie Word) den Text formatieren kann, aber das war aus Zeitgründen leider bisher nicht möglich, daher geht das nur manuell.

Wir werden dafür aber noch eine Hilfe bereitstellen sowie eine Übersicht über die unterstützten Rich Text Tags. Hier eine ganz grobe Übersicht (aber nicht alles davon ist unterstützt):

Der Pfeil bzw. "Play" bzw. Vorschau-Button ist dann dazu da, die Formatierung anzuwenden, damit du eine Vorschau davon sehen kannst.

Quote from Forscherdrang

Es wäre natürlich super, wenn man die kompletten Einstellungen kopieren & Einfügen könnte.

Ja, da stimme ich zu Entweder packen wir das direkt in den Texteditor rein, oder ggf. als Option im Radialmenü (wenn man das Schild anwählt)

Quote from Forscherdrang

Die transparenten Textposter werden leider Absurd gigantisch, wenn man bloß 1 kurze Zeile mit großer Schrift hat.

Hmm... wenn du das transparente Schild auf normaler Größe belässt (also 1x1), dann sollte es anschließend (nach dem Setzen von Text) von der Größe her eigentlich nur so groß wie der Text selber sein Wenn das Schild aber vorher skaliert wurde, dann wird es proportional mit dem Text vergrößert (was dazu führt, dass das eigentliche Schild u.U. viel größer als der Text ist)... das ist nicht optimal... das werden wir nochmal anpassen. Aber wie gesagt, bis dahin einfach die Größe des Schildes auf Standard belassen, dann sollte es eigentlich keine Probleme geben

Quote from Deirdre

Die Leuchtkraft der Schilder ist in der Unity nicht besonders ausgeprägt, schlecht zu sehen irgendwie.

Wie oben gesagt, es kommt eigentlich nur auf die gewählte Farbe an... ggf. auch auf die Farbe des Schildes selbst, aber das kann ja - wie von Ludy erwähnt - auch geändert werden. Aber auf meinen geposteten Bildern oben kann ich eigentlich nicht unbedingt bestätigen, dass die Farben grundsätzlich zu dunkel wären

Quote from Deirdre

Beim nächsten Beispiel kann man erkennen, dass das durchsichtige Schild zwar vergrößert werden kann, aber im Gegensatz zur selbst gestalteten Schrift nicht separat skaliert werden kann, sondern nur an an allen Enden gleichzeitig, sodass die Schrift dadurch etwas merkwürdig verzerrt aussieht.

Generell ist es so: Beim durchsichtigen Schild orientiert sich die Textgröße an den Proportionen des Schildes. Wenn das Schild zB auf Standardgröße belassen wird (1x1), dann ist die Schrift frei von Verzerrung. Wenn das Schild proportional vergrößert/verkleinert wird (was nicht unbedingt nötig ist), also zB auf 2x2, 3x3 usw, dann sollte die Schrift ebenfalls nicht verzerrt werden. Wenn aber das Schild doppelt so breit wie hoch gemacht wird (zB 2x1), dann ist die resultierende Schrift in die Breite verzerrt. Wenn es höher als breit gemacht wird (zB 1x2), ist die Schrift in die Höhe skaliert.

Das war so beabsichtigt, weil das der einzige Weg ist, verzerrten Text zu haben (was ja manchmal gewollt sein kann). Auf den anderen Schildern ist Text hingegen nie verzerrt. Wir könnten das ändern, aber dann sind verzerrte Texte nicht mehr möglich.

Wie gesagt, verzerrte Schrift kannst du vermeiden, indem du Schilder immer gleich lang und breit belässt. Grundsätzlich kannst du Schilder auch auf der Größe 1x1 belassen.

Quote from room6675

Vielleicht wäre es besser gewesen die JAVA-Version weiter zu entwickeln als auf eine komplett neue Engine umzusteigen. Was aus meiner persönlich besser geworden ist, ist das Bausystem mit den Neigungen und den Andockpunkten. Die Grafik hat sich zwar verbessert aber der Landschaftsgenerator war vorher auch besser, kaum halbwegs ebenes oder nur leicht welliges Gelände zum gescheiten Bauen.

Es ist schade, dass du die neue Version unterm Strich schlechter findest als die Java Version... es kommt sporadisch tatsächlich immer wieder vereinzelt Kritik an nahezu sämtlichen Aspekten der neuen Version. Manche beschweren sich über das Bausystem, manche finden das Crafting schlechter, manche mögen die neuen Tiere nicht, manche empfinden Blaupausen als unbrauchbar, und vor einiger Zeit wurde sich sogar über die Grafik beschwert, dass diese in der Java Version deutlich besser gewesen sei...

Ich versuche in solchen Fällen immer wieder die Kritikpunkte so gut es geht nachzuvollziehen, aber manchmal ist mir das leider einfach nicht möglich Es gibt zwar bei vielen Features der neuen Version noch Luft nach oben (so auch die Schilder oder Weltgenerierung), aber ich kann leider meistens nicht erkennen, dass die Features in der Java Version insgesamt besser gewesen seien... ich will nicht sagen, dass die Java Version ein schlechtes Spiel wäre, aber ich muss ganz ehrlich sagen, dass es mir persönlich etwas schwer fällt, sie heute noch zu spielen (angesichts der neuen Version)...

Wenn es um die Schilder geht, so sind diese wie gesagt noch nicht perfekt und es gibt definitiv Luft nach oben, aber ich hätte gedacht, die Schilder der neuen Version bieten bereits wesentlich mehr Möglichkeiten als die Java Version, da der Text nun frei formatiert werden kann sowie Schriftart und -größe angepasst werden können. In der Java Version gab es 2-4 feste Zeilen, eine handvoll vordefinierter Farben, eine feste Textgröße und einen einheitlichen Font.

Die Sache ist, wir stecken unheimlich viel Zeit in die Überarbeitung diverser Features des Spiels rein. Hätten wir alle Features 1:1 aus der Java Version portiert, dann hätte die ganze Umstellung wesentlich weniger lange gedauert, sprich die Portierung wäre deutlich schneller vonstatten gegangen. Denn der meiste Zeitaufwand fließt in die Überarbeitung bzw. Neuimplementation der Features.

Bitte nicht falsch verstehen: Es gibt in diversen Punkten Probleme und auch Bugs, und die müssen auch so angesprochen werden. Es gibt natürlich manchmal auch die Fälle von Feedback, in denen ein gesamtes Feature quasi als "schlecht" abgestempelt wird, obwohl sich die Person evtl. in Wirklichkeit nur über besimmte Kleinigkeiten oder Bugs ärgert. Uns fehlt leider vielfach die Zeit, eigentlich stehen wir nur noch im Dauerstress, denn sämtliche Updates der jüngsten Vergangenheit richten sich "nur" an die Bestandscommunity (da auf der Steam-Page ja noch die Java-Version beworben wird), was zB keinerlei positiven Einfluss auf unsere Verkäufe hat. Entsprechend beeilen wir uns so gut es geht, wodurch bei manchen Features auch ein paar Funktionen auf der Strecke bleiben (oder sich ein paar Bugs mehr einschleichen).

Wenn das Feedback nun aber besagt, dass die überarbeiteten Features insgesamt schlechter als in der Java Version sind, dann ist in unserem Plan offensichtlich was gewaltig schief gelaufen Da stellt man sich schon die Frage, warum wir überhaupt daran weiterarbeiten

Quote from Deirdre

Es flackern übereinandergelegte Poster, leider, da das bei Pflanzenbildern, wie früher beim Efeu, nicht zu vermeiden ist, aber wie in meinem Fall, andere Bilder auch. Bei der Badematte vermute ist, dass darin zu viel Weißanteil vorherrscht. Habe dir auch von einem Fußboden Material per Pn geschickt. (Habe im Moment kein anderes Poster im Kopf, aber das Flackern geschieht öfter mal, auch wenn nichts übereinander liegt).

Das "weiße Flackern" liegt im Falle der Badematte daran, dass der durchsichtige Teil im Bild tatsächlich weiß ist (und nicht den Farbton der Matte hat). Ich habe dir mal das gleiche Bild gesendet, allerdings nicht mit weißem durchsichtigen Hintergrund, sondern mit farbigem Hintergrund. In der Bilderanzeige von Windows sieht man zwar keinen Unterscheid, aber im Spiel ist hier kein weißer Rand oder weißer Bereich mehr zu sehen.

Wir schauen aber mal, dass wir das vll schon vom Spiel aus abfangen

Was das Flackern selber angeht: Es scheint ein bisschen auf die Position des Posters anzukommen... in manchen Situationen funktioniert es besser, in manchen schlechter. Das ist etwas, was wir auf jeden Fall noch verbessern können Ich packe es mal auf unsere Liste.

Quote from Deirdre

...Wäre es möglich, per Kurzbefehl alle Poster auf einmal zu glätten? Ich habe es nicht so mit Ölgemälden in modernen Wohnungen und das dauernde Tippen von flat...., dauert zu lang.

Vll wäre ein allgemeiner "editall" Befehl praktisch, in welchem man zB alle Objekte eines bestimmten Typs auf einmal bearbeiten kann... ich packe das mal auf unsere Liste

Quote from noci

Könnte mann das nicht, beim Platzieren für jedes Poster, mit einem Häckchen das Variabel halten, oder läuft das Global

Grundsätzlich wäre das sinnvoll, allerdings wäre es vmtl. auch generell nicht verkehrt, wenn Bilder, die teilweise durchsichtig sind - wie zB das Bild von TheKing - generell auf der Rückseite gespiegelt sind

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