Posts by red51

Tatsächlich hat ein Block ca. eine Größe von 0,5 x 0,5 x 0,5 Metern Dieser Maßstab hat diverse Gründe, einer der Hauptgründe ist aber, dass wir den Maßstab der Java Version gerne beibehalten wollten. Damals bot sich diese Blockgröße an, da dadurch Hauswände eine passende Dicke bekamen.

Aber auch die "Auflösung" des Terrains spielt eine Rolle, denn auch dort hat das zugrundeliegende Raster, in welchem die Terrain-Daten liegen, diesen Maßstab. Wäre ein Block (bzw. eher gesagt "1 Einheit") 1 Meter groß, würde das Terrain deutlich ungenauer sein. Natürlich hätte man die Werte fürs Terrain auch jeweils umrechnen können, aber so ist es etwas einfacher.

Es bietet sich auch ein wenig an, dass ein Block standardmäßig eine Größe von "1 Einheit" hat. Wäre "1 Einheit" entsprechend 1 Meter groß, würde das zu ziemlich großen Blöcken führen (wären ja nach aktuellem Maßstab 2 x 2 x 2 große Blöcke).

Wir könnten aber evtl. eine Einstellung einbauen, wodurch das Spiel die Größen automatisch ins metrische (oder imperiale) System umrechnet. Dann würde ein Standardblock statt "1 x 1 x 1" eine Größe von "0,5 x 0,5 x 0,5" Metern haben. Beim imperialen System wirds schwieriger, hier müsste man evtl. einfach auf "20 x 20 x 20" Zoll aufrunden (schließlich sehen "19,685 x 19,685 x 19,685" Zoll blöd aus und sind keine wirklich tolle Standardgröße)... andererseits aber auch wieder heikel, wenn die Umrechnung zwischen Meter und Zoll so ungenau erfolgt

Quote from finisher7

Kann man schon ungefähr abschätzen wann die Blueprints kommen?

Definitiv nicht später als Januar

Quote from Avanar

Aktuell kennt man die genaue bezugsgrosse nicht. Daher gehen viele davon aus das 1 block 1 Meter entspricht und wundern sich dann warum der char nicht durch die Tür kommt

Bei MC (oder anderen Spielen mit gleichgroßen Blöcken) war es mit den 1 Meter großen Blöcken tatsächlich einfacher, wobei ich hier sagen muss, dass die Größenverhältnisse bzgl. Türen auch nicht so 100% passten, bzw. die Türen verhältnismäßig klein wirkten... bei RW merkt man aber zumindest bei einer 1x2 Block großen Tür sofort, dass das nicht stimmen kann bzw. deutlich zu klein ist In der Vergangenheit haben manche Leute intuitiv die Türen 1x3 oder 2x3 Blöcke groß gebaut, was in der Java Version grenzwertig klein war (eigentlich zu klein). In der neuen Version ist der Spieler ein bisschen größer, sodass er keinesfalls mehr durch eine 3 Block hohe Tür gehen kann.

Ich weiß aber auch leider nicht, wie man das intuitiver gestalten könnte Wären die Blöcke in RW standardmäßig 1 Meter groß (also nach jetzigem Maßstab 2x2x2 Blöcke), dann wären die echt riesig

Danke für die bisherigen Türvorschläge Einige dieser Varianten haben wir auf jeden Fall schon in der Vorbereitung, ich kann aber leider noch nicht sagen, wann das "Türen-Update" genau kommen wird. Es wird aber deutlich mehr Abwechslung als die verschiedenen Türen der Java Version bieten

Quote from lenko

Ich denke Mal das Deirdre eher das schon öfter angesprochedes Schanier für den Bau von Türen mein.

Sowas wäre natürlich auch mein Favorit, was Türen und damit auch leicht zu gestalten Fenster angeht.

