We don't have plans to use any free Unity or Unreal assets 
Posts by red51
-
-
The new version supports some input commands which can be entered in the server console - not to be confused with ingame commands which can be entered in the ingame console!
Input commands don't require you to be logged into the server and they don't require specific permissions, considering that everyone who has access to the server process is probably also a server admin.
Note: If you want to execute the commands from the scheduler, make sure to put a slash at the beginning, e.g. "/say" etc.
Overview of all currently available input commands:
Command Description say Sends a chat message to all players. If you want to send a chat message to a specific player, append "@playername" (e.g. "say @Testplayer Hello Testplayer!").
Supports rich text, e.g. to send a blue chat message, you can type "say <color=blue>This is blue text</color>yell Sends a yell message to all players (i.e. a big announcement message). Like the say command, you can send this to a specific player by appending "@playername".
Example: "yell Server will restart in 10 minutes" or "yell @Testplayer Stop griefing!"kick Kicks a particular player. Use "kick <player> <reason>" kickall Kicks all players from the server. Use "kickall <reason>" spg Changes the permission group of a player saveall Saves all world changes. Usually this happens automatically every few seconds restart Restarts the server, i.e. shuts down the server and restarts the server process (experimental feature) shutdown Shuts the server down gracefully (may take a few seconds). If you append a "now", the server process terminates immediately (but this is not recommended) httprequest Sends a http request to a specific url. If the request is sucessful, the result will be invoked as a separate command. Use "httprequest <url>" reloadplugins Reloads all plugins which are currently loaded through the Plugin API unloadplugins Unloads all plugins which are currently loaded through the Plugin API makeadmin Gives admin permission to a particular player. Use "makeadmin <playername>" or "makeadmin <playeruid>" revokeadmin Revokes admin permission from a particular player. Use "revokeadmin <playername>" or "revokeadmin <playeruid>" tod Changes the time of day (24 hour format). Use "tod <hours> <minutes>" weather Changes the weather. Use "weather <name>". If you append a "1", the weather changes immediately (instead of a smooth transition) memory Prints information about the current memory usage. Note: This only covers memory which is actually used be the server, not the overall memory that's already allocated by the process version Prints the current server version -
Es handelt sich dabei tatsächlich um die Spielerfigur, welche schon in der Demo in der Nähe des Nullpunkts in einem Raum in T-Pose zu finden war
Ich bin mir sicher, dass sich nicht jeder Spieler mit dieser Figur identifizieren kann, aber sobald wir die Weltgenerierung im Kasten haben und ein wenig den Survival-Bereich angeschnitten haben werden wir dafür sorgen, dass es Anpassmöglichkeiten, eine weibliche Version und vor allem auch Kleidung gibt
-
Ich habe damit mal etwas weiter getestet, dabei ist mir aufgefallen, dass es sich meistens (es scheint wenigen Ausnahmen zu geben) so verhält:
Achso, ich denke das ist folgendes Verhalten: Bei manchen Bauteilen (insbesondere Eckstücken, aber auch dem halben Zylinder) wird die Rotation mitberücksichtigt bei der Suche nach dem passenden Pivot. Beim Block ist das bspw. nicht so, d.h. wenn er zB an einen Eckpunkt andockt, kannst du ihn um diesen Eckpunkt herum drehen (und dabei ändert er normalerweise nicht mehr den Pivot). Bei Rampen oder anderen Eckstücken ist es aber so, dass durch die Drehung möglicherweise ein anderer Pivot näherdrückt, und das Bauteil sich entsprechend verschiebt. Auch wenn sich das im ersten Moment merkwürdig anhört, aber bei Eckstücken macht das durchaus Sinn.
Haariger wird es bei den halben Zylindern, da die ja eher so ein Zwischending zw. ganzen Bauteilen (wie Blöcke oder Zylinder) und Eckstücken darstellen. Weder das Verhalten von Blöcken noch das von Eckstücken (was momentan aktiv ist) sind da 100% passend...
Hier müssen wir uns mal Gedanken machen, ob wir eine schönere Lösung dafür finden. Abhilfe kannst du aber grundsätzlich mit dem manuellen Pivotmodus schaffen
Es wäre also gut, wenn man beim Ziehen mit dem einstellbaren Abstand auch noch kippen könnte vor dem Setzen, weil man ansonsten Lüftungsgitter etwas aufwändiger bauen muss!
Oh, jetzt verstehe ich was du meinst
Das wäre generell kein Problem, wir müssten uns nur Gedanken machen, wie man die Steuerung dazu am besten umsetzt 
Das Radialmenü wird langsam voll, und eine separate Tastenbelegung könnte evtl. auch umständlich sein...Wie kommt das Licht außerhalb an die Wand und vor den Kasten (Vom Boden hab ich jetzt kein Bild, aber da leuchtet es auch hin)
Das Problem ist, dass alle Lichtquellen die ersten cm um sich herum ignorieren, wenn es um die Schattengenerierung geht. Das hat den Hintergrund, dass das Lichtobjekt selbst (zB die Laterne, Fackel etc) sonst ebenfalls Schatten werfen würde, was eher unschön ist.
In der Praxis ist das normalerweise kein Problem, da bspw. die Laterne eh groß genug ist, dass man die eigentliche Lichtquelle gar sicht so dicht an eine Wand stellen könnte. Beim Herunterskalieren des Objektes sieht die Sache dann aber natürlich anders aus, da dieser "Mindestradius" um die Lichtquelle herum nicht mitskaliert wird.
Generell stellst du schon richtig fest, dass Lichtquellen momentan nicht mitskaliert werden - eine riesige Laterne spendet also genausoviel Licht wie eine Miniaturlaterne. Das können wir theoretisch ändern, sind uns da aber noch nicht ganz sicher: Denn während riesige Laternen sicher unproblematisch wären, machen wir uns um Miniaturlampen Sorgen, denn aus Performancesicht sind diese fast genauso "teuer" wie größere Lichtquellen. Und je kleiner die Lichtquelle ist, desto eher würde man auch besonders viele davon auf engstem Raum platzieren (um eine entsprechende Ausleuchtung zu erzielen).
Hinzu kommt, dass das Skalieren von Lampen ja grundsätzlich so nicht direkt vorgesehen ist - das ist ja nur im Creative-Modus möglich, aber auch nur, weil wir dort keine künstliche Limitierung vornehmen wollen
Das "teure" sind in erster Linie die Schatten. Was wir vll machen könnten wäre die Schatten bei besonders klein skalierten Lichtern zu deaktivieren, um einen Performance-GAU zu verhindern
Oder wir könnten vll den oben genannten Mindestradius um die Lichtquelle herum, der beim Rendern der Schatten "ignoriert" wird, entsprechend mitskalieren.
Und bei der Kerze ist mir vermutlich ein Fehler aufgefallen - Ich dachte immer, das Licht kommt von da, wo das Feuer ist und nicht vom Wachsboden - Wenn man die Kerze nur etwas größer macht, leuchtet die in sich hinein in die Innenseite des Bodens (So blendet zwar nichts, aber es macht auch kein Licht mehr nach Außen) - Wenn man sie kleiner macht, hat man etwas mehr Licht, da der Lichtradius gleich bleibt...
Hmm... das ist eigenartig, das konnte ich jetzt bei mir so leider nicht direkt reproduzieren
Die Lichtquelle ist tatsächlich genau an der Stelle, wo auch die Flamme ist (siehe Anhang, oder habe ich was übersehen?)Allerdings muss man bei der Kerze dazu sagen, dass der Lichtradius generell sehr klein ist.
Bei den plastischen Ziegelsteinen, die ich auch im vorherigen Post eingesetzt habe, habe ich mich über das Einfärben gefreut (auch, dass es irgendwann noch mehr Farben geben soll), denn Ziegelsteine umfärben ist machbar, aber warum muss die Spachtelmasse direkt mit eingefärbt werden? - Kann man das nicht so machen, dass man die Auswahl hat, nur die Ziegel umzufärben?
Da müssten wir uns mal Gedanken machen... grundsätzlich müsste dafür für jede Textur individuell festgelegt werden, welche Bereiche einfärbbar sein sollen und welche nicht. Und diese Informationen müssen in irgendeiner Form für die Grafikkarte zugänglich sein, was den RAM und VRAM Verbrauch etwas nach oben steigern würde. Das ist aber definitiv nicht unmöglich (und wäre auch generell ein wünschenswertes Feature)
Ebenso fände ich es ganz gut, wenn man beim Einfärben eine Art Transparenz-Regler hätte, sich also selbst die Deckkraft zusätzlich einstellen könnte!
Das ist leider wieder ein bisschen heikler, weil wir diese Information noch irgendwo unterbringen müssten - denn den eigentlichen Wert für Transparenz verwenden wir bereits für die einzelnen Einfärb-Stufen
Wir könnten natürlich auf die Einfärb-Stufen verzichten und stattdessen darüber die Transparenz bzw. Deckkraft umsetzen, aber ich weiß nicht, was vorteilhafter wäre... mal sehen, wie sich das mittelfristig entwickelt 
-
Heißt es jetzt, dass alle Spieler erstmal nur der "Glatzkopf" in Unterwäsche sein werden?
Leider ja...
-
Wozu soll ein Befehl der Gebäude entfernt gut sein? Was müsste der/die Spieler tun damit nichts entfernt wird.
Red könntest du mir "bestimmte Zeit nicht online war" etwas konkreter beschreiben? Ich möchte ja verstehen warum so ein Befehl sinnvoll wäre. Danke...
DE: Ich poste diese Antwort mal auf Deutsch und Englisch, da dies ja ein englischsprachiger Thread ist
Jedenfalls kann so ein Befehl hilfreich sein um bspw. angefangene Gebäude von Spielern, die eh nicht mehr auf dem Server spielen, zu entfernen. Man könnte also bspw. festlegen, dass alles Gebaute eines Spielers, welcher seit 6 Monaten nicht mehr online war, gelöscht wird.
EN: I'm writing this response in German and English, considering this is a English thread
Anyway, such a command may be helpful in order to remove abandoned buildings of players who don't play on your server anymore. You could, for example, remove all buildings of players who haven't been online for the last 6 months.
-
Hey, do you use the plugins or the lua scripts? Does that mean the scripts/plugins work correctly, but they just don't save their data? In this case it could be a permission issue (i.e. maybe the server does not have write permission to the scripts/plugin folder)... there could be more information about what's going on in the server log. You can find them in the "Logs" subfolder in the server directory. Maybe you can upload the latest log file here (or alternatively send it via PM to me)
-
Maybe it's not a bad idea to have a command which removes old buildings (or more precisely, buildings of players who haven't been online for a given amount of time)... I'll put that on our to-do list
About a flag: We're working on two protection systems - one is set up by admins (very much like the old area protection), the other one allows players to claim land without having to call an admin (i.e. they could place a flag or a similar object get a protected area). Ofc admins can choose which protection system they want to use. When it comes to the latter system, we could basically implement some optional decay of buildings
-
Wenn man bei einen Befehl nachträglich einen Wert ändern will springt der cursor ein nach rechts.
Das passiert immer wenn ich die Backspace Taste benutze.
Das ist leider ein Problem mit UI Toolkit (also dem zugrundeliegenden UI Framework von Unity) i.V.m dem neuen Input System von Unity
Beides ist leider noch extrem fehlerbehaftet - uns sind gleichzeitig aber auch leider die Hände bei diesen Dingen gebunden Fairerweise muss man sagen, dass UI Toolkit auch immernoch eine Preview-Version ist. Hier soll es aber lt. Unity gegen Ende des Jahres Besserung geben.
Zudem funktioniert die Entertaste auf dem Numpad bei der Konsole nicht.
Das werden wir mit dem nächsten Update ändern
Diese Änderung wird aber nicht automatisch aktiv bei bestehenden Versionen - hier kann aber (auch jetzt schon) die config.properties Datei im Spielverzeichnis von Hand mit einem Texteditor bearbeitet werden: Es muss beim Eintrag Input_UIButtonSubmit noch key_numpadEnter hinten angefügt werden (mit Komma getrennt), also zB so: Input_UIButtonSubmit=key_enter, gamepad_buttonSouth, key_numpadEnterZudem wäre es toll wenn es wieder den Befehl "editc" geben könnte (den Befehl vermisse ich)
Das stimmt, der wird voraussichtlich mit dem nächsten Update reinkommen
Wenn ich aus dem Desktop wechsle wärend das Spiel läuft und wieder ins Spiel wechsel kann ich in der Konsole kein Pfeiltaste links sowie die Backspace Taste nicht mehr benutzen.
Auch das ist leider durch das InputSystem verursacht... manchmal hilft es, einmal kurz Alt zu drücken. Dieser Bug ist Unity seit Januar 2020 bekannt
Aber auch hier kann es sein, dass sich das in den kommenden Monaten bessert. Wir sind immernoch am überlegen, ob wir auf Unitys altes Inputsystem umsatteln, falls sich die Lage nicht bessert - das wird von fast allen bisherigen Unity-Spielen verwendet und funktioniert deutlich robuster, ist aber sehr eingeschränkt und technisch auf dem Stand von 2008 (und selbst für 2008 war das Inputsystem schon nicht ganz auf der Höhe der Zeit).
Mir ist aufgefallen wenn man frei (außerhalb des Rasters) baut, dass die Elemente sich optisch ganz leicht versetzt platzieren. (was jetzt nicht tragisch ist, weil man es erst sieht wenn man ganz nah ist)
Ja, das ist leider ein Nebeneffekt von folgender Sache: Damit überlappende Bauteile möglichst wenig flackern (sog. "Z-Fighting"), wird beim Rendern pro Element ein minimaler Versatz hinzugefügt. Dieser Versatz ist wirklich winzig, aber die Reihenfolge, in welcher die Bauteile platziert werden, spielt dabei eine Rolle, daher kann es manchmal passieren, dass zwischen zwei Bauteilen ein etwas größerer Versatz sichtbar wird (immernoch sehr klein, aber durchaus sichtbar).
Ich finde die Steamanzeige vom Verhälnis zum Bildschirm etwas zu groß skalliert (Auflösung im Spiel 3840 x 2160)
Oh, das ist eigenartig
Das wird eigentlich automatisch von Steam gesteuert... soweit ich sehe bietet die Steam API leider offenbar keine Möglichkeit, die Größe dieser Anzeige zu ändern (lediglich die Position und den Abstand zum Rand) 
Ich würde es richtig toll finden wenn es eine Spirale (Schraubenfeder) als Model geben würde.
[...]
Ich denke aber, das die nicht ganz so leicht umsetzbar ist, weil neben der Breite, Länge und Höhe auch die Dicke des Materials einstellbar sein müsste
Das wäre nicht schlecht! Vor allem aus Performancesicht wäre es deutlich vorteilhafter, wenn das Spiel dafür ein fertiges Objekt bieten würde, statt wenn es aus einzelnen kleinen Bauteilen nachgebaut würde.
Es stimmt aber, dass die Umsetzung tatsächlich erschwert wird, wenn die Feder eine einstellbare Dicke und Länge haben soll... hier müssen wir uns mal Gedanken machen, wie wir das am besten umsetzen würden
PS: Die Lok sieht schon extrem vielversprechend aus!
Wie ist so der aktuelle Stand mit dem Multiplayer-Update red51 ?
Auf Trello sehe ich Dedicated Server, Protection und Player Model. Wird davon etwas nochmal Postponed?
Das MP Update wird bald erscheinen, auf jeden Fall noch innerhalb der nächsten 2 Wochen. Ich werde in Kürze mehr Infos dazu schreiben
Für das Update fehlt im Grunde noch eine richtige Protection. Zwar kann über die Permissions - ähnlich wie in der Java Version - grundlegend darauf Einfluss genommen werden, aber eine umfangreichere Protection vergleichbar mit der AreaProtection fehlt noch. Das würden wir vll gerne noch fürs Update fertig bekommen (auch wenns für den ersten Release ggf. nicht zwingend erforderlich ist).
Hinsichtlich der Player sind wir eigentlich durch (zumindest das, was für das Update geplant war). Weiterhin fehlen Anpassungsmöglichkeiten der Spielerfigur sowie Kleidung, aber das ist ohnehin erst für später geplant.
Beim RCON Tool weiß ich weiterhin nicht, ob es rechtzeitig fertig wird. Wenn nicht, wird es aber relativ zeitnahe nachgereicht.
Wir haben nochmal relativ viel Zeit investiert um den RAM Verbrauch zu drücken und die Auslastung für schwächere Server-CPUs besser zu verteilen: Ursprünglich hat sich der Server quasi wie der Server in der Java Version verhalten, aber da die neue Version jetzt deutlich höhere Sichtweiten und eine größere Maximalhöhe der Welt hat, sind die Anforderungen massiv nach oben gestiegen (während ein Spieler in der Java Version mit max. Sichtweite "nur" knapp 3500 Chunks vom Server angefordert hat, fordert ein Spieler in der neuen Version nun bei max. Sichtweite knapp 70.000 Chunks an). Wir sind mit dem Ergebnis aber bisher zufrieden
-
For dedicated servers, there is a new task scheduler available which allows you to set up custom tasks which will be executed after a given amount of time (or at fixed times). You can also react to certain events (e.g. if a player connects or if a player dies). The scheduler allows you to execute various commands, including messages (both chat and yell messages), server-related tasks (restart, shutdown etc), world-related tasks (change weather or time of day) and even http requests.
The dedicated server is already shipped with an example scheduler file called "scheduler.txt", which is located in the server directory (if it's missing, just create a new "scheduler.txt" file in the server directory). If you modify this file, you either have to restart the server or execute the "reloadscheduler" command to apply the changes to the server.
Every line in the "scheduler.txt" file is treated individually - this means you can add one command per line. Every command starts with an "@" character, followed by the trigger and the actual command. Example: @15m /say This is a test message! - this executes the /say command every 15 minutes (defined by the 15m).
Lines with a "##" prefix are just comments and have no effect on the server. Example: ##This line has no effect
You can either define time intervals (examples: "@10m" for every 10 minutes, "@40m" for every 40 minutes, "@1h" for every hour, "@2h30m" for every 2.5 hours), time offsets (e.g. "@+10m" to execute a command once after 10 minutes, "@+1h" to execute a command once after 1 hour, "@+12h" to execute a command once after 12 hours) or fixed times (e.g. "@12:00" to execute a command once at 12:00 pm system time, "@16:30" to execute it at 4:30 pm etc).
You can also access a few built-in variables, which are always available. This covers the current player count (accessible via %playercount%) and every server option defined in the "server.properties" file (e.g. %serveroption.server.shortname% or %serveroption.world.seed%).
Apart from times, you can also react to certain events (every event also has a set of built-in variables). Currently the scheduler supports following events:
Event name Parameters Description @OnPlayerConnect %name% (name of player) Called whenever a player connects to the server @OnPlayerDisconnect %name% (name of player) Called whenever a player disconnects from the server @OnPlayerSpawn %name% (name of player) Called when a player spawns on the server (i.e. right after the loading screen) @OnPlayerRespawn %name% (name of player) Called when a player respawns (after death) @OnPlayerDeath %name% (name of player) Called when a player dies (unless he was killed by another player or npc) @OnPlayerKilledPlayer %name% (name of player who died), %killer% (name of killer), %item% (item that was used) Called when a player was killed by another player @OnPlayerKilledNpc %name% (name of player who killed the npc), %npc% (npc that died), %item% (item that was used) Called when a player kills an npc @OnNpcKilledPlayer %name% (name of player who died), %npc% (name of killer npc) Called when an npc kills a player @OnWeatherChange %weather% (name of new weather type), %oldweather% (previously set weather type) Called when the weather changes (either naturally or via command) The upcoming RCON tool will have access to the scheduler. It can be used to modify or set up new tasks.
-
(1) Fangen wir erstmal mit dem Auffälligsten an:
Hmm... ich konnte das bei mir leider nicht genau reproduzieren, aber ich fürchte, dass ich die dafür nötigen Schritten auch nicht ganz verstanden habe
Hast du evtl. ein Video von diesem Problem?(2) Im Zusammenhang mit der Zahl (0.001) habe ich dann auch noch ein Anliegen:
Das kann ich bestätigen, der size Befehl macht momentan einige Probleme. Das werden wir noch beheben
(3) Dann habe ich noch etwas, was mir seit der Überarbeitung des Rasters aufgefallen ist:
Ich hoffe, man kann das Problem einigermaßen erkennen.
Ja, das liegt daran, dass die Vorschau geringfügig größer ist als das eigentliche Element. Es gab ein paar Gründe, das so zu machen, aber beim Bauen mit kleinen Bauteilen (wo es auf jeden cm ankommt) ist das zugegebenermaßen sehr problematisch... das werden wir ändern!
Einerseits setzt sich beim Setzen (wenn man vorher mit "STRG" festsetzt) der halbe Zylinder nicht zurück, sondern bleibt in der gedrehten Position ...
und
... andererseits scheint es egal zu sein, ob ich vorher mit "STRG" festsetzte oder nicht, auch ob ich mit oder ohne Raster baue - Bei einigen Positionen springt das Bauteil raus!
Ich kann es leider nicht ganz nachvollziehen, aber manschmal hat es den Anschein, als hätte es teilweise ein Problem mit der Drehposition an der mittleren Stelle der Rundung des halben Zylinders ... aber manchmal kann ich diese Gradzahl auch erst später erreichen, was mich vermuten lässt, dass auch die Position und eventuell sogar die gesetzte Rotation damit zu tun haben könnte!
Was genau meinst du in dem Zusammenhang mit "rausspringen"? Dass sich die Position des Bauteils ändert (es also plötzlich einen Block nach links verschoben ist), oder dass sich die Rotation zurücksetzt?
Wenn ich etwas um 1 Grad drehe, dann kann es sein, dass nach dem Setzen da steht "0.999 Grad" - Da ich die Rotation selbst nur mit 2 Nachkommastellen bearbeiten kann, kann ich das nicht einmal korrigieren.
Das ist in der Tat noch ein Problem: Nachdem mehrere Drehungen und Größenänderungen durchgeführt wurden, kann es sein, dass durch marginale Ungenauigkeiten bzw. Rundungsfehler der Wert nicht mehr genau 1 beträgt, sondern 0.9999999... (das Spiel zeigt nur max. 3 Nachkommastellen an). Diese "Ungenauigkeit" ist kein Bug, sondern technisch bedingt (das Spiel verwendet 32 Bit Gleitkommazahlen, die nur eine begrenzte Genauigkeit bieten) und im Alltag normalerweise nicht weiter problematisch. Es sieht halt nur blöd aus, wenn da 0.999 statt 1.0 steht
Mal sehen, ob wir die Anzeige durch etwas Aufrunden noch verbessern können.
(7) Desweiteren hätte ich noch eine Bitte betreffend der Möglichkeit des Ziehens in Kombination mit der Einstellung den Abstand zu bestimmen: [...]
Wenn ich mir die Vorschau von einem zum andren Ende ziehe und den Abstand einstelle, dann wäre es gut, wenn ich das Material dann auch noch kippen könnte und das dann für alle gleich gekippt wird - Wenn ich vorher kippe, zieht er in dem Winkel diagonal aber nicht mehr so!
Wie meinst du das genau? Grundsätzlich sollte beim Ziehen die aktuelle Drehung auf alle Bauteile angewendet werden
Bisher konnte ich nur mit der Blockform den "size"-Befehl nutzen, bei allen anderen Glasscheiben nicht und dann verhalten die sich beim Andocken noch anders (Nicht von der Mitte des Glases, sondern von einer Eckkante)!
Das mit dem Andocken kann ich bestätigen, das muss noch gefixed werden
Hin und wieder passiert es, dass sich bei mir das Radialmenü beim Öffnen direkt wieder schließt und dann kann ich auch keine Objekte mehr nutzen, aufheben und auch keine Lampen mehr einschalten / ausschalten - Und bisher half dann nur Spiel beenden und neu starten!
Das scheint in erster Linie dann aufzutreten, wenn vorher mit Alt+Tab das Spiel verlassen wurde (wie von Avanar erwähnt). Meistens hilft es, danach einmal Alt zu drücken, um das Problem zu beheben.
Leider sind sowohl die UI (basierend auf Unitys "UI Toolkit", was allerdings auch noch nicht "production ready" ist) als auch das Input System (hier verwenden wir auch Unitys neues Input System) noch extrem problembehaftet - vor allem auch die Kombination von beidem. Für das UI Toolkit Package ist das letzte Update leider von Februar (und leider wurden in dem Update nur wenige Fehler behoben), seitdem hat sich leider nichts getan (und anders als bei anderen Packages ist der Code auch nicht bei Github verfügbar), daher sind uns hier weitgehend die Hände gebunden.
Unity hat angekündigt, dass UI Toolkit Ende des Jahres "production ready" werden soll, daher hoffe ich, dass es in den nächsten Monaten Besserungen geben wird
Was mir aber auch noch aufgefallen ist, es scheint hin und wieder auch Probleme beim Positionsabspeichern zu geben, wenn ich das Spiel beende:
Jap, das stimmt leider. Das Beenden geht leider zu schnell, sodass die Welt nicht nochmal gespeichert wird
Das wird sich voraussichtlich mit dem nächsten Update ändern.Von der Java-Version habe ich irgendwas dunkel weit im Hintergrund meines Hirns. War da nicht was, dass Veränderungen "nur" alle paar Sekunden tatsächlich gespeichert werden? D.h. wenn jemand also schnell nach der letzten Änderung das Spiel verlässt, wird nicht alles übernommen.
Ob das bei der Unity-Version auch so ist, kann wohl nur red51 beantworten.Ja das stimmt: Grundsätzlich wird die Welt alle paar Sekunden gespeichert (genau genommen werden diverse Teile des Spiels auch zeitversetzt gespeichert, um die Last möglichst gut zu verteilen). Generell soll beim Beenden aber die Welt ebenfalls nochmal gespeichert werden (d.h. dieses "alle paar Sekunden speichern" ist in erster Linie nur dafür gedacht, dass zB bei einem Crash nicht gleich mehrere Stunden Spielzeit verloren gehen), aber leider funktioniert das beim Beenden momentan noch nicht. Das wird sich aber bald ändern
-
VR ist langfristig geplant, aber von der Priorität haben wir das erstmal nach hinten geschoben. Das wichtigste Ziel ist momentan, dass die neue Version einen Zustand erreicht, mit welchem sie die Java-Version ersetzen kann (also auch auf der Store-Page als Produkt erscheint, und nicht mehr in einem Beta-Branch versteckt ist)
-
# Wetter-entsprechende Wolken
Wolken sind geplant, das werden wir nach dem MP Update in Angriff nehmen
# Blitz und Donner
Das ist zumindest langfristig geplant. Leider kann ich momentan dazu noch nicht viel sagen... nachdem Wolken implementiert sind kann ich das auf jeden Fall besser einschätzen.
Ansonsten sind auf jeden Fall noch einige Wettereffekte geplant, wie Yarofey schon vermutet
Sandstürme für Wüsten sowie Schneestürme für Schneegebiete sind auf jeden Fall geplant. Auch Hagel wäre keine schlechte Sache.Größere Wetterereignisse wie Tornados sind da schon etwas heikler von der Umsetzung, wären aber nicht schlecht.
Da du das Anzünden erwähnst; ich frage mich, ob wir in RW mal "dynamisches" Feuer sehen werden, also damit meine ich Feuer, welches sich ausbreitet und Bauelemente brennen lässt usw. Das klingt für den einen oder anderen bestimmt nach einem Albtraum, aber wenn man das geschickt designt, könnte es ganz interessant werden
Also z. B. so, dass es Bauteile nicht komplett zerstört, sondern verkohlen lässt, da man diese dann reparieren kann, damit die Bauteile die Position behalten.
Wir haben damit tatsächlich mal herumexperimentiert - zumindest beschränkt auf Items (die zB ins Feuer geworfen werden), Bäume und Objekte (wie Möbel). Bei Bauelementen wäre es eine wirklich gute Idee, wenn diese nicht direkt zerstört werden, sondern nach einem Brand nur verkohlt sind und repariert werden können
Wir haben "dynamisches Feuer" bislang noch nicht auf unsere Roadmap aufgenommen, da wir dafür erst noch etwas weiter herumexperimentieren müssen - vor allem um herauszufinden, wie sich das performancetechnisch verhalten würde, gerade bei Großbränden auf MP Servern
Es wäre aber ein tolles Feature und wir behalten das auf jeden Fall im Hinterkopf! -
We've created two Steam guides some time ago about the available console commands and the items in the Java version.
For getting a construction element with any texture, you can use the command mentioned by Avanar (or the planks 'n beams plugin)
This part works a bit better in the new version, since all construction elements are available with any texture in the crafting menu (without having to use console commands).
-
1. Die Texturen der Dachschindel drehen sich willkürlich nach Belieben. Mal zeigen die Schindel nach oben, mal nach unten. Das passiert auch urplötzlich beim Mehrfachsetzen innerhalb einer Reihe. Ein vernünftiges Dach hiermit zu decken ist unmöglich, es sei denn, man reißt den Block x-mal wieder ab und hofft auf eine passende Ausrichtung.
Ja, die Ausrichtung der Dachtexturen ist leider noch etwas problematisch
Diese können wir nicht einfach wie restliche Texturen anhand ihrer Weltposition ausrichten (da die Orientierung der Schindeln sonst nicht passt), aber dafür werden wir noch eine Lösung finden.2. Ist die mehrseitige Texturierung der Blöcke noch auf der Agenda? Es kann nicht der Sinn des Bauens sein, Wände mit zusätzlichen Blöcken zu 'tapezieren' und somit im Prinzip ein Gebäude doppelt zu errichten. Ich kann es mir nicht vorstellen, dass ein beidseitig texturierter Block mehr Ressourcen verbraucht als 2 unterschiedlich texturierte gesetzte Blöcke...
Also zumindest das mehrseitige Einfärben ist geplant (sprich dass jede Seite eine separate Farbe bekommen kann). Zum mehrseitigen Texturieren müsste man sich nochmal Gedanken machen, hier sind wir uns nicht ganz sicher... fraglich ist hier vor allem auch, wie man die verschiedenen Texturen dann festlegen wird, vor allem auch im Survival-Modus. Hier wären "Tapeten" vielleicht denkbar... keine Ahnung... wir bräuchten dazu mehr Feedback
Dasselbe hatte ich auch mit einer Parkett-Textur (Siehe Bild). Ich würde echt gerne wissen, warum das passiert, denn ich erkenne da keine richtige Logik drin.
Manche Texturen habe eine feste Ausrichtung, da treten leider bisher diese Probleme auf (je nach Texturskalierung)
Wir müssen da unbedingt eine Lösung finden.Daher muss ich sagen, dass ich sehr begeistert von den neuen Baufunktionen bin - endlich keine Einschränkungen mehr - die Möglichkeiten scheinen nun schier endlos!!!
Danke fürs Feedback! Dein Turm sieht übrigens echt klasse aus!
Was mir aber aufgefallen ist, dass man die Dachtexturen bei den Rampen offensichtlich leider nicht um 180° drehen kann, so dass die Spitze der Rampe nach unten zeigt (siehe Screenshot) - die Unterseite der Textur scheint fest auf eine der beiden Längsseiten fixiert zu sein - auch über Spiegeln lässt sich die Textur nicht drehen
Ja, das ist leider eine Einschränkung, die wir in Kauf genommen haben, damit Texturen generell weniger Kanten zw. verschiedenen Elementen haben... es ist aber eine Funktion geplant, mit welcher von Hand eine separate Drehung der Textur pro Element angegeben werden kann.
- Bitte bei allen Materialien (auch beim Glas) unbedingt alle geometrischen Formen ermöglichen
Grundsätzlich sind alle Formen mit allen Texturen verfügbar (via Command). So kann man bspw. eine Treppe oder Rampe als Glastextur erhalten, aber zB auch eine Scheibe mit Holz- oder Metalltextur.
Im Crafting-Menü könnten wir die Formen grundsätzlich auch reinpacken, aber wir wollten das vorerst nur auf die Formen beschränken, die einigermaßen zur Textur passend sind. Vielleicht machen wir hier aber auch noch Gebrauch von den neuen Kategorien, und machen alle Formen im Crafting-Menü verfügbar, die unpassenden Formen lediglich in einer separaten Kategorie "versteckt"
- Bitte weitere Formen hinzu fügen: halbe Kugeln & hohle halbe Kugeln - letzteres ist sehr wichtig für Kelche (Trinkgläser), Suppenkellen, Schalen, Schüsseln u.s.w.
Das ist auf jeden Fall noch geplant
Nach dem MP Update werden wir uns dieser Sache widmen - Bitte wieder die Blaupausen einfügen
Blaupausen sind ebenfalls geplant
PS: Bitte bei den Glasscheiben einen mittleren Ankerpunkt hinzu fügen
- denn wenn man die Scheiben um 90° dreht, um die Textur quer statt hochkant zu bekommen, lassen sich die Scheiben nicht mehr mittig positionieren - sprich es snapt dann immer ein äußerer Ankerpunkt der Scheibe an dem mittleren Ankerpunkt des Objekts darunter an.Hmm... meinst du einen mittigen Andockpunkt direkt in der Mitte der Scheibe (also im Zentrum der Scheibe)?
Aber es scheint beim Andocken bei Scheiben generell ein Problem zu geben, abhängig von der Drehung der Scheibe... das müssen wir noch beheben.
Da wünscht man sich direkt noch eine Möglichkeit, um die Wände mit Moos oder Rissen zu verzieren, vielleicht kann man dies in Zukunft mit "Decals" realisieren (also so ähnlich wie Poster, die sich aber an eine Oberfläche anpassen, also perfekt für Rundungen).
Das ist sogar geplant
Mit dem "Poster-Update" (oder kurz danach) wird man auswählen können, ob das Poster als normales, "flaches" Poster dargestellt werden soll (quasi wie in der Java Version), oder eher als Graffiti (dann also an die Struktur der Oberfläche angepasst).wenn man auf heavysnow umstellt bleibt der schnee ja liegen, finde da die Geräusche auch cool. wenn man nun aber das spiel beendet und dann wieder neu ins spiel geht, blieb die heavysnow einstellung zwar aktiv aber der schnee lag nicht mehr.
Das wird sich mit dem nächsten Update ändern
Bislang wurde dieser Zustand noch nicht in der Welt abgespeichert, aber das MP Update schafft da Abhilfe (da dieser Zustand ja fortan auch korrekt synchronisiert werden muss).Leider Bleibt der schnee ja auch auf den Bauelementen nicht liegen, hier wäre eine langfriestige Änderung wünschenswert. vieleicht optional nur auf den Dachtexturen
Das ist leider etwas schwierig: Die Prüfung, ob ein Bauteil unter freiem Himmel ist oder nicht, ist verhältnismäßig aufwändig (und muss streng genommen auch mehrfach pro Bauteil ausgeführt werden, da ein Bauteil ja ggf. sehr groß sein kann und evtl. nur teilweise unter freiem Himmel liegt). Das dann bei tausenden oder gar hunderttausenden Bauteilen durchzuführen würde die Weltgenerierung leider zu extrem verlangsamen
red51 kannst du mal bitte den Unterschied beim wetter mit den befehlen clear und default erklären, ich bemerke da kein unterschied, clear könnte ja in sun umbenannt werden.
Grundsätzlich ist das wie in der Java Version: default ist das Standardwetter, clear hingegen besonders sonniges Wetter. Momentan sind die Unterschiede nicht ganz so gewaltig, da es noch keine Wolken gibt - denn hier würde der Unterschied am meisten auffallen (clear ist wolkenfrei, bei default wären ein paar Wolken am Himmel).
Derzeit ändert sich durch den Befehl also nur ein wenig der Nebel. Nach dem MP Update widmen wir uns u.a. dem Himmel, dann dürften Wettereffekte auch mehr zur Geltung kommen
clear könnten wir grundsätzlich auch in sunny umbenennen, wir haben clear lediglich so beibehalten, weil es in der Java Version auch schon so hieß.
-
zunächst mal sind in meiner config.properties sämtliche Zeilenumbrüche NICHT vorhanden (siehe Sreenshot) - was aber eigentlich ihre Funktion nicht beeinträchtigen dürfte - unnormal ist es dennoch. In meiner alten JavaVersion schaut die config.properties ordentlich aus.
Hmm... kann es sein, dass du evtl. Windows 8 verwendest oder eine alte Version von Windows 10? Ältere Windowsversionen brauchen spezielle Zeilenumbrüche (Windows halt), damit Microsoft Programme diese auch als Zeilenumbrüche erkennen (Microsoft halt). Das hat sich in Windows 10 endlich geändert (zumindest mit nachfolgenden Updates). Die neue Version von RW verwendet unter Windows und Linux die selben Zeilenumbrüche (anders als die Java Version, die unter Windows noch Windows-spezifische Zeilenumbrüche gespeichert hat), aber ältere Windowsversionen erkennen das wie gesagt leider nicht.
Ich denke es wäre nicht verkehrt, wenn wir das ändern, damit auch ältere Windows Versionen damit besser zurechtkommen
Als vorläufige Lösung könntest du bspw. Notepad++ verwenden, das interpretiert auch normale Zeilenumbrüche als Zeilenumbrüche - und das ist generell ein nützliches und empfehlenswertes Programm und tausendmal besser als das Windows-eigene Notepad Ansonsten habe ich dir eine Standard config anbei hochgeladen, in welcher die Sprache auf Deutsch festgelegt ist (die kannst du einfach ins Spielverzeichnis packen, aber am besten nicht mit einem Windows-Programm editieren).
Meine Vermutung ist, dass der Launcher beim Start bei Abgleich der Files die config.properties überschreibt
Die config wird beim Spielstart einmal eingelesen, alle Einstellungen (die korrekt ausgelesen werden konnten) werden übernommen, und anschließend werden alle Einstellungen wieder in die config gespeichert. Wenn das Spiel die Optionen nicht richtig lesen konnte, gehen diese Optionen leider verloren (zB wenn Zeilenumbrüche fehlerhaft sind).
-
Da stellt sich die Frage ob es nicht sinnvoller ist, etwaige Funktionen des Creative-Modes stattdessen für den Survival-Mode anzubieten. Diverse Dinge gibts ja da bereits als Option (zB das sofortige Abbauen, man kann Hunger/Durst sowie Dinge wie Temperatur ausschalten etc).
Grundsätzlich kann zwar über die Permissions der Creative-Modus angepasst werden (das ist zB relevant für MP Server), aber wenn alle diese Einstellungen auch zusätzlich ins Optionsmenü wandern, dann bläht das das Menü ziemlich auf... schon jetzt habe ich den Eindruck, das viele Einstellmöglichkeiten untergehen (eben weil das Optionsmenü schon recht umfangreich ist)
Wie genau meinst du das mit dem "unendlichen bekommen von Elementen und Objekten"? Meinst du die Möglichkeit, von überall das Craftingmenü aufzurufen und Items ohne Rohstoffe zu craften?
-
Der Befehl
object constructionbarrierist auch kaputt, er öffnet das Block-Crafting-Menü, anstatt die Barriere zu liefern
Oh, danke für auch diesen Hinweis, das sollte natürlich nicht sein
Auch das wird mit dem nächsten Update gefixed. -
This indicates that the server received an UDP packet, but couldn't find a connection for it...
Maybe you could use a program like Wireshark to find out the IP of the sender. -
I've moved your post into a separate topic, since it wasn't related to the original post in the german section (which was solely about dedicated servers)
Nevertheless, this error indicates that some game files are missing (it can't find the language files). If this is the Steam version, please try to verify the game files (rightclick on RW in your Steam lib -> Properties -> Local files -> Verify integrity of game files)
