Mal eine Frage die nicht auf Dedicated Server bezogen ist: Wird ein "Mit Freunden spielen"-Modus (Steam P2P) bereits enthalten sein?
Ja, zusätzlich zum Dedicated Server wird es mit dem Update den "Mit Freunden spielen"-Modus (Steam P2P) sowie den klassischen LAN-Modus geben - also wie in der Java Version 
The multiplayer update for the new version will be available on Tuesday, August 31. Here you find some basic information about the dedicated server:
Das Multiplayer Update für die neue Version wird am Dienstag, den 31.08 erscheinen. Hier findet ihr ein paar grundlegende Informationen über den Dedicated Server:
Vielen vielen Dank für die lieben Worte und euer Mitgefühl 
Avanar: Das klingt nicht gut, ich hoffe, deinem Hund geht es mittlerweile besser?
drakonas111: I'm sorry to hear that, my condolences to you!
AbtRS6R: Das tut mir sehr Leid mit Karlo 
Es ist aber schön, dass er so alt geworden ist!
Eigentlich wollten wir die ursprünglich angesetzten 2 Wochen wirklich nicht ganz ausnutzen (und anfangs sah der Zeitplan noch recht gut aus)... aber leider ist unser Haustier - ein Kater - vor knapp über 1 Woche unerwartet erkrankt und musste gestern eingeschläfert werden Das hat dem Update ein wenig den Wind aus den Segeln genommen... ich würde aber weiterhin das Update gerne im August rausbringen, daher würde ich jetzt als Release-Tag vmtl. Montag den 30. oder Dienstag d. 31.08 anpeilen (auch wenn das nicht mehr ganz in die 2-Wochen-Spanne fällt).
Das RCON Tool wird möglicherweise nicht ganz fertig, aber dafür zeitnahe nachgereicht Das integrierte RCON Tool wird einen Permission-Editor sowie einen "Aufgabenplaner" bzw. "Scheduler" beinhalten, und zur RCON API haben wir eine umfangreiche Dokumentation vorbereitet (damit kann man bspw. ein eigenes RCON Tool schreiben, oder aber auch einfach für eine Serversteuerung o.ä. benutzen).
Das Update bringt übrigens auch eine integrierte "Area Protection", die quasi auf dem Permission-System basiert und damit nahtlos verknüpft ist. Die ist zwar noch nicht ganz ausgereift (eine UI dafür fehlt bspw noch), aber dafür ist man Griefern nach diesem Update nicht schutzlos ausgeliefert.
Introduction
Like the Java version, the new version also provides a permission system. Permissions are used to tell the server what a particular player is allowed to do and what not. You can set up individual "permission groups" and assign players to these groups - for example, a group "admins" may have full control and is allowed to execute commands, while a group "visitor" may not even modify the world.
There is always a default permission - it applies to all players (who are not member of a permission group) automatically. Every group permission is derived from the default permission and only overrides the keys which are actually specified in the group permission file.
Unlike the Java version, the new version stores permissions as JSON file. While a correct syntax is required for the file to be loadable, our built-in RCON tool also provides an easy-to-use permission editor.
Getting started
The dedicated server is already shipped with a "Permission.Example" folder (it's called "Example" to prevent server updates from overwriting the permissions). Just rename this folder to "Permission" (alternatively this happens automatically if you start the server for the first time). It contains a "default.json" file which represents the default permission file (which is automatically active for all players). Alternatively you can find some example permissions attached.
To create a new group permission, create a folder "Groups" (if it does not yet exist) and place your group permission there - e.g. if you want to create a "Guest" group, you could create a "guest.json" file in the Groups folder. To create Area permissions (which are only active within specific areas), create a folder called "Areas" in the permission folder (if it does not yet exist).
To assign a permission group to a player, use the ingame command setplayergroup <player> <group> (or spg <player> <group>). If you want to specify a permission group new players get automatically assigned to, you can use the Permissions_DefaultNewPlayerPermissionGroup option in the server.properties file (just provide the name of the group there, or leave it blank).
When it comes to server admins, the permission group is always overridden - this means permissions have no effect for admins (instead admins always gain full permissions). To change that, you have to set Permissions_AdminsFullPermissions to false in the server.properties file.
1. server_custom_logo= Can this only be an image? I would like to include html or similar links so when the image comes up a link to our Teamspeak or our site is clickable. If not in that logo, is there a mod or other method to do so? This would / will likely be a question for the new version as well.
Yes, unfortunately only images are supported. It supports .jpg, .png, .dds and .gif files (but no support for animations) 
There is no way to change that.
When it comes to the new version, servers will be able to set up a custom description (supporting rich text) which will be visible to players before they connect to a server. However, we have no plans for clickable links at this stage, because this could be abused by setting up links to malicious sites, for example... but maybe we could let server admins set up Teamspeak or Discord links so players can join their TS/Discord at any time.
2. settings_start_weather= what are the available parameters?
It just accepts the internal weather names (i.e. the same names which are used for the ingame "setweather" command) These are all weather types in the Java version: default, clear, overcast, rain, heavyrain, rainthunder, heavyrainthunder, storm, fog, densefog. You can also set this option to random to have a random weather after every server restart.
3. settings_weather_preset=default What are the options for this?
The supported weather presets are default (for a mix of good and bad weather), sunny (for mostly good weather) and unsettled (for mostly bad weather)
We don't have plans to use any free Unity or Unreal assets
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_numpadEnter
Zudem 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!
