You mean preventing them from despawning (or more precisely, being able to place them persistently in the world)? Unfortunately this isn't implemented yet... I can't say for sure when this will be added, probably this will happen after the NPC update 
Posts by red51
-
-
Das Terraintool arbeitet zu langsam. Das Löschtool ist leider auch nicht schneller.
Das Terrain-Tool dürfte mit dem nächsten Update zumindest bei großen Gebietsänderungen etwas schneller werden, vor allem aber das Lösch-Tool wird deutlich schneller arbeiten, wenn größere Mengen gelöscht werden (das betrifft zB auch den Undo-Befehl bei Blaupausen)
Damit meine ich die Dauer, bis die Elemente verschwunden sind, nachdem man die Lösch-Taste gedrückt hat.
Ich habe mich schon in der Java-Version über das Einschlaftempo bei der Gebietssicherung geärgert.
Es ist irgendwie nicht möglich das Ganze mit dem Mausrad, wie beim schneller Fliegen, zu beschleunigen.
Kannst du das evtl. näher erläutern? Worauf beziehst du dich in dem Zusammenhang genau, wenn du von "langsam" redest?
Ich weiß nicht, wie das mit der Gebietssicherung in Zukunft funktionieren soll, aber einen Anfangspunkt festlegen und dann sehr sehr lang fliegen müssen, um bei einem riesigen Gebiet zum Endpunkt zu gelangen, kostet Zeit und Nerven.
Das funktioniert im Prinzip so, wie auch die Area-Protection in der Java Version. In den meisten Fällen werden die Gebiete, die man für einen Spieler erstellt, ja vmtl. eine mehr oder weniger überschaubare Größe haben... Wie groß ist das gewünschte Gebiet denn, wenn der Endpunkt so weit weg liegt, dass es zu lange dauert, dorthin zu fliegen?
In so extremen Fällen würde ich dann ggf. den Teleport-Befehl (also "goto") verwenden...Das Gleiche gilt für Terrain- und Löschtool.
Wie meinst du das?
Das Fliegen mit 400% ist meiner Meinung nach auch zu wenig. 600 Prozent wären da schon besser. Es ist klar, dass das Performancegründe hat, und sich bei manchen Pc's die Map langsamer aufbaut, aber wer die Ressourcen zur Verfügung hat, sollte sie auch nutzen können.
Naja, das Problem ist tatsächlich, dass das bei langsamen Rechnern dann etwas problematisch werden könnte... schon die 400% sind da oftmals "zu viel"... mit dem Welt-Update wird sich die Welt-Generierung leider etwas verlangsamen (da jetzt wesentlich mehr Krams gespawnt wird), daher müssen wir erstmal beobachten, wie das insgesamt ausfällt. Hier stehen in der Hinsicht generell noch ein paar Optimierungen im Raum, die wir aus Zeitgründen leider nicht mehr zum Update fertig bekommen - ggf. dann aber fürs nächste Update (oder wenn die Probleme doch größer als erwartet sind ggf. auch in einem Hotfix). Wenn das abgeschlossen ist, kann man sich dem Thema "höhere Fluggeschwindigkeit" definitiv nochmal widmen (oder dann alternativ eine Einstellung in der config anbieten o.ä)
-
Wären denn so Dinge wie Spendenkonto oder Sponsoring evt. ein Lösungsansatz? Oder hat hier vielleicht irgendwer zufällig 'nen reichen Onkel in Amerika, den man für ein solch großartiges Projekt begeistern könnte?
Naja, Spenden sind immer etwas kompliziert aus steuerlicher Sicht^^ Das Finanzamt runzelt die Stirn, wenn jemand freiwillig einer Firma Geld spendet - da kommt schnell der Verdacht auf, dass irgendwas "fishy" sein könnte (könnte ja Geldwäsche o.ä. sein).
Auch buchhalterisch würde eine Spende mehr Aufwand für uns bedeuten...
Da Spenden (ausgenommen für Parteien und gemeinnützige Organisationen usw) aber in DE so oder so als Einnahme gelten und voll versteuert werden müssen, ist es in der Hinsicht wesentlich sinnvoller, wenn jemand einfach das Spiel nochmal kauft oder einen Steam-Key kauft und einem Kumpel schenkt
Selbst wenn jemand 1000 Kopien auf einmal kauft, wäre das erstmal weder verwerflich noch suspekt 
-
We've been thinking about that in the past. It's true that it's basically possible to get an advantage by using larger construction elements (and therefore require less resources)^^
On the other hand, it may feel a bit less intuitive if resizing depends on the number of blocks you have in your inventory... for example, when resizing the block to 5 x 0.05 x 5, it would still require ~ 1 block, but if the player only has a single block in his inventory, he couldn't make the block thicker in this case (unless he reduces the length or width).
It is also a bit restricting when building with large elements in general, so probably it would still be reasonable to use smaller blocks, even if that's a bit more "expensive". Unless it's a rare material (iron, gold etc), it probably doesn't matter that much (considering it's easy to get stone or wood)
But once the world gen update is ready, the survival part may play a bigger role in general. We will keep a close eye on this, and if it turns out that the currently resource handling is indeed too unbalanced, we will definitely change that
-
Thanks for your suggestions
I agree that the current mechanic is indeed unrealistic, but it was originally meant to be just a placeholder 
Unfortunately steel or other alloys never made it into the Java version... however, for the new version, we actually have plans for various alloys (including steel). We've prepared a new crafting station for that in the past, but unfortunately it's not in the new version yet... we'll hopefully introduce it after the NPC update. Steel, for example, would then indeed be created by combining iron and coal^^Unfortunately I can't say much about mithril yet, because it's currently not in the new version... but I like your suggestion of using mithril to create special alloys with fantastical properties
Maybe this would be a good reason to reintroduce mithril (at least once alloys are in the game)... we'll definitely keep that in mind! -
Yeah, that's indeed the latest PNB plugin... I couldn't reproduce the issue on my end unfortunately, but if you run into this issue again, please create a report file and upload it here
-
Рассмотрите вариант создания двух биомов пустыни, в java пустыня очень песчаная и по ландшафту больше похожа на пустыню Сахара, там нет растительности кроме оазисов, но пустыня дикого запада как в игре Red Dead Redemption категорически отличается от неё, там более твёрдый грунт и больше растительности и животных что позволяет полноценно выживать, такая пустыня даст возможность для развития тематики дикого запада с соответствующей архитектурой
It's definitely our intention to add more than just one desert type
The good thing about the approach in the new version (having one climate region per island) is that it allows us to add more biomes in general (this was a bit tricky in the Java version, because biomes always had the same scheme - e.g. desert surrounded by savannah etc). -
Ich hätte das Update tatsächlich gerne im September rausgebracht
Aber leider ist das Welt-Update ein ziemlicher Klotz... unter normalen Umständen hätten wir das Update eigentlich weiter aufgebröselt (zB hätten Boote & Wasser schon im August oder so kommen können), damit auch die Wartezeit reduziert wird. In diesem Fall war das aber nicht möglich, da Wasser ohne passende Welt-Generierung (dadurch nur im Creative-Modus zugänglich) einerseits etwas witzlos ist, andererseits aber auch viele Leute auf das Welt-Update warten, um überhaupt loszulegen.Die Zeit fehlt uns zwar jetzt ein wenig beim NPC Update, aber das ist kein Weltuntergang, denn das Update ist nicht so umfangreich (vom Arbeitsaufwand her) wie das Welt-Update. Spätestens wenn aber dann die NPCs auch da sind, haben wir zumindest den Punkt erreicht, dass man sich auch endlich um "kleinere" Dinge bzw. reinen Content kümmern kann (zB Poster, Schilder, neue Objekte, Türen usw). Wenn wir also nochmal an einem großen Update sitzen (wobei mir kein Update einfällt, was nochmal so arbeitsintensiv wie das Welt-Update werden könnte^^), können wir so zumindest ein kleineres Update zwischenschieben. Wie gesagt, das hätte dieses mal nicht geklappt, weil viele Leute dann nicht gerade entzückt über ein vermeintlich unwichtiges Update wären, während sie noch auf das Welt-Update warten.
Das Welt-Update wird aber jedenfalls definitiv noch im Oktober kommen
Ich meine mich erinnern zu können das er mal erwähnt hat das er dann aufgeben müsste was absolut ein worst case wäre.
Naja, ein "Aufgeben" ist so nicht direkt vorgesehen
Wir hoffen aber natürlich, dass sich die Verkäufe bessern, sobald die neue Version die Java-Version ersetzt hat. Seit Ende 2018 (als der Algorithmus auf Steam geändert wurde, was u.a. auch einer der Gründe für die neue Version war) reichen unsere Einnahmen nicht mehr aus, um die Kosten zu decken, und spätestens Anfang nächsten Jahr sind alle unsere finanziellen Reserven aufgebraucht... wenn also auch die neue Version an den Verkäufen nichts ändert, wirds natürlich kompliziert... aber ich bin mir sicher, dass sich selbst dann irgendwie eine Lösung finden wird^^ -
In der Java gab es doch Grastextur so dass man Dächer oder Anderes mit Grasoptik machen konnte.
Ist es möglich das auch in die Unity zu bringen aber nicht nur kurzes Gras sondern auch das längere. Damit wäre die Möglichkeit eines sauberen Kantenabschlusses, z.B. für Pools oder Wege, leichter zu bewerkstelligen.
Grasblöcke werden auf jeden Fall noch kommen
Ich fürchte aber, dass die nicht mehr fürs Welt-Update fertig werden... das Problem ist, dass die Terrain-Texturen grundsätzlich erstmal nicht für die Bauelemente zugänglich sind, sondern nur für das Terrain. In der Java Version wurden die paar Terrain-Texturen quasi einfach nochmal für die Bauelemente dupliziert und dann quasi als Baumaterial behandelt (was zwar etwas mehr VRAM verbraucht hat, aber da die Textur eine so geringe Auflösung hatten, waren das nur ein paar MB). In der neuen Version sind die Texturen aber so groß, dass diese Lösung nicht klug wäre. Jede andere Lösung kostet stattdessen unweigerlich etwas Performance, aber hier müssen wir den optimalen Weg noch finden (um die Performance-Kosten so gering wie möglich zu halten).Wir werden aber versuchen, sie zeitnahe einzubauen. Wir haben das bisher nur nicht gemacht, weil die meisten Terrain-Materialien bisher noch gefehlt haben (die kommen jetzt erst fürs Welt-Update), und wir uns da noch nicht sicher waren, ob und welche der bisherigen Texturen so in ihrer Form drin bleiben.
Die Grastextur ist aber dann - wie Avanar beschreibt - erstmal nur "plattes Gras" (quasi wie in der Java Version). Wenn wir 3D Gras haben wollen (also richtige Grashalme, wie das Gras, welches standardmäßig in der Welt spawnt), können wir das leider nicht einfach über die Textur lösen, sondern müssen das zusätzlich generieren. Auf Bauelementen klappt das leider nicht so gut, denn das würde einige technische Schwierigkeiten mit sich bringen... und zusätzlich müsste das Gras auch eine gewisse Dichte haben, damit es auf einem Würfel auch wirklich gut aussieht (also es müsste detailreicher sein, als bspw. das Gras auf dem Terrain)...
Die sinnvollere Lösung wäre da vmtl. Gras als zusätzliche, einzelne Pflanze zu haben (wie oben beschrieben). Aber damit wir damit nicht sofort die Büchse der Pandora öffnen, müssen wir erst einen effizienteren Weg implementieren, um Pflanzen zu rendern (ich hätte das zwar gerne schon fürs Welt-Update implementiert, da dichte Wälder auch schon recht teuer werden können, aber das passt zeitlich leider nicht mehr)
-
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
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
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
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
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
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
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 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
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 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
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
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 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
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
