Posts by red51

Danke für die Erläuterungen! Dieser "graue Bereich" ist momentan quasi nur ein Platzhalter, wie lenko schon sagt, dieses Gebiet wird später überwiegend vom Meer bedeckt sein. Gleichzeitig werden die Inseln aber auch wesentlich größer, denn der jetzige Berg, der sich in der Demo befindet, stellt nur einen recht kleinen Bereich einer Insel dar. Die Weltgenerierung ist leider insgesamt noch nicht fertig, daher ist die Landschaft etwas trist (wenig Vegetation, keine Wälder, kein Wasser etc). Viele warten auf die Weltgenerierung und das ist auch wahrscheinlich eines der wichtigsten Features, die noch fehlen. Das Update für die Weltgenerierung soll aber in der ersten Jahreshälfte 22 kommen.

Quote from zwerk7

Bei der Java Version habe ich auf Hessenstrolsche gespielt und war nicht als einziger Spieler auf der Mapp und somit humpelt man jetzt als einziger Spieler durch die Welt

Wie meinst du das genau? Der Mehrspieler ist ja bereits implementiert, d.h. man kann bereits mit anderen Leuten zusammen spielen. Die neue Version bietet alle Multiplayer-Optionen wie schon die Java Version (P2P, also "mit Freunden spielen", dedizierte Server usw).

Quote from zwerk7

Wenn man jetzt ein Gebäude baut und diesen Blueprint in die alte Version setzt stimmt das Größenverhälltnis nicht.

Hmm... das müsstest du evtl. auch etwas näher erläutern... wie kommst du darauf, dass das Größenverhältnis nicht stimmt? Eigentlich sollten die Maßstäbe weitestgehend mit der Java Version übereinstimmen. Die Spielerfigur ist lediglich marginal größer geworden (vll 5-10 cm), d.h. Durchgänge, durch die man sich in der Java Version gerade eben so durchquetschen konnte (was meist unschön war) könnten jetzt zu klein sein. Das sollte aber eigentlich in den meisten Fällen überhaupt kein Problem darstellen.

Allerdings wird es nicht möglich sein, Blueprints aus der neuen Version in die alte Version zu übertragen. Das wäre mit viel Aufwand verbunden, gleichzeitig würde uns das jetzt unnötig einschränken...

Man wird allerdings alte Blueprints aus der Java Version durchaus in die neue Version übertragen können (zumindest Bauelemente) Wir arbeiten derzeit daran. Wir haben zwischenzeitlich schon einige Blaupausen aus dem Forum testweise importiert und bisher passten die Größenverhältnisse ziemlich gut. Das Blaupausen-Update wird spätestens im Januar erscheinen.

Quote from lenko

Ich hatte mich jetzt mehr auf die Vorschläge beschränkt. Und dachte das man ja zb eine Balkontür nicht nur öffnen und schließen kann, sondern auch kippen. Das gleiche gilt ja auch für Fenster. Jetzt kämen noch Klappen hinzu die nach oben oder unten aufgehen. Zum Schluss noch der Traum von Schiebetüren die ja seitlich nach außen aufgehen.

Achso, verstehe Also die Möglichkeit, eine Tür zu kippen "universell" umzusetzen ist ein wenig schwierig, aber wir könnten das später durchaus für spezielle Türen anbieten (zB Balkontüren, die man auch in echt nicht nur öffnen, sondern auch kippen könnte)

Eine universelle Funktion um eine Tür zur Schiebetür zu machen wäre schon eher denkbar Aber ich würde vmtl. auch da spezielle Türen (also richtige Schiebetüren) bevorzugen, auch aus optischen Gründen (bei den regulären Türen wäre sonst wohl oft die Klinke im Weg, zumindest optisch).

Quote from paulevs

8. Hide grass if it is under construction element

Hehe, well, unfortunately there is currently a bug which prevents the "grass occlusion" to work properly Usually it only works if you actually stand on the ground, but if you're at a slightly higher elevation, it no longer works (resulting in grass being visible through construction elements again). But we will fix that ASAP

Quote from paulevs

9. Move items up if they are below terrain

Sometimes when you break element its center will be below terrain, and as a result - summoned item will be dropped below terrain into the void. Suggestion is to moved it to the nearest point of terrain above it, and the player will not lose any resources anymore.

Oh, that's not supposed to happen If blocks are slightly below ground (i.e. if their upper surface is still almost barely visible), they're supposed to spawn above the ground if removed via sledgehammer... this may not work properly on slopes though (if most part of the upper surface is covered by terrain, and if the distance between the center of the surface to the ground is too great)... this definitely needs some improvements. Or did you also experience that on flat ground?

Quote from paulevs

10. Change size of construction elements on icons

Construction elements can have different sizes, but this is not shown on their icon which sometimes makes their identification difficult. If the icon will have same outlook as an element in the world it will be much easier to define what elements you have in inventory

Well, the problem is that the size is not stored persistently for construction elements in your inventory...

Quote from paulevs

11. Make some construction elements possible to attach with snapping tool

Good point, we will add a pivot for the wall torch with the next update

Quote from paulevs

And if you will enable grid snapping instead Wall torch will be inside the wall until you make the grid really small

Yeah, the grid definitely needs a bit more love, especially when it comes to object placement. It's on our to-do-list

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