Das ist tatsächlich ein heikles Thema... wir werden uns aber damit auf jeden Fall nochmal auseinandersetzen Es wäre aber wahrscheinlich kein Ersatz für eine Grundauswahl an Türen, denn während Spieler mit großem Baufokus vmtl. viel Gebrauch davon machen würden, möchten Gelegenheitsspieler möglicherweise nicht alles selber bauen müssen und würden ggf. vorgefertigte Türen bevorzugen. D.h. wenn dann müssten Scharniere wohl zusätzlich zu einer Grundauswahl an Türen ins Spiel kommen

Quote from lenko

red51 vielleicht etwas unpassend aber wäre es in Zukunft hier nicht möglich der Tür durch das Menü zu sagen in welche Richtung sie sich öffnen lässt.

Wie meinst du das genau? Grundsätzlich kannst du ja bereits bestimmen, in welche Richtung die Tür sich öffnet: Wenn du sie um 180° drehst, öffnet sie sich in die andere Richtung, und wenn du sie dann spiegelst (über das Kontextmenü oder die ENDE Taste), kannst du quasi festlegen, auf welcher Seite der Türknauf sein soll (ohne die Öffnungsrichtung zu ändern). Damit können zB auch richtige Doppeltüren gebaut werden (anders als in der Java Version, wo dafür immer eine Tür offen stehen musste).

Seile werden vmtl. spätestens ungefähr dann kommen, wenn auch Elektrizität ins Spiel kommt (da das Platzieren von Kabeln dann wohl ähnlich vonstatten gehen wird) Vorher wird es aber auf jeden Fall wohl eine Seil-Textur geben, wodurch man Seile dann zumindest mit Blöcken nachbauen kann. Keine perfekte Lösung, aber vorläufig vll für viele Situationen ausreichend

Quote from Rüdi

Auch wenn es schwierig ist es umzusetzen, ich finde dass das Spiel mehr Physik haben sollte. Dadurch wirkt es "beweglicher" und nicht so steif und ist durch die Physik moderner und auch noch interessanter.

Da stimme ich zu, aber das Problem wäre dabei die Performance Bzw. die "Skalierbarkeit": Während ein paar Seile kein Problem wären, würden hunderte oder tausende physikalische Seile schon recht viel Rechenleistung erfordern. Selbst wenn "nur" die Takelage eines großen Segelschiffes aus physikalischen Seilen bestehen würde, könnte das schon Performanceprobleme bereiten...

Wenn Spiele heutzutage physikalische Seile bieten (also Seile, die wirklich physikalisch sind, sprich mit ihrer Umgebung interagieren), dann sind es meist nur sehr wenige Seile, die gleichzeitig sichtbar bzw. "aktiv" sind...

Quote from zwerk7

Vor ca. 6 Jahren habe ich schon red51 gebeten Seile ins Spiel zu bringen aber NICHTS und so wird es auch bleiben, genau so das fließende Wasser. Aber was kam eine neue Version von Rising World und die gefällt mir GARNICHT, so das mußte mal raus.

Tut mir Leid zu hören, dass dir die neue Version nicht gefällt Gibt es denn etwas konkretes, was dir nicht zusagt? Evtl. ist es ja etwas, was man ändern könnte. Erstelle aber vll einen eigenständigen Thread dafür, da es ja vmtl. nicht direkt mit Seilen zusammenhängt

Ich möchte aber auch sagen, dass wir im Laufe der Zeit viele Vorschläge der Community umgesetzt haben. Leider hat es bislang nicht alles ins Spiel geschafft (darunter auch Seile), oft gibt es dafür aber auch organisatorische Gründe (zB wenn für Feature B erst Feature A umgesetzt werden muss, was natürlich die Umsetzung von Feature B insgesamt verzögert).

Quote from Deirdre

Das Abbauen von Bäumen im Kreativmodus und die Reste der Bäumen sehen seltsam aus.

