Posts by red51

Quote from vinehold

Thank you for the detailed reply, I'm afraid I wasted some of your time due to a typo: my card is a Radeon RX570 (ie not integrated and quite adequate I should think at passmark 8097) I've no idea how I ended up typing RX7! Sorry

Oh, I see Yeah the RX 570 is definitely fast enough. You should be able to get decent framerates with that rig, at least on Medium settings (and there shouldn't be a need to disable grass), so if you're running into performance problems, it could be caused by another issue.

What Linux distro do you use exactly? Did you try to run the game via Proton? I'm curious if this makes a difference in terms of performance (Unitys Vulkan implementation is unfortunately inferior to their DirectX11 implementation).

Are you really having a low framerate, or is maybe something else causing these issues (e.g. input delay etc)?

Maybe you could also send us a report: To do that, load a world until you experience the performance issues, then open the console (usually that can be done by pressing key ~ or `, but on some Linux distros, it may be necessary to rebind the key in the controls settings) and type "report". That should bring up a dialog where you could add some additional information (e.g. just type "Performance issues"), then send the report

Quote from vinehold

With regard to volumetric clouds, I noticed the effect in this screenshot - many have a darkened edge and quite often there's a horizontal band in which the 'shimmering' occurs (look at left edge and near pickaxe head). I'm not at all bothered about having fancy clouds and will happily turn them off completely!

You can reduce the artifacts by increasing the volumetric cloud quality - but this has performance implications. But you won't get fully rid of the slightly darkened edge below the clouds - it's a limitation by design. It's our intention to improve that, but currently this has a low priority because these edges are usually only visible if you're at the same altitude as the clouds. This happens quite frequently atm, because the demo world actually consists of a relatively tall mountain - after the world generation update, most areas will be at a much lower altitude, so there should be a lot less situations where the dark edges really become visible But as mentioned, it's our intention to fix that in the long run^^

Quote from vinehold

In the new version, I chopped a few trees to the right of the start position. When I approach the tree indicated it 'shimmers' and disappears then reappears roughly when I get to the first boulder

Probably you mean the "fading" between different LOD levels? I.e. the closer you get to the tree, the more detailed it will be. In the new version, trees are getting replaced with lower-detailed versions the further you go away from them. At some point, they're replaced with a 2D billboard, and if you travel even further, they will become fully invisible. This is basically done for performance reasons, but in most cases it shouldn't be that much noticeable.

However, this behaviour is controlled by the "LOD Bias" slider in the graphics settings in the "View Distance" section: The lower the value, the sooner the tree gets replaced by a 2D version (or culled completely). The default value is 100%, but if you set it to a very low value (< 40-50%), you will mostly just see 2D trees (unless you get very close to them), and small trees may get culled very quickly.

To improve this situation, you can set a higher value for "LOD Bias" (for instance, at 100% that shouldn't be a big issue anymore), but the higher the value, the bigger the impact on performance.

"LOD Cross-Fade" in the graphics settings is indeed responsible for the "shimmering" - it tries to achieve a smoother transition between different LODs - disabling this may even slightly improve the performance, but this will result in popping (i.e. abrupt switchovers between different LODs).

Quote from vinehold

Incidentally, the performance seems much worse on my PC than many comparable 3D games - I have to turn off almost all visual effects but most especially grass which absolutely kills the framerate. I have an AMD Ryzen 5 2600, Radeon RX7 8gb, 16gb RAM running MX Linux. Not exactly cutting edge but even lowering the resolution, performance isn't good. Any help/suggestions welcome!

Your CPU and RAM are totally fine, but the bottleneck is the graphics adapter. It is an integrated RX Vega 7 graphics adapter? In this case, it doesn't meet the minium requirements of the game unfortunately

The game requires a graphics card which is at least comparable to a NVIDIA GT 1030 (or the much older GTX 650 Ti) in terms of performance. Or more precisely, a graphics card which has a score of at least ~ 2500 on passmark (the Vega 7 isn't listed there unfortunately, but a Vega 6 has a score of 1000, while the Vega 8 has a score of 1500, so the Vega 7 probably has a score between 1000 and 1500).

Our low-end test rig has a GT 1030 (+ a 12 years old Phenom II X4 955 CPU and 8 GB RAM) and we achieve roughly 30-40 FPS on low/medium settings (shadows and grass enabled) on Linux Mint - but the GT 1030 is twice as fast as the integrated Radeon, which makes a big difference

Unlike the Java version, the new version has an upfront cost - this enables the game to achieve much better framerates on larger view distances or complex scenes (i.e. consisting of very detailed buildings). In other words, you lose a lot less FPS compared to the Java version if the scene gets more complex. But the downside is that it runs terrible on low end graphics adapters...

Unfortunately it's also a bit difficult to compare it with other 3D games. Due to the randomly generated voxel terrain, there is a lot less room for optimizations from a technical point of view. A game with a static, pre-designed world, for example, could run a lot better (even if it has better graphics), simply because a lot more optimizations can be done in that case and less things need to be rendered in realtime. But even if you compare the game with another voxel game (like Minecraft), i.e. a game with a fully modifiable terrain, it still depends on various factors

Do you have any plans to get a newer graphics card in the near future? That will certainly give you a major FPS boost. But other than that, I'm afraid there isn't much you could do to improve the framerate, except disabling most visual effects - when hovering various graphics settings, the game shows a tooltip indicating the estimated impact on performance (according to your screenshot, you could disable volumetric clouds and shadows - they still have a considerable impact on performance)...

However, it is our intention to add support for AMD FSR in the near future (for both DirectX and Vulkan), which will probably give you a small FPS boost. Probably it won't make a huge difference with that graphics adapter, but it could possibly improve the framerate by 10-30%.

Quote from Deirdre

red51 Die Größe des Stacks s ist in dem Fall egal, da man die Steine ja überhaupt nicht braucht , man kann sie sich doch jederzeit wieder. herstellen. Ich habe diese in der ganzen Zeit, in der ich RW spiele, im Creativmodus nicht gebraucht. Vielleicht eine Abstell-Funktion einfügen.

Das Problem ist aber, dass es dann im Creative-Modus keinen direkten Weg mehr gäbe, Steine zu erhalten Geübte Spieler können natürlich dafür die Konsole verwenden, aber gerade für neuere Spieler wäre das suboptimal

Quote from Yaromid

Ich sehe das anders: Mit einem Stapel der Größe 1, ist es momentan nicht möglich, den Stapel aufzuteilen, was nötig ist, um unterschiedliche Bauformen (Quader, Rampen, Treppen usw.) festzulegen.

[...]

Allerdings ist es nicht sehr elegant, dass man direkt 999 Bauteile erhält, da stimme ich zu. Folgende Lösung fänd ich sinnvoll: Im Kreativmodus lässt sich auch ein Stapel mit nur einem Bauelement aufteilen, d. h. beim Aufteilen würde man den 1er-Stapel einfach duplizieren.

Guter Punkt! Ich denke es wäre tatsächlich sinnvoll, wenn es im Creative-Modus zusätzlich eine Option "Duplizieren" gibt, womit ein Item-Stack in den nächsten freien Slot dupliziert wird. Dann würde es reichen, wenn man mit der mittleren Maustaste nur 1 Item erhält und man diesen entsprechend beliebig oft duplizieren kann

Quote from Yaromid

Übrigens: Das Aufteilen und Wählen von Formen fühlt sich recht langsam an mit dem Herumklicken usw. Bitte mit passenden Tastenkombinationen im Inventar ausstatten

Das stimmt... wir können entsprechende Tastenbelegungen dafür auch mit dem nächsten Update hinzufügen

Quote from Dark Megatron

Ich wäre dafür, das alle Verbrennungsgeräte mit Brennstoff laufen, den man kann die Zeit für 1nen Stappel mit Holz und Stock ganz gut einstellen, wodurch auch nichts mehr Anbrennt, weil das Feuer rechtzeitig ausgehen würde

Wie meinst du das genau? Grundsätzlich haben die Öfen einen bestimmten Brennstoffverbrauch, theoretisch könnte man also abschätzen, wie lange er mit welcher Brennstoffmenge laufen wird... ist aber natürlich etwas umständlich.

Wir haben auf jeden Fall auch einen modernen Schmelzofen geplant, welcher eine automatische Abschaltung hätte, wenn die Erze fertig sind. Selbiges würde auch fürs Kochen bzw. für moderne Kochgeräte gelten^^

Quote from Dark Megatron

Und wird es auch eine Möglichkeit geben, Holzkohle herzustellen, welche als Kohleersatz benutzt werden kann ?

Wir könnten das grundsätzlich einbauen, dafür bräuchten wir eine Art Kohlenmeiler. Dazu müssten wir uns mal Gedanken machen... wir behalten das auf jeden Fall im Hinterkopf

Quote from Avanar

And will the regular water collide with static water?

Yes it will

Quote from Deirdre

Das Aufsammeln von Steinen im Kreativmodus helegt unnötig Inventarplätze.

Naja, das ist ja an sich nochmal ein anderes Thema. Hier gings ja nur darum, dass bei der "Block-Kopieren"-Funktion (mit der mittleren Maustaste) nur 1 Item statt ein ganzer Stack ins Inventar soll. Bei den Steinen, die man beim Buddeln ins Inventar bekommt, könnte man grundsätzlich zumindest über eine Einstellung nachdenken Es komplett auszuschalten könnte in manchen Fällen nämlich vll ungewollt sein...

Mit dem nächsten Update wird aber zumindest die Sortierung überarbeitet, sodass neue Items definitiv zuerst zu bestehenden Stacks hinzugefügt werden. Durch die Stackgröße von 999 wird es dadurch zumindest etwas dauern, bis das Inventar mit Stein gefüllt ist.

It's true that the first release won't contain collision between water and construction elements... so for now water will only collide with terrain

However, this is definitely on our to-do-list A dedicated water update is planned for the future which will improve the water visuals (it will add 3d waves etc), but it will also introduce collisions with construction elements. It will have some limitations though (for instance, water would not collide with very small or thin construction elements), but an underwater base will be definitely possible then (actually in creative mode it will already be possible to create an underwater base after the world update, but it requires the usage of static water, which will only be placeable in creative mode)

Avanar Das müssten wir uns mal überlegen Das Problem ist vmtl., dass man dann evtl. nur bedingt Kontrolle darüber hat, welche Blaupause in diesem Set landet. Und wenn das Thema zu breit gefasst wird (zB wenn ich 1000 Möbel habe und diese auch als "Möbel" speichere), würden da wohl trotzdem sehr viele Blaupausen landen (auch zu viel für das Radial-Menü, welches nur eine begrenzte Anzahl an Einträgen haben kann)... im schlimmsten Fall könnte auch hier wohl die Übersicht leiden (dass man seine Blaupause nicht mehr wiederfindet bzw. nicht mehr weiß, in welchem Set sie untergebracht ist)

Ich könnte mir - an der Idee mit den Sets anlehnend - vll eher eine Art "Blaupausen-Mappe" als eigenes Item vorstellen, welches quasi wie eine Kiste funktioniert, man allerdings komplett aus dem Inventar heraus steuert (und man auch nur Blaupausen darin lagern kann). Wenn man sie öffnet, kann man eine begrenzte Anzahl an Blaupausen darin ablegen. Zum Verwenden müsste man sie aber auch zunächst dort rausholen. Die Lösung ist aber nicht ganz unkompliziert umzusetzen, da dort pro Item recht viele Daten zusammenkommen könnten.

Alternativ wäre im Creative-Modus eine Art "Universal-Blaupause" denkbar, mit welcher jederzeit das Blaupausen-Menü geöffnet und die aktive Blaupause geändert werden kann - quasi wie in der Java Version. Hier müsste man nur im MP aufpassen, dass das an Permissions gekoppelt wird und nicht in die falschen Hände gerät.

Ansonsten wäre eine einfachere Lösung ggf. eine Möglichkeit, per Rechtsklick auf das Item die aktive Blaupause zu ändern - so ähnlich wie das bereits mit den Blockformen funktioniert. Dann würde sich das Blaupausen-Menü öffnen, und beim Auswählen einer neuen Blaupause würde das Item automatisch ersetzt werden. Im Creative-Modus würde sowas immer funktionieren und kostenlos sein, im Survival-Modus müsste dafür ein BP-Tisch in der Nähe sein (und ggf. könnten die bereits investierten Rohstoffe mit der neuen Blaupause "verrechnet" werden).

Unfortunately the only way would be to create a screenshot of the map, then upload it as poster For the new version, we may add a feature to use map data directly for posters, but unfortunately I can't say whether or when such a feature would be implemented... first we have to get the new version a bit more fleshed out in general

Da hast du recht, es wäre tatsächlich sinnvoller, ein einzelnes Item zu bekommen. Wir werden das mit dem nächsten Update ändern

Sicherheitshalber wird man das aber in der config ändern können (falls doch jemand weiterhin mehr Items erhalten möchte)

PS: Klasse Bilder!

Unfortuantely we have no plans to change the furnace in the Java version... I'm sorry Actually we don't have enough time to focus on the Java version, because there is still so much work to do to get the new version ready... There may be a small bugfix update for the Java version in the near future though.

Vielen Dank für das umfangreiche Feedback Sorry erstmal für die späte Antwort...

Quote from Forscherdrang

Leider ist es so, dass wenn man mit vielen Bauplänen Arbeitet, schnell die Übersicht abhanden kommt. Gerade bei Umfangreichen Bausätzen, zwischen denen man oft hin & her wechseln muss.

Das stimmt, allerdings weiß ich nicht, wie man das idealerweise lösen könnte... das ist natürlich dem Ansatz geschuldet, dass die fertige Blaupause direkt als Item gespeichert wird - später wird das so sein, dass man (im Survival) direkt beim Herstellen der Blaupause bereits die nötigen Rohstoffe zahlen muss. Darauf ist zumindest dieser jetzige Ansatz ausgelegt

Quote from Forscherdrang

Auch die Schnellzugriffsleiste ist mir persönlich zu kurz, zudem man ja 10 Ziffern Tasten besitzt ( 0-9 bzw. 1-0 ).

Geplant war ursprünglich zumindest, dass man mehr Slots per zusätzlicher Ausrüstung freischalten kann (also zB mit einem Werkzeuggürtel o.ä).

Im Creative-Modus macht es natürlich Sinn, immer alle Slots zur Verfügung zu haben. Wir müssen aber noch implementieren, dass sich das Inventar korrekt verhält, wenn man zB vom Creative-Modus wieder in den Survival-Modus wechselt (und sich dadurch die Slot-Anzahl ggf. wieder reduziert).

Quote from Forscherdrang

Hier würde sich eine kleines Vorschau Bild direkt auf der Blaupause mehr als nützlich erweisen, natürlich in geringer Auflösung, meinetwegen auch leicht verschwommen.

Das macht auf jeden Fall Sinn, und tatsächlich wird das mit dem nächsten Update auch reinkommen

Quote from Forscherdrang

Es ist ja toll, dass man verschiedene Unter-Ordner erstellen kann um so die Ordnung aufrecht zu erhalten. Aber müssen diese ständig bzw. IMMER & ALLE im zentralen Hauptfenster aufgelistet sein ? ! ?

Da stimme ich auch zu. Leider wird es etwas umfangreicher, wenn wir das ändern wollen... die momentanige Listenansicht haben wir ursprünglich extra etwas generisch gehalten (das gleiche technische Element kommt zB auch im Crafting-Menü zum Einsatz) - leider ist dort dieser Grad an Verschachtelung nicht vorgesehen.

Wir möchten das auf jeden Fall anpassen, es bedarf aber leider ein paar größerer Änderungen, daher kann ich leider noch nicht sagen, wann das genau kommt

Quote from Deirdre

Die Sache mit dem Block bei den Blaupausen vermisse ich von Anfang an in der Unity.

Grundsätzlich sollte es *eigentlich* so sein, dass sobald ein Block (also ein Bauteil mit einer Größe von 1x1x1) im Raster (also auf größter Rasterstufe) platziert wird bzw. in der Blaupause mitgespeichert wird, die Blaupause automatisch am Raster ausgerichtet werden sollte. Falls das bei einer Blaupause nicht der Fall ist, schick sie mir am besten mal, damit ich mir das genauer anschauen kann

Quote from Deirdre

red51 Apropos Plätze. Da ich einige Blaupausen ständig im Inventar behalte, reicht mir der Platz vorne und hinten nicht. Wäre es möglich dafür einen separaten Reiter einzuführen?

Das ist auf jeden Fall nachvollziehbar... dazu müssten wir uns mal Gedanken machen... das würde eigentlich mit der jetzigen Auslegung der Blaupausen (also dass Blaupausen als Item gespeichert werden) vmtl. nicht ganz zusammenpassen. Vor allem müssen wir sicherstellen, dass es keine zu große Diskrepanz zwischen Creative- und Survival-Modus gibt (da man in RW ja jederzeit zwischen beiden Modi wechseln kann) Schwieriges Thema...

Thanks for the log! The error indicates that the blueprint file is apparently corrupted... Is it one of your own blueprints, or did you download the blueprint from the forums?

Unfortunately there is no way to access the player preview UI element from the API They require some special handling to render the object dynamically, unfortunately such an element was never exposed to the API...

Quote from james1bow

Also, i cant seem to get any of the stuff for skin's to work.

Hmm... it looks like syncing the skin retroactively was never fully implemented... that's why the skin actually gets changed, but it doesn't get synced with connected players Changing the skin in the OnPlayerConnect event works though, because the player hasn't been loaded for other players yet at this stage...

I can't think of a proper workaround for this unfortunately... but we will make sure that this gets properly implemented in the new version (once the API is ready)

As Skarafass mentioned, you can change the length or height of the element by pressing Shift + Page up / Page down

The reason why this works a bit different compared to the Java version is that elements can now be resized in 3 directions (length, width, depth), while in the Java version, it was only possible to resize them in 2 directions...

You can, however, change that behaviour (to make it work like in the Java version): To do that, go to the settings -> Miscellaneous -> scroll down to the "Building" section and change "Resize Mode" to "Legacy". This enables you to resize elements just by using Shift + Arrow keys (similar to how it worked in the Java version).

We would love to make that part a bit more straigthforward, but I must admit that I have no idea how to do that without taking away too much control We could enable the "Legacy" Resize Mode by default, since that works quite well for certain shapes, but this mode can be annoying when it comes to blocks, especially if you want to make thin blocks, similar to planks in the Java version... some people have suggested to reintroduce planks, but I'm not sure if that's really the way to go (certainly this would only make sense if the Legacy Resize Mode really becomes the default mode)...

Quote from Deirdre

Wäre es möglich Blaupausen noch kleiner zu skalieren als bisher, so dass man Miniaturen herstellen kann? Pflanzen sollen ja dann auch kleiner zu skalieren sein.

Geplant ist das bisher leider nicht, der Grund ist tatsächlich - wie du und Avanar schon feststellt - das potenzielle Performanceproblem... die Miniaturgebäude sind in puncto Performance genauso "teuer" wie ihr großes Pendant, mit dem Unterschied, dass man davon wesentlich mehr auf der selben Fläche unterbringen kann Je kleiner die Gebäude werden, desto heikler wird natürlich auch dieser Umstand...

Wenn man seine Gebäude also weiter verkleinern möchte, muss man das am besten nach eigenem Ermessen machen (also wie oben erwähnt, zB 2x blaupausen)

This looks great I'm glad to hear it worked!

Basically it is possible, but a bit cumbersome because there is no direct method to retrieve objects But you could use the Internals class to get access to the internal chunk data, then access the internal object data via reflection - the only issue with this approach is that the game is obfuscated, so this becomes a rather hacky solution (all methods and fields are named a, b, c etc)... there is also a chance this breaks with the next update (although we have no ETA for the next Java update)...

This code wouldn't work in the new version anymore of course, but it's our intention to add methods to the new API which enables you to get objects from a chunk easily

One issue of the the obfuscation is that it results in one class having multiple variables or methods with the same name - this is illegal in Java, but legal in byte code. Unfortuantely this makes reflection more complicated - I've added two helper methods to get the correct fields and methods.

The Java version stores the objects in a so called "ChunkAddition" - these special chunks only have a X and Z coordinate, and they contain all objects irrespective of their Y (vertical) position (so when calling this method, you may also get objects from underground dungeons, for example).

Here is a basic example where I also created a new "ObjectElement" class to hold the individual object data we get via reflection (definition and world position for now).

public ArrayList<ObjectElement> getAllObjects(int chunkX, int chunkZ){
    try{
        Object chunkAddition = getInternals().getRawChunkAddition(chunkX, chunkZ);
        if(chunkAddition != null){
            Object objects = getFieldOfType(chunkAddition.getClass(), "a", Class.forName("commons.util.c")).get(chunkAddition);
            if(objects != null){
                Field arrayField = getFieldOfType(objects.getClass(), "a", Object[].class);
                arrayField.setAccessible(true);
                Object[] objectsArray = (Object[]) arrayField.get(objects);
                if(objectsArray != null){
                    ArrayList<ObjectElement> storeTo = new ArrayList<>(objectsArray.length);
                    for(Object rawObject : objectsArray){
                        if(rawObject != null){
                            ObjectElement o = new ObjectElement();
                            short typeID = (short) getFieldOfType(rawObject.getClass(), "a", short.class).get(rawObject);
                            o.definition = Definitions.getObjectDefinition(typeID);
                            o.worldPosition = new Vector3f();
                            o.worldPosition.x = (float) getMethodWithReturnType(rawObject.getClass(), "g", float.class).invoke(rawObject);
                            o.worldPosition.y = (float) getMethodWithReturnType(rawObject.getClass(), "h", float.class).invoke(rawObject);
                            o.worldPosition.z = (float) getMethodWithReturnType(rawObject.getClass(), "i", float.class).invoke(rawObject);
                            storeTo.add(o);
                        }
                    }
                    return storeTo;
                }
            }
        }
    }
    catch(Exception e){
        e.printStackTrace();
    }
    return null;
}
    
private static Field getFieldOfType(Class<?> clazz, String name, Class<?> type){
    Field[] fields = clazz.getDeclaredFields();
    for(Field f : fields){
        if(f.getType() == type && f.getName().equals(name)){
            return f;
        }
    }
    return null;
}

private static Method getMethodWithReturnType(Class<?> clazz, String name, Class<?> returnType){
    Method[] methods = clazz.getMethods();
    for(Method m : methods){
        if(m.getReturnType() == returnType && m.getName().equals(name)){
            return m;
        }
    }
    return null;
}



//Our new object representation
public class ObjectElement{
    //Object definition
    public Definitions.ObjectDefinition definition;

    //Object world position
    public Vector3f worldPosition;
}

As said, it's an ugly and extremely hacky solution, but it should do the trick There is also room for improvements: You could cache the Method and Field objects so the game doesn't have to search them for every object.

Anyway, if you now want to get all objects from the chunk where the player is, you could get the player chunk position and then call our new method:

Vector3i chunkPos = player.getChunkPosition();
ArrayList<ObjectElement> objects = getAllObjects(chunkPos.x, chunkPos.z);
if(objects != null){
    for(ObjectElement o : objects){
        System.out.println("Object " + o.definition.getName() + " @ " + o.worldPosition);
    }
}

To find all nearby objects, it certainly makes sense to check surrounding chunks as well

Unfortunately this is not possible atm But it's on our to-do list for the new API

Sorry für die späte Antwort, aber vielen Dank für die Blaupausen! Ich habe mir das Problem zwischenzeitlich mal genauer angesehen und den Bug auch gefunden. Die Blaupausen selber sind intakt, lediglich beim Platzieren tritt das Problem auf (wenn das Objekt kleiner o. größer skaliert wurde). Mit dem nächsten Update sollte das behoben sein