Posts by red51

    Zudem hat man den Eindruck, das die Jeweiligen Pinsel sich an einer Art Raster orientieren

    Ja, das ist korrekt: Grundsätzlich kann man sich das Terrain so vorstellen, dass es quasi aus einzelnen Blöcken besteht (die entsprechend 1x1x1 groß sind, nur, dass das fertige Terrain nicht blockig, sondern "weich" dargestellt wird). Mit anderen Worten: Eine "Terrain-Zelle" hat die Größe von einem Block. Daher kann momentan zB nicht noch kleiner bzw. feiner operiert werden...


    Das kann leider nicht so problemlos geändert werden, denn auch wenn das Terrain dadurch wesentlich schöner werden würde, würde das die Performance zu sehr verschlechtern :/ Vor allem würde es zu wesentlich mehr Daten führen: Wenn eine Terrain-Zelle halb so groß wäre, also 0.5 Blöcke, würde das 8x mehr Daten verursachen. Wenn eine Zelle nur noch ein Viertel so groß wäre (0.25 Blöcke), würde das schon 64x mehr Daten verursachen. Gleichzeitig steigt auch die Anzahl der Polygone entsprechend, und das Spiel braucht ebenfalls länger zum Generieren von Chunks (also langsamere Weltgenerierung und langsameres Bearbeiten von Terrain).


    Vll probieren wir das eines Tages mal aus, aber damit würde ich in nächster Zeit leider erstmal nicht rechnen :silenced:


    was zur Folge hat, dass z.B der Grasspinsel am Rand immer die gleiche Grasskante erzeugt, was sicherlich weit von einem nürlichen Look entfernt ist

    Da kann man sicherlich was machen ^^ Wirklich 100% natürlich wird es vmtl. nie werden, aber man könnte wenigstens etwas mehr "Randomness" da rein bringen. Ich kann aber leider noch nicht genau sagen, wann wir die Zeit dafür finden... bis dahin kann man versuchen, von Hand die Kante etwas auszufransen (also keine gerade Kante malen).


    Zuletzt möchte ich auf mein Problem mit Bocktexturen eingehen, welches darin besteht, dass sich bei Blöcken die Vertikaltexturen nicht durch einen einfachen Klick im Radialmenü quasi fixieren lassen, so dass diese sich mit aus der Vertikalen, in die Horizontale drehen

    Das liegt daran, dass - wie paulevs schon beschreibt - die Texturen fest an der Welt ausgerichtet sind (anders als in der Java Version, wo das nur zum Teil der Fall war, die Textur aber grundsätzlich am Bauteil ausgerichtet war).

    Die Intention dahinter ist einerseits (wie Avanar korrekt feststellt), dass überlappende Bauteile weniger bzw. nicht mehr flackern sollen (was in der Java Version mehr oder weniger ausgeprägt war), andererseits sollen aber auch weniger "harte Kanten" bzw. sichtbare Übergänge zwischen Bauteilen (mit gleicher Textur) auftreten, nämlich sowas:


    Dafür werden wir aber auf jeden Fall noch eine Lösung anbieten, also dass man die Ausrichtung der Texturen pro Bauteil ändern kann ;)


    Ich persönlich hoffe auf mehr verschiedene "Pinsel"-Formen. Evtl auch eine die nach dem Zufallsprinzip die Form und Größe wechselt. Das kann sehr hilfreich sein wenn man ein Gebirge erschaffen oder verändern möchte. Formen wie Rauten, Dreiecke, Sterne, etc. fehlen mir persönlich. Auch die Terraprints, also geblaupaustes Terrain, fehlen mir noch. Kommt aber bestimmt

    Ich kann zu verschiedenen Pinseln leider noch nichts konkretes sagen (absolut sinnvoll, aber wir müssten uns mal Gedanken zur Umsetzung machen), aber für Gebirge wird es noch ein zusätzliches "Anheben/Senken" Werkzeug geben. Das ist quasi wie das Aufschütten (1), nur mit dem Unterschied, dass zum Rand des Pinsels weniger Terrain aufgeschüttet wird. Sozusagen eine Mischung aus Aufschütten (1) und Glätten (2). Das macht es auf jeden Fall deutlich einfacher, wenn man zB Berge aufschütten möchte ;)


    Zu Terraprints: Die kommen definitiv noch :D


    Ich ärgere mich immer bei meinen Schwimmingpools darüber, dass der Rasen nicht akkurat an den Poolrand gebracht werden kann

    Das Problem ist, dass Gras momentan an die Terrain-Genauigkeit gebunden ist... in der aktuellen Situation fällt mir dazu leider keine direkte Lösung ein :|


    Worüber wir aber nachdenken könnten wäre, dass wir das normale Gras auch als eigenständige Pflanze anbieten (quasi so wie die jetzigen Blumen). Das Problem hierbei ist, dass Pflanzen hinsichtlich der Performance deutlich teurer sind, als das bisherige Gras. Wir arbeiten aber an einem System, womit vor allem große Mengen Vegetation effizienter gerendert werden (dann würden wir uns vll auch trauen, Gras als eigene Pflanze anzubieten, das dann zumindest im Creative-Modus für solche Feinarbeiten hilfreich wäre) :)


    Alternative solution: I'm not sure, but it is probably possible to use one bit in element flag to mark texture world-aligned or fixed. If this is so this will be even better solution as in that case any element can have both fixed and world-aligned texture

    Our current fixed UV mode doesn't work well for blocks unfortunately... it first requires a few changes to reduce seams between individual elements. But once that's done, we could expose this setting per element ;)


    Apart from that, it's our intention to add an option to change the texture orientation (i.e. rotate the texture). But this requires a world conversion, so we'll focus on that after the world update :D


    Avanar Die Texturen laufen in die falsche Richtung, was hat das mit Flackern zu tun?

    Das hängt tatsächlich damit zusammen, denn wenn sich jetzt zwei Bauteile überlappen (also sich konkret zwei Oberflächen exakt an derselben Position befinden), flackern die grundsätzlich (weil sich das Spiel nicht entscheiden kann, welche Oberfläche zuerst gerendert werden soll). Das ist ein allgemeines Phänomen und bekannt als "Z-Fighting"

    Allerdings fällt das Flackern nicht auf, wenn die Textur auf beiden Bauteilen exakt gleich groß und gleich positioniert ist ;)


    Wir haben aber auch noch weitere Mechanismen eingebaut, um das Flackern generell weiter zu reduzieren.


    Am einfachsten wäre es doch wenn es für manche Texturen zwei Versionen gäbe, einmal längs, einmal quer. Natürlich nur, wenn der vorhandene Platz für Xxx zusätzliche Texturen ausreicht.

    Das wäre zwar in der Tat eine einfache Lösung, aber sehr redundant (wie Yarofey schon sagt), und auch sonst nicht unbedingt schön :thinking: Das Problem ist, dass wenn wir das einmal so einbauen, es nur schwer ist, es später wieder zu ändern (einerseits müssten danach bestehende Welten & Blaupausen konvertiert werden, damit sie kompatibel bleiben, andererseits ist es auch für die Spieler eine Umgewöhnung) - daher können wir das leider auch nicht einfach als temporäre Lösung anbieten...


    Mittelfristig wird die Lösung sein, dass man die Textur drehen kann (zumindest die Ausrichtung zwischen Horizontal & Vertikal ändern). Das kann man dann bspw. über das Baumenü (über C) einstellen, oder aber auch nachträglich per "edit" Befehl.

    Wenn das Welt-Update und ggf. auch die NPCs über die Bühne sind, bekommen wir vll endlich die Gelegenheit, uns dieser Sache zu widmen ^^

    That's weird :wat: Which PNB plugin do you use exactly? Unfortunately I couldn't reproduce this issue on my end (at least with the latest PNB plugin)...


    If this happens again, maybe you could post a report? To do that, open the console and type "report" - then a file called "report" should show up in the game directory. Please upload that file here (or send it via PM to me), maybe it contains more information about what's going on there ;)

    Thanks a lot for your feedback and your suggestions! :) You bring up some interesting points I wasn't aware of!


    First of all: Thanks for your offer! Actually you did already support us by purchasing the game :D If you really want to support us beyond that, we would be more than happy if you buy a Steam key on our homepage and give it to a friend, for example :saint:


    About the asset pack, usually we try to stay away from the asset store, but I must admit the cactus package you've mentioned looks quite good! Once the world update is ready, we will definitely take a closer look at it and replace the current cactus in the game eventually!


    When it comes to biomes and diversity, one problem is that we only have a limited set of vegetation available for the hot regions. This area is definitely still work-in-progress. As you said, it would be indeed a bit weird if there are just one or two plants in a particular biome...

    But due to time constraints and a lack of funds, it's tricky to get enough new plants and trees. So we probably have to find a compromise, even if it's not 100% realistic... I hope sales will improve once the new version is ready, that would give us a lot more room for better and more realistic biomes^^


    I will definitely keep most points you've mentioned in mind! Even if the first version of desert biomes wouldn't be very realistic, we could always improve it in the future (actually we can change the plants which should spawn in a particular biome without breaking existing worlds) ;) That's probably the right way... As soon as we're no longer in the red, it would be possible to put a lot more attention on these things.


    1a) You can't plant them - delete "cactus saplings".

    I'm not sure about that... this definitely makes sense, but it would be a pity if players couldn't plant cactuses in survival mode :thinking: Even if it's not realistic, it's maybe still better for reasons of gameplay if we keep this mechanic... sometimes we have to find a balance between realism and playability :D


    1b) They don't produce lumber - delete lumber drop.

    It's indeed unrealistic to get wood from cactuses, but this was originally implemented because there aren't enough sources to get wood in deserts in RW :D


    We may remove that once we have more plants and trees for hot regions (although removing a feature may also cause more harm than good, so we really have to think about that)... it depends a bit on which arid biomes will spawn close to the desert once that's fully implemented.


    1c) They damage you - make it hurt if player bumps it.

    Oh, I didn't know they can cause such severe wounds :wat: From this point of view, it certainly makes sense to get damage from them. I'll put that on our to-do list^^


    1d) They don't grow in sand - don't let them spawn in sand dunes, only from sandstone or a solid desert floor.

    This is good to know! Although if we stick to that, it may put too many restrictions on us, considering the biggest areas in our desert would be sand... we have to think about that!


    5) Desert animals? - No tigers, elephants, or giraffes out here. I know adding a dozen new animals is a huge fix. Maybe just populate the desert biome with what desert animals you had in the java version: donkeys, horses, deer, jaguars, rabbits, bears, and boar (which kind of look like javelinas, so I'll take it) .... or delete the saguaros.

    If we just use the same animals from our regular forests (deers, rabbits etc) for deserts, I'm afraid the game could become a bit too monotonous as a result... but it's still unclear which animals will actually make it into the game. We can't just use the game models from the Java version (due to the lack of details), that's for sure^^


    im hoping alot of the plants can be added via plugin once the api is available

    I'm afraid this won't be part of the first API release :/ Our main focus for the initial API release is to cover the existing API of the Java version... but being able to add custom plants through the API is definitely on our to-do list! ;)

    The ethical aspects of game piracy may be debatable, but downloading pirated games is indeed illegal in most countries (including the US)... things can get a lot worse when using torrents, so I'd really stay away from them :dizzy:


    Anyway, I guess it's best if we close this topic now ;)

    The new version indeed has an auto-walk feature, but unfortunately it's not exposed to the settings yet, so it needs to be set up in the config file manually :hushed: To do that, go to the game directory (to the "_New Version" subfolder if you have the Steam version) and open the "config.properties" file with a text editor. There should be an entry "Input_AutoRun", just change it to the desired key (e.g. enter "key_v" w/o quot. marks if you want to bind it to V, so the line would look like this: Input_AutoRun=key_v), then save the file and launch the game. If you now press V ingame, the player will start walking automatically ;)


    Unfortuantely this feature is still a bit limited, i.e. the player cannot sprint or avoid obstacles automatically. It also doesn't work while flying (F2), for example.

    Is it this plugin? Teleport

    In this case, this isn't caused by the teleport plugin.


    Do you maybe use some old Lua scripts as well? They're located in the "scripts" folder in the game directory. Lua scripts are basically a predecessor of the plugin API.


    You can delete plugins or scripts by just removing the particular folder btw (but quit the game first before doing that) ;)

    I am trying to set up a LAN server for java version but get this error whenever I try to run!

    This error occurs if a Java version newer than Java 8 is installed. According to the log, Java 18 is installed, but the game (and server) only supports Java 8 :|

    Installing Java 8 should to the trick in this case :)

    As far as I can tell it's neither caused by the "animalbreedmaster", nor "ChickenCoop", nor "SmeltingNotifier" nor "Backpacks" plugin (at least if you use our example backpack plugin).


    I couldn't find the tp plugin though, could you maybe post a link to the according topic?

    Good News, I uninstalled jdk18 and jre8 started working and the server started up without a problem. So....
    Do Not Have a JDK installed with JRE8 or there is Interference!

    I'm glad to hear it works now :) If you have a JDK installed in addition to the JRE, the default "java" command typically runs the JDK. You can find out which version is used by the "java" command to run "java -version" in cmd (it's determined by an environment variable). The .bat file that's shipped with the server just uses the "java" command (because we can't know the absolute path of the JRE).


    If you have multiple Java versions installed and want to use a specific version, you can use the absolute path instead of the "java" command. To launch the server on Windows, for example, instead of using java -jar server.jar, you can use "<path-to-jre>/bin/java.exe" -jar server.jar accordingly ;)

    I Have changed my bat file to download the legacy version from "+app_update 339010 validate +quit" to "+app_update 339010 legacy validate +quit". What downloaded does not work. It goes to start up and crashes. This is the log.

    This error is caused by the installed version of the JRE: according to the log, Java 18 is installed. The "legacy" beta branch basically still has the same requirements as the default Java version - and unfortunately it only supports Java 8.

    This message comes from the plugin API ;) If you're playing on a multiplayer server, the server admin did set up a plugin which shows this message. If you're playing in singleplayer, it looks like you've installed a plugin which brings up this message

    too bad for me the beta is in steam. would LOVE to see the unity version

    Actually the new version is also available for the standalone (it's a separate launcher in the downloads section, which is accessible if you own the standalone) ;) But it looks like you don't have the standalone (at least it's not linked to your account)? :wat:

    :crazy: :crazy: :crazy: I will NOT ask how you define "near" in this context :crazy: :crazy: :crazy: I just have words in my brain popping up like "next week", "next month", "next year" and you know what happens, right? :wacko: Never, never ever use anything which could be understood as the slightest sign of a promise :lol: :lol:

    Hehe, yeah that's true, although the final transition to the new version (i.e. replacing the Java version on the Steam store page) must happen in early 2023, there is no room for us to postpone that :saint:

    Ich fände eine dauernde Anzeige wie in der Java Version praktischer

    Wie meinst du das genau? Die Höhenanzeige in der neuen Version wird so wie in der Java Version sein, also direkt am Höhenwerkzeug (aber natürlich auch nur, solange das Höhenwerkzeug eingeschaltet ist, wie in der Java Version auch). Oder meinst du was anderes?


    Wie sieht es eigentlich mit dem Terraforming bei Abhängen aus? Eine stufenlose Rampenfarm ist ja so nicht möglich, das einzige was mir dazu einfällt. wären Terra- Blöcke, Grasblöcke, die gingen ja stufenlos

    Das Glätten von Terrain funktioniert momentan noch ähnlich wie in der Java Version. Die neue Version kann grundsätzlich noch weicheres Terrain generieren (wie es bei natürlich generierten Chunks der Fall ist), aber leider kann man das mit dem Tool so noch nicht hinbekommen... das werden wir aber auf jeden Fall noch ändern ;)

    Mit Blöcken könnte man natürlich auch arbeiten, allerdings wird der Übergang zum Terrain damit vmtl. trotzdem recht sichbar (so ähnlich wie auch damals in der Java Version)...


    Die Hubbel bei den Schrägen kommen wahrscheinlich davon weil sich das Terrain an der Grundgröße 1 orientiert. so ist es auch beim Wasser in der Java gewesen, deshalb diese Absätze. Red müsste wohl die Größe 1verkleinern (z.B. 0.25). Da denke ich aber dass sich diese auf die Performance negativ auswirken wird.

    Genau, ein "Terrain-Block" ist im Grunde 1 Block groß ^^ Würden wir kleinere "Blöcke" verwenden (zB 0.5 oder gar 0.25), würde man ein traumhaft detailiertes Terrain hinbekommen - aber hinsichtlich der Performance hätte das deutliche Auswirkungen: Wenn ein Terrain-Block zB 0.25 groß wäre, würde das 64x so viele Daten bedeuten. Das würde auch spürbar mehr Polygone mit sich bringen, was die großen Sichtweiten wesentlich erschweren würde :dizzy:


    Interessant wäre es aber wie gesagt schon, vielleicht bauen wir irgendwann mal probeweise so einen "Ultra-HD-Modus" ein :D


    Aber nichtsdestotrotz speichert die neue Version für einen Terrain-Block noch Zusatzdaten, wodurch das Terrain glatter dargestellt werden kann als in der Java Version (wo ein Terrain-Block ebenfalls 1 Block groß war)^^

    Ich habe die Diskussion zu einem Blaupausen-Museum mal in einen eigenen Thread verschoben, da sie sonst im Bilder-Thread vmtl. etwas untergehen könnte :saint:


    Ein eigener Server für Blaupausen klingt interessant, würde aber auch einige Herausforderungen mit sich bringen... es kommen ja durchaus so einige Blaupausen zustande (und wenn die Spielerzahlen *hoffentlich* wieder steigen dürften es umso mehr werden), da wird es vmtl. schwierig, alle irgendwo auf einem Server unterzubringen. Zumindest ist viel manuelle Arbeit durch einen Admin erforderlich, denn er müsste die Blaupausen ja platzieren, da ein normaler Spieler so eine Berechtigung nicht haben dürfte (sonst werden sich die Griefer freuen)...


    Da müsste man ggf. mal auf die Plugin API warten, denn damit könnte man ein System implementieren, welches neuen Spieler automatisch eine Area in einem bestimmten Gebiet zuweist (denn auch das sollten Spieler in dem Fall ja nicht selber machen können, sonst würden die Areas kreuz und quer auftauchen) :D


    Was Tags angeht: WBB hat dazu ein eingebautes System, das funktioniert aber ein wenig anders... das müssten wir uns mal genauer anschauen, aber ich glaube, das ist nicht das richtige für sowas... stattdessen könnte man hingegen tatsächlich die "Labels" benutzen, die ja so auch schon zum Einsatz kommen (Sprache, Java Version / New Version etc). In dem Fall könnte der User aber keine eigenen Labels anlegen, sondern nur aus einer Liste bereits bestehender Labels wählen. Hier müsste man sich mal überlegen, welche Kategorien man bräuchte? :thinking:


    Server-absoluter-Noob-Frage: Wenn riesige Bauten auf dem Blaupausen-Server gesetzt werden, würde das dann irgendwann den Server-auf-VoodooPanz-eigenem-Rechner überfordern?

    Wenn viele detailreiche Blaupausen sehr nahe beieinander sind, dann ja, da würde ein Server (oder eher gesagt das Spiel beim Client selbst) ins Schwitzen kommen :D Wenn man die aber auseinander platziert (vll wirklich darauf ausgelegt, dass man sich zu den gewünschten Blaupausen hin teleportiert), sollte das kein Problem sein^^


    allgemein denke ich, dass tags für Blaupausen toll wären. Auch ingame. Manchmal benutze ich die selben Blaupausen für verschiedene Objekte/Gebäude. Sie in einem Ordner zu speichern wird dem dann oft nicht gerecht. Daher könnte das ganze Blaupausen-System vielleicht geändert werden in ein Tag-System in dem wir nach dem suchen können wofür wir die Blaupause eigentlich brauchen anstelle von einer absoluten Ordner-Struktur

    Dazu machen wir uns mal Gedanken :thinking: Das klingt grundsätzlich ganz gut, und wäre auf jeden Fall auch umsetzbar ;) Wäre allerdings auch mit einigem an Arbeit verbunden (zumindest wenn wir nicht mehr die Ordnerstruktur verwenden, sondern dort eine ganz andere Lösung umsetzen). Wenn die Tags aber zusätzlich angezeigt würden bzw. man auch nach Tags filtern könnte (ähnlich wie die Suche), wäre das durchaus machbar.

    Auf dem Bild ist der einzige Baum in der Nähe zu sehen

    Der ist eigentlich zu weit weg :thinking: Wenn dort kein anderer Baum in der Nähe ist, kann ich mir das Pfeifen jetzt nicht erklären... ich würde aber mal das nächste Update abwarten, da sich dort einiges an den Windgeräuschen (auch i.V.m. Wetter) ändern wird. Falls du dann die Probleme weiterhin hast, melde dich am besten nochmal ;)

    Das funktioniert, allerdings fehlt generell noch die Höheneinstellung, Rasterhöhe usw. Beim Wasser war das ein größeres Problem nach längerer Zeit die richtige Höheneinstellung wieder zu finden

    Du meinst für das normale Terrain-Werkzeug (1)? Mit dem nächsten Update wird eine Anzeige der aktuell eingestellten Höhe dazukommen. Um die richtige Höheneinstellung wiederzufinden kannst du aber sonst auch das Höhenwerkzeug einmal kurz ausschalten, dann die gewünschte Position betrachten und wieder einschalten - anschließend sollte die Höhe genau auf eben diese betrachtete Höhe eingestellt sein.

    Ich fand den Wind eben wieder extrem laut, er pfeift richtiggehend.

    Ist evtl. ein toter Baum in der Nähe? In dem Fall gibt der Wind eher ein pfeifendes Geräusch von sich. Die sind in der aktuellen Version auch manchmal tatsächlich etwas zu stark (auch bei gutem Wetter), das wird sich mit dem nächsten Update definitiv bessern ;)

    Hehe, don't worry, it's indeed not very obvious that there is a Unity version available ^^ This will definitely change in the next couple of months, when the new version is a bit more fleshed out and ready to replace the Java version (but of course the Java version will also remain playable).


    About the FOV setting, if you play on a 16:9 screen and resolution (e.g. 1920x1080), 70-85 is usually a good setting. If you have an ultrawide screen (e.g. 21:9 aspect ratio), it may be necessary to set a larger FOV value (80-100). If the FOV is too large, the screen gets distorted on the left and right. If the FOV is too small, everything feels "zoomed in". But at the end of the day, it also depends on your own preferences ;)

    Wir müssen uns das mit dem Wind nochmal genau anschauen :monocle: Oder eher anhören^^

    Ein paar Änderungen sind in dem Bereich auf jeden Fall auch noch geplant, aber ich weiß nicht, ob das wirklich auch das Phänomen betrifft, was du beschreibst...


    Es gibt mittlerweile auch mehr Raben-Geräusche, wo sind die eigentlich :thinking: , Stechmücken, aber weniger Singvögel.

    Die Vogelgeräusche hängen momentan überwiegend mit der Anzahl an Bäumen in deiner Nähe zusammen. Wenn keine Bäume da sind, gibt es deutlich weniger Vogelgeräusche. Auch bei "setsnowiness 1" gibt es weniger Vögel (in einer eisigen Winterlandschaft hält sich der Vogelgesang ja meist auch etwas in Grenzen). Aber auch das ist ein Punkt, wo noch etwas Luft nach oben ist ^^


    Was aber auf jeden Fall noch kommen wird sind die einzelnen Lautstärkeeinstellungen (wie in der Java Version). Allerdings kann ich leider noch nicht genau sagen, inwieweit der Wind separat eingestellt werden kann... das müssen wir nochmal prüfen