Oh, I'm glad to hear it works now 
Posts by red51
A small new update is available now!
-
-
-
Looks like I somewhere on the forum missed the information that the area works only for admins, and that the server somehow retains the old settings (but the server behaves this way).
I am inclined to believe that somewhere in the settings some kind of saving (copy) is enabled, which somehow works on the server. Is it possible?Hmm... could you elaborate on that? If you refer to the area creative mode tool, this can be fully controlled via permissions, but it's recommended to make it only available to admins (otherwise players could abuse this feature).
What do you mean exactly with "saving"?
I used the Admin group to create the Builder group and accordingly changed the color of the group to green, after deleting the Builder group (because it does not work, there is no protection for the area), the Admin group is green on the server, and in the permissions it is red (I’m not garbage inside the server I keep, all files that are not up-to-date are stored on a separate storage medium or deleted).
Was it only the color that was incorrect? Otherwise maybe you could send me the permission files in question, then I can take a closer look at it
It may be that some type of "cloud" saving is enabled in the settings. Is it possible?
There is unfortunately no cloud saving available for the dedicated server
-
If you disable "Permissions_AdminsFullPermissions", you can only execute commands which are actually permitted in your current permission group. If you don't assign this player to a particular permission group, he is only affecetd by the default permission. Also make sure the permission file for that particular group is valid (if the server cannot parse it, the server starts anyway, but there is an error message in the log). You can also use this site to make sure there is no syntax error (just paste the content of the particular permission file there): https://jsonformatter.curiousconcept.com/
If you want to execute the "spg" command, but you don't have permission to do that, you could also type this command into the server console (if you have access to it).
-
i had noticed in the last update if you closed the server and restarted it would take a few minutes to reconnect, i just dealt with it. the issue with players getting stuck at 5% had never happen before so i figured it was a new issue. thanks for all the hard work
Do you mean the last update (i.e. 0.4), or the latest hotfix that was just released an hour ago? If the server takes a few minutes to reconnect, it could be the port checker which halts the server until all ports are open (this was actually already implemented for TCP connections, but only the recent hotfix also takes UDP into account).
Do you have access to the server console? In this case there could be an indicator what's taking to long. If it's the port checker, you will see an ongoing output like "Checking ports...." (with lots of dots behind it if it takes long). If it's not the port checker, it could be Steam which takes a long time until it's connected (Steam is fully connected if you see this message in the log: "[STEAM] Server connected, public IP -> x.x.x.x").
How did you restart the server exactly? If you kill the process, it typically takes some times until the TCP connections (for the server query port) gets closed automatically on Windows. But if you shutdown the server gracefully (either by using the "restart" or "shutdown" command), the server should be able to restart immediately.
-
Hier frage ich mich wie du das meinst ? unterschiedliche Texturen oder extra Frarbe noch drauf
Das bezieht sich nur darauf, jede Seite eines Blocks unterschiedlich zu färben
Unterschiedliche Texturen pro Seite zu haben ist etwas heikler, da sich hier auch Fragen zur Spiellogik ergeben (ein Steinblock mit Holztextur wäre zB weiterhin ein Steinblock, obwohl er nach Holz aussieht etc).Ich denke das Sie das feine arbeiten meint. Und das war in der Java auch schon ein Problem. Wenn ich also nur kleine Ecken und Kanten weg haben möchte.
Achso, naja, das ist leider schwierig, da das Terrain nur 1 Wert pro Block vorsieht (und ein "Terrainblock" eine feste Größe hat)
Man kann ja nun in den Einstellungen die Dauer die der Schelzofen braucht einstellen, dies finde ich auch gut.
Nun versteh ich nicht warum in den Einstellungen mit Prozenten gearbeitet wird und für den Server mit einem Factor ?
Es wäre doch bei den Einstellungen, insoweit für SP & MP welche da sind, hier vom gleichen wert auszugehen.
Bei der eigentlichen Einstellung handelt es sich um einen Faktor (im mathematischen Sinne). In dem Fall entspricht also 1 genau 100% (bzw. Standarddauer), 0.5 entspricht 50%, 2 entspricht 200% usw. In der server.properties ist dieser Wert so angegeben und auch so beschrieben. Im Spiel hingegen ist das aber womöglich für Spieler irritierend, mit so einem Faktor zu arbeiten, daher wird das in Prozent umgerechnet und entsprechend etwas anders beschrieben (also 100%, 50% etc). Außerdem sehen Prozentzahlen (zB "75 %") meist schöner aus und sind für viele Spieler leichter verständlich als Faktoren ("0.75").
Wenn wir in der server.properties auch Prozentangaben (0-100) hätten, dann wäre das tatsächlich aber recht irritierend: Denn wenn da stünde OreSmeltingDurationFactor=50, dann wäre dabei nicht klar, was das denn bedeutet. Ich würde daraus wohl lesen "50x so schnell" oder sowas (was falsch ist). Wenn da aber steht OreSmeltingDurationFactor=0.5, dann finde ich, ist das Risiko für Missverständnisse schon deutlich kleiner (der "Faktor" für die "Dauer" beträgt nämlich 0.5, also "Dauer * 0.5 = halbe Dauer").
Generell hat die server.properties einen direkteren technischen Bezug.
Das Spiel macht das übrigens überall so (also alle Angaben, die im Spiel in Prozent sind, sind meist in der config Datei als Zahl zwischen 0 und 1 angegeben). Die Java Version hat das auch so gemacht (zB die Spawnraten für NPCs)
-
There is now an update available for Windows multiplayer servers specifically. It should fix the UDP issue mentioned above, at least we couldn't reproduce it anymore on our end. This version also performs a port scan (to find out if there is already a TCP or UDP listener on the server port), but this can be disabled by setting "Server_EnablePortCheck" to false in the server.properties.
This fix is not available for Linux currently because apparently Linux servers were not affected by this issue. However, if you still run into any connection issues (either on Windows or Linux) or any other server-related issues, please let us know
-
Das Terraforming Tool macht, zumindest bei mir, manchmal gar nichts, dann wieder malt es in der "Anheben/Absenken" Funktion Grass. Die "Glätten" Funktion kann ich gar nicht nutzen und der Texturenpinsel macht zwischendurch auch was er will. Vielleicht hilft es aber auch, wenn ich das ganze mal deinstalliere und neu aufspiele.
Das ist aber eigenartig
Ich konnte das leider bisher noch nicht reproduzieren... muss ich mir aber nochmal genauer anschauen 
Ich habe nicht mal so ein Fadenkreuz. Kann man das irgendwie über die Konsole an- und ausschalten?
Das kann in den Grafikeinstellungen unter "Ansicht Einstellungen" (also dieser Button relativ weit oben, unter VSync und sowas) eingestellt werden. Ganz unten kann darin das Aussehen des Fadenkreuzes gewählt werden.
Ich finde es auch viel sinnvoller doppelwandig zu bauen, weil es viel besser aussieht. Am Ende braucht man an den Innenseiten eines Fensters meistens eh zwei Texturen, siehe Beispielfoto. Ein weiterer Vorteil ist, dass wenn der Boden und die Decke jeweils einzeln gebaut werden, kann man die Fliesen oder das Laminat neu verlegen, ohne dass man Löcher im Haus hat
(siehe zweites Bild).Sollten zwei halbe Blöcke mit einer Textur weniger Daten zum Laden benötigen als ein ganzer Block mit individuellen Seiten, wäre es mir persönlich lieber, wenn es so bleiben würde wie es ist. Ansonsten habe ich nichts gesag
Ich denke es gibt durchaus viele Situationen, in denen individuell gefärbte Seiten keine doppelten Wände ersetzen können.
Aus Performancesicht ist es so, dass zwei separate Bauteile definitiv "teurer" sind als ein Bauteil mit individuell gefärbten Seiten. Es stellt sich dabei immer nur die Frage, wieviele der verbauten Bauteile man insgesamt anmalen würde (und in der jetzigen Situation deshalb doppelwandig baut). Bei individuell gefärbten Seiten müssen diese "Mehrkosten" für jeden Block bezahlt werden, auch wenn gar keine Farbe gesetzt ist. Wenn nur 20% aller Bauteile wirklich eingefärbt werden, kann ein Feature "individuell-gefärbte-Seiten" unterm Strich also teurer sein. Wenn aber eh die Mehrheit der verbauten Blöcke angemalt wird (und zwar so, dass man dann deshalb doppelwandig bauen muss), dann wären "individuell-gefärbte-Seiten" günstiger (vorausgesetzt, die doppelte Wand könnte man wirklich einsparen)
Die Frage bleibt also sowieso, wieviel doppelwandige Blöcke man wirklich einsparen würde, wenn es dieses Feature gäbe. Aus spielerischer Sicht ist es aber vll so oder so vorteilhaft, dass man Seiten individuell färben kann.
Wenn wir hier aber von "günstig" und "teuer" reden, dann muss man das auch immer relativ sehen
Solange man mit seinem Computer nicht unbedingt an den Mindestanforderungen kratzt (vor allem was den RAM angeht), dann sehe ich da eigentlich kein großes Problem Das Terrainwerkzeug ist noch nicht ganz ausgereift. Gras zu übermalen, fand ich schon in der Java nicht wirklich funktionabel. Der Gärtner braucht dringend ein paar Fortbildungskurse.
Also das einzige Problem, welches ich beim Malen mit Gras unmittelbar sehe, ist, dass der gesamte Bereich mit Gras bemalt wird und nicht nur die Oberfläche (man also bei großen Radien durchaus eine 5 oder 10 Meter tiefe "Grasschicht" hat)... da wäre es absolut wünschenswert, wenn sich das ändert. Oder hast du mit dem Malen noch ein anderes Problem entdeckt?
red51 Wie ist es mit den Holzteilen jetzt beim Ziehen? In der Java-Version wurde ein gezogenes Teil nur als ein Teil gerechnet, sofern ich mich nicht irre.
In der Java Version wurde dafür tatsächlich nur ein einziges Bauteil abgespeichert, während in der neuen Version dafür einzelne Bauteile platziert werden. An der Framerate ändert das nichts (in beiden Versionen werden sämtliche Bauteile in einem Chunk sowieso zu einem einzigen Bauteil heruntergerechnet), aber in der neuen Version wird dafür mehr Speicher verbraucht. Generell verbrauchen Bauteile jetzt mehr Speicher als noch in Java, da wir nun viele zusätzliche Informationen abspeichern (zB die ID des Spielers, der das Bauteil platziert hat, das Platzierdatum, die Farbe, und außerdem noch alle Daten für die zusätzlichen Einstellungen wie Oberflächenbearbeitung, Texturskalierung etc).
Aber das betrifft nur den RAM. Das hat keinen wirklichen Einfluss auf VRAM oder CPU-/GPU-Auslastung. Was den RAM angeht, da hat die neue Version ohnehin den Vorteil, dass wir den benötigten RAM nicht im Vorfeld zuweisen müssen (wie in der Java Version), sondern jederzeit so viel RAM nehmen können wie benötigt wird (natürlich nur sofern vorhanden). Die Java Version hat - wenn ich mich recht entsinne - standardmäßig maximal knapp über 7 GB RAM verbraucht (es sei denn, man hat mit Startparametern mehr RAM zugewiesen). Standardmäßig war es daher so, dass selbst wenn 64 GB RAM vorhanden waren, das Spiel bei maximal 7 GB aufhörte (und dann im Zweifelsfall crashte, wenn mehr benötigt wurde). Die neue Version hingegen würde in so einem Szenario einfach mehr RAM nehmen (und erst crashen, wenn das System wirklich keinen RAM mehr hergeben kann)
-
This is really strange
So far this only seems to affect Windows servers, but I see no reason why that should happen (except something related to firewall etc, but it's weird that it was apparently working before) How often do you restart your server? Do you use the built-in "restart" command (or the built-in scheduler), or do you actually kill the process and start a new one?
Could you maybe share the latest server logs (for the Logs folder)? Maybe you could send them via PM to me?//Edit: After some investigation, it seems like the UDP port sometimes still stays active for a brief moment after shutting down the server. If the server gets restarted immediately (either by the built-in restart command, or by killing the process and restarting it manually), this results in the old UDP listener not getting closed. This only seems to happen when binding to all addresses (i.e. if no specific server ip is provided). Apparently this was already happening in 0.3 (the previous multiplayer update). We're looking for a solution and will provide a fix for this ASAP!
-
That's the issue: If Permissions_AdminsFullPermissions is set to True, the current permission group is ignored for actual server admins (i.e. admins which are in the server.properties file). Basically this setting was just meant for servers which are not using any permissions at all (so admins can at least use commands etc).
If you set Permissions_AdminsFullPermissions to False, the actual permission group of the player (probably a group permission called "admin") will be used (and if no clipping is set to true there, it should take effect).
-
The new version indeed uses UIToolkit under the hood (which is linked in your 2nd post)
But the API will basically only support a subset of UIToolkit. This is probably the most relevant page so far: https://docs.unity3d.com/2020.…ual/UIE-LayoutEngine.htmlThe API will also provide absolute and relative layouts.
The API will probably expose most of the settings of the IStyle interface (although some of them will likely be simplified a bit): https://docs.unity3d.com/2021.…ce/UIElements.IStyle.html
-
Was mir noch aufgefallen ist: Das Item xmaswreath taucht nicht im Craftingmenü auf
Hehe, ja, das Item macht noch ein paar Probleme
Wir wollten es nicht wieder löschen, aber es auch nicht unbedingt in die Liste der neuen Objekte aufnehmen -
There is unfortunately no setting for this, but there is a hack to place it manually in creative mode: While a sapling is equipped (I know this sounds strange), type "id ironore" into console to turn it into iron ore (the same works for regular rocks tool by typing "id rock")
On another note, I'm assuming iron and other ores will be back in the ground again when world gen works?
The current iron ore will stay (we think it's a nice addition if at least some iron ore and maybe some coal spawn at the surface), but underground ores are still planned and will be added in a future update (not necessarily with the world gen update though).
-
Does it only affect admins? Is the Permissions_AdminsFullPermissions setting in the server.properties file also set to true? In this case, the permission for this is ignored and all permissions default to a predefined value for server admins (which is "False" in case of no clipping).
-
Das Terraforming Tool macht noch etwas Faxen.
Oh, was für Probleme gibt es damit denn genau?
Pinsel und Farbrolle funktionieren manchmal nicht so richtig und könnten überdies hinaus so etwas wie ein Fadenkreuz vertragen
Eigentlich sollte das normale Fadenkreuz auch beim Pinsel und Farbrolle aktiv sein
Zudem wäre es von Vorteil, wenn man Blöcke auch nur einseitig streichen könnte
Darüber gabs tatsächlich mal eine Diskussion... wie Yarofey schon sagt, das würde zu spürbar mehr Daten führen, die pro Bauteil gespeichert werden müssen (was allerdings erst ins Gewicht fällt, wenn sehr viele Bauteile verbaut wurden).
Ich denke es macht aus spielerischer Sicht trotzdem Sinn, Seiten einzeln einfärben zu können. Wir werden das also höchstwahrscheinlich einbauen, allerdings ist dafür eine Weltkonvertierung nötig, was die Sache ein wenig erschwert
Und ganz wichtig: Lieber Red, würdest Du mal beim Christkind nachfragen, ob wir zu Weihnachten einen Mülleimer haben dürfen? Wir sind auch alle ganz doll artig.
Ich weiß nicht, aber ich kann mal fragen, kostet ja nichts
-
Auch ich wäre für Brücken. Würden wir die dann bauen können/sollen oder wird das Weltupdate sie mitbringen?
Vom Spiel generierte Brücken sind momentan leider erstmal nicht geplant, meine Aussage war eher darauf bezogen, dass ich es als Spieler cool fände, wenn auf einem Server diverse Inseln via Brücken verbunden wären (insbesondere wenn das Bauland nicht ausreichen sollte), es also optisch was hermachen würde (vermutlich imposanter, als wenn zwischen zwei Städten nur Ödland ist)
-
HIT PICKABLE: WorldElement [id: 549776, dbID: -1, created: 1638699901, chunk: [26, 0, 18], pos: (21.50, 520.50, 6.50), rot: (0.04404, 0.89387, -0.00557, 0.44611), scale: (1.04, 1.04, 1.04)]
This looks ok to me, the "dbID" is just the player ID (typically the database ID of the player who placed it, but for naturally spawned elements, it's always -1).... the actual unique ID of the element was 549776 in this case.
Restarted world, objects were still there but this time managed to chop tree down... *shrug*
So after a restart it didn't happen anymore? I will still try to reproduce this issue on my end... in case you run into this bug again, please let me know
-
Vor dem Update war diese Einstellung aber auch so und da ging es
Das ist eigenartig... aber da vor dem Update eh noch einige Bugs im Bereich Permissions waren, kann es durchaus sein, dass es nur deshalb funktionierte
-
Oh, I see
Probably this wasn't an issue in the Java version, considering that only player sync was sent via UDP there (every 80 ms, so this probably didn't trigger the flood protection). The new version, however, sends everything through UDP (and unlike the Java version, it only uses a single port for networking) -
It's indeed a bug which was introduced with this update
I'm not sure if there is room for another hotfix, so this will be fixed with the next update at the latest.Also, there appears to be some items that are invincible (trees and rocks) - I'm guessing these are left over from the original demo?
Oh, that's strange
Left overs from the original demo really shouldn't be an issue... did it happen in multiplayer? Are these elements still invincible after restarting the server?
