Posts by red51

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

It's indeed a bug I'm sorry about that, it's really a pity these bugs stayed under the radar for so long... these bugs will be definitely fixed in the new version though (once the Plugin API becomes available there)

We will also fix them once we release a new update for the Java version, but currently we have no ETA for that yet...

Leider bieten bislang nicht alle Serveranbieter Server für die neue Version an Manche Anbieter warten damit wohl, bis die neue Version die alte Version ersetzt hat. Ich weiß leider nicht, wie die Lage aktuell bei Nitrado ist. Ich weiß lediglich von GTXGaming, dass sie explizit auch für die neue Version Server anbieten.

Der Server für die neue Version ist von unserer Seite aus genauso verfügbar wie der alte Server, er ist lediglich in einem Beta-Branch. Wenn man den Server zB über den Steam Client herunterladen möchte, muss unter Eigenschaften die "unity" Beta ausgewählt werden (ähnlich wie beim Spiel auch). Um ihn über SteamCMD herunterzuladen, muss nur der Parameter "-beta unity" zum Downloadbefehl hinzugefügt werden (wie hier beschrieben). Die meisten Game-Hoster werden aber keinen direkten Zugriff auf sowas bieten... da kann vmtl. nur der Support des Hosters weiterhelfen...

Quote from derKoenisch

Moin Red,

was meinst du wann man das nächste Update erwarten kann?

Die Unity Version ist der Hammer und ich kann es kaum abwarten bis das Spiel fertig ist.

Hehe, danke Leider kann ich nicht genau sagen, wann das Update erscheinen wird... Angepeilt ist September, allerspätestens kommt es im Oktober (das möchten wir aber lieber vermeiden, damit noch genug Zeit fürs NPC-Update bleibt)

Quote from Fabianovic

ein Verbesserungsvorschlag habe ich: Beim benutzen des Megafons kommt ständig eine Rückkopplung bei Sprechen. Liegt das nur an mir, weil ich mit Kopfhörer spiele oder kann man da Ingame was verändern?

Es ist beim Megafon tatsächlich so, dass man sich momentan auch selbst hört. Das war ursprünglich eher zum Testen gedacht (da das Megafon ja bereits in der Demo vorhanden war, aber noch kein Multiplayer zu dem Zeitpunkt drin war)... ich denke es ist sinnvoll, dass wir das mit dem nächsten Update deaktivieren

Oh, this is unfortunately a bug If the item couldn't be added due to a full inventory, the game still returns the unused item instance (which is quite useless)... that's not intended...

But I'm afraid there isn't even a proper workaround available You could check if the newly returned item instance exists in inventory (I've posted an example below), however, that does not work in case of stackable items (if the item was added to an existing stack)... so this solution only works reliably for non-stackable items (e.g. tools, weapons etc).

//Your new code
@EventMethod
public void onPlayerChangePosition(final PlayerChangePositionEvent event) {
    //Do some stuff
    //...

    Item newItem = event.getPlayer().getInventory().insertNewItem(itemID, itemVariation, 1);
    //Check if returned item is null or if it still does not exist in inventory
    if(newItem == null || !isItemInInventory(newItem, event.getPlayer().getInventory())) {
        event.getPlayer().sendTextMessage("cannot add to inventory");
    }
    else {
        //Do other stuff
        //...
    }
}


//Helper function
public boolean isItemInInventory(Item item, Inventory inventory) {
    for(Item i : inventory.getAllItems()) {
        if(item == i) return true;
    }
    return false;
}

Quote from Deirdre

Was mich irgendwie stört, ist das automatische Andocken, ohne Magnetfunktion, meist zu weit von der gedachten Ansatzstelle.

Wie meinst du das genau? Wenn die Magnetfunktion nicht aktiv ist, sollten Bauteile eigentlich nicht automatisch andocken

Quote from Avanar

Mit "normal" meine ich den eingestellten rotations Modus.

Und nur beim andocken sollte sich das für das aktive Bauteil ändern, je nachdem wie das anvisierte gedreht und ausgerichtet ist

Bitte sei nachsichtig mit mir, aber ich verstehe leider immernoch nicht so recht, wie du das meinst Wenn du ein Bauteil irgendwo andockst, dann wird die Ausrichtung des Bauteils ja automatisch angepasst. Beim Andocken ist es ja quasi auch bereits so, dass sich das Bauteil abhängig vom anvisierten Bauteil dreht - so ist zB auch dieses Bild zustande gekommen: https://trello.com/1/cards/5f3…wnload/constructions2.jpg

Quote from Rüdi

Der grüne Pfeil zeigt wie ich es mir dachte, so als ob es die Weltachse nicht gibt. Beim Drehen oder Kippen orientiert sich das Bauteil an der "Bauteilachse" des schon gesetzten Bauteils, das soll ja auch so sein. Nur beim Verschieben ist die Weltachse die Orientierung. Da wäre es schön wenn die (von mir sogenannte Bauteilachse) Orientierung wäre, wie halt beim Drehen und Kippen.

Mit dem nächsten Update wird es auf jeden Fall eine Option geben den "Bewegungsmodus" (beim manuellen Platzieren) von Welt auf Lokal zu ändern Zumindest als Konsolenbefehl wird es definitiv rein kommen (vmtl. nennen wir es movemode, was dann "world" und "local" akzeptiert), ich weiß aber noch nicht, ob wir das Radial-Menü auch noch rechtzeitig anpassen können (wir haben damals dummerweise keine größeren Radialmenüs vorgesehen, wie das jetzige Baumenü, daher ist da leider etwas mehr Aufwand hinter )... sonst müssen wir das nachreichen.