Does that mean you want to join a friends game (who owns the Steam version)? Or do you want your player data to be linked to your Steam account, so when joining a server, both the Steam and Standalone version use the same player data?
Posts by red51
-
-
If it's only happening in multiplayer, it indicates that the server maybe uses a plugin which suppresses this key input
Input handling in singleplayer and multiplayer is identical, so if the game properly recognizes the input in singleplayer, it's unlikely that there is a technical issue. Maybe try to join a different multiplayer server (for testing purposes) and see if the key input works properly there 
-
Besser wäre wahrscheinlich sowas wie LowStamina oder CriticalStamina Events bei <25% / <10%, aber ja die Frage wofür ist da berechtigt
Das wäre evtl. denkbar, allerdings auch schwierig, hier passende Grenzen zu ziehen (wenn es bei 25% und 10% ein Event gibt, dann benötigt aber evtl. jemand auch bei 20% oder 50% ein Event usw)
Andere Idee: Wie wäre es mit einer Methode, wo man den Verbrauch deaktivieren und aktivieren kann (Nicht nur für Ausdauer, sondern für jedes einzelne). Vielleicht ist das die bessere Variante.
Das würde auch viele Events vermeiden.
Achso, also das ist grundsätzlich sogar schon möglich (zumindest für Stamina)
Mit Player.setMaxStamina() kannst du den Maximalwert an Stamina verändert (Standardwert ist 100). Wenn du das auf einen absurd hohen Wert setzt, dann kommt das einem Deaktivieren gleich. Setze es idealerweise einfach auf Integer.MAX_VALUE. Denke auch daran, zusätzlich noch Player.setStamina() auf denselben hohen Wert zu setzen:Zwar verbraucht der Spieler weiterhin Stamina, aber er müsste viele Jahre ununterbrochen durchsprinten, damit sein Stamina aufgebraucht wird
-
Hey, grundsätzlich wäre das möglich, das Problem ist leider nur, dass sich das Stamina sehr häufig ändert... immer wenn man rennt (und auch danach, wenn es sich regeneriert). Das Event würde also extrem häufig getriggert
Das Spiel kann auch nicht prüfen, ob ein Plugin überhaupt diese Info benötigt (es kann nur geprüft werden, ob zB generell PlayerUpdateStatusEvent verwendet wird, d.h. der Overhead dafür wäre immer da...Wofür genau benötigst du diese Info bzw. den Änderungshinweis denn? Wahrscheinlich wäre es sonst günstiger, einfach selbst das Stamina auszulesen (Player.getStamina()), evtl. zusammen mit Player.isSprinting() (das kannst du zB mit einem Timer, oder einem weiteren Thread, oder mit dem UpdateEvent machen)
-
It's difficult to tell what's going on there, but please send a report after loading the world (i.e right when you experience the low fps), maybe it contains more information about what's going on there
To send a report, just press ESC and hit the red report button in the lower right corner (maybe also add a brief description like "low fps in old world"). -
Mit März wird es leider etwas knapp, daher wird das Update ein kleines bisschen nach hinten rutschen.... sorry!
Denn erst nach der 1.0 kann man Neues einbauen, was zu mehr Verkäufen führt. Die 3rd Person Ansicht ist, wenn ich meine Spielesammlung so ansehe die bessere Wahl als die Ego Perspektive als Fokus auf das Spiel.
Naja, eigentlich können wir auch vor der 1.0 neue Sachen einbauen (und haben wir ja auch gemacht)
Was aber eine 3rd Person Ansicht angeht: Ich weiß nicht, wie hoch die Nachfrage danach heute tatsächlich ist. In der Umfrage vor einigen Jahren war die Nachfrage eher so mittelmäßig, aber das kann sich mittlerweile natürlich auch schon geändert haben... eine 3rd Person Ansicht ist aber weiterhin geplant (natürlich optional, d.h. die bisherige Ego-Perspektive bleibt) Ich muss aber dazu sagen, dass RW als 1st Person Spiel konzipiert ist. D.h. alle Animationen etc. sind mit Fokus darauf erstellt worden. Eine 3rd Person Ansicht wird nicht ganz so perfekt sein wie in einem Spiel, welches von vornherein auf 3rd Person ausgelegt ist (genauso wie in Spielen, die als 3rd Person Game ausgelegt sind, die 1st Person Ansicht meist nicht optimal ist).
Habe ich jetzt irgendwas verpasst?
Gibt es neue Infos zum Update?
Vor kurzem gab es ein kleines Update auf der Roadmap
Der wichtigste neue Punkt ist eigentlich der hier (das dauerhafte Platzieren von Items in der Welt, d.h. ohne, dass sie despawnen): https://trello.com/c/vM28SwYs/194-persistent-itemsWas definitiv im Update sein wird:
- Platzieren von Items
- Tierzucht
- Gamepad- und SteamDeck-Support
Ein etwas weniger aufregendes Feature wird ein Reparatur-Tool für defekte Welten sein (falls die Welt-Daten zB durch Steam Cloud o.ä zerschossen wurden und nicht mehr vom Spiel geladen werden können). Evtl. wird im Update auch eine testweise Möglichkeit zum Ersetzen von Spieltexturen sein (so ähnlich wie die Texturepacks der Java-Version).
offentlich lassen sich auch alle Gegenstände dann frei platzieren , damit gerade Leute die im Mittelalter spielen auch die Werkzeuge und Waffen an einem Verkaufsstand präsentieren können.
Ja, man wird sämtliche Gegenstände frei platzieren können
Im Grunde wird es so ähnlich sein wie wenn man das Item wegwirft, nur mit den Unterschieden, dass das Item einerseits nicht despawnt (und nach dem Neuladen der Welt vorhanden bleibt), und andererseits man es auch richtig platzieren können wird (so wie man jetzt auch ein Objekt oder einen Block platzieren kann).I hope there will be a feature for water colliding with blocks and a feature for smoke colliding with blocks as well, so we can build chimneys for houses and have waterfalls. The only feature I'm eagerly awaiting is railways and trains.
Unfortunately I have no ETA for water-block-collision... it's a problematic feature anyway... blocks can be freely placed (with arbitrary size and rotation), and there is also no limit to the number of blocks that can be placed, making water collision calculations way too expensive. But it is our intention to make water collide at least with 1x1x1 sized blocks placed in a grid.
Placeable smoke, however, will probably be part of one of the next updates
-
Dass die Permission beim Verlassen der Area nicht aktualisiert wird ist merkwürdig, evtl. ist das aber auch bereits behoben
Ansonsten am besten nach dem Update nochmal melden, falls das weiterhin auftreten sollte.Das Problem mit Player.getCurrentArea() kann ich aber bestätigen, das sollte mit dem nächsten Update behoben sein
-
Was zumindest geplant ist ist die Möglichkeit, Schnee über Feuer (in einem Topf o.ä) zu schmelzen, um Süßwasser zu erhalten. An die Tonnen habe ich hingegen noch gar nicht gedacht... hier wäre vll denkbar, dass ein Feuer in der Nähe stehen muss o.ä, damit Schnee/Eis darin auftaut. Ich packe das auf jeden Fall mal auf die Liste
-
-
Ja, das würde grundsätzlich auch gehen. Ich könnte einen weiteren Parameter zur Funktion hinzufügen, womit man dann angeben kann, ob nur freigeschaltete Items angezeigt werden sollen. Momentan hat das Spiel das Konzept des "Freischaltens" aber nur für Crafting-Rezepte, die Item-Auswahl hingegen beinhaltet ja alle Items (also auch die, die man nicht craften kann). Wahrscheinlich wäre es dann am konsistentesten, wenn solche Items nur als "freigeschaltet" gelten, wenn der Spieler so eines zuvor schonmal aufgehoben hat?
In Zukunft wäre vll auch denkbar, dass man selbst genau definieren kann, welches Item darin auftauchen würde. Anders als oben beschrieben würde ich vmtl. dann fürs Callback nicht einfach ein Item zurückgeben, sondern eine Art Datencontainer, zB "ItemData" oder "ItemInformation" o.ä (damit man dann später auch dasselbe Objekt als Parameter verwenden kann).
Es wäre auch allgemein sehr schön, wenn es auch eine Methode geben würde, wo man prüfen könnte, welches Item der Spieler freigeschalten hat.
Ja, das wäre sinnvoll
Das würde dann eine neue Player.isRecipeUnlocked() Funktion sein (was den Rezept-Status prüft) bzw. alternativ auch Player.isItemUnlocked() (was dann wie bei der Item-Auswahl entweder das Rezept prüft, oder - wenn kein Rezept vorhanden - prüft, ob das Item schonmal aufgehoben wurde. -
Sorry für die späte Antwort, aber das kann ich auf jeden Fall mit dem nächsten Update einbauen
Man wird dann separat angeben können ob reguläre Items angezeigt werden sollen, und/oder Objekte und/oder Kleidungsstücke.Für das Callback wäre vmtl. am einfachsten, wenn das Spiel eine temporäre "Item" Instanz übergibt. Daraus würde man dann alle notwendigen Infos auslesen können
-
Leider ist die Blockvorschau in der Tat nicht durch die Wasseroberfläche hindurch sichtbar
Das Problem werden wir aber mit dem nächsten Update beheben -
Das mit dem Löschen kann ich nachvollziehen (also dass die Berechtigung nicht mehr aktualisiert wird), das ist tatsächlich ein Bug, welcher aber mit dem nächsten Update endlich behoben sein dürfte
Wenn die sich nach der Zuteilung ihrer Berechtigungen aus ihrer Area entfernen, wird keine Wildnis mehr angezeit und sie nehmen die Area Berechtigungen mit - bis sie sich aus und wieder einloggen.
Meinst du mit "entfernen" dass sie aus der Area rausgehen, oder meinst du dass sie sich selbst aus der Area löschen, also ihre Permission-Zuweisung darin?
-
Das meinte ich - wenn man eine Area mit F9 erstellt und sich innerhalb dieses Bereichs befindet, muss man erst raus gehen und wieder rein damit die Berechtigungen aktualisiert werden.
Hmm... sorry dass ich da nochmal nachhake, aber ich bin mir noch nicht ganz sicher, wie du das meinst. Das normale Verlassen einer Area sollte die Permission eigentlich wieder zurücksetzen (auf die eigentliche Standardpermission des Spielers)... oder meinst du dass wenn die Berechtigung einer Area geändert wird während ein Spieler in dieser Area ist, dass er dafür erst raus und wieder rein muss, damit diese Änderungen für ihn aktiv werden?
Vielleicht hab ich das ein-/zweimal benutzt. Aber ich denke, das kann man trotzdem ausschließen, da er ja tagelang in einer Tour gecrasht ist. Seit der Änderung im Plugin läuft er immer noch einwandfrei
Achso, also ich wollte nur sicherstellen, ob der Server auch crashte, wenn in der Session dieser Befehl nicht verwendet wurde. Das Nachladen von Plugins kann theoretisch für Crashes sorgen, aber nur innerhalb derselben Session (d.h. wenn es irgendwann nach einem Restart crasht, dann hängt das nicht miteinander zusammen). Freut mich aber, dass der Server soweit läuft (wobei ich schon gerne auch die eigentliche Crash-Ursache abstellen würde)
-
Das sollte tatsächlich sogar möglich sein, momentan leider aber etwas versteckt: Du kannst dafür den edit Konsolenbefehl benutzen, genaugenommen musst du das Lagerfeuer betrachten und dann einmal edit flag disablesmoke eingeben, um den Rauch zu deaktivieren und edit flag disableparticles um die Glutpartikel loszuwerden (vll ändern wir das aber sodass "disablesmoke" auch direkt die Glut ausschaltet). Das wird aber zB auch in Blaupausen gespeichert, d.h. du kannst danach eine Blaupause vom Feuer erstellen und musst dann nicht immer die Befehle eingeben
-
Also du kannst auch ein Passwort festlegen indem du die Einstellung Server_WebRequestAuthPassword (samt gewünschtem Passwort) der server.properties hinzufügst
Bei Anfragen müsstest du das PW dann über den Header "Authorization" mitsenden. Bei Map-Tiles kannst du dann die Parameter x und z für die Koordinaten verwenden.Du musst allerdings bedenken dass die Map-Tiles nicht als Bilder gesendet werden, sondern als komprimierte Rohdaten. Die Heightmap ("HMBytes") enthält für jeden "Pixel" bzw. jede Zelle die Terrain-Höhe als 32 Bit Float, während die Biomemap ("BMBytes") für jeden Pixel je 4 Bytes speichert (RGBA). Als Komprimierung wird LZ4 verwendet. Falls du das Thema weiter verfolgen möchtest kann ich gerne noch weitere Infos dazu geben
Oder wenn du in diese Richtung konkrete Wünsche hast lass es mich einfach wissen^^ -
Was ist genau gemeint mit weniger Bauteilen? Gibts da ne Zahl? Bzw. ne Grenze, ab wann es für das Spiel relevant ist?
Nicht so direkt, kommt ein wenig darauf an. Der Fehler mit der Kollision kann ab ca. 40.000 bis 80.000 Bauteilen innerhalb eines Chunks auftreten (32x32 Größe, nach oben/unten unbegrenzt). Bei vielen komplexen Bauteilen (hohler Zylinder, Kugel usw) auch schon etwas eher. Meine Aussage mit weniger Bauteilen war aber mehr darauf bezogen wenn das auch in Bereichen mit deutlich weniger Blöcken auftritt (zB nur ein paar Blöcke oder ein paar hundert Blöcke oder so)
Und was ich hier nicht verstehe - muss man bei der Auswahl nicht auch die Höhe definieren?
Jein, also es ist immer eine Mindesthöhe definiert (wenige cm), und das Spiel löscht einfach alle Elemente, die innerhalb dieses Bereichs sind
-
Ich muss sagen je mehr Anzeigen auf dem normalen Spielfenster herumschwirren, umso unübersichtlicher wird es.
Ich mag dieses graue Fenster auf der linken Seite nicht, z.B. und wenn noch mehr informative Fenster erscheinen, desto unübersichtlicher wird es meiner Meinung nach. Klar hätte der eine oder andere Spieler mitunter gern eine solche Information, aber bitte zum Ausschalten für diejenigen die das nicht brauchen und die die zusätzlichen Fenster irritieren. F3 z.B bietet auch viel Informationen, aber ist nicht die ganze Zeit sichtbar.
Es gibt tatsächlich auch bereits eine Einstellung, um das Informationsfenster beim Bauen auszuschalten. Das kann unter "Verschiedenes" -> "Bauen" mit "Informationen anzeigen" ein- und ausgeschaltet werden
Alternativ kann sonst auch die Transparenz des Hintergrunds geändert werden, damit es weniger sichtbar ist. -
Sorry für meine späte Antwort! Aber beziehst du dich auf das Platzieren von Terrain (oder das Entfernen), d.h. vorher konntest du die Maustaste gedrückt halten und jetzt musst du sie jedes Mal einzeln drücken?
Tatsächlich hat das Spiel eine Einstellung für das "Durchgehende Bearbeiten"... ist leider etwas unscheinbar. Standardmäßig wird das mit STRG Rechts an- und ausgeschaltet. Wenn du die Taste drückst müsste eine Meldung erscheinen, ob der Modus nun aktiv ist oder nicht.
Aber ich gebe zu, dass das nicht sehr intuitiv ist und man schnell versehenlich den Modus deaktivieren kann... vll macht es Sinn, eine Anzeige auf dem HUD dafür zu haben
-
There had been some considerations for this before and it's still on my to-do list
I will try to add this with one of the next updates
