Hehe, freut mich, dass das Problem gelöst ist 
Posts by red51
-
-
Hmm... grundsätzlich sollte es eigentlich so sein, dass sobald ein Block mit Einheitsgröße (also 1x1x1) im Bauplan vorhanden ist, das Raster daran ausgerichtet wird. Schwierig wird es nur, wenn mehrere Blöcke (1x1x1) vorhanden sind, und nicht alle im Raster gebaut wurden.
Es kann aber durchaus auch sein, dass irgendwas noch nicht ganz so funktioniert, wie es eigentlich soll...
Kannst du mir evtl. zwei Blaupausen zusenden, die zwar einen Block enthalten, aber trotzdem nicht richtig zusammenpassen?
-
Puhh, das Fenster-Thema wird ja doch umfangreicher als erwartet
Ich finde z.B. nicht das die Lehm-Textur unpassend ist. Zum einen kann man die Texturauflösung so umstellen, dass es nicht zu auffällig ist. Und dann hat man einen bräunlichen Fensterrahmen mit einer Musterung. Nicht viel anders als bei Holz aber eben eine zusätzliche Option. Meiner Meinung nach solltest du da die Entscheidung den Spielern überlassen welche Textur sie als "angemessen" empfinden. Vielleicht kannst du ja bei den Texturbildchen eine Anzeige mit machen welche Textur für was empfohlen wird.
Es geht ja nicht darum, eine Empfehlung seitens des Spiels auszusprechen
Es ist einfach unlogisch, dass ich zB ein Fenster aus Lehm herstellen kann. Zumindest sieht es dann eher bescheiden aus, vor allem mit den scharfen Kanten und Abgrenzungen. Wenn, dann müsste ein "Lehm-Fensterrahmen" eine etwas organischere Struktur haben (und definitiv keine Sprossen), dann wäre das in meinen Augen akzeptabel. Das ist allerdings mit einem enormen Aufwand verbunden. So hingegen würde das Ganze sonst einfach lieblos reingeklatscht wirken...Es wird ja niemand daran gehindert, jede beliebige Textur auf Rahmen zu legen, es wird nur nicht direkt im Crafting-Menü als Option angeboten.
Die Fensterrahmen wurden mit dem Hintergedanken eingeführt, dass die Mehrheit der User die vermutlich wirklich nur als Fensterrahmen verwenden (und da ist es sinnvoll, für Rahmen übliche Materialien anzubieten).
Fensterrahmen wurden auch nicht direkt als Bauform konzipiert, sie verhalten sich also etwas anders als die üblichen Formen, da sie eine spezielle Texturausrichtung haben (die Ecken des Rahmens sind auf Gehrung). Das spielt nicht gut mit allen Texturen zusammen, zB Dachtexturen oder diversen Metalltexturen (zB 765).
Da fände ich es wesentlich sinnvoller, einen hohlen Block als separate Bauform einzuführen. Zusammen mit dem hohlen Zylinder würde er eigentlich alle relevanten Fälle abdecken, in denen man ggf. Fenster als Bauform verwenden würde.
Die Änderung der Textur von Stühlen, Tischen, Türen, etc. wollte ich eh mal vorschlagen. Freut mich das du es jetzt gemacht hast
Hehe, naja, das Problem bei sowas ist leider, dass Texturen ganz anders auf Objekten dargestellt werden. Jedes Objekt hat spezielle auf dieses eine Objekt angepasste Texturen. Es gäbe zwar ein paar Bautexturen, die man bei manchen Objekten evtl. verwenden könnte, viele Texturen würden aber "kaputt" aussehen. Wenn so ein Feature kommen sollte, dann wird das auch nichts sein, was man direkt im Crafting-Menü auswählen könnte, denn abgesehen von o.g. Problem gäbe es dabei nämlich auch wieder das Logik-Problem wie bei Fenstern - schließlich fühlt sich ein "Waschbecken aus Lehm" auch irgendwie falsch an. Wenn das aber per Command (oder Creative-Mode o.ä.) geändert werden kann, sehe ich das ganz locker.
Bei Türen kann man das noch anders sehen, da die Textur nicht änderbar ist und es sich ja um ein Objekt handelt
Ich weiß nicht, ob für den User die Unterscheidung "Objekt" oder "Bauteil" wirklich relevant ist. Evtl. kommen später ja auch Fenster hinzu, die man öffnen kann - die wären dann technisch gesehen auch ein Objekt (wie die Türen), aus spielerischer Sicht aber bestünde kein großer Unterschied zu den jetzigen Fenstern
Mein Hauptanliegen ist es, dass die Fensterrahmen in einem Menü zu finden sind das auch Sinn ergibt und das möglichst viele Texturen verfügbar sind, ohne Einschränkungen
Wie gesagt, eine separate Kategorie für Türen & Fenster wäre in meinen Augen durchaus eine Überlegung wert, damit Fenster nicht zu übersehen sind (was in der jetzigen Kategorie evtl. schon eher passieren kann). Bei den Bauformen passen Fenster in meinen Augen leider gar nicht rein...
Wer kann schon sagen ob nicht mal eine besonders kreative Person einen Fensterrahmen haben möchte um einen Tunnel gleich mit Seitenwänden und Boden zu bauen, anstelle mehrerer Blockformen zu verwenden. Oder möchte das der Fensterrahmen eine Lehm-, Gras oder Stofftextur hat weil.. ja weil halt. Ich erinnere mich das du anfangs überrascht warst das Spieler die Planken und Bretter für mehr als nur Fussleisten verwendet haben
Das stimmt, aber das ist natürlich nur bedingt vergleichbar
Es wird jetzt ja niemand daran gehindert, Fenster mit allen Texturen zu verwenden - genau wie in der Java Version man ja auch alle Texturen auf Planken legen konnte. Das Spiel hingegen hat die Holzplanken nur mit Holztexturen angeboten.Wir sind uns zwar sicherlich alle einig, dass RW schon deutlich eingeschränkter gewesen wäre, wenn man Holzplanken wirklich nur mit Holztexturen versehen könnte (also auch per Command keine andere Textur möglich wäre), aber es wäre keine zufriedenstellende Lösung gewesen, einfach alle Texturen für die Holzplanken freizuschalten - denn es waren immernoch "Holzplanken" (und da ist es einfach unlogisch, wenn sie plötzlich eine Ziegeltextur haben). Da hätte man also eine andere Lösung finden müssen (darum geht die neue Version ja von vornherein einen anderen Weg).
Wir müssen doch gar nichts empfehlen. Jeder hat einen anderen Geschmack.
In der Java-Version habe ich eine Sandsteintextur auf Woodlogs als Bambus verwendet, sah dann wirklich ähnlich aus. Erlaubt ist was gefällt. Nur weil die Textur einer Kategorie zugeordnet ist, heißt das nicht, dass ein Spieler sie nicht als Fensterrahmen oder ähnliches schön findet. Ich habe auch Java Lehmdächer, einfach weil der Lehm meiner Vorstellung von Ried am nächsten kam. Binsen im Mittelalter als Bodenbelag; da gab es auch nicht viel Auswahl, Hauptsache man sieht was der Erbauer ausdrücken möchte. Im der Unity-Version habe ich Marmorsessel gesehen, finde ich zwar ungemütlich, aber auch bei den Rahmen, warum möchte man den Spieler einschränken und sagen, diese oder jene Textur sei nicht geeignet. Warum denn, wenn sie ihm aber doch für seinen Zweck passend erscheint.
Es geht ja wie gesagt nicht unbedingt um Empfehlungen, sondern darum, dass die Dinge im Spiel einigermaßen logisch erscheinen. Könnte man Items mit beliebigen Texturen versehen, gäbe es bestimmt gute Anwendungsfälle dafür, trotzdem wäre eine Spitzhacke aus Lehm irgendwie unlogisch.
Es geht uns dabei ja wie gesagt auch darum, wie das Spiel auf einen neuen Spieler wirkt (der evtl. auch gar nicht unbedingt Bauen im Sinn hat). Und da das Spiel ein Lehmfenster auch nicht so darstellt, wie man es erwarten würde, ist es nicht nur unlogisch, sondern wirkt auch "reingeklatscht" (wie gesagt, anders sähe es ggf. aus, wenn ein Fenster aus Lehm wie oben beschrieben keine scharfen Kanten hätte, sondern eine organische Struktur und keine Sprossen).
Einfacher wäre es wohl noch einige Formen wie die Form des Fensterrahmen zu integrieren. Somit hätten wir dies und die Fenster bleiben Fenster.
Das wäre in meinen Augen definitiv die sinnvollste Lösung
Die Intention hinter Fensterrahmen war ja nunmal, dass man sie als Fensterrahmen verwendet. Vmtl. überwiegend auch für Leute relevant, die eh nicht so viel Fokus aufs Bauen legen und eine schnelle und einfache Option haben wollen, ein Fenster zu bauen Wenn es noch eine entsprechende Bauform gäbe (hohler Block, um den eckigen Rahmen abzudecken) hätte man da ohnehin mehr Freiheit, als wenn man die Fensterrahmen ins Baumenü packen würde (die sich ja nunmal auch anders verhalten als die regulären Bauformen).
-
Any idea when this will be?
Well, that's a good question
It's unfortuantely a bit difficult to give an ETA for the new API... once the world generation update is ready, we will probably have a bit more time to work on the API. What's still missing is the UI part, database handling and custom asset handling (models, textures etc, and everything related to that, e.g. WorldElements), as well as a bunch of events and functions -
Just a small info about the API in the new version (because the snippet I've posted above won't work there anymore): The new API will have a new executeCommand() method (which replaces the existing executeConsoleCommand() method). It can be used to execute both console commands and API commands (depending on whether or not a preceding slash is added to the command).
So executing a command "/pnb" (which invokes the PlayerCommandEvent across all plugins) could look like this in the new version:
-
red51 Ich muss gestehen, dass wir hier nicht einer Meinung sind - wenn auch sonst (meistens)
Ich denke wir sind uns einig, dass wir uneinig sind
Zum einen kann ich nicht nachvollziehen warum nicht einfach alle Texturen für Fensterrahmen verfügbar sind. Ja, einige sind nicht hübsch aber erstmal kann keiner sagen was andere als "hübsch" bezeichnen und außerdem - so what? Die ungeeigneten werden dann halt nicht genutzt.
Naja, dabei geht es nicht unbedingt darum, ob es "hübsch" ist (Geschmäcker sind ja schließlich eh verschieden). Das Problem ist, dass einige Texturen wirklich unpassend als Rahmen sind. Ein Fensterrahmen aus Lehm mit seinen präzisen Kanten und dünnen Sprossen passt einfach vorne und hinten nicht (zwar trifft das auch auf manche Bauformen zu, aber da kann man leider nichts machen). Da es aber seitens des Spiels explizit "Fenster" sind (und keine Bauform) erweckt das eher den Eindruck, als hätten wir das komplett zusammengewürfelt und reingeklatscht.
Ähnlich wäre das wenn wir (nur als Beispiel) zB eine Möglichkeit schaffen, die verschiedenen Bautexturen auf alle Objekte zu legen (also zB auf Stühle). Das mag einige Vorteile bringen, aber auch hier müsste man unbedingt die erlaubten Texturen beschränken (schließlich wäre ein Stuhl mit der Lehm-Textur absolut unpassend).
Es geht uns dabei auch ein wenig um den Eindruck, den das Spiel auf einen neuen Spieler vermittelt. Wenn alles ohne Sinn und Verstand zusammengewürfelt ist (was leider in manchen Bereichen der Java-Version der Fall war), kann das unter Umständen einen eher negativen Eindruck hinterlassen
Du könntest in einem zusätzlichen Fenster, z.B. am rechten Rand, eben 2 Symbole anzeigen. Eines stellt einen Block dar, das andere einen Fensterrahmen. Je nachdem welche Textur man ausgewählt hat ändert sich auch das Symbol. So kann man schon vorab sehen ob das gut aussieht oder nicht. Und wenn man sich entschieden hat klickt man auf das Symbol, je nachdem ob man zu den Bauformen oder Fensterformen möchte.
Ich sehe den Vorteil davon leider noch nicht
Warum wird in der Bauen-Sektion ausgerechnet zwischen Bauformen und Fensterrahmen unterschieden, warum dann nicht auch ein weiterer Button für zB Scheiben? Ich habe die Befürchtung, dass das Crafting-Menü dadurch verkompliziert würde Plus dass die Textur-Problematik damit nicht gelöst wäre: Schließlich müsste man weiterhin die Texturen erst anklicken, um zu sehen, ob sie für einen Rahmen geeignet sind oder nicht. Bei ein paar hundert Texturen, von denen nur eine Handvoll als Fenster geeignet sind, bedeutet das viel Klickerei...
Und ich nutze Fensterrahmen auch zum Bauen. Für Glasfronten z.B. oder für Gewächshäuser. Dabei ist es ideal, dass Glas sich automatisch an den Rahmen anpasst.
Aber damit erfüllt der Fensterrahmen ja in erster Linie seine Funktion als "Fenster" (und nicht als Mauerwerk).
Wie gesagt, wenn der Fensterrahmen im Crafting-Menü momentan untergeht (was ich durchaus nachvollziehen kann), wäre es ggf. eine Überlegung wert, eine eigene Kategorie "Fenster & Türen" o.ä. einzuführen (also als eigener Kategoriepunkt auf der linken Seite des Crafting-Menüs). Das sollte dann eigentlich nicht mehr zu übersehen sein
Ich wäre sehr dafür, er wäre auch nutzbar für Blumenkästen, Grabumrandungen u.v.m.
Das wäre ein sinnvoller Anwedungsfall. Vielleicht macht es generell Sinn, den hohlen Block als Form hinzuzufügen. Für alle Bauarbeiten, bei denen es nicht um Fenster oder Glas geht, wäre er dann definitiv besser geeignet als die Fensterrahmen
-
brezel87 Das klingt danach, als wenn die Java Version startet - die kann leider nicht zum Unity-Server verbinden. Da die neue Version momentan ja noch nicht das "Hauptspiel" ist (erst im Laufe des Jahres werden wir die Java Version durch die neue Version ersetzen), wird beim Auswählen des [unity] Beta-Branches sowohl die Java-Version als auch die Unity-Version installiert (damit man weiterhin beide Versionen spielen kann, denn sonst würden sich die Daten der Unity- und der Java-Version in die Quere kommen). Beim Server ist das übrigens nicht so, dort wird entweder die Java Version, oder die neue Version installiert, aber nicht beide (da der dedicated Server darauf ausgelegt ist, auch ohne grafische Umgebung auszukommen, und ein Wechseln zwischen Java- und Unity-Version i.d.R. nicht nötig ist).
Wenn der [unity] Beta-Branch aktiv ist, sollte beim Spielstart über Steam ein Dialog erscheinen, in welchem man auswählen kann, ob die Java Version oder die neue Version gestartet werden soll. Leider zeigt Steam diesen Dialog irritierenderweise nur an, wenn man das Spiel direkt aus der Steam-Bibliothek heraus startet (ansonsten startet Steam immer die Standardversion, was eben die Java Version ist). Ich glaube, wenn du über den steameigenen Server-Browser verbinden möchtest, zeigt Steam diesen Dialog ebenfalls nicht an und startet somit die Standardversion.
Bitte prüfe einmal, ob tatsächlich die Unity-Version gestartet wird - das Hauptmenü der neuen Version sollte komplett anders aussehen. Auch ist die Versionsnummer der neuen Version ist 0.4.5.1, während die Java Version die Versionsnummer 0.9.6 hat (jeweils unten links im Hauptmenü sichtbar).
Ist Crossplay möglich? Wenn nein, installiert Steam möglicherweise eine andere Plattform als der Server ist. Ist es nachvollziehbar, ob Steam (Client) die Java oder Unity installiert und auf dem Server das jeweilige andere läuft?
Ja, Crossplay im Sinne von unterschiedlichen Betriebssystemen (Windows, Mac oder Linux) sowie Crossplay zwischen Steam-Version und Standalone wird vom Spiel unterstützt. Allerdings kann die Java-Version logischerweise nicht mit der Unity-Version zusammenspielen, da beide Spiele ja fundamental anders sind
-
Warum sind nicht alle Texturen mit Fensterrahmen kompatibel? Wenn ich die Skalierung 0, also Texturescale 0 verwende, müsste das doch möglich sein?
Technisch sind alle Texturen möglich (und wenn du dir einen Rahmen via Konsolenbefehl oder per Befehl item pnb bzw. item construction gibst kannst du auch alle Texturen frei wählen). Das Spiel bietet aber im Crafting-Menü nur die Texturen an, die zu einem Fensterrahmen passen würden - schließlich wäre ja bspw. ein "Lehm-Fensterrahmen" etwas abwegig und unpassend.
Dasselbe macht das Spiel zB auch bei Glas (nicht alle Bauformen sind mit den Glastexturen auswählbar, auch wenn es technisch möglich wäre und auch per Befehl geht).
Wie gesagt, wenn man aus Gründen der Kreativität trotzdem einen Fensterrahmen braucht der bspw. aus Lehm besteht, müsste man eben den Konsolenbefehl verwenden.
Bei nur einem einzigen Rahmen, skalierbar, wäre dann der edit size-Befehl weiterhin möglich?
Der "edit size" Befehl soll in jedem Fall funktionieren. Dass er momentan bei Fensterrahmen nicht richtig funktioniert wird auf jeden Fall noch geändert
Kann sehr gut sein, aber auch nicht. Ich kämpfe sehr oft, damit dass ich das automatische Snappen gar nicht möchte. Gäbe es da einen Befehl dieses kurzfristig auszustellen?
Aber das klingt ja für mich eher so, als wenn es sinnvoll wäre, wenn es bspw. hohle Blöcke o.ä. als separate Bauform gibt (wie in meinem obigen Post erwähnt). Dann wäre es sinnvoller, man verwendet zB stattdessen den hohlen Block, welcher ja definitiv eine Bauform wäre - hier würde also das Glas nicht snappen.
Es gibt Fenster mit Sprossen innerhalb des Glases, aber auch außerhalb, je nach Geschmack. Ich kämpfe öfter mit dem Snappen bei solchen Fensterrahmen. Die Snapfunktion ist toll, allerdings nicht immer wünschenswert, vor allem wenn das Glas innerhalb des Rahmens liegen soll und nicht damit abschließen soll.
Leider würde es das bisherige System vmtl. verkomplizieren, wenn man auch bestimmen kann, ob die Sprossen innerhalb oder außerhalb des Glases liegen sollen
Da ist es wahrscheinlich besser, wenn man einen Rahmen von Hand baut bzw. einen leeren Rahmen benutzt (oder eben einen hohlen Block o.ä) und zumindest die Sprossen selber von Hand setzt. -
Es kommt ein wenig darauf an, welche Bauteile tatsächlich entfernt werden könnten. Grundsätzlich wäre dafür wohl nur ein Bauteil geeignet, welches vollständig von einem anderen Bauteil umgeben ist (also in einem anderen Bauteil drinsteckt ohne irgendwo herauszuschauen). Grundsätzlich könnten wir dafür ein Creative-Mode Werkzeug anbieten, um innerhalb eines wählbaren Bereichs solche Bauteile zu entfernen
3. Wie wäre es mit der Funktion Rahmen um ein Gebäude legen können, à la Blaupause oder F-Tool und dann das gewünschte Bauteil
herunterrechnen lassen?
Das wäre wahrscheinlich der sinnvollste Weg
Noch gibt es keine Npcs, keine Pflanzen, keine Deko,
das führt dann unweigerlich wieder zu mehr Performanceproblemen.
Also zumindest bzgl. NPCs kann ich da etwas Entwarnung geben: In der Java Version war es ja noch so, dass NPCs in der Nähe von detailreichen Gebäuden einen spürbaren Einfluss auf die Performance hatten. Das lag dort vor allem an der sehr ineffizienten Kollisionsprüfung. In der neuen Version funktioniert das hingegen wesentlich effizienter und schneller. Das heißt zwar nicht, dass NPCs komplett "kostenlos" sind (aus Performancesicht), aber zumindest im Vergleich zur Java Version wird es da eine deutliche Besserung geben
-
thank you, was trying to make it so players didnt have type commands for /ap /pnb.
You could implement something like that by triggering the PlayerCommandEvent manually (see example below)
However, this only works in the Java version, unfortunately this wouldn't work in the new version anymore... the reason is that events in the new version now longer store their related data directly, instead they just contain a pointer referencing the according data on native side. But if a plugin manually creates a new event, there is no data on the native side it could reference - so as soon as an event listener tries to get any information from the event, the API will throw an exception.
If it's just about invoking commands, we could instead add a separate method for it though?
-
Ja, so wie du geschrieben hast. Allerdings ist das Spiel so vielfältig und kaum ein Element, das fest gesetzt werden kann, kann ausschliesslich nur für einen Zweck genutzt werden.
Das Spiel schreibt das ja keineswegs vor
Nur sind die Fensterrahmen ja als "Fensterrahmen" eingeführt worden, da macht es ja zumindest Sinn, wenn das Spiel sie als solches präsentiert. Sie haben ja zB auch Sprossen, was ja direkt den Eindruck vermittelt, dass es sich wirklich um Fenster handeln soll. Dem Spieler steht es ja frei, wie er sie verwenden möchte. Wie ja im obigen Beispiel erwähnt, auch Leitern könnten zB als Geländer zweckentfremdet werden - dennoch verkauft das Spiel sie ja explizit als "Leitern".Ansonsten hätten die Fensterrahmen stattdessen als Bauform eingeführt werden müssen und nicht als Fensterrahmen. Dann dürften sich die Fensterrahmen aber auch nicht so wie jetzt verhalten (sprich sie müssten frei skalierbar sein und Glas dürfte sich nicht automatisch damit verbinden wollen). Die Frage stellt sich welche Fensterrahmen denn eigentlich häufig als Bauform verwendet werden? Da würde ich es unter Umständen sinnvoller finden, dafür eine zusätzliche Bauform einzuführen. Einen hohlen Zylinder gibt es ja bereits (entspräche ja dann u.U. dem runden Fenster). Ein hohler Block (entspräche dem normalen Fenster) würde dann dem eckigen Fenster entsprechen.
Daher meine Frage an alle, die die Fenster eher als Bauform verwenden: Werden denn wirklich auch die Fenster mit Sprossen zum Bauen verwendet, oder in erster Linie nur der normale Fensterrahmen? Wäre es nicht sinnvoller, ggf. noch zusätzlich einen hohlen Block einzuführen, der dann explizit eine Bauform ist und sich so wie die anderen Formen verhält? Das wäre in meinen Augen wesentlich stringenter.
Rein intuitiv finde ich persönlich dass Fensterrahmen zum Bauen verwendet werden und daher auch ins Bau-Menü kommen sollten. Aber... je mehr Formen es gibt, desto unübersichtlicher wird das. Daher fände ich eine eigene Unteroption, gerne auch im Bau-Menü selbst, auf Dauer besser. Jetzt aktuell muss ich sagen hab ich die Rahmen nur zufällig gefunden und ich nutze die Option gar nicht.
Aber das Problem, welches weiterhin besteht, ist, dass nicht alle Texturen auf Fenstern verfügbar sind. Wie gesagt, das Spiel bietet die Fenster momentan ja nur mit dafür geeigneten Texturen an. Da im Bau-Menü aber erst die Textur gewählt wird und dann die Form, wäre gar nicht ersichtlich, ob es die Wunschtextur überhaupt als Fenster gibt oder nicht...
Aber die Rahmen bei den Werkzeugen bzw. Türen zu suchen war nicht mein erster (oder zweiter) Gedanke.
Die Fenster sind ja nicht bei den Werkzeugen, sondern in der Kategorie "Einrichtung" (wo ja u.a. auch Türen untergebracht sind). Ich gebe aber zu, dass das nicht 100% optimal ist. Die Kategorie "Einrichtung" ist momentan für alle Objekte gedacht, die als Einrichtung verwendet werden, d.h. Möbel, Lampen, später aber auch Dinge wie Bäder, Waschbecken, Heizungen usw.
Eine Überlegung von uns war schonmal, stattdessen noch eine separate Kategorie für feste Installation zu haben (Türen, Fenster, Bad, Küche etc), das ist aber auch irgendwie unschön...
Was ggf. noch eine Überlegung ist wäre eine eigene Kategorie "Türen & Fenster", in welche sowohl Türen als auch Fenster kommen könnten
Vielleicht macht es Sinn, in das Fenster des Baumenüs ein seitliches Fenster anzubringen in dem man auswählen kann ob man eine Bau-Form, ein Rahmen oder sonstwas haben möchte. Klickt man auf Blockform kommt man eben dorthin. Würde man aber auf Rahmen zusätzlich klicken, dann öffnet sich statt der Blockformen die Seite mit den Fenstern. Quasi als Ersatz für die "Weiter" Taste mit der man aktuell zu den Blockformen kommt.
Hierbei würde ja vmtl. weiterhin das Problem bestehen, dass ja nicht alle Texturen für Fensterrahmen geeignet sind, und daher im Baumenü nicht ersichtlich wäre, was ich genau als Fenster verbauen könnte und was nicht
Außerdem werden Fensterrahmen damit ja auf eine Stufe gestellt wie Bauformen, bzw. wenn ich wählen kann, ob ich eine "Bauform" oder einen "Fensterrahmen" haben möchte, wirkt das so, als hätten Rahmen eine gleichhohe Gewichtung (es würde sich die Frage stellen, warum man Fenster dort auswählen kann, nicht aber Türen) 
Ich fände es bei den Fensterrahmen übrigens auch schön wenn man die Dicke verändern könnte.
Für einen Fensterrahmen als Bauform wäre das unabdingbar. Ansonsten wäre das zwar nicht schlecht, würde aber gleichzeitig bedeuten, dass Fensterrahmen nicht mehr so bequem skaliert werden können wie bspw. Türen. Oder mit anderen Worten: Momentan funktioniert das Skalieren der Rahmen genauso wie das Skalieren von Türen, oder auch von Glasscheiben.
Würden wir aber eine zusätzliche Bauform einführen (zB "eckiger hohler Block"), wäre es natürlich absolut sinnvoll, dass er frei skalierbar ist, wie auch andere Bauformen.
Irgendwie verstehe ich nicht ganz warum ein Fensterrahmen nicht zu bauen gehört Wenn ich eine Wohnung miete oder ein Haus miete oder ein Haus kaufe, die Fenster sind dabei stets eingebaut. Die Möbel sind n Deutschland meistens nicht vorhanden, sondern werden selbst mitgebracht.
Naja, wenn du eine Wohnung mietest, dann sind die Türen ja i.d.R. auch bereits eingebaut. Oder auch die Badewanne oder das Waschbecken. Fakt ist aber, dass die Fenster nicht Teil des Mauerwerks oder der Bausubstanz sind. Die Kategorie "Einrichtung" ist nicht explizit auf Möbel beschränkt, sondern wie gesagt, später würden dort bspw. auch Heizkörper, Sanitäreinrichtung usw. reinkommen. Auch das Wort "Einrichtung" selbst ist ja nicht nur auf Möbel oder bewegliche Dinge beschränkt.
Aber wie oben gesagt, denkbar wäre sonst vll eine separate Kateogrie "Fenster & Türen", da beides ja zugegebenermaßen etwas aus der Reihe tanzt und evtl. in einer eigenen Kategorie besser aufgehoben sein könnte
-
Vielen Dank für die Logs und die Infos brezel87
Ich habe mal versucht, dem Server zu joinen - tatsächlich hat das problemlos funktioniert! Es liegt also scheinbar nicht am Server, sondern es muss ein clientseitiges Problem sein. Höchstwahrscheinlich ist es die Firewall oder ein Antiviren-Programm, welches die Verbindung blockiert (also nicht auf dem Server, sondern auf deinem PC selbst). Schon die Windows-Firewall bzw. Defender kann da bspw. solchen Ärger verursachen.
Das erklärt auch, warum du den Server nicht im Spiel siehst (sofern das Problem weiterhin besteht): Denn dort tauchen nur die Server auf, die du anpingen bzw. deren Infos direkt abgefragt werden können (ist keine Verbindung zum Server möglich, taucht der Server hingegen nicht auf).
PS: Wegen der Passwortabfrage, ich denke, ich habe das falsch verstanden: Kommt die Passwortabfrage im Spiel (also im Ladebildschirm, siehe Bild), oder kommt die von Steam selbst (während du noch auf dem Desktop bist)? Letzteres zeigt Steam dir nämlich immer an, wenn du zu einem passwortgeschützten Server verbinden möchtest, selbst wenn keine Verbindung möglich ist (das Passwort wird dann als Startparameter dem Spiel übergeben)
-
There is unfortunately no showChat method in the Java version, but it will be part of the new plugin API
If you want to send a chat message to a player, you can use the sendTextMessage() method.
The PlayerChatEvent you've linked, however, is an event, as mentioned by Minotorious : It gets triggered by the game as soon as a player sends a chat message (i.e. after he presses the Return key). At this stage, it's not visible in chat yet, so you can manipulate the chat message through the API (or cancel the event if you don't want the chat message to show up). The message from the PlayerChatEvent will be broadcasted to all players (unless you cancel the event).
-
Danke für das bisherige Feedback! Es ist nach wie vor ein schwieriges Thema... ich weiß leider noch nicht so richtig, ob die Rahmen wirklich gut bei den Blockformen aufgehoben sind. Aus Sicht eines Profi-Baumeisters wird der Fensterrahmen vmtl. häufig nicht als Fensterrahmen benutzt, sondern als Bauform verwendet - da macht es also Sinn, wenn es bei den Bauformen wäre. Aber aus Sicht des Spiels bzw. für den durchschnittlichen Spieler (und insbesondere auch für neue Spieler) werden die aber wahrscheinlich explizit als Fenster verwendet.
Ein Problem, welches sich ergibt, wenn Rahmen ins Baumenü geraten: Bisher sind die Rahmen standardmäßig nur mit den Texturen herstellbar, die auch einigermaßen zu einem Fensterrahmen passen würden (also diverse Holz- und manche Metalltexturen). Man kann im Crafting-Menü also ohnehin nicht alle Texturen auswählen. Da man in der "Bauen"-Kategorie aber erst das Material auswählt und dann erst die Form, ist anfangs gar nicht ersichtlich, ob das Material auch wirklich für Fensterrahmen geeignet ist oder nicht
Technisch gesehen sind allerdings alle Texturen auf Fensterrahmen möglich. Bei Verwendung des item pnb oder item construction Befehls tauchen die Fensterrahmen (zusammen mit Glasscheiben) für alle Texturen auf.
*grübel* eine Tür bewegt sich, ein Rahmen nicht ... Ich glaube, in der Java-Version (lang lang ist's her, vielleicht erinnere ich mich falsch?) hatten Türen keinen Rahmen, Fenster aber schon.
Ist es bei Unity nötig, diesen Unterschied beizubehalten? Könnten Türen da nicht auch einen festen Rahmen bekommen?Türen haben tatsächlich keinen Rahmen, bei den Fenstern hingegen gibts bzw. gabs ja auch quasi nur die Rahmen (+ Scheibe), also kein separates Fenster, welches in den Rahmen eingesetzt werden konnte
Wir haben damals schonmal über Türrahmen nachgedacht, aber das würde ein paar Nebeneffekte auf das Bauen haben, da die Türen dafür etwas kleiner als die jetzige 2x4 Abmessung werden müssten (bzw. der Rahmen müsste diese Größe bekommen, und die Tür entsprechend dann nur 1.99x3.99 oder so)... daher hatten wir uns damals schon dagegen entschieden... besser ist es vmtl., wenn man einen eigenen Türrahmen von Hand baut (wenn man einen Rahmen haben möchte).
Ggf. könnte man sonst alle Türen aber auch zusätzlich als Version mit Rahmen anbieten
Weiß aber nicht, ob das wirklich vorteilhaft ist...Was unterscheidet Fenster- und Türrahmen von hohlen Blöcken? Nur die Dicke, oder? Blöcke sind in Höhe, Breite und Tiefe veränderbar. Müsste es da nicht möglich sein, einen innen hohlen Türrahmen"block" passend in Lücken zu ziehen?
So gesehen wären hohle Blöcke schon sehr ähnlich zu Fensterrahmen
Allerdings gibt es den Rahmen ja auch zB in dreieckiger oder halbrunder Form, und dazu auch diverse Varianten mit Sprossen. Und Fensterrahmen haben standardmäßig eine geringere Dicke (die nicht regulär verändert werden kann) und Glasscheiben können direkt eingesetzt werden (da sie an den Rahmen andocken).Bislang gibts leider noch keinen hohlen Block (nur den hohlen Zylinder), aber den einzubauen wäre - unabhängig von Fensterrahmen - natürlich durchaus eine Überlegung wert.
Aber auch ansonsten fühlen sich Fenster für mich eher so an, dass sie eine größere Zugehörigkeit zu Türen haben, als zum Mauerwerk (letztenendes müsste man die verschiedenen Bauformen ja eher zum Mauerwerk zählen)^^
Was unterscheidet Fenster und Türen von Blöcken? Letztlich machen doch "nur" die Scharniere und Klinken einen Fenster-/Türblock beweglich. Wäre es machbar, dass sozusagen ein Klick auf die Klinke bewirkt, dass der Block, an dem sie befestigt ist, seine Position zwischen "auf" und "zu" wechselt?
Naja, Türscharniere sind leider etwas kompliziert umzusetzen... wir haben zwar Pläne für bewegliche Bauteile (bzw. ein Mechanismus, mit welchem man bspw. eigene Windräder usw. bauen könnte), und darüber könnte man ggf. auch Scharniere umsetzen, aber ich weiß noch nicht, wann das kommt... aber so oder so würden wir trotzdem noch ein paar vorgefertigte Türen brauchen, denn nicht jeder User möchte seine Türen selber bauen - d.h. Scharniere wären wenn nur eine Zusatzoption
Ist ja quasi wie mit den Möbeln allgemein: Die meisten Bau-Profis erstellen sich meist eh ihre eigenen Tische, Stühle oder Betten (und hier ist es durchaus sinnvoll, wenn das Spiel zB nur einzelne Sitzflächen oder Matratzen bietet), aber für andere Spieler ist es trotzdem praktisch, ein paar vorgefertigte Möbel zu haben (vor allem wenn der Schwerpunkt dieser Leute tendenziell eher auf Survival & Co liegt)
Ich denke was tatsächlich das Problem ist , ist dass man bei den Fensterrahmen wohl die Farbe auf dem Bild erkennen kann , aber nicht die Texturnummer. Es wäre sinnvoll , wenn die ausgewählten Rahmen auch mit der entsprechenden Texturnummer im Auswahlmenü versehen werden , sonst wäre es ja sinnlos soviele verschiedene Rahmenfarben anzuzeigen.
Da stimme ich zu, eine Anzeige der Textur-ID wäre auf jeden Fall sinnvoll! Wir werden das beim nächsten Update auf jeden Fall noch hinzufügen
red51 ich gebe insoweit Recht, wenn wir von Fensterrahmen als Fensterrahmen sprechen. Ich und andere Spieler sehen die Fensterrahmen aber auch als ein Bauelement, was nicht nur als Fensterrahmen genutzt werden wird. Man braucht wohl weniger die automatische Anpassung von Glas, doch eher die anderen Merkmale die andere Bauelemente haben. Für mich zur Verwendung im Vergleich ist der Fensterrahmen also eher in der Stufe des hohlen Zylinders einzustufen.
Das stimmt natürlich, aber die Fensterrahmen sind vom Spiel ja schließlich auch als Fensterrahmen vorgesehen (sonst würden wir sie anders nennen)
Das Spiel schreibt zwar nicht vor, wie man sie zu verwenden hätte (und es gibt sicherlich viele andere Anwendungsfälle für die Rahmen), aber die vom Spiel vorgesehene Funktion bleibt ja "Fensterrahmen". Aus Sicht eines neuen Spielers würden die Fensterrahmen ja auch zunächst als solches wahrgenommen werden.Ich finde jetzt aktuell müssten die Rahmen Formen im baumenü zu finden sein.
Später aber in einem separaten unter MenüDas verstehe ich leider nicht so ganz... was meinst du mit separatem Untermenü? Quasi das, was ich oben erwähnte (also eine separate Kategorie für "Festinstallationen", zB Fenster, Türen, ggf. später auch Heizungen, Waschbecken etc)? Darüber haben wir ursprünglich mal nachgedacht, aber das würde auch einige Fragen aufwerfen, welche Objekte tatsächlich in diese Kategorien gehören. Wenn es nur um fest installierte Dinge geht, müssten Lampen auch in diese Kategorie - aber nur ein paar der Lampen. Dinge wie die Fackel, Laterne oder das Flutlicht wären bei "Einrichtung" passender, während Deckenleuchten dann in die neue Kategorie kämen. Fühlt sich irgendwie nicht ganz so optimal an... damit nähern wir uns ein wenig der Situation wie in der Java Version, in welcher auch nicht immer ersichtlich war, bei welcher Werkbank welches Objekt oder Item hergestellt werden konnte.
Wenn die Rahmen aber ins Baumenü kommen, würde das quasi bedeuten, dass die Rahmen als weitere Bauform betrachtet werden. Die "Bauen"-Kategorie ist ja ein Spezialfall, in welcher man ja nicht direkt ein bestimmtes Objekt oder Bauteil herstellt, sondern das Material im Vordergrund steht. Die anschließende Form ist demnach zweitrangig und austauschbar. Ich weiß aber nicht, ob es sinnvoll ist, Rahmen vorerst dort aufzuführen, sie aber später wieder in eine andere Kategorie zu packen
Das ist leider das Problem, wohin damit, wenn etwas auffällt? Ich möchte im Grunde nicht über Gegebenheiten diskutieren, sondern diese
nur mitteilen.
Aber anscheinend ist zu diesem Thema eine Diskussion angebracht. Also unter "Problemen" (wofür die Hilfe-Sektion ja gedacht ist) würde ich eher technische Probleme, Bugs, allgemeine Schwierigkeiten mit dem Spiel etc. betrachten. Die "Hilfe"-Sektion wäre demnach die passende Sektion wenn das Spiel crasht, irgendein Fehler auftritt, es Performanceprobleme gibt, oder aber auch wenn irgendwas im Spiel nicht funktioniert (zB Crafting geht nicht, Steuerung geht nicht, Blaupausen werden nicht erkannt usw).
Wenn es hingegen um "Änderungswünsche" geht, wäre der Diskussionsbereich (oder ggf. die Vorschläge-Sektion) grundsätzlich schon passender
-
Ich wünsche mir eine hohle Kuppel.
Wir haben sowas vorbereitet, da sich sowas natürlich auch sehr gut als Schüssel oder Schale anbietet
Eine Trapetzform wäre auch toll
Wie Yarofey sagt, das wäre doch eigentlich schon beim Block via Oberflächenbearbeitung umsetzbar?
-
I'm glad to hear it's working now
-
Ich vermute, es handelt sich um die neue Version, oder? In dem Fall müsste die Portfreigabe *eigentlich* korrekt funktionieren, wenn du schon bis zum Passwortdialog kommst
Ich habe deinen Server mal rausgesucht, bei mir taucht er aber auch im Ingame-Serverbrowser auf (nach einem Serverstart kann es aber manchmal bis zu 30 Sekunden dauern, bis der Server im Serverbrowser auftaucht). Fehlt er bei dir denn weiterhin?Kannst du zum Server denn verbinden, wenn du das Passwort entfernst? Wenn es dir nichts ausmacht, könntest du sonst einmal testweise irgendein beliebiges Passwort einrichten und es mir vll via PN senden, dann kann ich versuchen, ob ich zum Server verbinden kann oder nicht (um herauszufinden, ob das Problem client- oder serverseitig vorliegt).
Ansonsten wäre ein Serverlog sehr hilfreich. Der findet sich im Serververzeichnis im "Logs" Ordner (dort einfach die neueste Log-Datei). Bitte lade ihn hier einmal hoch oder sende ihn mir via PN
-
This indicates that there is probably a firewall or antivirus program which blocks the Java server. If you don't run any additional firewalls / av programs on your computer, you should have a look at the Windows firewall / defender.
If the site says that the ports are closed, this isn't directly related to the server, or more precisely, the server has no control over this - there must be an external factor which causes this issue (as mentioned, most likely a firewall or antivirus program).
-
Thanks for the log!
The server starts properly (and according to the log, no other process is using the ports at that time), so it must be either related to the port forwarding not working correctly, or maybe a firewall / antivirus program is blocking the server.While the server is running, please check if the ports (4254-4259) are open on this site: https://www.yougetsignal.com/tools/open-ports/
If the ports are open according to that website, the issue is most likely caused by a firewall or antivirus program (even the built-in Windows firewall could already cause such issues).
-
Java 1.8.0_321 x86) is supposed to be 64bit
x86 actually refers to the 32 bit version
Unless you're using a 32 bit OS, this indicates that the 32 bit Java version is currently in use. The 64 bit version is typically indicated by "x86-64" or "amd64".I have RW dedicated server unity set up and it's running fine.
I just want to set up dedicated server Java - The server is running -
It is not showing up to join in the Multiplayer screen.
Do you have to set up the modem different than RW dedicated Server unity?
Server setup for the Java version is indeed a bit different to the setup for the new version, however, the topic I've linked above specifically refers to the Java version.
You can check if port forwarding was successful on this site btw: https://www.yougetsignal.com/tools/open-ports/ (make sure the server is running when checking the individual ports)
As mentioned by sharkbitefischer, make sure no other process on your machine is already using the ports in question. If the Unity server is already running on port 4255, you cannot run the Java server on the same port simultaneously.
If the server still doesn't work, please post the latest server log (which can be found in the "logs" folder in the server directory) and maybe also the server.properties file here (alternatively you can send it via PM to me)
