lol 
What items were involved exactly? Maybe we can add them anyway 
Posts by red51
A small new update is available now!
-
-
Very cool 👍 I assume there will be animation support.
Most likely yes, but it depends on whether or not we add support for Unity assets/prefabs - otherwise we don't have a pipeline to import animations at runtime (unless we add fbx support)
I guess there will be support for Unity assets eventually, so we could enable support for Unitys "AnimationClip" (but that would mean you have to prepare them in Unity).But probably I can say more about that once we've added npcs to the new version
I assume by custom item/object/plant you mean the customization of an existing object? Like a sword or pickaxe with a different set of attributes as opposed to an entirely new item that includes a custom object?
Oh, actually I was refering to adding entirely new items
Unlike static models (e.g. models loaded through World3DModel in the Java version), the game would store them persistently and treat them like built-in objects. For example, you could give a custom bed (which could have a custom model and texture) a "bed attribute", define a lying position etc. Similar to how CustomItems worked in the Java version. the player could then craft your custom bed at the workbench, place it in the world and use it (it would just behave like a vanilla object)Yes, this is about custom vertices & indices handling. This is a very useful thing, especially for natural-looking objects and optimisation (when you can merge meshed into one to reduce render calls)
Does that mean you're mainly looking for an API to modify existing meshes (e.g. loaded through an obj file or a Unity asset), or an API to create entirely new meshes from scratch?
-
This is unfortunately a technical limitation of the old version
Blocks are basically placed in a fixed grid, and only one block can be placed inside a "cell".The new version doesn't suffer from this limitation anymore btw, so there you wouldn't run into such issues
Having that said, one thing you could do in the old version is removing the triangle blocks and place full blocks there instead. That would work from a visual point of view, but that wouldn't help if you want two different textures / materials in a single cell.
-
Puhh, die letzten Beiträge weichen tatsächlich zu stark vom eigentlichen Thema ab und werden viel zu persönlich... wie Sandboxgamer schon sagt, am besten weitere Unstimmigkeiten via PN klären - hier sollten wir uns wieder auf die Blaupausen bzw. das letzte Update konzentrieren
-
1. Will plugins have a system for custom objects?
It depends: The old API only had a system to load custom models (through World3DModel class) and custom items (CustomItem class). It was possible for players to interact with custom models (and plugins could react on this interaction), but other than that, you couldn't make custom models behave like built-in objects (so it wasn't possible to create a custom chair, for example).
Custom items, on the other hand, provided a bit more freedom in this regard, since they could behave like regular tools or melee weapons. Implementing more complex items (like firearms) was a bit difficult though.
For the new API, we have plans to provide an easier way to create custom objects which behave like built-in objects (e.g. custom chairs, beds, chests etc). Same about plants and npcs in the long run.
2. If yes how it will work? Will objects be loaded from some sort of unity assets or it will be possible to load models from formats like OBJ?
You will definitely be able to load obj files, but probably we will also add support for Unity assets/prefabs
3. Will it be possible to construct things in code procedurally or it will require manual model loading?
When talking about procedural construction, do you actually mean an API to create custom meshes (by providing individual vertices and indices)? If there is demand for such a feature, we could implement that
4. Will models have support for different shaders or they will use single shader with different texture maps?
Probably the game will provide a default lit and unlit shader for custom objects/models. Objects will require a single texture, however, we want to implement support for submeshes (so you can have separate textures per submesh). When it comes to custom plants (and other things like items or npcs), the game will probably use the same shader it already uses for built-in elements (so plants support wind and snowiness, for example).
If you provide a Unity asset/prefab, it will probably also be possible to provide custom shaders/materials. However, the game uses Unitys HDRP, so it would be necessary to provide HDRP-compatible shaders in this case. Currently Unity doesn't provide surface shaders for HDRP, and authoring hand-written shaders for HDRP is extremely cumbersome, so the only "smooth" way atm would be to use shader graph.
But this could also introduce compatibility issues: Unitys HDRP is still undergoing lots of changes, so there is always a chance that a newer Unity/HDRP version breaks old shaders/materials. So when providing custom materials/shaders, there is a chance they no longer work in a future RW version... ofc this doesn't happen when just providing raw obj files and textures.5. Will game automatically store objects data in worlds database or each plugin should implement its own system to store objects?
It depends on how the elements will be loaded: When just loading a custom model, the game doesn't store it persistently, so the plugin would be responsible for storing it in a file or database. However, when creating a custom item/object/plant through the specific API, they will actually be stored in the world database when a player places them in the world, so there is no need for the plugin to implement custom serialization.
When it comes to custom biomes: If a plugin alters the world generation, it will be necessary for the user to keep the plugin installed, otherwise the game will fallback to the default world generation once the plugin gets removed (which could result in messed up chunk borders if a custom world generation was used before). For custom objects or plants, it will also be necessary for the user to keep the plugin installed - otherwise the custom elements won't show up in the world anymore (they're still in the database though, so reinstalling the plugin will bring them back)
tl;dr Yes, when adding custom objects/plants/npcs etc, the game automatically stores them in the world database (when a player places a custom plant or object, or when a custom npc spawns)
-
Ich finde es ja eigendlich ganz gut das auf einem MP Blaupausen von mir nicht von einem anderen Spieler genutzt werden können.
Du meinst das entsprechende Item, also wenn man die Blaupause (den Plan) auf den Boden wirft oder in einer Kiste ablegt? Das hat tatsächlich technische Gründe, nämlich das Item speichert nur die Referenz auf die Blaupausen-Datei (und wenn ein anderer Spieler exakt diesen Bauplan nicht hat, dann kann er ihn nicht nutzen).
Damit sowas funktionieren würde, müssten alle Blaupausen, die hergestellt wurden, auch auf dem Server gespeichert werden. Darüber gabs ja vor kurzem eine Diskussion. Das Problem ist, dass sich im Laufe der Zeit viele Daten auf dem Server ansammeln könnten. Andererseits könnte man darüber nachdenken, sowas zumindest optional anzubieten. Wir sind uns da noch nicht ganz sicher
Dazu ist es ja momentan so, dass wenn ein Spieler eine meiner Blaupausen nimmt, diese dann für diesen unbrauchbat ist, aber warum ist diese dann für mich auch unbrauchbar ?
Das sollte eigentlich nicht sein
Seine eigenen Blaupausen sollte man jederzeit wieder aufheben können - wenn nicht, wäre das wohl ein Bug 
Tritt das denn erst auf, nachdem ein anderer Spieler sie aufgehoben hat?Der Befehl "Undo" ist zwar praktisch, aber die Blaupause explizit zu entfernen, ist leider nicht möglich. Erst nach mehrmaligen Undo-Wiederholungen, wird auch die Blaupause entfernt, je nachdem was man geändert hatte.
Der "undo"-Befehl geht leider immer der Reihe nach... mittelfristig möchten wir ihn auf jeden Fall so abändern, dass man vll direkt eine Liste bekommt in welcher eine Übersicht über alle letzten Undo-Schritte ist - und man dort direkt auswählen kann, welchen Schritt man rückgängig machen will.
Vll können wir auch zusätzlich einen "undobp" Befehl einbauen, der explizit zum letzten Blaupausen-Undo-Schritt springt
Könnte man die Zeit, die für das Blaupausen setzen nötig ist, verkürzen? Setzen und zack, jedenfalls im Kreativmodus.
Das ist doch bereits nur wenige Sekunden lang
Da gibt es nicht mehr viel zu reduzieren... Der Sinn dahinter ist, dass damit möglichst verhindert werden soll, dass man eine Blaupause aus Versehen platziert, und auch versehentliches doppelt-Platzieren soll verhindert werden (wie von Rüdi erwähnt). Außerdem ist es schon sinnvoll, dass zumindest eine 1-sekündige Pause zwischen den Platziervorgängen liegt, da beim Platzieren einer Blaupause nun mehr Arbeit im Hintergrund passiert als noch in der Java Version (das ist zwar eher im MP relevant, aber wir möchten das Verhalten im SP und MP gerne identisch haben).In den meisten Spielen sind Zeitverzögerungen auch dazu da, damit die Spieler länger im Spiel bleiben.
Ich glaube kaum, dass jemand wirklich nennenswert mehr Zeit in RW verbringt, weil das Platzieren von Blaupausen ein paar Sekunden dauert... wenn wir sowas wirklich wollten, dann hätten wir das direkt auf 5 Minuten gesetzt oder so
-
Was mir zum Thema Fensterrahmen einfällt ist , dass man sie zwar mit der Textur der Leuchtmittel versehen kann , sie aber dann leider nicht leuchten. Wäre es eventl. möglich leuchtende Fensterrahmen zu bekommen ? Man könnte damit soviel gestalten.
Oh, das sollte aber eigentlich nicht sein
Also Fensterrahmen, die man per Befehl mit Leuchtmaterial erhält, sollten sich *eigentlich* genauso verhalten wie normale Blöcke. Wenn du sie zB direkt mit dem Leuchtmaterial spawnst (also zB "item window1" und dann das Leuchtmaterial auswählst), sollten sie direkt leuchten. Wenn du hingegen die Textur nachträglich setzt (via "edit texture"), dann muss allerdings wie bei anderen Blöcken auch zusätzlich noch die Farbe und Helligkeit gesetzt werden (beim Betrachten des Blockes die Interaktionstaste [F] gedrückt halten, und dort im Radial-Menü die Helligkeit und Farbe ändern [und ggf. den Block auch einschalten]) Und dann noch eine Frage. Wäre es auch wieder möglich die Leuchtmittel sichtbar einzufärben , damit man auch im ausgeschalteten Modus sieht welche Farbe sie haben. Am Anfang war dies noch möglich. Die beiden Beispielfotos von meiner künftigen Musikbox zeigen was ich meine.
Das könnten wir machen. Dass man die Farbe nicht sieht, war ursprünglich eine bewusste entscheidung (quasi in Anlehnung an RGB-Lampen, die im ausgeschalteten Zustand ja auch keine Farbe haben)... aber ich verstehe natürlich das Argument i.V.m. der Jukebox... wahrscheinlich ist es sinnvoll, wenn wir das entsprechend abändern
Oh und was mir noch einfällt , aber nicht unbedingt zum Thema passt , wären künftig beschreibbare Schilder aus Glas , damit auch schöne Leuchtreklamen oder Türklingeln möglich wären.
Das klingt nach einer guten Idee, ich packe das mal auf unsere Liste
Apropos Schilder. Gab es die am Anfang nicht in der Demo, bzw. Leuchtreklamen?
Schilder gab es leider noch nicht in der Demo
Wir hatten zwar die Leuchtblöcke schon vor längerer Zeit auf unserer Trello-Roadmap gezeigt (und ich glaube in dem Zusammenhang gab es im Forum auch Diskussionen zu Leuchtreklame), aber verwendbar wurden die Leuchtblöcke ja erst mit dem Crafting-Update... vorher gabs da eigentlich nichts direkt...Aber richtige Schilder sind auf jeden Fall geplant
Was Leuchtreklame angeht, da wird natürlich das zukünftige Stromsystem relevant: Damit wird man Leuchtblöcke einzeln ansteuern können (ein-/ausschalten bzw. Farbe oder Helligkeit ändern), sodass man darüber natürlich alle erdenklichen Leuchtsignale, Reklametafeln oder gar Bildschirme erstellen kann
-
So lange der Thread noch offen ist, xd. Ich suche verzweifelt die Einstellung Blaupausen-Umrandung entfernen. Nach dem ich außer Audio und Gamepad alles viermal durchsucht habe und nicht fündig geworden bin.
Unter "Verschiedenes" sehr weit unten, der Punkt heißt "Blaupausen: Abgrenzungen anzeigen"
Wäre der o.g. Befehl auch für die hohlen Zylinder anwendbar? Ich habe es nicht probiert, aber die Logik sagt nun einmal Ja.
Also die Wandstärke lässt sich ja wie gesagt noch nicht ändern, aber mit dem "edit size" Befehl kannst du auch die hohlen Zylinder natürlich entlang ihrer X, Y und Z Achse skalieren.
-
Ich wusste lange Zeit gar nicht, dass das geht (zumal das ja nur mit Commands möglich war)
Es war wie gesagt eher ein unbeabsichtigter Nebeneffekt, aber es stimmt schon, dass sowas trotzdem praktisch wäre Leider in der neuen Version nicht so einfach umzusetzen, da Bauteile ganz anders generiert werden als in der Java Version, aber eine Lösung muss da ja auf jeden Fall her (die indirekt auch anderen Formen zugutekommen würde, zB um die Wandstärke von hohlen Zylindern einzustellen etc). -
I just was wondering is it possible to make blueprints to behave like blocks when it comes to scaling them ?
for example at the moment when you scale them the size changes at all axes X Y Z the same what I would love to see is to have possibility to change each axes individually ( like if I want my wall panels to be X 4 Y 5 Z 0.1 scale but original size is X 5 Y 5 Z 1) would it be possible to do so maybe in a next update Well, unfortunately that would lead to some technical limitations: If a construction element is not aligned straight to the blueprint (e.g. a block placed diagonally), it would be distorted when resizing the blueprint. I've attached an image that illustrates the problem. Our current implementation cannot generate distorted construction elements, it can only resize elements along their local axes. Maybe we will change that in the future, but for now, blueprints can only be resized proportionally
-
That's a good idea, we will add this to the new API
-
Wir werden das mit dem nächsten Update soweit anpassen, dass zumindest über den size Parameter auch die Tiefe bzw. Größe entlang Z veränderbar sein wird
Beim normalen Skalieren müssen wir uns mal Gedanken dazu machen, ob die Tiefe dort auch separat einstellbar sein soll - das würde die Steuerung etwas abändern (momentan ist das bei Fensterrahmen ja wie in der Java Version)...Was die Dicke des Rahmens angeht, so ist das etwas heikler: In der Java Version war das Verhalten, dass der Rahmen dünner wird wenn die Tiefe verändert wird, eher ein Nebeneffekt, der nicht direkt beabsichtigt war. Ich gebe aber zu, dass es Situationen gibt, in denen sowas vorteilhaft sein kann. Wir müssen mal schauen, wie wir das am besten in der neuen Version umsetzen
Bis dahin kannst du aber folgenden Workaround verwenden, um zumindest die Tiefe zu ändern, wenngleich leider etwas umständlich: Platziere ein Fenster mit der gewünschten Breite und Höhe in der Welt und verwende darauf den edit size Befehl mit gewünschter Tiefe (Z). Anschließend kannst du - wenn du einen Fensterrahmen in Händen hälst - beim Betrachten des Rahmens die EINFG Taste drücken, um den Rahmen daran anzupassen.
-
Ich dachte an das ausklappbare Menu, diese Einstellungen, keine Stamina oder Fußspuren.
Ich kann dir leider noch nicht ganz folgen
Meinst du die jeweiligen Einstellungskategorien sollen lediglich ein-/ausklappbar sein? Wenn nicht wäre sonst evtl. eine kleine Skizze via Paint hilfreich Ich meinte Item-Leiste links und Creativ-Leiste rechts (Baumenu?). Ich habe nur Ombiant Occlusion verändert und für einen Screenshot den Pivotmodus? (2. Zeile im Reiter Helligkeit und Gamma) etwas erhöht, aber das ändert sicherlich keine Einstellungen wie aufklappbare Menus.
Kannst du evtl. einen Screenshot davon posten?
Ich möchte nur alle Texturen und Items aufgeklappt sehen, keine andere Leiste.
In dem Spieleinstellungen gibt es die Einstellung "Crafting-Kategorien einklappen" - wenn du die ausschaltest werden die Crafting-Kategorien alle ausgeklappt. Allerdings wird ja der letzte Zustand (ob eingeklappt oder ausgeklappt) nach Beenden des Spiels gespeichert, daher wird diese Einstellung vmtl. in deinem Fall keinen Effekt haben (die hat nur beim erstmaligen Zustand einen Einfluss)... das ist natürlich suboptimal und ich denke es macht Sinn, wenn wir diese Option nochmal überarbeiten (die kam ja rein deutlich bevor der Zustand der Kategorien spielstartübergreifend gespeichert wurde)
Die Anzeigedauer für die Slotleiste wäre mit 20 Sekunden Zeit auch gut. Es gibt wählbar nur 10 Sekunden oder immer.
Das können wir mit dem nächsten Update hinzufügen
Wo finde ich eigentlich die Panoramafotos?
Die findest du im Spielverzeichnis unter "Screenshots/Panorama"
Muss noch immer jedes einzelne Licht separat berechnet werden wie in der Java-Version?
Lichter funktionieren in der neuen Version komplett anders als noch in der Java Version. Dafür muss ich etwas weiter ausholen
In der Java Version wurden Lichter bei der Chunkgenerierung auf der CPU berechnet und dann der Lichtwert für jedes Polygon (genau genommen jeden "Vertex") gespeichert. Wenn ein Bauteil verändert oder eine Lampe platziert wurde, musste das neu berechnet werden. Vorteil war, dass Lichter nach ihrer Berechnung so gut wie keine Performance gekostet haben. Nachteil war, dass die Beleuchtung sehr ungenau und Dinge wie Schatten unmöglich waren (und bei vielen Lichtern sich die Chunkgenerierung verlangsamt hat).
In der neuen Version sind alle Lichter dynamisch, d.h. sie werden im Grunde überwiegend auf der Grafikkarte berechnet, und zwar dynamisch (also fast jeden Frame). Vorteil ist, dass Lichter dadurch wesentlich besser aussehen und ein Vielfaches präziser sind, zudem können Schatten und auch andere Dinge wie Glanz dargestellt werden. Nachteil ist, dass Lichter deutlich teurer sind als in der Java Version.
Die Art und Weise, wie Lichter gerendert werden, ist aber Stand der Technik - es gibt keinen wirklich besseren massentauglichen Ansatz für sowas, zumindest für Spiele wie Rising World, die auch wirklich dynamische Lichter benötigen.
Spiele mit fester Welt (vor allem gänige AAA Titel wie COD oder BF) hingegen berechnen die meisten Lichter & Schatten vor und speichern die Beleuchtungsdaten quasi in Texturen - so kosten Lichter zur Laufzeit so gut wie gar nichts mehr, und sehen spitze aus. In diesen Spielen sind nur wenige Lichter dynamisch, meist welche die sich bewegen (zB Scheinwerfer von Fahrzeugen, Taschenlampen usw) - aber durch diesen Ansatz reden wir meist von höchstens von 2, 3, 4 oder einer handvoll aktiver dynamischer Lichter).
Für RW ist so ein Ansatz logischerweise ungeeignet, da die Spielwelt ja nicht vorgegeben ist, daher müssen sämtliche Lichter dynamisch sein...
Schatten sind übrigens nochmal ein ganz anderes Thema und sind grundsätzlich unabhängig von den Lichtern: Und tatsächlich sind Schatten mit Abstand der teuerste Part in dieser Hinsicht. RW speichert die gerenderten Schatten aber zwischen, wodurch schon viele Ressourcen gespart werden.
In den meisten anderen Spielen, die dynamische Lichter mit Schatten benutzen, gibt es meistens viel strengere Limitierungen. Rust bspw. bietet soweit ich mich entsinne maximal 3 Lichter mit Schatten
-
Prinzipiell kann man sagen, dass 1 Block ca. 0.5 Meter groß ist
-
You first have to craft an empty blueprint in the crafting menu (you can find it in the crafting menu in the "Equipment" category). You can then use it to select an area (similar to how it worked in the Java version) by defining a start and end position (first click defines a start position, another click then defines the end position, and everything between it will be stored in the blueprint). Hold your right mouse button to save the blueprint, this will bring up a dialog where you can set a name and folder for it
-
Das ist mir auch schon aufgefallen, das ist tatsächlich ungewollt
Das wird mit dem nächsten Update behoben -
Jetzt war nach einem Neustart sehr vieles verstellt, Lichtermaximum 100?
Das Lichtermaximum vor dem Update war 50, das haben wir mit dem Blaupausen-Update auf 100 erhöht
Das hieße für mich ich darf 100 Lichter setzen und das wars? Von einer Chunkbegrenzung aus Performancegründen
steht dabei nichts.
Das Limit sagt nur, wieviele Lichter das Spiel gleichzeitig darstellt. Du kannst auch 10000 Lichter platzieren, aber dann werden - wenn 100 eingestellt ist - zB nur 100 Lichter im näheren Umkreis dargestellt.
Noch höhere Limits sind auch für Leistungsstarke PCs heikel, da vor allem die Schatten sehr rechenintensiv sind...
Sowie auf Bauen gehen, (benutze die Taste V) öffnenete sich jetzt links das Inventar und irgendwann die Creativeleiste rechts. (Das habe ich vorher ausgestellt, ich weiß nicht wie
das wieder aktiviert wurde). Habe ich jetzt erneut ausgeschaltet.
Hmm... Kannst du das genauer erläutern?
Also mit Inventar links meinst du den Button zum Inventar (der im Craftingmenü ja links ist)? Welche Creativeleiste rechts meinst du genau? Meinst du zB die Terrain-Werkzeuge (Glätten, Malen etc)?Sandsteintexturen von ID 255 - ID 261 werden überhaupt nicht mehr angezeigt, auch nicht zum Auswählen. Es war heute Mittag schon bei einer anderen Textur der Fall, aber diese
habe ich mir nicht gemerkt.
Danke für den Report, das ist tatsächlich ein Bug! Leider können wir keinen Hotfix mehr rausbringen, daher werden wir das zusammen mit dem nächsten Update beheben
Als "Workaround" bleibt momentan nur, einen Sandsteinblock per Command zu spawnen (zB item block um die Texturauswahl für Blöcke zu öffnen, oder item pnb um auch zusätzlich eine Blockform auszuwählen)
Wenn ich ganz ehrlich bin, bin ich immer am Suchen wo ich etwas verändern kann oder muss, da wäre eine Spalte die nur für diese Einstellung gedacht ist, sehr hilfreich.
Wie meinst du das genau? Mir würde da eine Suchfunktion in den Sinn kommen, aber das klingt nicht nach dem , was du meinst?
-
Das Aufstellen von Objekten auf ungeraden Straßen, Oberfläschen, Böden ist schwierig.
Das Platzieren von Objekten auf Terrain ist tatsächlich noch suboptimal... das muss nochmal angepasst werden. Das ist auf jeden Fall auf unserer Todo-Liste
Das Spiel setzt die Tür auf schrägen Untergrünen mit der Andockfunktion sofort richtig hin. Fixiert man diese aber, um sie in die korrekte Postition zu rücken, wird die Tür wieder schräg.
Ja, das ist allerdings wahr, das müssen wir auf jeden Fall noch ändern.
Diverse Blaupausen Namen wurden / werden nicht mehr korrekt übernommen. Aus Säule wird Sule oder Saule. Dann habe ich einen Fugngerberweg, soll heißen Fußgängerüberweg
, Strae_gefile_ = Straßengefälle, Strae_ = Straße, Strasse, bleibt Straße, aber Straße wird falsch. Dann habe ich noch eine Stra?e schr?g = Straße schräg.Hmm... beziehst du dich auf Java Blaupausen, oder neu erstellte Blaupausen? Java Blaupausen haben leider damals schon im Namen Umlaute nicht korrekt gespeichert, das kann die neue Version leider nicht so eben korrigieren... bei neuen Blaupausen hingegen sollten Umlaute und auch andere Symbole wie 'ß' eigentlich korrekt angezeigt werden, oder fehlen sie da bei dir auch?
Und wie gebe ich meinen Namen "Deirdre" dauerhaft ein, anstatt immer bei Deirdr das E ergänzen zu müssen?
Der Name wird korrekt gespeichert, aber der Tooltip zeigt ihn bei dir ja wie gesagt unvollständig an, weil das fälschlicherweise abgeschnitten wird. Das ist ein Problem in Unity i.V.m diversen Auflösungen, ich kann das Problem aber bisher leider nicht zuverlässig reproduzieren...
-
Wie bekomme ich meine gewünsche Farbe auf den Farbroller? Ist das überhaupt schon möglich?
Dass man darüber direkt eine Farbe frei wählen kann (zumindest im Creative-Mode) ist geplant
Bis dahin ist die einzige "Zusatzfunktion" das von Rüdi angesprochene Adaptieren einer bestehenden Farbe (mit EING, je nach Tastenbelegung) -
Als ich heute zum zweiten Mal Rising World Unity gestartet habe, war mein Inventar komplett leer. Ich bin nicht gestorben, bzw. wüsste keinen Grund warum das passiert ist.
Am besten bei sowas direkt einen Report (Konsole -> "report") senden, nachdem das auftritt, denn dann enthält der Log ggf. noch Hinweise darüber, warum das passiert ist
