Es gab bestimmt einen Log, aber das Spiel behält lediglich den aktuellen und den letzten Log (d.h. wenn du seit dem Vorfall schonmal wieder gespielt hast, ist dieser Log nicht mehr vorhanden) 
Wie gesagt, wenn das Problem nochmal auftritt, idealerweise am besten einfach "report" in die Konsole eingeben - damit wird der aktuelle Log automatisch angehängt 
Posts by red51
-
-
The API in the Java version will still be available and active in the future (because it's part of the game). However, probably it won't get any new features, since every new addition also requires changes to the game...
Having that said, the API for the new version will be very similar to the API in the Java version (except a few minor differences). This means that Java plugins require little to no effort to become compatible with the new version. So if you start working with the Java API now, this definitely wouldn't be a waste of time because the vast majority of your code will still be compatible with the new version (>>this<< is probably the only "breaking" change - if you keep that in mind [which is recommendable even in the Java version anyway], you won't have much trouble to upgrade your plugin to the new version in the future)
-
Hmm... actually the profile is stored in the config file, but apparently the config file isn't covered by the Steam cloud
IIRC the reason for exempting the config file from cloud back then was the idea that different computers probably have different hardware and therefore require different graphics settings (and if the config was stored in cloud, it would always overwrite the config on other machines)...However, once the new version is ready to replace the Java version, we will remove cloud support for the Java version anyway (otherwise it would mess with the cloud data of the new version unfortunately). The new version will also provide more control over Steam cloud, so we will make sure that the profile data will be synced properly
-
Ich dachte jetzt an die Spiegelung des Wassers oder einiger nerer Texturen
Die momentanigen Spiegelungen auf Materialien (oder Pfützen) sind leider relativ eingeschränkt, da nur das gespiegelt werden kann, was auf dem Bildschirm sichtbar ist - es ist quasi so, als würde das Spiel einen Screenshot machen und das als Spiegelbild benutzen (natürlich mit diversen komplizierten Berechnungen dazwischen). Der Vorteil dabei ist, dass das Bild nicht erneut gerendert werden muss, allerdings kann nichts erfasst werden, was auf dem Bildschirm momentan nicht zu sehen ist.
Da für einen richtigen Spiegel aber vor allem auch die Dinge sichtbar sein müssten, die außerhalb des Sichtfelds liegen (zB der Bereich hinter dem Spieler), wäre diese Lösung für Spiegel leider ungeeignet
Es gibt nur zwei wirkliche Lösungen für dieses Problem: Entweder die Szene nochmal aus Sicht des Spiegels rendern (wie oben beschrieben), oder Raytracing. Ersteres bringt aus Performancesicht einige Hürden mit sich, Letzteres ist nur auf aktuelle Hardware beschränkt...
-
Zur Lösung deines Problems könnte man diese char gebunden machen. Oder an die uid binden. Wenn das Projekt von jemand anderem aufgehoben wird, dann ist es entweder nicht nutzbar oder nur eine Normale Blaupause, ohne das er sie platzieren könnte.
Das könnte man tatsächlich so machen. Man müsste dann aber am besten tunlichst darauf achten, dass man die Blaupause nicht versehentlich wegwirft (da man die Rohstoffe ja im Vorfeld zahlen würde) - wäre schon ärgerlich, wenn ich ein Mammutprojekt in einer Blaupause habe und gerade die ganzen Rohstoffe dafür bezahlt habe, diese aber aus Versehen irgendeinen Abgrund runterwerfe
Bei der Idee mit der Baustelle hab ich bedenken. Ich finde es z. B. In forest echt gut. Und bei Gebäuden auch sinnvoll. Aber wir bauen ja auch sehr kleine Dinge. Die findet man dann ja kaum. Und was wäre ne Baustelle für n glas, n Becher oder so.
Bei kleinen Dingen wäre die Baustelle nicht ganz so sinnvoll, aber wie gesagt, wenn man die benötigten Rohstoffe dafür im Inventar hat (was bei einer kleinen Blaupause ja durchaus machbar wäre), würde man die Blaupause direkt platzieren können. Wenn wir bei den jetzigen Stack-Größen von 999 bleiben, dann würde man theoretisch sogar in der Lage sein, auch größere Bauwerke direkt zu platzieren.
Und wie läuft das wenn die Baustelle an einem Ort wäre dann man zwar mit der Blaupause erreicht, durch die Steuerung, aber nicht um das Material einzubauen? Bspw etwas in der Luft, Flugzeug, ne schwebende Stadt, etc.
Solche Situationen könnten tatsächlich etwas fummelig werden... statt einer Baustelle könnte man aber auch quasi erstmal nur eine Vorschau der Blaupause platzieren, mit welcher man dann interagieren und die benötigen Rohstoffe nachträglich einfügen kann
Edit: statt einer Baustelle ne Kiste wäre sicher möglich aber skaliert die mit der Größe der zu setzenden Blaupause?
Es wäre sinnvoll, für kleine Blaupausen eine kleinere Kiste darzustellen (oder aber bei besonders kleinen Blaupausen - zB in der Größe einer Kerze - direkt zu verlangen, dass die Rohstoffe im Inventar sein müssen). Vll ist aber auch die o.g. Variante besser, erst nur die Vorschau des Bauwerkes darzustellen (vll auch nur solange, wie eine Blaupause in der Hand ist) - das würde dann zumindest bei sehr kleinen Blaupausen kein Problem sein.
Wie wäre es wenn man auch Blaupausen in Stufen anfertigen könnte ?
Ich stelle mir das so vor: Ich baue ein Fachwerkhaus, natürlich erst mal nur das ganze Gerüst des Hauses ( 1. Blaupause ) nun geht der Bau weiter und die Außenwände entstehen ( 2. Blaupause ) nach dem Dach die ( 3. Blaupause ) Nun baue ich im Inneren die Wände und lege mich auf die Räume fest ( 4. Blaupause ) Inneneinrichtung wird nun gebaut ( 5. Blaupause )
Hier muss die Blaupause natürlich wissen das sie aus mehreren Etappen besteht und nicht Baumaterialien doppelt genommen werden.
Das wäre auf jeden Fall interessant, aber für das Spiel wäre es schwierig, solche Stufen zu bestimmen
Beim Beispiel des Fachwerkhauses wüsste das Spiel ja nicht, was genau jetzt Gerüst, was Deko und was Wände wären. Beim schrittweisen Platzieren wäre die einzige Lösung also nur, dass das Bauwerk quasi "von unten nach oben" aufgebaut wird - sprich zB werden erst die Bauteile im unteren Bereich der Blaupause erstellt, dann die im mittleren Teil, und zum Schluss die Bauteile im oberen Bereich.Hier könnte man Alternative natürlich auch zb mit einer bestimmten Anzahl an Goldbarren, Diamanten, Rubine die Blaupause bezahlen sag ich mal. Wenn man für die 10000 unterschiedlichen Bauelemente nun 1000 Baren Gold baucht, wäre dies vom Prinzip dann auch recht überschaubar. Außer die Blaupause besteht aus 10000 Goldbarren, hier müsste dann zb automatisch auf Diamanten oder einen anderen Rohstoff gewechselt werden. Die Wertigkeit sollte ungefair eingehalten werden.
Das könnte man evtl. auch machen. Das wäre dann aber vmtl. erst eine Option, wenn es auch NPC Händler im Spiel gibt - denn wohl erst dann wären auch entsprechende Werte für die jeweiligen Baumaterialien definiert.
Ich denke wir sprechen hier aber nur vom Survival. Im Kreativmodus sollte sich bitte nichts ändern.
Ja, im Creative-Mode würde ich alles so belassen wie es ist
-
Dies wäre insgesamt auch sehr Interessant. Jeder denkt ja über die Mengen beim craften anders. Speziel Server könnten hier dann ihr eigenes Ding machen.
Eine Art config-datei wo man die crafting rezepte ändern oder anpassen kann
Das wäre generell tatsächlich sehr praktisch. Wir müssen uns da mal einen sinnvollen Weg überlegen, wie solche Informationen am besten angelegt werden könnten
-
Auf dem einen Screenshot ist 1 x Texturskalierung 0 und 1 x Texturskalierung 4 zu erkennen. Die Skalierung 0 ist toll, da sie ja einen Braunton erzeugt.
Allerdings ist diese oder die anderen Texturen mit Maserung ansonsten nicht zu verwenden. Ich habe mich in der Java-Version oft geärgert, dass eine schöne Textur
dank dieser Musterung nicht sehr oft einsetzbar war. Es ist wohl die Abgrenzung der einzelnen Bretter, die eine Verarbeitung als normales Textur
schwierig machen.
Bei der blauen Fliese wäre diese rechts, ohne die Muster, wunderschön im Bad oder sonstwo zu verwenden.
Hmm... das Muster bzw. die Maserung ist ja Teil der Textur. Ich weiß leider nicht genau, was du meinst bzw. wie du dir das ungefähr vorgestellt hast. Meinst du damit, dass du gerne bspw. die Fugen bei den Fliesen loswerden möchtest?
In dem Fall bringt uns die Texturskalierung leider nicht weiter (Texturskalierung 0 ist nichts anderes, als wenn du in einem Grafikprogramm die Bildgröße auf 1 Pixel reduzieren würdest - da kann dann nur noch 1 Farbton übrig bleiben). Wenn du Fliesen zB ohne Fugen möchtest, dann müssten das separate, eigenständige Texturen werden
-
Ideal wäre es in dieser Situation, wenn du uns einen Log bzw. einen Report senden könntest
Natürlich nur, wenn das erneut auftritt, denn jetzt würde nichts mehr davon im Log auftauchen 
-
Wäre es möglich das Raster auch auf dem zu bewegenden Balken sehen zu können?
Das können wir anbieten, dann aber als separate Option die standardmäßig deaktiviert ist, da das manchmal etwas irritierend aussehen (das muss dann einmal in den Einstellungen unter "Verschiedenes" aktiviert werden).
Ein Problem ist, dank der wunderbaren Möglichkeit Dinge einzufärben
, die vorher verwendete Farbe wieder zu finden.[...]
Eine Möglichkeit die Farbcodierung zu sehen, wäre sehr hilfreich.
Mit dem nächsten Update wird die Möglichkeit kommen, mit dem Farbpinsel den aktuellen Farbton des betrachteten Bauteils zu übernehmen. Gleichzeitig wird der Farbcode dann auch unten kurz als Nachricht angezeigt
-
-
Grundsätzlich wird die neue Version deutlich umfangreichere Rechte und Einstellmöglichkeiten bzgl. Blaupausen bieten: Da das Spiel jetzt ja weiß, wer welches Bauteil platziert hat, kann auch sehr einfach eine Permission hinzugefügt werden, dass ein Spieler nur Blaupausen von selbstgebauten Elementen anfertigen darf - dadurch können fremde Bauwerke nicht einfach geklaut werden, aber Spieler können ihre eigenen Kreationen sichern. Das ist vermutlich bereits der wichtigste Punkt (bzw. das war die nervigste Einschränkung in der Java Version).
Da pro Area separate Permissions gesetzt werden können (und auch abweichende Permissions pro Spieler), kann ein Admin auch relativ einfach festlegen, dass ein Spieler bspw. nur in der eigenen Area Blaupausen anfertigen (oder platzieren) darf. Durch die Areas ist es auch möglich, dass - wenn gewollt - Gruppenarbeiten gesichert werden können (sprich wenn mehrere Spieler an einem Bauwerk arbeiten).
-Nur eigene Blaupause setzen: ja/nein
Meinst du damit, dass ein Spieler nur seine eigenen Blaupausen (also die, die er selbst angelegt hat) platzieren darf? Das ist ein wenig heikel, denn dadurch könnten Blaupausen aus dem Forum (oder aus einem künftigen Ingame-Browser) nicht mehr platziert werden, was die Freiheit insgesamt deutlich einschränkt
Außerdem könnte dieses Limit einfach umgangen werden, indem der Spieler die fremde Blaupause erst in einer Singleplayer-Welt platziert, und anschließend erneut eine Blaupause davon anlegt.
-Transparenz der Blaupause: zahl
Das sollte vll lieber eine Einstellung in den Spieloptionen sein, damit jeder Spieler das individuell anpassen kann
-Blaupause beschränkt auf Gruppen: Admin;Member
Da die Permissions pro Gruppe angelegt werden können, kann jede Gruppe tatsächlich individuelle Rechte haben. Ein Beispiel-Setup wäre: Gäste dürfen weder Blaupausen erstellen noch platzieren, Member dürfen Blaupausen platzieren und nur Blaupausen von selbstgebauten Sachen anlegen, und Admins dürfen sämtliche Blaupausen anlegen.
-Blaupause craften Material: 5 Goldbarren; 1 Papier
Schwierig, das pro Permission einzustellen
Hier wäre ein universellerer Weg, um Crafting-Rezepte anzupassen, generell wünschenswerter...-Blaupause Maße Länge/Breite anzeigen: ja/nein
Auch das wäre vll lieber eine Einstellung in den Spieloptionen, damit auch das jeder Client für sich ein-/ausschalten kann
Ist es im MS nicht möglich die Blaupausen nur auf das eigene Grundstück zu beschränken. So kann könnte niemand einfach bei anderen Spielern Blueprints machen?!
Ja, auf jeden Fall. Jede Area bzw. jedes Grundstück kann individuelle Permissions haben, einmal eine Grundpermission, die für alle Spieler gilt, und dann noch separate Permissions pro Spieler (typischerweise die "Grundstücksinhaber"): In der Grundpermission könnte dann das Erstellen von Blaupausen verboten, in der individuellen "Eigentümer-Permission" hingegen erlaubt sein.
Vielleicht wäre ein besonderes Gebiet in dem Blaupausen getestet und hingestellt werden können, praktisch. Mit automatischer Löschung nach xx-Stunden oder xxx-Tagen, so dasss kein Admin tätig werden müsste.
Das könnte definitiv mit dem aktuellen Permission-System umgesetzt werden
Was Blaupausen betrifft, sollte auch für die Poster gelten.
Welcher Aspekt genau? Poster werden vom Spiel weitestgehend wie normale Bauteile behandelt. Aber auch da bietet bereits das aktuelle Permission-System grundsätzlich alle relevanten Einstellmöglichkeiten.
Separat hinzukommen wird lediglich eine Permission, ob Poster überhaupt platziert werden dürfen, und voraussichtlich auch eine Maximalauflösung (wie in der Java Version).
ganz ander idee das die leut ihr eigens blaupausen machen könnten 2 bedingungen
1 eigens grundstück2 vom admin einem permit ( zeitlich begrenzte erlaubnis X min blaupausen machen zu können )
Punkt 1 ist auf jeden Fall möglich, zu Punkt 2 müssten wir uns mal Gedanken machen (da wäre evtl. eine Art Command oder so denkbar). Alternativ könnte ein Admin einen Spieler aber auch temporär einer entsprechenden Permission-Gruppe zuweisen (die die nötigen Blaupausen-Rechte hat), und dann nach ein paar Minuten wieder wegnehmen.
Es werden fremde Blaupausen geringfügig verändert oder gefärbt und dann als eigene Kunst ausgegeben. Das war mein Grund keine Blaupausen mehr anzubieten. Ein sehr unschönes Verhalten, aber ein Copyright dafür gibt es ieider nicht. Das Umbeschriften durch das Kopieren der Blueprints sollte auch nicht möglich sein.
Schwierig, sowas zu verhindern... spätestens wenn die Blaupause platziert wurde, geht das Spiel davon aus, dass das Bauwerk dem Spieler gehört. Das ist anders auch nicht zu lösen (sonst müsste das Spiel die UID des Spielers pro Block speichern, was den RAM-Verbrauch massiv nach oben treiben würde, da die UID als Text gespeichert werden muss [da auf manchen Plattformen die UserID auch Zeichen enthalten kann] - ohne einen wirklichen "Vorteil" im Spiel zu bieten).
Auch unabhängig von der technischen Seite ist es immer etwas schwierig, festzustellen, ab wann eine geänderte Blaupause als eigenes Werk zu betrachten wäre. Wenn ich ein Gebäude herunterlade und nur einen Block umfärbe, dann ist das sicherlich nicht gegeben, wenn ich aber einen Stuhl herunterlade und in einer detailreichen Burg platziere, dann wäre eine Blaupause der Burg (inkl. Stuhl) durchaus als eigenes Werk anzusehen
In eindeutigen Fällen (zB Person A veröffentlicht einen Stuhl, und Person B kopiert den Stuhl, malt ihn lediglich etwas an, und gibt es dann als eigene Kreation aus) würden wir die Blaupause löschen (und Wiederholungstäter sonst auch sperren). Bei weniger eindeutigen Fällen sollte sich der betroffene User am besten an den Autor der vermeintlich geklauten Blaupause wenden (oder im Zweifelsfall uns kontaktieren).
a simple not allowing a blueprint to be made in the base permissions of an area in the unity version should be protection enough from other people making blueprints of your builds. While when a player is added to the property, they can be allowed to make blueprints on that property when set to something like friend or owner. This is done in the permissions and set when setting a protected area and adding a player to the area. I believe you can restrict the placement of blueprints the same way.
Yes, this is indeed possible and probably this will be the most common way to handle blueprints. But of course this also works for regular permissions (i.e. one could restrict players to only create blueprints containing blocks that were originally placed by that player), so even a server which does not use any areas gets enough control over blueprints
-
Wenn ich das richtig verstehe geht es dann quasi in erster Linie um die Crafting-Kosten, sprich zum Herstellen der Blaupause (also um sie erstmal nur ins Inventar zu kriegen) muss man die Rohstoffe aufbringen (und kann sie anschließend irgendwo platzieren)? Das wäre ein interessanter Ansatz. Hier wäre ggf. sogar eine eigene Werkbank denkbar (also eine "Blaupausen-Werkbank"), die so eine Kiste bereits integriert hat in welche die notwendigen Rohstoffe reingelegt werden können. "Problematisch" bei dem Ansatz wäre nur, wenn die Blaupause weggeworfen wird und ein anderer Spieler sie aufhebt - von der Logik her müsste er ja dann die Blaupause für mein spezifisches Projekt erhalten, momentan werden Blaupausen aber in der Form nicht mit Spielern synchronisiert. Das wäre aber sicherlich ein lösbares Problem...
Damals war mal geplant, dass im Survival beim Platzieren einer Blaupause zunächst eine Art "Baustelle" erscheint, an welcher dann ebenfalls eine Art Kiste auffindbar wäre. Erst nachdem dann alle benötigen Rohstoffe in diese Kiste gelegt werden, könnte der Bau abgeschlossen werden.
Wenn beim Platzieren der Blaupause hingegen bereits alle Rohstoffe im Inventar vorhanden wären (zB besonders bei kleineren Blaupausen wie Möbelstücke usw), würde die Blaupause direkt platziert (ohne diesen Kisten-Zwischenschritt). Ebenso würde sich das im Creative-Mode verhalten.
Die Frage wäre, welcher Ansatz praktischer wäre
Beim ersten Ansatz (wenn ich ihn denn wirklich korrekt verstanden habe) würde man den "Preis" der Blaupause direkt beim Craften bezahlen, anschließend kann die Blaupause irgendwo sofort platziert werden (oder auch erstmal in eine Kiste für später eingelagert werden). Beim zweiten Ansatz hingegen hat die Blaupause selbst (also das Item) keinen Wert, sondern erst wenn man die Blaupause platzieren will, muss man die Rohstoffe aufbringen (wofür man allerdings beliebig viel Zeit hat und auch andere Spieler könnten dabei helfen). -
Bei den Fliesen könnte man beim Färben derselben die Fugen mit einer andere Farben einfärben. Das geht zwar wie in der Vergangenheit auch, bedeutet aber gleichzeitig mehr Bauteile.
Evtl. ändern wir es langfristig, dass beim Färben von Fliesen bspw. nicht mehr die Fugen mitgefärbt werden, aber mehrere Farben pro Textur (sprich eine andere Farbe für die Fugen als für die Fliesen) wird es wohl in absehbarer Zeit leider erstmal nicht geben
Bis dahin wäre die Variante, mehrere Bauteile zu verwenden wohl die einzige Option... hilfreich sein kann in dieser Hinsicht übrigens evtl. die "Scheiben" Form - nur entsprechend statt Glas mit einer anderen Textur: Anders als Blöcke ist die Scheibe komplett flach und bzgl. der Performance vorteilhafter (da weniger Polygone), und kann daher bspw. verwendet werden, um ein Muster an einer Wand oder dem Boden zu erzeugen (auch praktisch für Straßenmarkierungen usw).Um so eine Scheibe zu erhalten, muss man einfach item pane in die Konsole eingeben (anschließend eine gewünschte Textur auswählen).
Beim Selbsterstellen von Fugen, muss meist auf die 0 Texturskalierung zurückgriffen werden. Diese Skalierung weist aber überhaupt keine Textur mehr auf, sondern ist glatt, so dass man eigentlich jede andere Textur verwenden kann. Es wäre praktisch die Skalierung glatt und zusätzlich einen Reiter mit einer 0 Skalierung mit Textur anzubieten
Texturskalierung 0 kann man sich vorstellen, dass die Textur auf die Größe 0 skaliert wurde - entsprechend wird nur 1 Pixel der Textur verwendet. Viele Texturen ähneln sich bei dieser Skalierung logischerweise (je nach Farbton des 1. Pixels der Textur).
Was meinst du mit "zusätzlichem Reiter mit einer 0 Skalierung"?
Bei den Texturen fehlt noch mehr Auswahl.
In Zukunft werden noch mehr Texturen folgen, da haben wir definitiv noch einiges an Spielraum
Wir müssen uns allerdings erstmal auf ein paar andere Dinge fokussieren, bevor wir uns mehr Texturen widmen können 
-
Beim Anmalen oder Ausbessern von Areal mit dem Terraforming Werkzeug, fällt man trotz kleinstem Radius Bäume in der Umgebung, das heißt das Tool verändert die Pflanzen außerhalb des
Sichtfeldes des Bearbeitungskreises hinaus
*Eigentlich* sollte das nur Bäume betreffen, die keinen Bodenkontakt mehr haben
Momentan wird diese Prüfung bei Änderungen des Terrains für den gesamten Chunk durchgeführt, daher kann es passieren, dass beim Graben eines kleinen Loches ein nahegelegener Baum (sofern innerhalb des Chunks, welche 32x32 Blöcke groß sind) umfällt, sofern er schwebt.Wenn die Bäume aber Bodenkontakt haben und dennoch umkippen, sollte das hingegen nicht sein
Ein späteres Verschieben der Bäume ist zwar möglich, obwohl fixiert, eine Drehung in eine andere Richtung leider nicht mehr. Es wäre sehr praktisch wenn das noch implementiert werden könnte.
Die Drehung sollte auch mit dem edit Befehl möglich sein, geht aber nur im Creative-Mode. Du kannst zB edit rotate (für eine relative Rotation) oder edit setrotation (für eine absolute Rotation) verwenden. Als weitere Parameter dann die Drehung um die X (links/rechts), Y (hoch/runter) und Z Achse (vorwärts/rückwärts). Um den Baum zB zur Seite zu legen, kannst du bspw. edit setrotation 90 0 0 eingeben etc.
Die Möglichkeit Bäume zu minimieren ist toll
, allerdings wäre ein wenig kleiner noch besser, da diese Bäume vorerst reicht wuchtig und nicht gerade als Zimmertanne dienen können.Zumindest sind mit dem edit Befehl beliebig kleine Größen möglich (also edit setsize)
Beim normalen Platzier-Werkzeug (des Setzlings) müssen wir uns die Min- und Max-Größen nochmal genau anschauen. Das Platzieren von Bäumen in dieser Form ist momentan eh eher eine temporäre Lösung
(DIe Hickorybäume, die es bisher gibt, werden ja sofort groß).
Das wird sich ändern sobald Landwirtschaft bzw. richtiges Pflanzenwachsum implementiert ist
Beim Wechseln der Blöcke in einer andere Textur ist mir jetzt mehrmals aufgefallen, dass in der Slotleiste zwar der Block in der gewünschten Textur angezeigt wird, allerdings das Spiel
das noch nicht gemerkt hat und leider noch die vorherige Textur verwendet
Ja, das ist leider noch ein Bug... möglicherweise wird das mit dem nächsten Update behoben.
-
Genau weiß ich es nicht mehr, ich hatte verschiedene Farben ausprobiert, zu viele und der gewünschte Farbton war nie dabei. Auf jeden Fall war meine Tür irgendwie weiß, anstatt blau.
Hmm... leider kann ich das so bisher nicht reproduzieren
In der Java-Version hatten wir Planken oder Woodplanktriangles, die immer auf der gewünschten Ebene liegen blieben und sich beim Bauen nicht ungewollt hochkannt stellen ließen oder in eine sonstige Richtung drehen ließen. Dreiecke auf dem Boden blieb zur weiteren Benutzung brav
auf dem Boden liegen.Wenn ich jetzt mit Dreiecken arbeite, ist leider die Wahl des Untergrundes nicht möglich, d. h. das Dreieck bewegt sich, ungewollt! natürlich, in verschiedene Richungen.
Es sind Formen keine flachen Teile wie in der Java-Version, das ist schon klar.
Es wäre sehr praktisch wenn man für gewisse Bastelarbeiten die Ebene, also waagrecht oder senkrecht, vielleicht auch diagonal, feststellen könnte, so dass ein ungewolltes Herumdrehen gar nicht möglich ist. Fixation auf den Boden, waagrecht, und das Mosaik lässt sich viel einfacher formen, als wenn sich das Bauteil durch eine ungewollte Bewegung in der Achse verschiebt.
Die Wahl und Festlegung der gewünschten Achse würde sicherlich das Bauen erleichtern.
Puhh... sei mir bitte nicht böse, aber ich fürchte, ich habs immernoch nicht verstanden
Ich habe mir das Verhalten des "Dreieck" Blocks mal angeschaut und auf Anhieb keinen großen Unterschied zur dreieckigen Holzplanke in der Java Version festgestellt Sprich ich habe sie dünner gemacht (Shift + Pfeiltaste links), dann auf die Seite gelegt (Bild Auf/Ab), anschließend konnte ich sie mit Pfeiltasten Links/Rechts um die Y-Achse drehen...Ist vll das modulare Andocken aktiv? Oder das Raster? Beides kann nämlich einen Einfluss auf die Ausrichtung und Positionierung des Bauteils haben, was teilweise irritierend sein kann.
Ich weiß allerdings auch nicht, wie man am besten ein Mosaik baut (weder in der neuen noch in der alten Version)
Ideal wäre evtl. ein Video aus der Java Version, die das gewünschte Verhalten zeigt?Allerdings bleibt die Fps trotz HUD bei einem Screenshot sichtbar. Wäre schön, wenn die Schrift dann verschwinden würde.
Das sollte eigentlich nicht sein
Wenn das HUD ausgeschaltet ist, dann sollte überhaupt keine UI auf dem Screenshot auftauchen (weder FPS noch irgendwelche Menüs)... verwendest du die Ingame-Screenshot Funktion? -
Spiegel wären ein nettes Feature, können aber aus Performancesicht etwas problematisch werden (wie yahwho schon erwähnt), da für das Spiegelbild die Umgebung ein zweites Mal gerendert werden muss (statt aus Sicht des Spielers, aus Sicht des Spiegels). Wenn jetzt viele Spiegel in näherer Umgebung vorhanden sind, kann das ein ziemlicher Performancekiller werden
Hier gäbe es zwar durchaus Spielraum für Optimierungen, aber da es mit der Performance dennoch etwas heikel bleibt, würde ich so ein Feature lieber nach hinten schieben -
Was dazu aus meine Erfahrung noch fehlt ist die Möglichkeit eine Farbe zu picken (aufzunehmen)
Achso, das wird im nächsten Update auch drin sein: Wenn die Taste für "An Weltelement anpassen" (standardmäßig EINFG) gedrückt wird während man den Pinsel oder die Farbrolle in der Hand hält, dann wird autom. die Farbe des betrachteten Bauteils übernommen
-
WHEA_UNCORRECTABLE_ERROR deutet tatsächlich auf ein Hardwareproblem hin
Es kann aber auch durch Temperatur- oder Treiberprobleme verursacht werden.Ist Windows denn auf dem neuesten Stand? Ansonsten am besten auch nochmal den neuesten Grafiktreiber installieren (vll idealerweise eine Neuinstallation des Treibers vornehmen).
Es kam zwischendurch übrigens eine Option zum Spiel hinzu, die Framerate zu begrenzen - das kann die Last auf die Komponenten reduzieren. Damit wird ein etwaiges Hardwareproblem zwar nicht gelöst, aber je geringer die Last auf den Komponenten, desto weniger wahrscheinlich ein Absturz (zumindest i.d.R). Der Punkt "Frame Limiter" findet sich in den Grafikeinstellungen. Du könntest die FPS dort evtl. mal auf 60 oder 50 begrenzen (bzw. auf einen geringen Wert als du typischerweise im Spiel erreichst).
-
Zugegebenermaßen passt der Bug ja ganz gut zu Halloween
Es ist aber denoch ein sehr eigenartiges Phänomen
Ich konnte es bei mir leider bisher noch nicht reproduzieren... konntest du es denn bei dir reproduzieren (also wenn du deinen Kollegen aufnimmst)? -
Okeeeey, jetzt habe ich doch mal eine Verständnisfrage. Woher weiß das Spiel, welcher User wohin gebaut hat und dort nicht beeinflussen darf? Der eine baut links vom Berg, der andere rechts davon, der nächste gräbt Tunnel oder baut zusätzliche Berge etc. Die Konvertierung muss dann je nach User woanders wirksam werden.
Das kann ja immer woanders sein, daher ist der einzige Weg, das "einigermaßen" zu konvertieren, dass das Spiel alle bebauten Chunks durchgeht, drumherum jeweils einen ausreichend großen Bereich mit der alten Generierung erstellen, und diesen langsam mit der neuen Generierung verschmelzen. Es ist keine perfekte Lösung, würde aber einigermaßen passen. Ist aber leider ein gewisser Komplexitätsgrad hinter...
Oder langfristig (am Ende der ToDo-Liste) vielleicht sogar zu einem Tutorial-Gebiet werden, um die Steuerung etc zu lernen????
Das wäre eine gute Idee, für sowas wäre der Startbereich der Demo-Welt (mit etwas Anpassung) tatsächlich gut geeignet
Das behalten wir mal im HinterkopfIch habe mal einen Screen von einer alten Welt nach Konvertierung bzw. Biomupdate gefunden. Was bei einer Konvertierung passieren kann. Nicht, dass es passiert, aber was durchaus für eine komplett neue Welt / Karte sprechen würde und solche Vorkommen auch 100% ausgeschlossen werden können.
Ja, alte Welten waren damals nach dem Biom-Update nicht mehr kompatibel. Also genau genommen konnte man sie noch laden (und Gebäude mit Blaupausen sichern), aber die alten Chunks passten nicht mehr ansatzweise mit neu generierten Chunks zusammen - und da das Spiel immer nur die Chunks speichert, die geändert wurden, kam da dieses Durcheinander bei raus. Das haben wir damals in Kauf genommen, weil eine richtige Konvertierung wäre enorm zeitaufwändig gewesen. Manche User haben uns das schon sehr übel genommen, weshalb wir die Welt-Generierung daraufhin in künftigen Updates eher nur noch mit Samthandschuhen angefasst haben (wodurch solche Situationen nicht mehr so in dieser Form auftraten, aber im Gegenzug leider auch diverse Terrain-Updates oder neue Biome auf der Strecke blieben)
Bei der Demo Welt ist wohl davon auszugehen, dass in den meisten Fällen bisher noch nicht so viel gebaut wurde (das war damals beim Biom-Update ja noch anders) - und in den Fällen, in denen bereits viel gebaut wurde, ist es vermutlich "ausreichend", wenn man die Welt einfach wie bisher weiter laden kann und alle bisherigen Chunks noch intakt sind
Diese Riese hast du heute beim Terraforming schon.
Das ist noch etwas anderes: Momentan können offenbar in LOD Bereichen solche Risse auftreten, das liegt aber an einem Bug in der LOD-Generierung. Sobald man sich dem Bereich nähert, sollten diese Risse verschwinden. Dieser Bug ist nervig, sollte aber hoffentlich bald behoben sein (vmtl. im Zuge des Welt-Updates).
Beim Biom-Update damals hingegen haben die Chunks ja vorne und hinten nicht mehr gepasst, und teilweise waren Chunks übereinander usw
We will implement that for the next update (where it will at least affect the time it takes to smelt an ore). Once growing plants and food is implemented, they will also be affected by this setting (or maybe we'll add separate settings for these things).
