Well, basically every plugin needs at least a few minor changes for the new version (due to syntax changes - e.g. we've replaced the "getWorld()" or "getServer()" methods with static "World" and "Server" classes). In most cases this just means a few lines need to be replaced, that will be quite easy, but of course it's up to the plugin author to decide whether or not he wants to support the new version 
Posts by red51
-
-
red51 warscheinlich würde es reichen, wenn es eine Lokale ausrichtung geben würde.
Mann könnte dann einen Block Platzieren, der nicht mit dem Globalen Raster übereinsimmtDas wäre bestimmt ein hilfreiches Feature... müssten wir mal ein wenig mit herumexperimentieren, um zu sehen, ob es in der Praxis genauso gut funktioniert wie in der Theorie
red51 Leuchtet mit ein. Aber wenn ich einen Block mit dem Oberflächentool z. B. nach hinten neige, kann man ja, nimmt dieser Block einen gewissen Winkel an. Sieht wie 45° aus. Das Tool bietet sich da auch wunderbar an. Womit hängt diese Neigung zusammen?
Naja, wenn die Oberfläche nach hinten verschoben wird, dann entsteht ja automatisch eine Neigung
evtl wäre ja ein MT-Block (MultitextureBlock) eine Lösung den man nur verwendet wenn man ihn verschieden einfärben möchte und ansonsten eben die einfarbigen wo es bis jetzt gibt.
Das klingt an sich nicht schlecht, aber aus Performancegründen ist es wichtig, dass jedes Bauelement die selbe Größe im Speicher hat, also der Speicherbedarf vorhersehbar ist. Außerdem wäre es vmtl. auch etwas schwierig, einen separaten Block für sowas zu haben - hier stellt sich auch die Frage, was dann mit anderen Blockformen wäre.
Zu dem Thema Performance tut sich mir auch noch ne Frage auf:
Spielt es eine Rolle, ob ich eine Wand aus einem Block 10 x 6 baue oder aus 60 Blöcken 1 x 1?
1 Block à 10x6 verbraucht wesentlich weniger Resourcen und ist deutlich weniger rechenintensiv als 60 1x1 Blöcke. Ein Block verbraucht im RAM ca. 100 byte, im VRAM ca. 1 kb, besteht aus 24 Vertices und 12 Polygonen - egal wie groß er ist. Jeder Vertex und jedes Polygon kostet "Rechenleistung". In diesem Fall also besteht der einzelne 10x6 Block nur aus 24 Vertices und 12 Polygonen (und verbraucht nur 100 byte im RAM und 1 kb im VRAM), während 60 1x1 Blöcke insgesamt 6 kb im RAM und 60 kb VRAM belegen und aus 1440 Vertices und 720 Polygonen bestehen. Die Größe ist dabei fast egal*
Man muss sich hier allerdings auch nicht verrückt machen: Das Rendering ist weitestgehend optimiert, sodass auch viele Bauteile effizient dargestellt werden können. Man kann ohne Bedenken mit 1x1 großen Blöcken arbeiten. Auch kleine Details sind überhaupt kein Problem. Schwieriger wirds erst, wenn jemand eine 100 m² große Fläche mit 0.01 x 0.01 großen Blöcken ausfüllen möchte - hier fällt die Vielzahl an Bauteilen dann schon deutlich eher ins Gewicht.
Das war in der Java Version grundsätzlich auch so: Je mehr Bauteile verbaut sind, desto teurer wird es.
* streng genommen ist das Rendern eines großen Blockes immernoch teurer als das Rendern eines kleinen Blockes (da ein großer Block mehr Pixel auf dem Bildschirm einnimmt), aber trotzdem weitaus günstiger als die selbe Fläche in kleinen Blöcken zu rendern
-
These are nice suggestions, but we don't want to change the name of the game
One could maybe think about a small suffix, like "Rising World HD" or "Rising World Reworked" (or maybe "Definitive Edition"), but I guess it's a good idea if we just keep the original name for now -
Danke für dein Feedback
Das mit dem Raster haben wir auf dem Schirm, hier arbeiten wir noch an einer passenden Lösung.Dass das Bauen viel länger dauert in der Java Version finde ich etwas komisch, ich hatte eher den Eindruck, dass es anders herum ist
Was genau sorgt dafür, dass es länger dauert? Oder beziehst du dich dabei nur auf das Raster? -
Danke für das Bild Rüdi
Der Fehler besagt leider, dass die Weltdatei nicht mehr gelesen werden kann, sie also möglicherweise beschädigt ist. Leider ist es schwer zu sagen, wie das genau zustandegekommen ist Ein Fehler im Spiel ist grundsätzlich nicht auszuschließen, allerdings ist uns das bisher noch nicht untergekommen 
Es könnte auch ein Hardwareproblem sein, oder u.U. mit einem Antiviren-Programm zusammenhängen (probiere evtl. einmal, das Antiviren-Programm kurzzeitig zu deaktivieren und starte das Spiel dann erneut).Manchmal kann auch ein Rechner-Neustart helfen (wenn bspw. ein anderer Prozess auf die Datei zugreift).
Wenn das nicht hilft, kannst du das Problem lösen, indem du den "Worlds" Ordner im "_New Version" Ordner löschst, allerdings gehen dann bisher gebaute Sachen verloren...
Ansonsten kannst du uns auch ggf. einmal deine Welt zusenden (im _New Version Ordner unter "Worlds"), dann könnten wir evtl. prüfen, was damit nicht in Ordnung ist. Du kannst die Welt zippen und uns entweder per PN senden (falls sie noch nicht zu groß ist), oder via Mail an support@jiw-games.net
-
Das Bauen in der neuen Version macht ziemlich Spaß und geht schnell, jedoch treffe ich oft auf folgendes Problem:
Das ist auf den Bildern leider etwas schwer zu beurteilen... Solche Situationen sehen zwar im ersten Moment manchmal falsch aus, in Wirklichkeit verhält sich das Bauteil dann aber dennoch korrekt
Das tritt normalerweise dann auf, wenn die Drehung des Bauteils nicht ganz zusammenpasst. Oder wenn bspw. die Bauteile anders skaliert sind (zB wenn das untere Bauteil 1 lang und 0.5 breit, das neue Bauteil aber 0.5 lang und 1 breit ist). Teilweise spielt es auch eine Rolle, wenn das Bauteil gespiegelt wurde (mit der ENDE Taste). Aber wie gesagt, das ist anhand der Bilder leider schwer zu beurteilen 
das weiß ich ja ... und eben drum wäre ne andere Tastenbelegung vielleicht besser .... ich probier grad mal, ob man das nicht einfach einstellen kann
Diese Tasten können in den Einstellungen geändert werden
Wir haben uns bei der Standardbelegung weitestgehend an der Java Version orientiert edit: frage mich, wieso es eine Einstellung drehen (halten) gibt, wenn das sowieso vom Modus abhängt, was die Pfeiltasten machen?
Das ist im Grunde auch wie bei der Java Version: Normalerweise ist ja keine Taste für die Drehung notwendig, d.h. die Pfeiltasten drehen direkt das Bauteil, aber im manuellen Modus verschiebt man ja das Bauteil stattdessen mit den Pfeiltasten, daher muss STRG gedrückt gehalten werden um zu Drehen
-
-
But as far as I am aware the next update is for multiplayer capability, at which point world generation will still not be complete. World generation will be the update after the multiplayer one.
Yes indeed, this is the plan
Which will give us an opportunity to maybe play with the new API? Or will it be a multiplayer without any API to start with?
I'm not sure if the API will be available with the first MP update... some important parts are still missing
I am wondering how many world resets new multiplayer servers may need to encounter to start with. . .
We're trying to keep the current world compatible with future versions. After the world generation update, you definitely don't have to worry about world incompatibilities, but it's very likely that the current world will also stay compatible.
-
Unfortunately the vanilla game will not have any options to change the length of night and day independently, you will only be able to change the duration of the whole day. If you want longer days and shorter nights, you will have to use the plugin API
-
Vielen Dank, das sind durchaus sinnvolle Änderungen
.json sollte nun im Forum auch als Anhang akzeptiert sein^^
-
red51 ; Ich nutze die Standaloneversion. Und wenn ich in der Config.properties unter Game_Language nachsehe steht da nichts. Trage ich da German ein passiert nichts ausser das im Game F1 und C nicht mehr funktioniert. Selbst nachdem ich das rückgängig mache funktioniert F1 und C nicht mehr. Hilft nur das Game löschen und neu laden. Trotzdem weiter nur in englischer Ausgabe.
Das ist eigenartig, normalerweise sollte die Sprache damit nichts zutun haben
Wenn das nochmal passieren sollte, evtl. direkt einen Report senden (Konsole öffnen und report eingeben).bei der Deutsch / Englisch Geschichte, fällt mir ein das die Erklärung in der Konsole alle auf Englisch sind, hier wäre in Zukunft auch eine Deutsche Erklärung bestimmt nicht schlecht. Es können ja weit nicht alle eine Fremdsprache
Naja, die Konsole mehrsprachig bereitzustellen ist etwas schwierig, das würde ich lieber etwas nach hinten schieben
Wenn ich einen Block habe und den Winkel verändere, dann mit der Oberflächentool neige, egal welchen Winkel
ich einstelle, der Winkel bleibt immer der gleiche. Ist das Oberflächentool dazu gedacht um lückenlos Teile aneinderzureihen
und sucht sich den besten Winkel dafür automatisch aus?
Ich weiß leider nicht ganz wie du das meinst?
So sieht das bei mir aus, mit Setr 5. weißer Block ohne Oberflächenbearbeitung, links daneben, Oberflächenbearbeitung auch mit Setr 5. Seltsam.
Der setr Befehl sollte auf die Oberflächenbearbeitung eigentlich keinen Einfluss haben (da man die Oberfläche ja nicht drehen kann, aber setr ja nur die Rotationspräzision angibt)
Die neue Version ist eine hervorragende Umsetzung der Möglichkeiten, welche die Unity-Engine bereitstellt, um schnell und effizient ein Bausystem zu integrieren.
Hehe, danke, aber das hat grundsätzlich nicht viel mit der Engine zutun, dasselbe Bausystem hätten wir auch in der Java Version abieten können
Was mir jedoch fehlt ist die fehlende Möglichkeit, Blöcke beidseitig verschiedenartig zu texturieren.
Dieses Thema wurde schon in der Vergangenheit angesprochen mit dem Hinweis, dass auf diese Funktion aufgrund erhöhten Ressourcenbedarfs durch den Arbeitsspeicher verzichtet wurde.
Das ist nachvollziehbar, wobei ich mich frage, ob es dennoch vielleicht möglich wäre, auf allen PC-Konfigurationen eine zufriedenstellende Lösung anzubieten, etwa durch eine optionale Hinzuschaltung in den Einstellungen. Dann könnte jeder das Spiel auf seine Hardware konfigurieren, ähnlich wie bei der Anpassung der Graphikqualität.Wir müssen uns hierzu unbedingt nochmal Gedanken machen... es ist tatsächlich lediglich der etwas höhere RAM Bedarf das Problem. Natürlich wäre sowas immernoch "günstiger", als wenn Bauteile mehrfach verbaut werden
Es als Option anzubieten wäre aber nicht gut, da dann im MP Gebäude u.U. komplett anders aussehen würde, abhängig von der Grafikeinstellung.
Die Ressourcen Frage bei einem Block/Brett zwei Texturen oder zwei Bretter mit unterschiedlichen Texturen ??????? Was jetzt wirklich mehr verbraucht kann wohl nur red51 wissen.
Mehrere Farben auf einem Block (bzw. unterschiedlich gefärbte Seiten) verbrauchen spürbar weniger RAM als zwei Bretter. Es stellt sich nur die Frage, wie oft braucht man wirklich unterschiedlich gefärbte Seiten. Wenn es häufig der Fall ist (oder viele User davon Gebrauch machen würden), dann lohnt es sich auf jeden Fall, wenn es hingegen fast nie der Fall ist, dann lohnt es sich eher weniger...
-
I just noticed that changes made via the altGR function doesn't get saved via preset. Is that intended, red51 ?
I guess it would be a good thing if the surface modifications get stored in a preset... I'll put that on our to-do list
red51 or whoever might know, is water planned for an upcoming release? So far the new RW is looking VERY nice. Thank you.
Yes, water is planned, but unfortuantely we have no ETA for that yet. We'll start working on it some time after the multiplayer and world generation update
-
Kann man hier etwas gegen die monströsen Arme machen?
Ja, es macht absolut Sinn, wenn die Arme bei diesen Bildern ausgeblendet werden
Wir haben die Panorama Funktion lange vor den Händen eingebaut, daher ist das nicht richtig berücksichtigt 
Ändern wir aber mit dem nächsten Update auf jeden Fall.
Die Dateigröße wird auch extrem groß. Theoretisch müsste man vor so einem Bild die Screenshot-Auflösung oder Qualität verringern.
Ich glaube die Bilder werden standardmäßig in 4K gespeichert, du kannst bei dem Befehl hinten dran aber auch eine Wunschauflösung anhängen, zB panorama 1024. Bei solchen Panoramabildern braucht man aber durchaus eine einigermaßen hohe Auflösung, damit es nicht zu schäbig aussieht
-
Rüdi Erstelle dafür vielleicht einen eigenen Thread, und falls eine Fehlermeldung auftritt, evtl. einmal den Inhalt posten, oder uns uns einen Report senden (wenn ein Fehler kommt findet sich unten ein entsprechender Button dafür)
-
Die neue Version ist bisher leider nicht von der Steam Cloud erfasst, d.h. damit wird momentan leider nur der Content der Java Version gesichert
Das wird sich spätestens ändern, sobald die neue Version die Java Version ersetzt.
-
Der Befehl heißt panorama, das erzeugt eine rektangulare Projektion bzw. engl. ein "Equirectangular image", sowas wie das hier: http://paulbourke.net/panorama/sphere2persp/pano4.png
Ich stelle aber gerade fest, dass es Probleme mit MotionBlur gibt und das Bild dadurch verzerrt wird. Das müssen wir fixen. Wenn man so ein Bild also erstellen möchte, sollte man MotionBlur vorher am besten ausschalten
-
red51 Kann leider nicht kopieren.
Was kannst du wo nicht kopieren?
Standardmäßige Richtung auf 2. Wem das nicht gefällt, kann es doch selbst ändern und speichern.
Da dieses Feature neu in den Einstellungen angezeigt wird, muss das doch erst einmal getestet werden. Wenn das später Probleme macht, kann der Standard dann immer noch geändert werden.Das ist ein Argument, vielleicht warten wir hier erstmal ein wenig weiteres Feedback ab
-
Please bear in mind that you will not get these things that easily in a procedurally generated voxel world. This is always the biggest limitation in terms of visual quality and performance
Even though the video does show some basic world modifications like explosions craters , this is not the same as having an actual modifiable world. Worlds like in the vdieo can still be represented by a 2D heightmap, while a world in RW or MC needs a 3D terrain (and having another, additional dimension always makes things a lot more complicated) 
Unreal engine offers some awesome features out of the box though, while Unity does have some serious flaws. Development at Epic is also a lot faster, while Unity progresses at a snails pace (at least in certain areas). And Epic is a game developer (so they actually use their own product under real conditions), which is a big pro, while Unity isn't eating their own dog food.
However, not everything is bad a Unity, especially their latest technologies (especially the HDRP) are very promising. We decided to use Unity for the new version because TextureArrays were not supported by Unreal back then (which is a crucial feature for a game like RW, especially it we want to offer many different construction materials).
We're definitely not going to switch engines again, that wouldn't make much sense, and in fact RW wouldn't benefit that much from Unreal right now. Unreal also has a few downsides (for example their C++ integration, which is quite cumbersome [e.g. you can't just delete a class, instead you have to modify your project files manually] - they really want you to use their blueprint system, but that's definitely not a silver bullet, especially from a programmers point of view). All that glitters is not gold
So for the next few years, Unity is certainly sufficient for RW.
-
Englisch oder Deutsch?
Hast du es ggf. sonst mal mit der Ambient Occlusion ausprobiert, ob das einen Einfluss hat? Wären Blueprints schon drin, würde ich ja um einen Blueprint bitten Kannst du mir ggf. von den obigen Bildern die ganze Version schicken (also nicht nur einen Ausschnitt)? Ist sonst ein wenig schwer in den richtigen Kontext zu setzen. -
Tatsächlich hat SonoBionda das Mysterium durchschaut: Die Größenangabe bei Objekten bezieht sich grundsätzlich auf ihre Ausgangsgröße. D.h. standardmäßig hat jedes Objekt eine Größe von 1 1 1. Oder anders gesagt: Alle Größenangaben sind relativ (sprich eine Größe von 2 heißt quasi nur, dass das Objekt doppelt so groß ist). Streng genommen ist das bei Bauteilen auch so, allerdings ist ihre Referenzgröße auch exakt 1 Block.
Ich gebe zu, dass das durchaus nicht optimal ist... aber andererseits ist es auch schwierig, hier Werte anzugeben, da bei vielen Objekten eher krumme Zahlen bei rumkommen würden. Selbst die Tür hat (gemessen in Blöcken) zwar eine passende Breite und Höhe von 2x4, aber die Dicke beträgt 0.1208...
Wir hätten da im Grunde nur zwei Möglichkeiten: Entweder wir verstecken die Angabe, oder wir zeigen schonungslos die tatächliche Größe an. Letzteres könnte natürlich im ersten Moment irritierend sein, besonders für neue Spieler (sieht ja irgendwie auch falsch aus, wenn überall krumme Zahlen stehen)
Vielleicht könnte man auch ein kleines "x" davorschreiben (also x1 x1 x2), oder mit Prozentangaben arbeiten (also 100% 100% 200%), um zu verdeutlichen, dass es sich hier um relative Werte handelt?