Wenn der umfallende Baumstamm sofort zerschlagen wird, bevor er wirklich umgefallen ist, dann spawnen die einzelnen Baumstammstücke (also die Items). Dasselbe ist auch in der Java Version so. Die despawnen erst abhängig von der Despawnzeit für Items.

Quote from Deirdre

Diese nehmen die Farbe zwar an, aber wirklich schön ist das nicht, da der Farbauftrag zu krass ausfällt. (Was heißt schön, kommt natürlich auf den

Verwendungszweck an). Eine Möglichkeit zur Einstellung der Farbintensität, halte ich da für sehr praktisch.

Links im Bild ist die ID 260, rechts die ID 266. Unten sind die Originale, oben die eingefärbten Blöcke.

Das Problem ist, dass je monotoner die Grundtextur ist, desto mehr tritt das Phänomen auf, welches du beschreibst... leider ist es schwierig, da eine allgemeingültige Lösung zu finden, die für alle Blocktexturen gleichermaßen funktioniert...

Du hast aber beim Malen mit dem Pinsel (statt dem Farbroller) etwas mehr Kontrolle über die Farbintensität. Falls du mit dem "edit color" Befehl arbeitest, dann kannst du den "Alpha" Wert mitangeben: Standardmäßig gibt man dort ja eine Farbe als Hexadezimalzahl an (nach dem Muster #RRGGBB, zB #FF0000 für knalliges rot). Hinten dran kannst du noch zwei Ziffern (auch hexadezimal) für den Alpha-Wert angeben (also zB #FF000080 für einen halb eingefärbten knallroten Block [80 hex ist 128 dezimal, was genau 50% entspricht], oder "#FF0000C8" für einen überwiegend eingefärbten Block etc). Wenn der Alpha-Wert nämlich nicht angegeben wird, dann setzt das Spiel automatisch ein "FF" hinten dran (also maximale Einfärbung).

Alle diese Dinge wären prädestiniert für das künftige Stromsystem Oder anders gesagt: Alle momentanigen Einstellungen (an/aus, Helligkeit, Farbe) wird man auf jeden Fall über das Stromsystem steuern können (das beinhaltet auch automatisierte Schaltungen und Timer).

Das einzige Problem ist nur, dass es wohl noch ein wenig dauert, bis Elektrizität reinkommt... wenn wir aber vorher eine andere spezifische Lösung einbauen (zB eine Schaltuhr explizit für Lampen), wäre das hinterher wohl doppelt gemoppelt sobald das Stromsystem da ist...

Vll wäre das aber zumindest für die Straßenlaterne ein denkbares Feature (wo so eine Zeitschaltung ja auch in Zukunft geeignet wäre), ähnlich wie die Einstellmöglichkeiten bei den Lichtern der Absperrung

Hehe, das wären auf jeden Fall nette Features Also der Schneemann aus der Java-Version wird auf jeden Fall noch seinen Weg in die neue Version finden

Schneebälle wären ebenfalls nicht verkehrt, schade, dass diese Dinge nicht passend zu Weihnachten reinkamen, aber ich packe es auf jeden Fall mal auf unsere Todo-Liste.

We also wish everyone a Merry Christmas and a Happy New Year!

Hehe, vielen Dank, vor allem auch vielen Dank für die netten Worte

Wir wünschen natürlich auch allen frohe Weihnachten und einen guten Rutsch ins neue Jahr!

Quote from Avanar

Ist es möglich die Tür wie ein Bauteil zu behandeln und dann auch AltGr zuzulassen? Nicht das ich eine Trapezförmige Tür möchte aber wenn diese Änderung dann abgerundet wäre, nicht eckig, dann könnte das sogar ganz gut aussehen.

Das wäre wirklich praktisch, aber leider auch etwas schwierig umzusetzen Während die Bauelemente ja eher relativ simple Formen haben, sind die Objekte meist deutlich komplexer aufgebaut... und auch die Textur wird bei Objekten anders projiziert als bei Bauelementen und würde bei so einer Aktion wohl unweigerlich verzerrt werden... selbst ein professionelles 3D Programm hätte Schwierigkeiten damit, so eine Funktion automatisiert bereitzustellen...

Quote from Avanar

Alternativ musst du uns für jede Tür eine oben abgerundete Variante bieten

Ich schätze das wäre wirklich die einzige Lösung Allerdings reicht es wahrscheinlich auch, wenn in erster Linie die mittelalterlichen Türen eine abgerundete Variante hätten, oder?

Quote from Deirdre

Für meine Bauweise im Kreativmodus wäre mir eine Funktionalität wichtiger, egal ob eingebaut, oder ob blockiert

Meinst du damit eine Funktion im Spiel, wodurch die Prüfung, ob eine Tür blockiert ist, ignoriert wird? Oder meinst du damit was anderes?

Hmm... also mit dem letzten Update hat sich in dieser Hinsicht tatsächlich was geändert, nämlich es ist nun möglich, das Spiel einem anderen Monitor zuzuweisen Es ist aber trotzdem eigenartig, warum zuerst der 2. Monitor bei dir angewählt wird... das bedeutet, dass Unity bei dir offenbar standardmäßig den 2. Monitor ansteuert (unser Code wird erst ausgeführt, nachdem das Fenster einen kurzen Augenblick sichtbar war - d.h. erst dann wird der aktive Monitor vom Spiel gesetzt).

Ist in den Einstellungen denn der korrekte Monitor ausgewählt? Was passiert, wenn du dort den Monitor einmal änderst, speicherst (funktioniert das?), und anschließend wieder auf den richtigen Monitor zurück änderst? Besteht das Problem nach einem Neustart dann immernoch?

Achso, ja, über so eine Checkbox bei der Posterauswahl könnte man tatsächlich nachdenken

Quote from Smoka

Sollte aber nicht alle Rechte vorhanden sein, wenn "Permissions_AdminsFullPermissions" auf True gesetzt wurde?

Jein... streng genommen sorgt es dafür, dass quasi die Standardeinstellungen für Admins verwendet werden (wie im Singleplayer auch)... und standardmäßig ist noclip deaktiviert...

Bei manchen Permissions ist es schwierig zu beurteilen, ob ein Admin sie standardmäßig haben sollte oder nicht... es gibt ja zB auch die Permission "nohungerthirst" (unter "general"), wodurch Hunger/Durst ausgeschaltet wird, oder "nofalldamage", wodurch Fallschaden deaktiviert wird, was aber standardmäßig ebenfalls nicht aktiv ist (auch nicht für Admins)...

Quote from lenko

Der Befehl galt bisher ja wenn für alle Plugins und nicht für einzelne. Das würde das bedeuten nur "RP" alle Plugins oder "RP xxxxxxx" dann nur das eine ?

Ich weiß leider nicht, ob wir das in zuverlässiger Form umsetzen können... generell ist das nachträgliche Laden und Entladen von Code nicht so wirklich vorgesehen in der Java VM... daher sind unsere Befehle "reloadplugins" und "unloadplugins" auch immer mit etwas Vorsicht zu genießen (wobei ich im Laufe der Zeit noch keine Probleme diesbezüglich entdecken konnte).

Momentan werden beim Neuladen alle Plugins entladen und alle Resourcen, die mit der Plugin API zusammenhängen, freigegeben - dadurch wird sichergestellt, dass beim erneuten Laden eines Plugins kein Konflikt auftritt. Wenn wir aber nur einzelne Plugins neuladen wollen, können wir nicht alle Resourcen der API freigeben (da ja andere Plugins dann noch weiterlaufen sollen), und das könnte möglicherweise für Schwierigkeiten sorgen...

Bist du evtl. als Admin in der server.properties eingetragen? Wenn gleichzeitig die Einstellung "Permissions_AdminsFullPermissions" auf True gesetzt ist, dann wird die Permissiongruppe für Admins (also Personen, die in der server.properties eingetragen sind) ignoriert. Das Verhalten ist quasi wie in der Java Version, aber das wollen wir auf jeden Fall noch abändern (sodass manche Berechtigungen davon zB trotzdem nicht betroffen sind)

Das Menü ist tatsächlich "nur" verschoben (wie Avanar schon sagt), wobei das Ergebnis aber unterm Strich ja quasi dasselbe ist

Das hatte eigentlich mal funktioniert (also dass das Kontextmenü korrekt positioniert wird, wenn es sich am Bildschirmrand befindet), aber mit dem letzten Update haben wir auch auf die neueste Version vom "UI Toolkit" (also das neue UI Framework von Unity) geupdated, welches leider einige "Breaking Changes" mit sich gebracht hat (u.a. dieses Problem, aber auch andere Dinge wie fehlende Emojis im Chat, stellenweise kaputte Texte etc). Ich denke ein paar dieser Dinge sind tatsächlich Bugs im UI Toolkit, aber in all diesen Fällen können wir zumindest Workarounds bieten, wodurch es nach dem nächsten Update eigentlich wieder wie gewohnt funktionieren sollte

Ich habe das mal auf unsere Todo-Liste gepackt Also sowohl ein Konsolenbefehl als auch eine API für das Plugin selbst.

Quote from lenko

Würde hier in Gedanken noch weiter gehen. Hier wäre es doch auch toll wenn man es nicht nur ausschalten kann sondern auch wieder an machen könnte.

Als Konsolenbefehl könnten wir das anbieten (wobei meistens der generische "reloadplugins" Befehl ausreichen könnte). Für die API hingegen geht das natürlich nicht (da ein Plugin ja keinen Code mehr ausführen kann sobald es entladen wurde)

Quote from lenko

Man sollte die Möglichkeit haben Bilder oder Poster nur Temporär zu nutzen.

Die Frage wäre nur, wie man das genau einstellt? ZB jedes Mal beim Platzieren eine Nachfrage anzuzeigen wäre evtl. etwas nervig für den User... wenn das hingegen nachträglich eingestellt wird, dann werden vmtl. viele User das sowieso nicht machen...

Quote from Deirdre

Ich fände es gut im Rcon-Tool ebenfalls eine Übersicht zu haben, wer welche Bilder benutzt und diese dann expliziert löschen kann, ohne 3000 Bilder durchzusuchen.

Das neue RCON Tool wird auf jeden Fall eine deutlich umfangreichere Übersicht über Bilder bieten als noch das alte RCON Tool, ebenso entsprechende Suchfilter wodurch das Verwalten der Bilder insgesamt einfacher werden dürfte

Quote from Deirdre

Was ich auch sehr vermisse, ist eine Übersicht welche Poster man selbst schon hochgeladen und gespeichert hat

Das ist auf jeden Fall auf unserer Todo-Liste, aber leider kann ich noch nicht viel dazu sagen

Quote from Deirdre

Wie umständlich ist das denn?

Naja, es ist ein zusätzlicher Tastendruck, sooooo umständlich ist es in meinen Augen nicht unbedingt... aber es ist ja auch eher als Übergangslösung gedacht. Wie ja in meinem vorherigen Beitrag gesagt, es ist ungewollt, dass die Kollision bei aktiven Raster trotzdem noch teilweise eine Rolle spielt, das werden wir ggf. mit dem nächsten Update ändern. Dann sollte es sich eigentlich so verhalten wie du es dir vorstellst.

Quote from Deirdre

Wie mache ich den komischen grünen Marker wieder weg? Ich habe einen Mauszeiger, doppelte Zeiger irritieren mich nur. (Hilfsmarker und Andockpunkte stehen auf aus).

Auch das ist ja wie zuvor gesagt der aktive Pivot auf einem Bauteil. Der kann durch die Einstellungen bisher nicht deaktiviert werden, aus o.g. Gründen, wobei es hier überlegenswert wäre, das vll zu ändern.

"Hilfsmarker" ist generell was anderes, das ist das Rote Kreuz, welches die Ausrichtung der Weltachsen anzeigt.

Quote from Deirdre

Für mich macht es einen großen Unterschied ob ich beim Drehen nur eine Pfeiltaste benutzen muss, oder mir die Finger verkrampfe und dazu noch STRG halten muss, warum so umständlich? Könnte man das nicht abschalten für diejenigen die lieber die alte Art nutzen möchten?

Beim manuellen Platzieren sehe ich bisher leider keine andere Lösung, da zB mit Shift standardmäßig Bauteile vergrößert/verkleinert werden, und ohne Zusatztaste (also nur die Pfeiltasten) wird das Bauteil verschoben. Das war - wie von Avanar erwähnt - in der Java Version auch bereits so.

Dass das Bauteil bei aktivem Raster von anderen Bauteilen weggedrückt wird (im Kern ist das ja das Verhalten, welches du monierst), hat nichts mit dem "manuellen Modus" zutun. Dass dieses Verhalten standardmäßig anders ist als in der Java Version liegt u.a. daran, dass Bauelemente jetzt auch als Ersatz für Blöcke dienen. Die Lösung wäre in der Situation, die Kollision auszuschalten, aber wie gesagt, es ist momentan ein Bug, dass das bei aktivem Raster nicht ganz hilft. Das wird sich mit dem nächsten Update ändern.

Die angesprochenen Probleme sind eigentlich tatsächlich identisch mit dem vorherigen Thread

Quote from Sandboxgamer

Wenn ich das Spiel als Admin starte, startet das Spiel, aber alles ist in Englisch.

Ist in der config.properties Datei evtl. neben Game_Language "english" oder "en" oder so eingetragen? Standardmäßig sollte das Feld leer sein, dann sollte die Standalone eigentlich die Systemsprache verwenden

Quote from Sandboxgamer

Leider hat er das Problem, immer auf die Config zuzugreifen. Ich nutze Win11 und habe sowohl die Steam-Version als auch die Standalone.

Ich empfehle, für die Standalone eine Setup.exe zu machen, damit das Spiel als "vertrauenswürdiges registriertes Programm" installiert wird.

Sonst bekommt das Standalone Probleme mit den Windows-Berechtigungen.

Ich habe mal testweise Windows 11 installiert, aber leider konnte ich das Problem bei mir nicht reproduzieren Unter welchem Pfad ist das Spiel denn abgelegt? Falls es entweder unter "Programme" oder auf dem Desktop liegt, dann könnte es evtl. daran liegen, weil Windows für diese Ordner schon immer spezielle Berechtigungen erwartet...

Ein Setup zumindest für den Launcher könnten wir anbieten, aber ich weiß nicht, ob Windows es dadurch bereits als "vertrauenswürdig" einstuft... vielmehr würde hier wohl eine Signierung der exe helfen, das ist aber mit laufenden Kosten verbunden (also jährliche Zahlungen, die wir für das Zertifikat leisten müssten)...

Quote from Deirdre

Gibt man im Multiplayer Suchfeld den Servernamen oder die IP ein, ist diese schwarz, d. h. fast nicht mehr lesbar.

Das ist leider durch ein Update der Unity Version (genauer genommen von "UI Toolkit", also deren neues UI Framework) zustandegekommen (genau wie ein paar andere unerwartete Änderungen)... das werden wir mit dem nächsten Update beheben

Quote from Deirdre

Es wäre gut, wenn bei HUD-Einstellung das Raster auch unsichtbar wäre.

*Eigentlich* etwas irreführend, da das Raster ja nichts mit dem HUD zutun hat, aber natürlich kann ich schon verstehen, warum das Sinn machen würde... ich packe das mal auf die Liste