@Red, wie war das nochmal mit der Textur Rotation, nachträglich ändern in der Console?
Die Rotation selbst kann leider nicht geändert werden, wenn du aber als Ausrichtung den Lokalen Modus wählen möchtest (damit die Textur am Bauteil ausgerichtet wird), ist das über einen Flag bzw. Attribut gelöst. Das kannst du mit edit attribute ForceLocalUV setzen bzw. entfernen 
Wir haben dann auch ein zeitliches bannen mit 1 und 5 Minuten ausprobiert. Aber das funktionierte leider auch nicht. Der "gebannte" Spieler wurde nur gekickt. Es gab zwar die Meldung, dass der Spieler für soundsoviele Minuten gebannt sei, konnte aber sofort wieder einloggen.
Die Meldung ist leider falsch: Die Banndauer ist in Sekunden, nicht Minuten 
Der Hilfetext bei Eingabe des Befehls in die Konsole erwähnt korrekt Sekunden, nur die Rückmeldung ist fehlerhaft. Wenn du also als Dauer 5 angibst, ist der Bann nach kurzer Zeit schon vorbei...
Die Blacklist habe ich, wie oben beschrieben angelegt und abgespeichert und hochgeladen. Und auch die Einstellung in der server.properties gemacht. Trotzdem keine Funktion.
Die Blacklist sollte korrekt funktionieren, ich habe das bei mir nochmal getestet 
Kannst du mir ggf. den Serverlog einmal senden (ggf. mitsamt der blacklist.txt), entweder hier oder per PN?
Erstmal tausend Dank red51 das Update ist großartig. Ich war in den Borealen um bei sternenklarer Nacht die Polarlichter zu bestaunen. Einfach Wahnsinn, gute Arbeit schon allein dafür. Folglich bin ich in die Polargebiete gezogen und schlag dort mein Lager auf. Höhlen sind klasse, vor allem solche, die teilweise geflutet sind
Vielen Dank für dein Feedback, das freut mich zu hören 
von da aus war es nicht mehr weit bis zur Hölle. Sie klingt allerdings ziemlich harmlos. Nichts zu hören von gepeinigten Seelen, die Ihr glaube ich in der Java Version hattet.
Die gibt es an sich auch weiterhin, nur leider sind die nicht immer hörbar... und ich habe den Eindruck, dass es mit einem der letzten Hotfixes (ungewollt) noch weniger wurde Das müssen wir auf jeden Fall nochmal anpassen
Vielleicht wären Dungeons dort unten eine SEHR GUTE IDEE
Spezielle Dungeons für die Hölle sind auf jeden Fall geplant 
Mir ist noch was aufgefallen, was nicht im Sinne des Erfinders sein dürfte. Der Tag ist global momentan kälter als die Nacht. Bei Sonnenuntergang wird es wärmer und nachts werden Tageshöchstwerte erreicht. Ich glaube eher, das hattet Ihr umgekehrt geplant oder?
Das ist tatsächlich so nicht gewollt, allerdings ist die Temperatur auch noch nicht wirklich implementiert... d.h. sie hat momentan noch keinen Effekt auf den Spieler o.ä. Sobald die Temperatur auch Wirkung zeigt, werden wir diese Ungereimtheiten ausmerzen 
Allerdings finden die Temperaturwechsel sehr schnell statt anders als das in der Natur passiert. Innerhalb von 1 Stunde Ingame ist es kälter oder wärmer geworden. Ich dagegen würde mir vorstellen, dass mit Sonnenaufgang die Temperaturen anfangen zu steigen und gegen Mittag die Höchstwerte erreichen. Dann 1 bis 2 Stunden vor Sonnenuntergang könnten sie allmählich wieder zurück gehen. Bevor im Verlauf der 1. Nachthälfte die Tiefstwerte erreicht werden.
Momentan ist es so, dass es tatsächlich direkt mit der Tageszeit bzw. dem Tag-Nacht-Zyklus zusammenhängt (daher die direkte Korrelation mit Sonnenauf- und -untergang). Ggf. passen wir das an, wenn wir die Temperatur implementieren... kann das aber leider noch nicht sagen^^
Ich habe in der Region den Wetterbefehl rain gegeben. Momentan führt das dazu, dass selbst in den kältesten Regionen der Welt dann auch Regen fällt. Selbst bei unter -30°. Dann gebe ich den Befehl snow und die Schneedecke schließt sich nicht in der milderen Tundra. Soll das so sein?
Leider gibt es momentan noch kein lokales Wetter, sondern nur globales Wetter... daher regnet es auch in Wüsten oder Schneegebieten. Das werden wir auf jeden Fall noch ändern
Cool. I did use an older project and was trying to convert it. What about the Profile and Encoding setting?
It's best to use the "Full JRE" profile and UTF-8 encoding
Sorry for my late response, but thanks for the log! It looks like there is unfortunately a bug with permanent bans... as a workaround, you could set a very high duration instead of -1, that should work then (but don't provide a value greater than 2,000,000,000, because that would be considered a permanent ban then).
Alternatively you could also create a blacklist: to do that, create a new file "blacklist.txt" in the server directory and enter the UIDs you want to ban (one UID per line). Then open the server.properties file and set Server_UseBlacklist to true. Now when starting the server, you should see a line "SERVER BLACKLIST ENABLED" in the console (or log), followed by every blacklisted UID (one per line).
Ich kann leider bestätigen, dass es mit dem ban Befehl offenbar einen Bug gibt 
Wie lange der schon existiert weiß ich leider nicht, werden wir allerdings mit dem nächsten Update beheben! Das Problem tritt auf, wenn ein Spieler dauerhaft gebannt wird... als workaround kann stattdessen den Spieler zeitlich begrenzt bannen (aber eine sehr lange Banndauer anzugeben - nur nicht länger als 2.000.000.000, da es sonst als permanenter Bann interpretiert wird).
Alternativ kann aber sonst auch die Blacklist verwendet werden. Wie von Skarafass und SonoBionda erwähnt, muss dafür eine blacklist.txt im Serververzeichnis (da wo auch die .exe bzw. das Startskript liegt) angelegt werden. Darin muss pro Zeile eine UID angegeben werden. Anschließend muss in der server.properties noch Server_UseBlacklist auf True gesetzt werden. Beim Serverstart sollte nun relativ weit unten in der Konsole (oder im Log) der Eintrag "SERVER BLACKLIST ENABLED" zu finden sein, gefolgt von allen gesperrten UIDs (eine Ausgabe/Zeile pro gesperrter UID).
The Javadoc contains an example about that
Basically you need to provide a bitmask of the Layers you want to include in the raycast. Do not use the layers directly, instead create a bitmask with the Layer.getBitmask() method. Other players have the Layer "REMOTEPLAYER", so getting the bitmask or performing the raycast would look like this:
Oh I thought that was why you left gaps in the item number list for additions and changes. I used the item numbers in my older JAVA day routines. Thanks for the pointers.
Yes, but if a certain update adds lots of new items, for example, the existing IDs may change. My previous post was perhaps a bit misleading: You still have to work with the IDs, but I just wouldn't recommend to use hard-coded IDs. So instead of
It's usually better to do it this way:
That code will remain compatible with future updates (and it's also obvious which item is about to be added, while the first snippet doesn't provide this information unless you add comments)
OH drat I just missed it in the API, Sorry, you have to add color = and turn it off /color
You don't necessarily have to add a closing tag (unless you want the remaining text to be drawn with default color). But apart from color changes, the new version also supports a lot more rich text tags (identical to the ones that are shown in the sign editor formatting help)
This happens if in your project settings (rightclick on the project -> properties -> sources) the "Source/Binary format" is is set to JDK 8. The new Plugin API uses Java 20, so you should change the Source/Binary format to JDK 20 accordingly
I wouldn't recommend using IDs for items and objects. These may change in the future, so it's better to work with the internal item name (which will never change). The API provides access to the item definitions, so if you know the internal item name (the same name that's used ingame to spawn an item), you can get the item definition for that:
If you want to compare items or item definitions, it's safe to use the id field of course.
If you have an Item instance, there is also a getDefinition() method to get the definition of that item. This way you can easily check what kind of item that is.
Example: if a player picks up an item from the ground and you want to check if it's a saddle:
Alternatively you can also check the item name of course. Saddles for horses are called "saddlehorse", so the check would look like this:
Or alternatively get the related clothing definition (since saddles are considered "Clothing" items) and check if it's a saddle (clothing defs have a so called "function" which defines special behaviour):
To give a new item to the player (e.g. a torch), it could look like this:
If you're referring to the new version, the language files are stored as .json files in the "Data/StreamingAssets/Languages" folder. To create a new language, you can create a new file there. It's recommendable to just clone the en.json file and rename it to the new language (e.g. "fr.json" for French, "es.json" for Spanish etc).
To use the new language then, you can change the "Game_Language" value in the config.properties file (either enter the full name or the language code), e.g. "French" or "fr" etc.
For me, I can have the modified recipes on my computer so when I go online to my server I will see the modified recipes because they are being read from my local computer.
No, if you only have the modified recipes clientside, that wouldn't work: The crafting UI would then show the modified recipes (and at first glance it will look like it's working), but the server wouldn't allow you to craft the item (if the serverside database isn't modified).
So right now there is no proper way to modify crafting recipes in multiplayer. It would require both the client and server to use a modified definitions.db, but that's not feasible (because clients will then run into problems if they join another, unmodified server). Modifying crafting recipes only works in singleplayer atm...
zu den Wasseroberflächen habe ich Bilder Hochgeladen.
Ich wollte eigendlich ein kleinen See anlegen, für ein Pump-Speicher-Werk
Danke für die Screenshots! Ist das erst kürzlich aufgetreten, oder ggf. schon vor dem letzten Hotfix (vom 21. Februar)? Das müssen wir uns unbedingt nochmal genauer anschauen
Was du probieren könntest: Gibt in diesem Bereich (wenn die kaputten LOD-Chunks sichtbar sind) mal recalculatelods in die Konsole ein (am besten wenn gerade nicht extrem viel los ist auf dem Server). Das dauert dann ggf. einen kleinen Augenblick. Sind die Chunks danach immernoch kaputt?
Was an Screenshots, die man alle 3, 4 Minuten updatet(oder andere Trigger wie neues Gebiet oder eine Veränderung) prozessorintensiv ist, verstehe ich zwar nicht, aber schade.
So einfach funktioniert das leider nicht: Einerseits reicht es nicht, nur alle 3 oder 4 Minuten die Szene zu rendern. Das Spiel muss stattdessen dafür sorgen, dass auch wirklich alle relevanten Chunks geladen sind. Das funktioniert nur bei Detail-Chunks, also nicht bei LOD-Chunks (da diese standardmäßig keine Gebäude enthalten). Die Java Version ist ähnlich vorgegangen. Dabei war pro Map-Tile bzw. pro Bild ein Bereich von 3x3 Chunks umfasst (und wie gesagt, das konnte immer nur dann gerendert werden, wenn diese Chunks alle geladen sind).
Bei hoher Sichtweite hat man einen Detail-Bereich von ca. 20x20 Chunks. Die Chunks sind jetzt etwas größer, also würde das Spiel vmtl. 2x2 Chunks rendern, was bereits 100 Bilder sind, die erzeugt werden müssen. Und das kann das Spiel ja nicht auf einen langen Zeitraum verteilen, sondern User erwarten ja auch, dass die Karte beim Öffnen was anzeigt, zumindest die aktuelle Umgebung. Außerdem muss das Spiel die Chunks dann rendern, wenn sie auch vorhanden sind (d.h. wenn das Spiel damit zu lange wartet, ist der Spieler vll zwischenzeitlich schon weitergereist).
In Unitys HDRP ist das Rendern einer 2. Ansicht extrem teuer. Das ist nicht zu verwechseln mit einem Screenshot, der ja immer nur das enthält, was du gerade ohnehin schon siehst (d.h. bei einem klassischen Screenshot wird einfach nur der bereits gerenderte Bildschirminhalt genommen). Für die Karte hingegen muss ja aus einer ganz anderen Ansicht heraus die Szene gerendert werden (d.h. diese Ansicht sieht Dinge, die du auf dem Monitor momentan gar nicht siehst), was in Unitys HDRP nicht vorgesehen ist (was zugegebenermaßen sehr ärgerlich ist). Der initiale Overhead, um von einer 2. Kamera aus zu rendern, kann durchaus bis zu 50 bis 100 ms betragen. Klingt erstmal nach nicht viel, ist aber für Echtzeitverhältnisse enorm. Einerseits ist selbst das bereits für einen deutlich wahrnehmbaren Ruckler bzw. Framedrop ausreichend, andererseits haben wir bei 100 Bildern bzw. Tiles schon eine Gesamtdauer von 5-10 Sekunden (was einfach indiskutabel ist). Aber auch wenn die Kamera dauerhaft rendert (ohne den initialen Overhead), dann ist mit einem Performanceverlust von bis zu 50% zu rechnen.
Wenn jemand dann durch die Gegend reist, kommen kontinuierlich neue Map-Bereiche hinzu, die gerendert werden müssen (zumindest beim erstmaligen Aufdecken). In Unity kann sowas auch nicht in einem separaten Thread passieren, sondern sowas muss im Hauptthread ablaufen (und führt entsprechend dann zu Framedrops/Rucklern/Hängern usw). Wenn wir 60 FPS erreichen wollen, darf ein einzelner Frame maximal 16 ms dauern.
Es mag zwar Situationen geben, in denen das alles kein Problem ist (zB wenn sich der Spieler lange in derselben Gegend aufhält), aber es gibt leider auch viele Situationen, in denen es sehr problematisch ist (besonders wenn der Spieler viel unterwegs ist).
Nach momentanigen Stand ist sowas in Unitys HDRP einfach nicht vernünftig umsetzbar.
Dann wären halt auch Gebäude mit drinnen und alles was der Spieler an der Welt verändert, so vereinfacht hat es halt ausschließlich eine grobe Orientierungsfunktion.
Grundsätzlich ist das der Hauptzweck, den wir mit der Karte erfüllen wollen: Ein Orientierungswerkzeug bereitstellen. Ich gebe zu, dass die Karte in der Java Version oftmals schön anzusehen war, aber in Unitys HDRP sind uns da einfach technische Grenzen gesetzt. Ich finde es auch ärgerlich, dass es so ist, wie es ist (die Unfähigkeit der HDRP, die Szene von anderen Kameras zu rendern, setzt dem Spiel auch in anderen Bereichen Grenzen).
Allerdings wäre es auch unvernünftig, wenn wir die Karte auf unbestimmte Zeit verschieben, bis es irgendwann ggf. eine andere Lösung für die Render-Problematik gibt. In mind. 95% der Fälle, in denen Spieler das Fehlen einer Karte monieren, dreht es sich effektiv darum, dass es Orientierungsprobleme gibt - und das Problem würde die Karte in der Form, in der sie kommt, weitestgehend lösen.
Wird in absehbarer Zeit ein Gforce Now Zugang kommen, oder wird das erst kommen wenn das Spiel mehr Inhalt hat?
Leider kann das nicht geschehen, bevor die Java Version nicht durch die neue Version ersetzt wurde. Wenn das geschehen ist, wollen wir einige Features einbauen, die für GFN erforderlich sind. Danach hängt es aber letztenendes von NVIDIA ab, ob sie RW in ihren Katalog aufnehmen wollen oder nicht
Will wireable (light) switches controlling multiple light sources ever be a thing?
Yes, that will be possible once electricity is added to the game
That's weird Losing the inventory is indeed to be expected (unless the permission has been changed, as mentioned above), but that should never affect chests in the world If this happens again, do you mind sending me a server log (feel free to send it via PM)? Maybe could also send a report when accessing his dead body: while the inventory UI (of the dead body) is still open, he could open the console (by pressing ~ or ` or ^) and type "report" (without quot. marks)
PS is there a command to take the entire body content and quickly move it into your inventory instead of one item by one item?
Unfortunately there is no option to take everything at once... we been thinking about adding a button for this, but maybe it's annoying if someone presses it accidentally? But it's possible to add such a feature through the Plugin API, as mentioned by james1bow
Right now the fastest way to move the items is via shift + click (but that's still necessary for every single item)...
Thanks for letting me know! The problem is that the server no longer processes any player sync packets while the player is dead (and doesn't update the state anymore)... we will change that with the next update, so the state will be set properly
But in the meantime you can check if the player is dead via Player.isDead()
Oh, that's weird Basically the game shouldn't distinguish between regular bans and offline bans (because the game only checks the UID anyway)... do you mind sending me a server log (from when you tried to join the server despite being banned)? Feel free to send it via PM to me
Unfortunately the game does not sync the definitions between the server and the client. If you modify the definitions.db on a multiplayer server, it works properly for everything that's solely handled by the server (e.g. things like npc health, biome related things, spawn definitions etc), but if a particular definition is used clientside, the client won't see the serverside modifications (e.g. things like asset path of an item, animation or move speed of an npc etc).
When it comes to the crafting recipes, it's a bit tricky, as mentioned by james1bow : basically it's handled by the server (so if the client sends a craft-packet to the server, the server checks if the client has all ingredients in his inventory - based on the serverside definitions of course). However, the crafting UI is shown clientside, so it uses the clientside definitions. Before sending a craft-packet to the server, the client also first checks if the player has all ingredients (based on the clientside definitions), to prevent the player from sending useless requests to the server.
So if you modify the crafting recipes on your server, it won't really work, because the client wouldn't even send the craft-packet to the server if you don't have the required ingredients (based on the clientside definitions). If the ingredients are in your inventory (so the client sends the craft packet), the server will perform the ingredient-check too (but based on his serverside definitions) and remove the ingredients from the client inventory.
However, it's our intention to change that, so once a client joins a server, the serverside definitions will be synced with the client This hasn't been added yet because there wasn't much demand for it in the past, but we're trying to get this ready with one of the next updates.
Until then, you can only change settings which are only used serverside, e.g. everything that's related to world generation (biomes, spawns etc), damage dealt by items or npcs, food/consumption values (health/hunger restore) etc.
The default setting is that you lose your inventory upon death. In multiplayer, this is handled through permissions: it's the keepinventory permission in the general section (set it in the default.json permission if you want it to affect all players).
Alternatively (if you don't want to work with permissions) you could add this line to the server.properties: Permissions_OverrideKeepInventory=True (this overrides the setting for all permissions).
However, chests should never be affected by a player death, so their content should still be there if a player dies What do you mean with "both inventories show up on the dead body"? When looting a dead body, the game shows your current inventory and the content of the dead body in a separate window on the right (but there should never be multiple windows like that, for example). I've never seen such an issue before... do you use any plugins?
Leider gibt es noch kein RCON Tool für die neue Version 
Dein obiger Link führt zum alten RCON Tool für die Java Version, das ist mit der neuen Version leider nicht kompatibel. Für die neue Version ist tatsächlich ein eingebautes RCON-Tool vorgesehen, welches dann einfach über eine Webseite aufgerufen werden kann (dadurch kann es auch problemlos via Handy usw. bedient werden).
Aktivieren kannst du das RCON Tool noch nicht, das haben wir deaktiviert. Was du siehst (IP, Gamemode usw) sind die Query-Daten des Servers (über den Query-Port, standardmäßig 4254), das hängt nicht mit dem RCON Tool zusammen (welches einen separaten Port benötigt, standardmäßig 4253).
An sich ist das RCON Tool bereits relativ weit fortgeschritten, doch in letzter Zeit ist da nichts mehr passiert... der Grund ist, dass es dazu leider nur eine geringe Nachfrage gibt, und da zuletzt noch größere Features wie Weltgenerierung, Tiere, Höhlen und Biome fehlten, war leider nur wenig Spielraum, daran zu arbeiten (selbst der API-Release, wovon grundsätzlich ja deutlich mehr Leute profitieren, kam nicht bei jedem gut an, da zu dem Zeitpunkt eben noch Biome und Höhlen fehlten).
Wir möchten das RCON Tool aber trotzdem noch zum Abschluss bringen. Ich weiß nicht, ob das passend zum Storepage-Update klappt, aber wenn nicht, dann haben wir spätestens danach mehr Luft dafür
