Hmm... that's weird 
I'm not sure what you mean exactly, so maybe this change was indeed unintended... I will take a closer look at this issue!
Posts by red51
-
-
I guess the proper solution for this would be to make sure that you can't place blueprints for free (so you need the actual resources that would also be required to create the blueprinted elements). In case of the iron rocks, that would be iron ore accordingly, as mentioned by Yarofey
We should make sure to add the resource requirement for survival in the near future, otherwise it's indeed too easy to exploit the game
-
Thanks for your feedback about clouds
I did a building on mountain, below the clouds, no light source and still can see it at low to medium distance. I was hoping the clouds made bit darker and harder to see anything at close range. I know a little more would put a little more stress on graphic cards. Would like to have dense fog with clouds during the day bit more dense/thicker or bit darker or bit of glare as the clouds keep the fog in the area.
It mostly depends on the weather... for example, "overcast" weather has quite dense clouds which should mostly cover buildings behind clouds^^ For the default weather, clouds are indeed not very dense, but increasing the density would block too much sunlight. But we will definitely tweak the clouds a bit more in the future (the same applies to the overall brighness/darkness during nights)
Where I live, we get Tule fog. Hoping the clouds to do or give effects of the Tule fog. I can give a link on it, if you want. 'Tule fog is a low cloud, usually below 2,000 feet'
Could you maybe post an image of that?
However, when getting too close to a cloud, we can't render it with full density, because that would cause lots of artifacts (or more precisely, if we want to make the "cloud fly-through" look better, this would become a lot more expensive in terms of performance) 
-
Kochen wird natürlich erst irgendwann im späteren Verlauf ins Spiel kommen, momentan gibt es da tatsächlich deutlich dringendere Features
Unsere Hauptpriorität ist, die Java Version durch die neue Version zu ersetzen, was circa Ende des Jahres passieren muss. Ich hatte ja in meinem vorletzten Post geschrieben, dass wir uns dem Thema Kochen erst widmen können, wenn die neue Version Fuß gefasst hat.Man kann aber natürlich trotzdem ruhig darüber reden, ist ja erstmal ganz unverbindlich
Es ist durchaus gut, im Vorfeld bereits Vorschläge zu sammeln, dadurch können wir uns umso besser darauf vorbereiten.Brauchst du 3d Modelle? Es würde doch ein icon Bild reichen?
Naja, wir bräuchten da vmtl. durchaus Modelle, da man das Item ja auch in der Welt sehen muss (spätestens beim Verspeisen müsste ja irgendwas sichtbar sein - ist ja sonst unstimmig, wenn wir zwar für das Verspeisen der Rohzutaten Items und Animationen haben, nicht aber für die fertigen Gerichte)
Zur Not könnten ein paar gewitzte bauer hier im forum doch Blaupausen davon bauen und die exportieren?
Vmtl. würden Blaupausen optisch nicht ganz zu den Rohzutaten passen
meine idee war immer eine teller zu haben wo mann 3 sachen drauf machen kann
Das wäre grundsätzlich sinnvoll, vielleicht werden wir das tatsächlich so umzusetzen
Essen gibt es ja schon im Spiel, es fehlen aber noch so viele andere Sachen, mehr Objekte , mehr Türen, mehr Möbel usw.. Ein Survival Spieler möchte fertige Möbel haben und nicht seine eigene Küche bauen müssen
Also die reinen Survival-Spieler sind eigentlich diejenigen, die meist eher ablehnend auf neue Möbel & Co reagieren
Aber es stimmt schon, dass noch viele andere Features fehlen, die wesentlich wichtiger sind als Kochen. Wie gesagt, so eine Sache wie Kochen kann erst reinkommen, wenn die neue Version die Java Version ersetzt hat und dadurch wieder ein bisschen Normalität im Spiel eingekehrt ist^^ -
one thing i noticed while peaking around the .jars is there is no icons for block's. im guessing these icons are created during runtime using model/ texture?
Sorry for the late response, but yeah, the icons for blocks, objects (like furniture) and certain items (e.g. ores) are rendered during runtime, so there is unfortunately no way to access them this way
-
Yes, Metal is the graphics API on Mac (it's a pity that Apple decided to create their own graphics API, instead of just using Vulkan), while the Windows-specific counterpart is DirectX.
You could try to improve the framerate by reducing the graphics settings... either try out the "Medium" or "Low" graphics preset, or alternatively enable/disable individual features (most settings show a tooltip if you move the cursor over them, indicating the estimated performance impact).
The lines are strange though, this seems to be a Metal-specific issue
We couldn't reproduce this issue on our Mac, so maybe this only happens with certain graphics cards or certain MacOS versions... we'll take a closer look at this issue!About the color gamut, unfortunately we have no direct setting for that, but you could try to change the "Saturation" or "Contrast" in the "View adjustment" menu in the graphics settings, maybe that helps
-
It's true that the element doesn't align to the element in the world in case of manual snapping... but I agree that it would be better if the element aligns to the world element... we will change that with the next update
Due to differences in building between versions and this behaviour of custom pivot point some constructions that were easy to build in older versions are now really hard to build as you can't attach element properly
Was this behaviour really different in previous versions?
IIRC the manual pivot snapping always behaved like that... we didn't touch it recently, so if something changed in this regard, that must be a bug. -
Wir werden das mit dem nächsten Update einbauen
Mittelfristig wäre da ggf. eine Option im Radial-Menü vorteilhaft, aber zunächst wird das dann über einen Konsolenbefehl laufen. Ich denke, dass wir das über den edit Befehl lösen werden. Wir möchten das gerne etwas allgemein halten, daher wird es dafür einen eher "technischen" Befehl geben, um "Attribute" eines Elements zu verändern. Der Befehl wird dann ab nächstem Update edit attribute disableobstruction lauten (wenn du das eingibst, während du eine Tür betrachtest, wird diese künftig nicht mehr durch Bauelemente blockiert) -
Ich kann leider noch nicht genau sagen, welche Biome von Anfang an dabei sein werden... Vorbereitungen haben wir schon für einige Biome getroffen, aber wir werden abwägen müssen, zugunsten welcher Biome das Update verzögert werden kann
Das Minimum beim Welt-Update werden natürlich die gemäßigten Biome sein, also Wälder und Wiesen.
Da wir aber sowieso nicht sämtliche geplante Biome ins Update bekommen würden, verlassen wir uns ein wenig darauf, nachträglich welche hinzufügen zu können. Das war in der Java Version sehr problematisch (daher kamen quasi auch nie zusätzliche Biome hinzu), aber in der neuen Version wird das dann so laufen, dass man ganze Inseln zurücksetzen bzw. mit einem neuen Biom neu generieren kann - so können auch künftige Biome in alte Welten integriert werden, ohne, dass diese unendlich weit weg spawnen
-
Avanar Vielen Dank für die sehr ausführlichen Erläuterungen!
Das meiste davon klingt sehr gut und würde das "Kochen-Feature" schon sehr mächtig machen. Wir müssten uns da nur Gedanken machen, wie die fertigen Speisen repräsentiert werden (also die 3D Modelle). Etwas unklar ist auch noch der Grad der Interaktivität, also mit wie wenig UI das ganze auskommt - denn bspw. das Braten von Fleisch wollen wir wieder wie in der Java Version umsetzen (also dass die Stücke in der Spielwelt auf den Grill gelegt werden), da müssen wir dann mal schauen, bis zu welchem Grad man das auch für andere Zubereitungsschritte so umsetzen kann.8. Jedes Nahrungsmittel kann auch als weitere Zutat genutzt werden (egal ob roh oder bereits vorher verarbeitet). Der Multiplikator ist in diesem Fall abhängig vom Basiswert dieser "weiteren Zutat". Z.B. hätten gekochte Kartoffeln +20 Hunger // +5 Durst - werden diese Kartoffeln einem Steak (Basiszutat) hinzugefügt, würden die Werte nicht einfach addiert, sondern der Nahrungswert des Steaks um z.B. *2 und *1,5 erhöht. So sollte das auch schön balanciert sein, damit man kein übermäßig mächtiges Essen zaubern kann.
Hier bin ich mir allerdings nicht sicher, ob es nicht evtl. besser wäre, die Werte tatsächlich einfach zu addieren
Zumindest müsste sichergestellt werden, dass das Gericht "Steak + Kartoffeln" mindestens genauso gut (oder eher besser) ist wie wenn ich das Steak und die Kartoffeln einzeln esse. Dass das Gericht nicht zu "mächtig" wird ist denke ich kein so großes Problem, denn wenn entsprechender Aufwand reingesteckt wird, darf das Essen ja ruhig herausragend gut sein^^Lediglich wenn Speisen bestimmte Buffs geben, zB "Ausdauer wird temporär um 50% über max. erhöht", sollte man natürlich irgendwo eine Obergrenze haben
-
Sowas wäre auf jeden Fall nicht schlecht (und natürlich auch deutlich realistischer)
Das wäre aber etwas, was wir wohl noch nicht in absehbarer Zeit umsetzen können, da dahinter durchaus etwas Aufwand stecken würde (und wir eigentlich auch angepasste Modelle für die jeweils wilden und gezähmten Varianten bräuchten)... das hängt also ein bisschen davon ab, wie es mit der neuen Version generell so weitergeht^^Ein DLC wäre auch durchaus denkbar, sowas könnten wir aber erst veröffentlichen, wenn das Spiel aus Early Access raus ist (sonst könnte das in der Community viel Unmut auslösen)
-
Wenn ich mich nun aber von diesem Fundament entferne, dann schauen trotzdem gut sichtbar wieder die Grashalme durch. Da bin ich höchstens 5 Chunks entfernt. Das finde ich unschön. Ich fänd es grundsätzlich besser, wenn die Grashalme auch aus der Ferne nicht mehr sichtbar wären. Ist das irgendwie lösbar?
Das Problem ist, dass das Gras nicht wirklich entfernt wurde, sondern stattdessen wird es nur ausgeblendet, wenn sich ein Element darüber befindet. Das ist quasi die "Grasverdeckung", die in den Grafikeinstellungen ein- und ausgeschaltet werden kann. Das kann leider nur einen bestimmten Radius um den Spieler herum abdecken - zwar ist der Bereich deutlich größer als in der Java Version, aber leider haben wir da kaum noch Luft nach oben, um ihn zu vergrößern
Die einzige "richtige" Lösung hierbei wäre vmtl., dass beim Platzieren von Bauelementen das Gras an der entsprechenden Stelle dauerhaft entfernt wird (so wie die Java Version es zumindest bei Blöcken gemacht hat). Vorteil wäre, dass das Gras dann wirklich weg ist (unabhängig davon wie weit man davon entfernt ist). Nachteile wären aber, dass Gras immer nur blockweise entfernt werden kann (das würde also nur bei größeren Bauelementen, die annähernd so groß wie ein Block sind) funktionieren, und zudem würde die Stelle auch nach dem Abriss des Bauteils kahl bleiben (wobei das allerdings nicht unrealistisch wäre)...
Einen Vorschlag und Wunsch hätte ich: Warum führt ihr nicht auch einen zentral einstellbaren Sickness Faktor ein. Jedes Nahrungsmittel sollte auch wenigstens minimal auf den Magen drücken und das gleichermaßen. Das würde verhindern, dass ich mir den Bauch mit 100 Tomaten vollschlage anstatt mit nur einem Steak und vielleicht 2 Tomaten.
Grundsätzlich wäre es keine schlechte Idee, dass es noch einen zusätzlichen Statuseffekt gäbe, dass zB der Magen voll ist (wenn man zu viel innerhalb kürzester Zeit isst)
Das ist allerdings vmtl. in erster Linie dann sinnvoll, wenn Nahrungsmittel auch Gesundheit zurückgeben (wie es ja momentan der Fall ist). Wir haben uns generell schonmal überlegt, dass es vll sinnvoller sein könnte, wenn Nahrungsmittel nicht direkt die Gesundheit wiederherstellen, sondern dies automatisch etwas langsamer passiert solange der Spieler einigermaßen satt ist...Ansonsten würde ich aber ggf. auch bevorzugen, wenn besondere Lebensmittel bzw. zubereitete Speisen positive Effekte haben (anstatt dass unzubereitete oder monotone Lebensmittel negative Effekte haben, so wie Desmagu es beschreibt). Das wäre ohnehin Voraussetzung wenn in Zukunft Kochen generell eine größere Rolle spielt: Denn sonst wäre das Kochen ja relativ nutzlos, wenn das Verspeisen der Rohzutaten (fast) genauso gut wäre wie das Verspeisen des aufwändig zubereiteten Gerichts
Offen ist noch, welche Rolle eine abwechslungsreiche Ernährung generell spielen könnte (sodass bspw. die ausschließliche Ernährung von Tomaten Mangelerscheinungen hervorrufen würde). Sowas kann allerdings schnell ein recht umfangreiches Thema werden, daher wäre das wohl erst relevant, wenn die neue Version generell erstmal in trockenen Tüchern ist^^
-
That's still on our to-do list
Unfortunately it didn't make it into the last update, but we try to get it ready for the next one.I also saw that when you paint a wall it paints all sides. Darn. But I can understand why that happens, and why it would be sort of impossible to do otherwise. I guess the solution would be to do double walls. (Like in real life!)
Probably we will implement that feature (i.e. the ability to paint all sides individually), but unfortunately I have no ETA for that yet... for now the only solution would be indeed to use double walls
I saw something called "surface edit" in settings—I wonder what that is?
The surface edit mode allows you to move or resize the upper side of an element individually. This allows you to modify the shape, for instance, you could turn a block into a trapezoid shaped element.
It's, however, a bit tricky to work with that tool - and it may be a bit confusing at first. Once the surface edit mode is enabled, the affected side of the element will be colored red. If you now use the arrow keys, you will only move that side (instead of moving the whole block). Using shift + arrow keys resizes that side accordingly (without resizing the rest of the block).
To reset the surface offset/size, press backspace and/or shift + backspace while the surface edit mode is active.
-
Yes, that's possible with the GameImageInformation object (which is derived from ImageInformation). It can be used to reference game textures or icons. Using it is a bit tricky though, because you need to provide the "path" to the game image. By default it tries to look for a "texture" in the "textures.jar" (which is located in "Rising World/data/assets/"), but if you add "Interface/" at the beginning of the path, it looks for the image in the "interface.jar".
For example, to use the pickaxe icon (which is located in the "interface.jar" under "Interface/Icons/Items/", the file name is "pickaxe_0.png"), the code could look like this:
-
Thanks for your feedback MommaT , I'm glad to hear you like it so far
I am still struggling with the X Y Z resizing of building materials—though I hope to figure it out. I just have not been about to get things to scale reliably on ALL three axises.
Are you struggling with the key bindings, or with finding out the actual direction behind "X", "Y" and "Z"?
I wonder if we will see seeds from the flowers in future?
Yes, that's planned
-
Thanks for the log! Unfortunately it doesn't contain any information about what went wrong, but it looks like it gets stuck when initializing the Steam API (that's when you run into the "red screen")
One thing you could maybe try is to launch the new version directly (from the game directory, i.e. not from the Steam library). Does that work?
-
When starting the dedicated server, this is the internal Steam ID of the server that was assigned to the server by Steam. If the server has no Steam ID (i.e. ID 0), the SteamID64 base number is printed (which is 76561197960265728).
You can ignore this output
It's not related to the Steam ID of your account or the admin settings. -
Das Texturewerkzeug F5 funktoniert seit dem Update nicht mehr richtig. Es braucht xxx Anläufe bis ich damit mal Erde entfernen kann. Terrainbearbeitung ist genauso langsam. Dass das Tool jetzt schneller wäre, konnte ich bisher nur einmal kurz feststellen. Report ging nicht.
Mit "schnellerer Terrainbearbeitung" bezogen wir uns auf die Dauer, die es braucht, bis die Terrain-Bearbeitung in der Welt umgesetzt wurde (also wie lange es dauert, bis das Spiel die Chunks aktualisiert hat).
Die Bedienung des Terrain-Tools ist unabhängig davon. Hier gibt es ein kleines Problem, dass beim Einschalten des Terrain-Tools (oder beim Ändern des Modus) das Werkzeug 1 Sekunde lang nicht bedient werden kann, sprich nachdem man F5 drückt und einen der Modi aktiviert (1-3) muss man leider 1 Sekunde warten, bevor man loslegen kann. Das werden wir mit dem nächsten Update ändern.
Wenn das Tool ansonsten bei dir "langsam" arbeitet kannst du prüfen, ob du ggf. das "Durchgehende Bearbeiten" deaktiviert hat - mit STRG Rechts kann das umgeschaltet werden.
Report ging nicht.
Danke für den Hinweis! Das passiert leider, wenn der Anhang zu groß ist (> 10 MB). Die Größe des angehängten Screenshots orientiert sich an der eingestellten Auflösung, was bei Auflösungen > 1080p die Bilder leider recht groß werden lässt. Wir werden das mit dem nächsten Update insoweit ändern, dass sichergestellt wird, dass das angehängte Bild klein genug ist
Das Vorschaubild einer Textur in der Slotleiste ändert sich nach dem Ändern der Form über Rechtsklick nicht mehr.
Du könntest ggf. einmal den "Cache" Order im Spielverzeichnis löschen (also im "_New Version" Unterordner) und prüfen, ob das Problem dann immernoch besteht.
Vielleicht kann der gute red51 noch was ergänzen oder eine aktuelle Liste veröffentlichen für die Shape befehle
Anbei eine Liste aller Namen der Construction-Elemente
-
Wäre es eigentlich technisch irgendwie umsetzbar, dass Blätter über Zeit langsam von grün auf gelb wechseln könnten? Also mit einer Art Farbschicht? Damit könnte man immerhin verhindern, von fast allen Bäumen Herbst-Duplikate anzulegen
Ja auf jeden Fall, grundsätzlich ist das auch bereits drin, wird allerdings momentan nur dafür verwendet, um ein ganz kleines bisschen Variation unter den Bäumen reinzubekommen (je nach Position des Baums ist der Farbton geringfügig anders)
Diese Mechanik wäre dann aber für Herbstbäume auf jeden Fall geeignet -
Wäre es irgendwann einmal möglich die Intensität von Nebel oder Schnee zu verringern oder anzupassen? Ich finde die Effekte zwar sehr gut, aber für Screenshots ist ein undurchsichtiger Nebel leider nicht so geeignet. Das ist nämlich schon Sichtweite unter 50 m.
Also der sauberste Weg wäre, beim Nebel noch einen 3. Wetter-Typ (quasi "schwacher Nebel") einzubauen. Momentan gibt es ja "fog" (normaler Nebel) und "densefog" (sehr dichter Nebel), der weitere Typ wäre dann vmtl. "lightfog" oder so.
Beim Schnee gibt es bereits neben "snow" (normaler Schneefall) und "heavysnow" (starker Schneefall) noch "lightsnow" (schwacher Schneefall), das könntest du ggf. mal probieren (also mit dem Befehl "weather lightsnow 1"). Die Schneemenge auf dem Boden kann mit "setsnowiness 0-1" geändert werden (das ändert sich aber je nach Wettereffekt weiterhin).
Alternativ können aber auch alle Wettereffekte manuell bearbeitet werden in der definitions.db (im Ordner "/Data/StreamingAssets", die Datei muss mit einem SQL Editor geöffnet werden, die gesuchte Tabelle dort heißt "weather"): Dort kann pro Wettereffekt alles erdenkliche eingestellt werden (Nebelstärke und -farbe, Wolkendichte und -höhe, Sonnenintensität usw). Der User paulevs hat damit schonmal herumexperimentiert: Custom Weather (Experiments)
