Soweit so gut, die Treppen sind weg aber jetzt hab ich so ein komisches leichtes flackern, sieht man am besten beim gewehr.
Verwendest du FXAA oder SMAA? Evtl. kannst du einmal ein Bild von dem Flackern posten (falls man es darauf erkennen kann). Ansonsten evtl. einen anderen Anti-Aliasing-Modus ausprobieren (oder im Falle von SMAA die Qualitätsstufe dafür ändern)
CedarMan Does that mean you run in offline mode, i.e. with no active internet connection? Maybe send us the latest log file. To get to the logs folder, press Windows key + R and enter %APPDATA%/../LocalLow/JIW-Games/Rising World. There should be a "Player.log" file, please upload it here (or send it via PN to me or via mail to support@jiw-games.net) 
aww... i hoped these movable blocks would work along with electrification, pistons, etc. i hope though there will be something similar then
Hehe, well, we do have some plans for a few moving things, but I can probably say more about that once electricity is implemented 
-Die Spieler Figur geht zu schnell und zu trocken in die hocke, in rl geht ja auch nicht so schnell. Vielleicht könnte man bei der hälfte schnell machen aber dann wenn er mehr in die hocke geht wird er bisschen langsamer.
Achso 
Da müssen wir mal schauen, ob wir das künstlich etwas verlangsamen können.
Hmm schade
hoffe das Unity das in Zukunft auch haben wird
Mal abwarten, wie Nanite und Lumen von Unreal wirklich werden, sehen aber zugegebenermaßen extrem vielversprechend aus... ich finde es auch schade, dass Unity sich nicht zu dem Thema äußert 
Man sieht am holz oder an der Gießkanne solche kleine stufen und es sieht nicht wirklich glatt aus.
Achso, dieser Treppeneffekt ist "Aliasing" Das kannst du verhindern, indem du "Anti-Aliasing" in den Grafikeinstellungen aktivierst. Entweder wählst du dort - wenn du es dir performancemäßig leisten kannst - SMAA aus, oder FXAA (das hat so gut wie keinen Einfluss auf die Performance).
Ne die Ausdauer ist eigentlich perfekt, nur müsste er am ende bisschen langsamer werden und laute Atem Geräusche von sich geben. Es würde für mehr Realismus ins spiel rein bringen, meine Meinung.
Achso, da stimme ich zu, das packe ich mal auf unsere Liste
Es sollte so aussehen tut es auch von nah aber wenn ich bisschen weg fliege sieht es so aus.
Oh verstehe. Naja das ist leider wie in der Java Version: Die LOD-Chunks (die die weiter weg sind) zeigen nur eine grobe Repräsentation des Terrains und können keine Überhänge oder Höhlen darstellen 
Das kannst du nur verhindern, wenn du die "Sichtweite Details" höher stellst - kostet aber leider entsprechend Performance...
Bei mir ist das so hab das spiel bei Steam gekauft und wolte mal die neue Version ausprobieren leider ist da was furchtbares pasiert jetzt kann ich weder die alte noch die neue version mehr geamen, jedes mal wen ich das game starte ladt es ein update herunter ich instaliere es und das game startet nicht mehr und bei steam in der Bibliothek kannn man so viel rechts klicken wie man will halt so wies in der beschreibung erklärt wird es passsiert halt nichts leider
Das tut mir Leid zu hören Ist denn der Beta-Branch noch ausgewählt in Steam? Bzw. steht [unity] neben Rising World (in der Steam Bibliothek)?
Überprüfe am besten mal die Spieldateien, gehe dazu mit Rechtsklick auf Rising World in Steam -> Eigenschaften -> Lokale Dateien -> Spieldateien auf Fehler überprüfen. Wenn er abgeschlossen ist, wird er fehlerhafte Dateien erneut herunterladen.
Ansonsten wenn sich Steam verschluckt hat am besten Steam neustarten, oder ggf. sogar den Rechner einmal neustarten.
Wenn du im Nachhin etwas färbst, hat eine Planke/Balken, von der Seite gesehen, eine andere Farbe als die Front, das sähe sehr unschön aus, Auf der anderen Seite sehen die Innenwände von Häusern meistens anders aus als draußen. Tapete oder anders gestrichen. Wie ist das eigentlich mit der kompletten Umfärberei von Blueprints oder Häusern, Bauteilen. Mit der Rolle würde das Jahre dauern.
Wie wäre es mit einer Möglichkeit, Beispiel Blueprint-Editor und für existierende Sachen eine Markierung im Sinne von F6 und dann das komplette Teil einzufärben?
Guter Punkt. Hätte definitiv seine Vor- und Nachteile... was das Einfärben geht: Standardmäßig werden Bauteile in Blueprints mit ihrer derzeitigen Farbe gespeichert. Für das großflächige Umfärben müssten wir uns mal Gedanken machen, wie wir das am besten umsetzen. Kann ich momentan leider noch nicht viel zu sagen 
Wäre es denn möglich 2 gleich effektive Spitzhacken einzufügen, also eine für kleine Löcher (Java) und eine Für große Löcher (unity). Oder eine sekundärfunktion für die Spitzhacke (wechsel von kleinen Löcher auf große und anders herum), oder die spitze Spitzhacke für kleine, und eine mit diesem Meißelkopf für große Löcher. Es muss doch eine Lösung für beide Seiten geben.
Naja, so viel kleiner waren die Löcher bei Java ja nicht, da könnte eine separate Spitzhacke für sowas evtl. irritierend sein 
Über eine Sekundärfunktion könnte man hingegen nachdenken - aber auch das könnte evtl. irritierend sein, wenn beide Tasten zwar ähnlich große Löcher produzieren, das andere Loch aber *irgendwie* immer etwas anders aussieht 
Ist wirklich ein schwieriges Thema... ich glaube wir müssen erstmal unseren Kopf dafür etwas frei bekommen 
Vielleicht melden sich ja noch ein paar weitere Spieler zu Wort, wie sie das sehen, oder evtl. wäre es wirklich sinnvoll, das in unsere nächste Umfrage mit aufzunehmen 
Jebblue Thanks for the log! Indeed Vulkan runs out of VRAM which is the reason for this crash - unfortunately the Linux version is quite VRAM hungry and - unlike Unitys DirectX 11 or Metal implementation - suffers from memory leaks apparently. I'm pretty sure that's a bug in Unitys Vulkan implementation (but this could also be related to the HDRP). For this reason we've raised our minimum requirement to 2 GB VRAM some time ago.
Only thing you could do is reduce the graphics settings. If you can make it to the graphics settings, you can change them there (select the "low" preset or maybe "medium"). If the game crashes earlier, open the config.properties file in the _New Version folder with a text editor and set "Graphic_ShadowsEnabled" to false and "Graphic_TextureQuality" to 0, then save the file. That should be enough to run the game without getting an OOM crash.
I'm still frustrated/annoyed I can't record this game for youtube while certain other people can.
Oh, that's a pity, why doesn't it work? 
What recording do you use?
Ok so I downloaded it and got it working on the laptop, copied the files across to my desktop PC which I think is meant to be okay and work but it gives me an error about login details I think. Yet everything is correct as I copied it directly from my laptop. ;/
Yes you can put it on any machine (as long as it has an internet connection, which is obviously required to download the files^^). What kind of error do you get exactly? Make sure to enter your serial and also make sure there are no unwanted or hidden symbols in the text you've copied (spaces, line breaks etc). Alternatively you can always find our serial here: https://shop.rising-world.net/license-list/
On Tuesday, I received my new M1 Mac mini, and here I am on Saturday playing your playable version of RW. With six pages of comments, I have no idea if someone else tried it on the new Macs, but it's truly amazing. Excellent graphics, no lag at all, superb sounds, and overall a lot of fun for the better part of an hour with zero crashes or even hiccups
Wow, thanks for the feedback, glad to hear it runs well so on the new Macs! 
This is the object, where I can see the lines the most. There are other cases like the Lanterns in the mine but there, the lines are barely visible.
Thanks for the screenshot! Indeed there are small lines, although I have to admit that I barely notice them It looks like the uv mapping isn't perfect, we'll take a look at the brazier (and the lanterns)!
Thanks for letting us know MarcosRC ! I have to admit that we have no clue at this stage why there is such an issue with the mouse movement (and movement input in general) on some Linux machines. There was another user who reported the same issue on Kubuntu.
It seems to be caused by Unitys new input system - in fact it's still experimental and far from being solid and battle-proven. In addition to that, Linux unfortunately does not get much love from Unity (at least their newer techologies - SRP, new input system, UI Toolkit etc - are having lots of issues on Linux) 
The problem is that most of Unitys code is black boxed - their source code isn't available. While parts of their new input system are written in C# and therefore available on github though, the native handling is still in their C++ code base (and therefore inaccessible)... as a result, issues like that are mostly out of our control
Is there any other input device connected to your machine? Do you own a gamepad? If you have a gamepad, you could maybe try if the same issues persist with gamepad input (at least xbox and ps4 controllers are supported right now).
Erstmal vielen Dank für das umfangreiche Feedback Freut mich, dass die Wärmeleitpaste doch noch kam
Was mir auffiel schon seit der Java Version ist das die Animation und das Movement nicht wirklich das beste ist. Zum Beispiel kann ich mich bewegen während ich in der Luft bin oder das ich mich so zu sagen in die hocke teleportiere, also keine Animation drin ist.
Naja, das ist ein schwieriges Thema Unsere ursprüngliche Implementation hat etwas mehr Realismus vorgesehen - zB dass der Spieler sich nicht in der Luft bewegen kann. Es fühlte sich aber etwas unpassend für RW an Bei einem richtigen Survival-Spiel wäre das definitiv passender aber bei RW ist es vmtl. schöner, "mehr Kontrolle" zu haben... aber vielleicht macht es Sinn, hier in naher Zukunft eine Umfrage zu starten um herauszufinden, was die Mehrheit bevorzugen würde
Was genau meinst du mit "in die Hocke teleportieren"?
Was das Sprinten an Steigungen angeht: Das müssen wir tatsächlich noch fixen Das hatten wir ursprünglich schon drin, hatte aber noch ein paar Probleme bereitet weshalb wir das für die Demo erstmal wieder deaktiviert haben. Das kommt aber auf wieder rein.
Der Rückstoß für die Kamera ist übrigens auch noch geplant
Was nicht so gut ist, ist das fliegende Gebäude zusehen sind welche aufm Berg erbaut sind, gemeint ist damit wenn ich zu weit entfernt bin das die chunks nicht geladen sind. Man könnte es theoretisch fixen wenn ein "Berg" davor ist, werden die Gebäude so lange nicht geladen bis der Berg selbst geladen ist. aber ich kenn mich in programmieren nicht so gut aus, soll auch nur als ein ein Vorschlag dienen. Zum weiteren habe ich immer sehr starke Frame Drops bei nächsten chunk loading egal ob ich es auf 1 chunk oder auf 50 chunks eingestellt habe.
Das ist momentan nur ein Nebenprodukt der Demo Aktuell sind ja noch keine richtigen Bauelemente drin, d.h. die Gebäude sind eher rein "gehacked" (wenn man es so ausdrücken möchte) 
Nach dem Bau-Update werden Gebäude zwar weiterhin ihre eigene Sichtweiten-Einstellung haben, maximal aber nur soweit sichtbar sein, wie das Terrain sichtbar ist.
Was ein absolutes no go für mich ist, dass geschlossen räume oder höhlen nicht wirklich dunkel werden. Nur bei den höhlen unter Y -40 wird es so langsam stock dunkel, obwohl der Himmel komplett frei ist und die sonne eigentlich rein scheinen sollte
Schwieriges Thema... richtige Dunkelheit wie in der Java Version (zumindest in Höhlen) zu erzielen ist leider nicht so einfach möglich, es sei denn, wir implementieren ein statisches Beleuchtungssystem (wie in der Java Version) - dann würden Lichter aber aufgrund der Limitierungen eines solchen Systems wieder so bescheiden wie in der Java Version aussehen
Das nächste Problem wäre, dass es derzeit keine vernünftige Lösung für Realtime GI gibt (abgesehen von RTX, wobei auch das eher noch in den Kinderschuhen steckt). Die Java Version hatte es noch einigermaßen einfach, da es keine richtigen Schatten gab - dadurch hat sich das Licht recht gleichmäßig verteilt. In der neuen Version wären umso mehr Lichter notwendig, damit wirklich jeder einzelne Schatten verdrängt wird (was bei stockfinsteren Innenräumen nötig wäre) - das ist aber doppelt problematisch, da Lichter nun deutlich "teurer" sind als in der Java Version.
Unterm Strich muss man also sagen, dass vollständig dunkle Innenräume momentan in einer dynamischen Spielwelt wie RW technisch nicht möglich sind (außer - mit diversen Einschränkungen - mit RTX Hardware). Hierbei muss ich betonen, dass sowas natürlich seit Jahren schon in statischen Spielwelten kein Problem darstellt - hier werden diese rechenintensiven Beleuchtungsberechnungen schon beim Compilieren bzw. Builden des Spiels durchgeführt. Aber da die Spielwelt in RW nicht vorbestimmt ist (und man Lichter an jeder beliebigen Stelle platzieren kann) entfällt diese Option.
Unreal hat für Ende 2021 ihr recht vielversprechendes "Lumen" angekündigt (eine Realtime GI Lösung). Unity hüllt sich bisher leider in Stillschweigen...
Die Grafik sieht gut aus aber die Ränder vom ganzen game sehen verpixelt aus, nicht glatt und gerade.
Was genau meinst du damit?
nur würde ich gerne mehr knall auf der Waffe.
Da stimme ich zu
Ich würde sehr gerne das der Spieler sich hinlegen kann, mit Y wie in viele spiele
Das wurde ja schon manchmal vorgeschlagen, schon in der Java Version. In einem Shooter wäre es fast ein Muss, sowas einzubauen. Bei RW bin ich mir noch nicht ganz sicher... wir haben es trotzdem auf unserer "was-wir-in-Erwägung-ziehen-müssen"-Liste.
Oder das der Spieler ein Körper hat und nicht wie ein geist rumfliegt, wenn man nachunten schaut
Das ist geplant, allerdings leider recht aufwändig umzusetzen (da wir in der First-Person etwas andere Animationen als in der Third-Person verwenden).
er kann auch 40 Sekunden durch sprinten ohne schlapp zu werden
Das war eigentlich eine bewusste Entscheidung In der Java Version war das Sprinten deutlich strenger ausgelegt, aber es hatten sich immer wieder mal Leute zu Wort gemeldet, dass die Ausdauer zu schnell aufgebraucht sei, daher haben wir das in der neuen Version etwas großzügiger ausgelegt. Auch hier wäre es vielleicht interessant, etwas mehr Feedback auch von anderen Spielern zu erhalten (vll auch ein Kandidat für die nächste Umfrage^^)
I Love it, wenn man sprintet mit den Händen, dass die Fäuste sich im Bildschirm bewegen. Mehr würde ich es lieben wenn du auch mit den zuschlagen kannst aber das später zum pvp update
Das wäre eine Überlegung wert
Und zum Schluss würde ich mehr Reflektionen sehen Beispiel an den Fenster scheiben, die sehen echt toll aus und ich freue mich auch mehrere Fenster arten zu sehen. aber die fackeln oder eher gesagt das licht reflektiert nicht an der scheibe und alles sieht generell matt aus.
Hier ist leider das gleiche Problem wie oben mit der Beleuchtung: In einer festen Spielwelt können solche Reflektionen im Vorfeld berechnet werden und zur Laufzeit kostengüntig angezeigt werden. In einer Welt wie bei RW (in der nichts vordefiniert ist) kann sowas nur in Echtzeit berechnet werden - was sehr teuer ist. Bei Fenstern müsste die Szene für jede Scheibe zusätzlich gerendert werden - für korrekte Reflektionen sogar 6x pro Scheibe. Man kann sich denken, dass man sich da von Performance verabschieden kann
Wir arbeiten aber an Screenspace Reflections. Das hat zwar auch einen Einfluss auf die Performance, wäre aber tragbar. Das Problem hierbei ist, dass dieser Effekt sehr eingeschränkt ist - es kann nur das gespiegelt werden, was auch auf dem Bildschirm sichtbar ist. Wir hatten hier mal ein Bild davon gepostet: https://trello-attachments.s3.…1d54a828b8c2b4cd7/ssr.jpg
Ich hab heraus gefunden wenn ich auf die maximale höhe baue, wird dort ein Fläche auftauchen die nicht zu ist. Und man theoretisch einfach rein gehen könnte und durch die map fallen was nicht so schön ist. Oder wenn ich ein künstlichen Berg erschaffe wird der schlecht geladen und sieht verzerrt aus in der ferne.
Oh, das sollte tatsächlich nicht sein Das werden wir beheben!
Was meinst du mit "künstlicher Berg sieht verzerrt aus"? 
Danke für das Feedback so weit sowie den Infos zu euren Systemen / Performance!
beim 2 mal anstreichen von sachen (Christbaum) geht das gleich mit 1X rollen ganz in der neuen farbe
Ja, da müssen wir mal schauen, ob wir noch einen schöneren Weg finden Idealerweise würde die 2. Farbe Schrittweise drübergemalt, aber das hätte einen Einfluss auf die Performance für alle Objekte in der Welt (also auch die, die gerade nicht angemalt werden)
Wenn ich die Demo starte, kann ich Feuer an und aus machen, aber sonst nichts ausser rum laufen. Ich habe keine Toolbar in der Mitte. Hab die Grafik ganz nach unten gestellt.
Die Toolbar in der Mitte verschwindet standardmäßig nach kurzer Zeit (und taucht erst wieder auf wenn man das Inventar öffnet [Tab] oder das Item wechselt). Das kann aber in der config umgestellt werden (später auch direkt in den Spieleinstellungen).
Wenn du das Feuer an und aus machen kannst, müsstest du eigentlich auch alle anderen Objekte benutzen können (Türen öffnen etc). In der Demowelt liegen außerdem ein paar Items herum die du aufheben und verwenden kannst
Was die Performance angeht: Deine Hardware müsste eigentlich mit dem Spiel klarkommen Ich habe auch "nur" eine GTX 980 (die zwar schneller als die 970 ist, aber nicht sooo viel schneller) und keine Performance-Probleme soweit auf hohen Einstellungen. Unser Linux-Testsystem hat lediglich eine mickrige NVIDIA GT 1030 (die hat ca. 25% der Leistung einer 970) und einen uralten AMD Phenom II X4 955 (über 10 Jahre alter 4-Kerner), aber auch hier ist es auf niedrigen Einstellungen gut spielbar.
Was für Performanceprobleme hast du denn genau? Mit F9 kannst du dir übrigens die Framerate unten rechts anzeigen lassen.
Damit meinte ich nicht dass der Auto-Hit das Problem sei sondern eigentlich dass man den Stein als Physikalisches Objekt anschlägt (Hit Ton wird abgespielt) obwohl dieser nur noch aus Brocken besteht.
Achso Das ist merkwürdig, eigentlich zerbricht der Stein erst im gleichen Moment Vielleicht wird der Sound irgendwie verzögert abgespielt, das müssen wir nochmal genau überprüfen!
Ich habe auch zwei 4K Monitore laufen und das könnte etwas zu viel sein.
Eine 1070 dürfte damit klarkommen, allerdings muss ich auch sagen, dass die Auflösung in der neuen Version eine wesentlich größere Rolle als in der Java Version spielt - also was Performance angeht.
Beim Vergleich F3 alte und neue Version fehlt mir der Boden bei der neuen. Ich kenne viele IDs mittlerweile auswendig, aber da jetzt neue Texturen dazu kommen, kann solch eine
Information sehr nützlich sein.
In der neuen Version ist das "GroundID" genannt in der Debug-Anzeige Die IDs der Demo sind aber nicht unbedingt final, da noch sehr viele Texturen fehlen, d.h. das wird sich wohl noch ändern.
- Die SET-Befehle funktionieren, nur die neuen Werte sind etwas gewöhnungsbedürftig.
Ja, die neuen set-Befehle orientieren sich nun an Block-Größen (was eigentlich auch viel sinnvoller ist). Sprich setp 1 bewegt ein Objekt in 1-Block Schritten. setp 0.25 in 0.25-Block Schritten usw. Der Vorteil ist nun, dass eine wesentlich höhere Präzision möglich ist (bis in den mm-Bereich).
aber beim ersten antrisch rollt die Rolle mehrmals rauf und runter bis die Farbe komplett deckt
beim übermalen der gleichen Stelle mit anderer Farbe reicht schon ein klick.
Ja, das ist ja auch das, was Ludy angesprochen hat... hier weiß ich leider noch nicht, ob wir da noch eine performante Lösung finden
- Türen Hier fände ich es besser, wenn beim anmalen nur eine Seite die Farbe annehmen würde
Da müssen wir uns mal Gedanken machen Grundsätzlich wäre das möglich, allerdings müsste wir dann für jedes Objekt 2 Farbwerte speichern - d.h. 4 zusätzliche Byte pro Objekt. Das ist an sich erstmal nicht viel, summiert sich aber irgendwann (hier ein paar Bytes, dort ein paar Bytes) Auch würde der Shader etwas komplexer werden, aber das ist vmtl. noch im grünen Bereich... wie gesagt, wir müssen mal schauen
Wo wir gerade davon sprechen: Unsicher sind wir uns noch, ob Bauelemente wie Planken und Balken auf allen Seiten individuelle Farben haben können sollten. Wenn eine Planke nur 1 Farbe haben kann, kostet uns das 4 Bytes. Wenn wir alle Seiten individuell färben wollen, müssten wir 24 Bytes investieren. Bei Millionen von verbauten Teilen kann das schon einen beachtlichen Teil ausmachen 
Fraglich wäre, wie hilfreich das Feature wirklich wäre?
- Setzlinge können noch nicht gesetzt werden oder hab ich da was falsch gemacht
Das geht in der Demo leider noch nicht
Zum Schluss möchte ich euch noch mein kleines neues Haus, was ich in der Demo gebaut habe zeigen
Wow, das ist echt beeindruckend, hammer! 
Die Erstellung von Wegen ist super geworden, eine Möglichkeit Teleports zu setzen, wäre schön.
Teleports kommen auf jeden Fall noch, momentan gibts leider nur den (auch schon aus der Java Version bekannten) Befehl mark und gotomark - leider auch nur temporär, d.h. die Koordinaten verfallen wieder beim Spielstart 
Bei Überfliegen habe ich Grafikfehler entdeckt, die beim Näherkommen verschwinden. Vielleicht ist das ein Fehler in meinem PC, dass zu langsam gerendet wird, keine Ahnung.
Hmm... das ist eigenartig Scheint so, als würde der Chunk nicht geladen Evtl. könntest du einen Report erstellen: Fliege dazu zum kaputten Chunk hin (also so, dass der Grafikfehler sichtbar wird) und gib report in die Konsole ein.
Das Aufheben von Gegenständen dauert nach meinem Empfinden länger als in der Java-Version. Könnte die Dauer nicht für den Kreativmodus verkürzt werden?
Meinst du das aufheben von Objekten wie Möbel usw? Ich denke auch, es wäre sinnvoll, das im Creative-Mode ein wenig zu beschleunigen
Was sind Set-Befehle? setr usw? Den Wert kann man verändern.
Lenko meint sicherlich die setp, setr und setl Befehle.
Weiß niemand wie man baut? Außer Türen und Möbel auseinanderziehen, bin ich bisher nicht weitergekommen.
Leider gibts momentan noch keine Bauelemente, d.h. Möbel sind das einzige, womit man "bauen" kann...
Mir ist aufgefallen, dass die Texturen bei der Skalierung auch skaliert werden. Das sieht bei Brettern z.B. nicht mehr schön aus.
Ja, das ist allerdings nur bei Objekten wie Möbel so. Leider unvermeidlich, da die Objekte nun eigene Texturen haben und richtig UV-gemapped sind. Das ließe sich nur verhindern, wenn wir die Objekte eher wieder im Stil der Java Version halten (also generische Texturen mit wenig Struktur drüberlegen), das wäre aber nicht so schön.
Bei den kommenden Bauteilen werden sich die Texturen wie in der Java version verhalten, d.h. die werden sich nicht mitskalieren
Was mir aber aufgefallen ist das wenn ich den Kamin aus mache das trotzdem noch Rauch aus dem Schornstein kommt ,ist das so gewollt oder wird sich das noch ändern ??
Ja, naja, die Sache ist etwas komplizierter Tatsächlich stammt der Rauch nicht vom Feuer, sondern entspricht dem "Technical Smoke" der Java Version - d.h. beides ist komplett unabhängig voneinander.
In einer festen Spielwelt würde man sowas ganz einfach verhindern (da ja klar wäre, dass der Rauch zum Feuer gehört), aber in RW muss das ja etwas abstrakter gehalten werden.
Wird es später möglich sein, in die Objekte wieder hineinzufliegen bzw. ganz nah an Dinge heranzukommen? Ich finde das für das Bauen sehr wichtig.
Das geht jetzt auch, dafür muss in der config.properties Datei der Wert Game_NoClipping auf true geändert werden
Könnte nicht jeder Spieler es bei sich einstellen, wie groß er abbaut (Java oder Unity) ? Wenn man schon jede Größe beeinflussen kann sollte sowas auch möglich sein.
Da müssten wir uns mal Gedanken machen Das Hauptproblem bei solchen Abweichungen ist immer der Multiplayer - hier müssten eigentlich die gleichen Bedingungen und Regeln für alle Spieler herrschen. Jetzt könnte man zwar argumentieren, dass man es zumindest für den Singleplayer erlauben könnte, aber es ist irgendwo auch unschön, wenn sich das Abbauen im Singleplayer anders verhält als im Multiplayer
Gibt es (oder wird es) eine Möglichkeit (geben) die skalierten Objekte wieder in ihre originale Größe zu setzten, nachdem man es mit der Skalierung etwas übertrieben hat?
Ja, dafür musst du einfach Backspace drücken während du Shift gedrückt hälst
Thanks a lot for your feedback!
Since particles get rotated to your view, you can see them partly through blocks etc. (see the chimney in the hut)
Yeah that's indeed still an issue in the demo, but that will be mostly fixed once the building system is available (yes, that's indeed related to the building system, or more precisely, construction elements)
torches seems to miss the flickering light
Flickering lights would look great on torches, however, in fact there was a reason why we made them a bit more static: We're caching the shadow maps of the torches, so we only have to update them every few seconds (which saves performance). But if a light has this flickering effect, we still need to update the shadows every frame (otherwise shadows move jerkily).
We decided that this effect still makes sense on large fires, like the campfire, fireplace or bonfire. Usually people won't place too many of these objects at the same location, but usually they place lots of torches in their world
the tree texture is one of my main critic points. Imo is there too much brown/ not enough green. The tree itself feels too dark and the leaves are to small
Thanks for the feedback, there is indeed some room for improvements when it comes to this particular tree model.
saving problems (?) The bottles behind the hut disappeared after returning to the main menu once and reload
Yeah that's unfortunately caused by the way how items are currently placed in the world. Actually this feature isn't fully implemented yet, so the items only spawn once in the demo.
This will be "fixed" once the item placing feature is actually implemented
In the menu "Settings" you are able to select multiple things if you select one thing, exit with [Esc] to the game and then go back to the menu (see image "riw_ui_selection"resources)
Oh, thanks for letting us know, we will fix that!
3D objects seems to have black lined boarders
Hmm... could you maybe post a screenshot of that? You can also use the built-in report tool for that (which attaches a screenshot automatically) - just look at an object which has this issue and type "report" into console
I can't zoom while sitting on a chair
Unfortunately zooming is part of the "player movement" (not sure anymore if that even makes sense) which gets disabled when a player interacts with an object (like sitting on a chair)... maybe we will refactor this part!
breaking boulders return no resources
Yes, that's unfortunately not implemented yet (so more or less, it's a limitation of the demo)
trees rotate too much (for my feelings) if you chop them down
We'll try to reduce their angular velocity a bit It's a bit tricky to find a good balance without constraining the physical element too much^^
(again) nearly invisible saplings when in gras
Yeah, that's still on our todo-list
CedarMan Glad to hear you got it working now Just in case someone else who purchased the Standalone is looking for serial serial and/or downloads, here are the direct links:
Licenses: https://shop.rising-world.net/license-list/
Downloads: https://shop.rising-world.net/download-list/
Hehe
4. strange. i have destroyed everything i could so i cant try it out again or probably id have to uninstall the beta branch and reinstall again. but im pretty sure i didn´t hit the closet 7 times and the doors by coincidence an 8th time. i hit the closet maybe 4-5 times and the doors just once. but id have to try again.
That's really strange Unfortunately I wasn't able to reproduce this issue...
1. i can open the locked door to the christmas-tree-room by simply picking up the doors. i guess thats not the purpose of "locking doors"
Oh, yes indeed, I guess it makes sense to prevent people from picking up the door as long as it is locked
2. when i dig under the foundation of your testing area i can see that a part of it is made with wooden texture blocks. these are overlapping the concrete a bit and in this area i can see the same flickering as we currently have in the java-version. will this be fixed/solved until the building update?
If two elements with different textures are placed at exactly the same location (or more precisely, two faces are overlapping), you will always encounter z-fighting (the flickering). This won't change unfortunately, however, render precision is greatly improved in the new version: While in the Java version you still got flickering even if there was a small offset between two faces, this won't happen in most situations in the new version. For example, in the Java version, there were many situations where posters or thin planks placed on top of other elements were flickering - that shouldn't be an issue in the new version anymore.
If you still want overlapping elements (with different textures), just add a slight offset (e.g. 1mm) to avoid z-fighting in the new version*
*in the Java version it was usually necessary to add a much greater offset to avoid flickering
Oh man... i really love these movable blocks, whatever they are
Basically they were just used for some physics tests Nothing too special... they're unfortuantely not related to the electrification of RW
I presume that at some point limitations will be placed as to how far an object can be resized
Yeah, unfortunately most animated objects may look a bit odd if they're resized differently on each axis This can be fixed however, but this requires some additional work per object and we haven't done that yet 
Bei mir wird es leider nichts. CPU 74 %, GPU 100 %. GPU 76 °C.
Die Zahlen sind erstmal soweit absolut unproblematisch Hast du denn Performanceprobleme? Kannst du uns evtl. mitteilen, was für Hardware du genau hast (also CPU, RAM und Grafikkarte)?
My main computer currently has a Core2Duo 6400 (LGA 775). I thought about upgrading but the aren't new CPUs for this socket so I would have to buy an older one or upgrade my motherboard, but then as well I just just assemble a whole new computer. Besides, I would have to get a 64-bit version of Windows and transfer all of the files.
Oh, I'm afraid you won't be able to run the game on that CPU That CPU is 14 years old now, I still went to school when it was released In fact even the Java version struggles with that CPU...
Great job with the physics with those blocks did anyone else run into the hanging block just to watch it swing
not sure if its a thing or it will be separate would this also apply to water as well ie waterfalls with physics??.
Thanks But unfortunately they're not related to water physics For "proper" water physics, we would need thousands or millions of physical mini particles - but that would be way too demanding (in terms of performance), at least if there is more than a small pond in the world. Another problem is that water needs to be persistent - i.e. it's necessary to store the current state of the water and the individual positions of the water particles (and in multiplayer, we have to sync that data). Unfortunately that would be way too much data
My issue is : in windowed mod with my native resolution 3840x2160 I am loosing a part of the bottom screen (half of the squares with f1 etc) and if I change for the under resolution 2560x1600 the screen for the game is little on my 4k tv screen and the square between the - and the x to enlarge a windows is not active
Hmm... is there a reason you want to play in windowed mode (using your native resolution)? Otherwise I'd recommend to use the "fullscreen windowed" mode, this removes the border of the window so everything should be visible (but under the hood it's still a window - you cannot move it though, but you can easily switch to the desktop for example)
Wie lange dauert es bis aus einer grünen Welt eine weiße wird, Spielzeit? Kann diese durch Schlaf oder einen Befehl verkürzt werden?
Das dauert - je nach Wetter - ein paar Minuten. Du kannst alternativ auch den Command setsnowiness 1 eingeben, um sofort alles zugeschneit erscheinen zu lassen
Wie wird das in der Wüste sein? Ich gehe davon aus, dass es nur dort schneien kann, wo das Terrain passt, oder kann es in der Wüste auch schneien?
Vermutlich wird es in der Wüste keinen Schneefall geben
Wir das Straßenpflaster bei Regen nass und bilden sich vielleicht kleine Pfützen in Unebenheiten?
Ich fürchte auch hier wird es leider etwas eingeschränkt bleiben... es ist relativ "teuer", wenn wir prüfen wollen, ob ein Bauteil unter freiem Himmel liegt oder nicht. Gerade Bauteile werden ja teilweise tausendfach oder hunderttausendfach verbaut, das würde die Performance vermutlich endgültig killen
Der Weg ist ja genial geworden, ich hoffe dass Weggestaltung bei uns dann genaus perfekt aussieht.
Der Weg ist nur mit "Bordmitteln" des Spiels angelegt worden, also ja, man wird das auch selber machen können
Wie wird das mit den Blaupausen funktionieren? Heißt das die alten Blueprints unterscheiden sich von den neuen dermaßen, dass sie eine separate Rubrik bekommen müssen? Werden alte Blaupausen automatisch angepasst, wegen neuer Texturen oder hat das manuell zu geschehen?
Ich würde vmtl. bevorzugen die alten Blueprints in eine eigene Sektion zu packen und die Blueprints für die neue Version getrennt zu behandeln. Auch wenn alte Blueprints mit der neuen Version kompatibel bleiben, gibt es ja dennoch sichtbare Unterschiede (andere Texturen usw).
Die neuen Texturen würde das Spiel automatisch auswählen, wir denken aber auch über einen ingame-Blueprint-Editor nach, mit welchem man selber die Texturen austauschen kann.
Die Farbrolle hat mehrere Farben zur Auswahl. Können diese später auch durch Id's vorgegeben werden, denn das Klicken geht bei mir extrem aufs Handgelenk. Wäre es möglich das Färben und Auswählen auf Tasten zu legen, Zusatzoption?
Ja, das können wir auf jeden Fall einbauen
Vor allen dingen hat der Schnee mir gefallen und wie alles weiß wurde.
(Könnt ihr das auch ins RL rein Programmiren?
Hehe, im RL ist dieses Feature leider schon seit einigen Jahren verbuggt und funktioniert nicht richtig...
Das einzige was mich gestört hat war, der Krissel Effekt den ich die ganze zeit hatte und irgendwie nicht ausstellen konnte.
Du kannst dieses leichte Krisseln auch loswerden indem du die config.properties Datei im Spielverzeichnis öffnest (im Unterordner "_New Version") und dort Graphic_FilmGrain auf false änderst
Deirdre hat das jetzt auch nochmal mit angesprochen. Wir wissen ja alle das wir die Blaupausen aus der alten Version mit in die neue nehmen können, wobei es Unterschiede bei der Texture dann geben wird und mit den Objekten war man sich ja noch nicht ganz sicher.
Ja, die Texturen fallen in der neuen Version ja gänzlich anders aus, aber auch die neuen Objekte haben ja nicht mehr viel mit den alten Objekten gemeinsam - daher wäre es wohl einfacher, die Objekte einfach wegzulassen (ich denke in den meisten Fällen geht es den Leuten ja eh darum, dass die Construction Elemente [und evtl. auch das Terrain] übernommen werden)
Ich würde auch die Frage interessant finden ob Blaupausen das auch andersrum benutzt werden können ? Also in der neuen Version gebaut und in der alten aufgestellt !!!
Schwer zu sagen, theoretisch ist das möglich, aber müsste halt entsprechend implementiert werden. Es würde sich nur die Frage stellen, ob sich das lohnt, umzusetzen
Hier sind die 2 Dateien.
Danke für die Logs! Leider geben die Crashes keinen weiteren Aufschluss darüber, was passiert ist... wahrscheinlich ist in dem Fall ein Crash des Grafiktreibers, installiere am besten mal den neuesten Treiber von der AMD Seite. Auch fürchte ich musst du das Spiel bei dieser Grafikkarte auf niedrigste Einstellungen stellen
Habe einen fehler gefunden auch wenn das jammern auf Hohem Nivau ist. HeavySnow wechsel auf HeavyRain crasht das spiel ohne fehlermeldung. Hab es nicht auf 1 gestartet.
Hmm... ich konnte es leider bisher noch nicht reproduzieren, aber schau vielleicht auch einmal, ob du einen Crash Report findest: Drücke dazu Windowstaste + R und gib dort %APPDATA%/../Local/Temp/JIW-Games/Rising World/Crashes ein. Gehe dort in den neuesten Ordner und schicke uns dort die "error.log" und "Player.log" (entweder per PN, oder einen neuen Thread aufmachen, oder per Mail an support@jiw-games.net)
ich freue mich schon ewig auf die neue Version, aber wie kann ich sie runterladen, wenn ich das Spiel gar nicht über Steam, sonderen direkt bei euch gekauft habe? Also nur den Launcher zum starten habe und keine Steambibliothek?
Wie lenko schon sagt, in der Downloadsektion kannst du den Launcher für die neue Version herunterladen Wichtig ist, diesen unbedingt in einen eigenen Ordner zu tun (also nicht bei der Java Version reinpacken, sonst werden Dateien der Java-Version überschrieben).
Ich fände es allerdings auch schön, wenn es schon Konzepte für Langzeitmotivation geben würde - den Grafik alleine mag für ein paar Stunden vielleicht begeistern - aber was mich wirklich an ein Spiel bindet ist Content - das wäre zum Beispiel ein Skill/Perk-system, vielleicht gekoppelt mit einem Währungssystem - gerne mit steigenden Kosten und Open-End. Ehrlich gesagt hätte mir die alte Java-Engine auch gereicht, wenn dort mit ein paar Patches mehr Content eingebaut worden wäre.
Naja, uns war bewusst, dass die Demo keine Langzeitmotivation bieten wird - daher haben wir auch versucht zu beschreiben, dass es eher eine "Tech Demo" wird bzw. ein "Walking Simulator" Die Idee hinter der Demo ist nur, schonmal einen kleinen Einblick in die neue Version zu gewähren. Nicht nur hinsichtlich der neuen Grafik, sondern auch was andere Dinge angeht (Steuerung, Interaktionen mit der Umwelt, Physik usw).
Wir werden nun nach und nach Updates für die neue Version liefern bis diese immer vollwertiger wird. Natürlich wird es etwas dauern, bis der Stand der Java Version erreicht ist, aber schon mit den nächsten Updates (Bausystem usw) wird die neue Version schon spielenswerter. Für die weitere Entwicklung wird auch weiterhin unsere Trello-Roadmap dienen: https://trello.com/b/t5Leypcj/rising-world-development
Yeah unforuntately there is indeed not much we could do about that We're using triplanar texture mapping for the terrain, but this comes to its limitations at strange angles. The only real solution for this would be to increase the resolution of the terrain (i.e. having much smaller voxels), but that would have a big impact on performance
However, we're still looking into ways to improve that in the near future
Oh I see, thanks for the image! Currently UI Toolkit has no built-in support for animations (according to their roadmap, that's planned for late 2021), so unless such an element is available in the vanilla game (in this case we could just expose it), you have to write the animations in code. Problem about the API is that there is currently no hover event - which would be crucial for animations like that. Basically we could add such an event, but I'm not sure if this might cause a bit too much traffic in multiplayer
Nevertheless, it would be still a bit cumbersome to create an animation like that through the API
Maybe things change once UI Toolkit has official animation support. I'm not sure how their implementation will look like, but if they provide a proper way for authoring and loading animations, we could add this feature to the API - in theory
We're also looking for a way to enable plugin creators to create their UI right in Unity (using their new UI Builder, which is specifically made for UI Toolkit - but of course it's also still in preview). Loading .uxml and .uss files during runtime has some restrictions, but if we add such a feature, creating complex UIs would be a much smoother experience compared to creating UIs in the Java version
