Posts by red51

Quote from VoodooPanz

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

Quote from VoodooPanz

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.

Quote from Desmagu

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

Quote from Deirdre

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?

Quote from Deirdre

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.html

The 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

Quote from Yaromid

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")

Quote from Red_Baron

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).

Quote from VoodooPanz

Das Terraforming Tool macht noch etwas Faxen.

Oh, was für Probleme gibt es damit denn genau?

Quote from VoodooPanz

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

Quote from VoodooPanz

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

Quote from VoodooPanz

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

Quote from Rüdi

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)

Quote from yahwho

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.

Quote from yahwho

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

Quote from lenko

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.

Quote from yahwho

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?

I'm glad to hear it works now!

About the UDP Flood Protection, was there also an adjustable threshold value? Depending on this value, it may indeed interfere with multiplayer servers: while a single client typically doesn't send enough packets to trigger that (unless this is set to a very low threshold value), this could easily happen if there are multiple clients on the server. Depending on how this is implemented in that particular router model (which router do use exactly?), the router may block these ports.

Vielen Dank für die Messungen Yarofey , das veranschaulicht das echt ziemlich gut

Das kommt tatsächlich auch alles soweit hin. Große Inseln werden meist so annährend 8000x8000 groß sein (der max Bereich ist 8192x8192, aber ein bisschen Wasser muss ja auch noch um die Insel herum). Das sollte eigentlich auch dafür genügen, dass man nicht sofort den Eindruck bekommt, man befände sich auf einer Insel Auch im MP sollte *eigentlich* genügend Platz zum Bauen vorhanden sein (wobei ich persönlich auch finde, dass Brücken zu anderen Inseln eine elegante Lösung wären).

Thanks for letting us know, I will try to reproduce this on my end

Quote from Tester700

Also das mit den Waffen/Werkzeug platzieren würde mir persöhnlich auch so am besten gefallen das man mit einer bestimmten Taste das item das man in der Hand hält in Baumodus umschaltet und damit Platzieren kann wie eine Planke in allen Richtungen.
Und wenn man mit der Waffe/Werkzeug zu einem Waffen/Werkzeughalter geht und diesen benutzt wird automatisch das in der Hand gehaltene Item dort Platziert

Ich denke das wäre wohl der beste Weg

Quote from Tester700

Drücke ich Ü bleibt es da liegen wo es landet damit könnte man Kisten füllen (oder Verkaufsstände)

Das wäre nachvollziehbar, ich habe aber ein wenig Sorge vor so ein Feature Das kommt quasi dem gleich, dass weggeworfene Items dauerhaft liegen bleiben sollen. Ich weiß nicht, ob viele Leute nicht evtl. nur noch die Ü Option nutzen würden - was die Zahl der Items in der Welt im Laufe der Zeit massiv nach oben treiben könnte... das wiederum könnte einen sehr negativen Performanceeinfluss haben...

Im Multiplayer wäre die Lage noch verheerender, außerdem käme dort die Gefahr hinzu, dass Griefer dieses Feature sehr einfach missbrauchen könnten (einfach einen x999 Stack Steine in die Hand nehmen und via Ü das Grundstück eines anderen Spielers zumüllen)...

Ich fürchte, wir könnten mit der Einführung eines solchen Features die Büchse der Pandora öffnen... Ich würde mich für den Anfang daher lieber auf das explizite Platzieren von Items beschränken

Quote from Deirdre

Bei gewissen Steintexturen ist mir aufgefallen, dass diese in die falsche Richung weisen. Die Texture mit dem Block wird beim Setzen entgegen der Musterrichtung platziert

Wie meinst du das genau? Dass Texturen alle die gleiche Ausrichtung haben?

Quote from Deirdre

Wäre eine Richtungsvorgabe von Texturen durch eine Tastenbelegung möglich, so dass man generell immer für sich die richtige Richung hätte?

Eine Option, die Textur zu drehen, ist auf jeden Fall geplant, nur leider kann ich noch nicht genau sagen, wann die kommen wird

Quote from Deirdre

So do I. I use E nearly from the beginning.

Maybe we could even move the default inventory key to E (and put "Crafting" on tab)... maybe this feels more "natural"

Quote from Cluas

Hope this will still be possible in the future?

Yes, this will be definitely still possible in the future;)

Quote from lenko

In der Admin permission steht er auf true, ingame bei den berechtigungen auf false ( "noclipping": true, )

sowie ist in der server.properties der Eintrag Permissions_AdminsFullPermissions=True

Das ist das Problem: Mit "Permissions_AdminsFullPermissions" werden die Gruppenpermissions überschrieben bzw. ignoriert - das verhält sich quasi wie in der Java Version. Es wird dann der vordefinierte Wert verwendet, die im Falle von NoClipping auf false gesetzt ist. Wir werden das in Zukunft noch dahingehend ändern, dass mit "Permissions_AdminsFullPermissions" nicht mehr zwangsläufig alle Permissions auf einen bestimmten Wert gesetzt werden, sondern nur noch diejenigen, die wirklich relevant sind.

Wenn ihr bei euch eine eigene Admin-Permission angelegt habt, dann kann "Permissions_AdminsFullPermissions" in der server.properties auch ruhig auf False gesetzt werden. Die Einstellung war ursprünglich eigentlich dafür gedacht, dass man schnell Admin auf einem Server werden kann (va. damit man Befehle eingeben darf usw), ohne Permissions anlegen oder definieren zu müssen

Error code 0 usually indicates that there was no response from the server - typically it's a timeout. When entering the IP with query port in the browser I can't query the server either, which indicates that the query port (if your port is 3253, the query port would be 3252) is probably blocked. Otherwise you would get a response like this (this is taken from the test server): http://94.130.179.127:4254/

However, your server did show up in the server list earlier today (when I tried to join it), so at that time, at least the query port was reachable (but IIRC it used a different port then?)