Posts by red51

Quote from Deirdre

Der Hunger- und Durstbalken im Kreativmodus hat mich ehrlich gesagt schon immer gestört. Mittlerweile hat man genug Informationen während des Spiels, dass wenigstens, solange der Spieler im Kreativmodus ist, darauf verzichtet werden kann. Im Survival Modus lasse ich mir das gefallen, aber im Kreativmodus ist das doch unnötig.

Das könnten wir evtl. einbauen Dann würde man die von lenko erwähnte Einstellung bzgl. Hunger/Durst natürlich entsprechend mitberücksichtigen.

Quote from Deirdre

Ich wurde nach dem Ausschalten der Bauinformationen links gefragt. Diese würden den Ideenfluss hindern, denn nicht jeder möchte zusätzliche Möglichkeiten nutzen, sondern einfach nur bauen. Manche Spieler sind davon überfordert und wollen nicht näher in die fortschrittliche Bauweise einsteigen.

Diese Anzeige kann ausgeschaltet werden: Dazu müssen in den Spieleinstellungen ("Verschiedenes") unter "Bauen" einfach "Informationen anzeigen" ausgeschaltet werden.

Aber ist die Anzeige wirklich so kompliziert? Die Größenangabe und Rotation mag vll etwas irritierend sein, aber ansonsten wird ja nur angezeigt, ob zB das Raster usw. aktiv ist oder nicht.

Quote from Deirdre

Desweiteren ist diese Leiste zu hell. Sie ist nicht ausschaltbar, bei hellem Licht aber auch kaum sichtbar. Zu 100% nutzbar ist sie oft nicht.

Doch, sie ist ausschaltbar (s.o.). Die Sichtbarkeit haben wir mit dem letzten Update etwas erhöht, weil die Sichtbarkeit zuvor zu gering war.

Quote from Deirdre

Auf V.

Welches Baumenü meinst du denn genau? Das normale Baumenü kann es ja eigentlich nicht sein, da dies nur aktiv ist, wenn ein Bauelement in der Hand ist (hier kann ja also keine Spitzhacke ausgerüstet sein)?

Quote from Deirdre

Leider wird meine vorab eingestellte Rotation in der Config beim Neustart des Spieles nicht übernommen.

Hmm... eigentlich sollte das aber übernommen werden Welchen Wert hast du in der config denn eingetragen? Evtl. kannst du einmal diese Zeile hier posten (oder die config Datei hochladen)?

Quote from Deirdre

Wenn ich mir das Licht der verschiedenen Tageszeiten zwischen Java-Version und Unity-Version vergleiche, gefällt mit das Licht, Sonne und der blaue Himmel in der Java-Version viel besser. Wir haben jetzt zwar Schatten, aber die Morgensonne un 8 Uhr ist nicht mehr da, der Sonnenuntergang ist rot, sehr rot, gut für manche Bilder, erinnert aber eher an den Mars als an die Erde. So sieht die untergehende Sonne in manchen Gebieten aus, aber nicht überall auf der Welt. Irgendwie fehlt der abgeschwächte Teil, der eher an einen Regenbogen, mit Verlaufsoptik erinnert, als an eine Marssonne.

Das ist tatsächlich noch nicht final. Dass der Himmel mit dem letzten Update so rot geworden ist hängt ein wenig mit den kommenden volumetrischen Wolken zusammen - die Art und Weise, wie diese gerendert werden, hat nämlich einen Einfluss auf die finale Farbe des Himmels bzw. des Nebels. Volumetrische Wolken sind momentan leider erstmal deaktiviert (da fehlt zwar nur noch etwas Feinschliff, das wollten wir aber nicht beim Crafting- oder Blaupausen-Update dazwischenschieben), sobald sie aber drin sind, wird sich ein realistischeres Gesamtbild ergeben.

Wir können das Rot auch im nächsten Update schon etwas abschwächen, aber wie gesagt, das Endergebnis wird es wohl erst zusammen mit den volumetrischen Wolken geben

Quote from Sandboxgamer

ich versuche gerade ein eignes Event zu schreiben, das man auch Abbrechen kann.

Nun weiß ich aber nicht, wo man nun abfragt, das das Event Abgebrochen ist, da du ja mal gesagt hast, dass Event, sobald sie abgearbeitet worden sind, verschwinden.

Das kannst du grundsätzlich so machen Auch in der neuen Version dürfte das Konzept von eigenen Events weiterhin funktionieren. Zwar hat die "Event" Klasse dort noch ein paar zusätzliche Funktionen und Variablen, die in dem Fall aber irrelevant sind.

Das "Verschwinden" bzw. "Ungültigwerden" von Events betrifft aber in der neuen Version nur Events, die vom Spiel ausgelöst werden (da existiert nämlich auf nativer Gegenseite auch das Event mit den entsprechenden Daten, wird aber nach Abarbeiten des Event-Aufrufs gelöscht, wodurch dann das Java-Event ungültig wird). Eigene selbstgeschriebene Events sind davon aber nicht betroffen (da diese nur auf Java Seite bestehen), d.h. die kannst du in der neuen Version genauso verwenden wie in der Java Version.

Mit dem "Abbrechen" (also "Cancellable" Events) hängt das aber nicht zusammen: Die Events, die abgebrochen werden (durch einen Aufruf von "setCancelled(true)"), werden auf nativer Seite nicht weiter bearbeitet. Wenn zB das "PlayerDamageEvent" ausgelöst wird und mit einem Aufruf von "setCancelled(true)" abgebrochen wird, dann wird der Spieler auch keinen Schaden bekommen (also dann wird auf Spielseite so getan, als wäre das Event nie ausgelöst worden).

Bei selbstgeschriebenen Events ist das mit dem Abbrechen nur für einen selber relevant. Wie gesagt, das Spiel selbst weiß quasi nichts von selbstgeschriebenen Events (da sie auf nativer bzw. Spielseite nicht existieren), d.h. wenn du es mit "setCancelled(true)" abbrichst, dann ist das nur relevant, wenn du das selber irgendwo prüfst (also via "isCancelled()"). Du hast hier volle Kontrolle

Quote from Sandboxgamer

if (!evt.isCancelled()){ //<---- Ist das so richtig? Oder kommt bei "evt" NULL raus?

Das ist so korrekt. Wenn irgendein Plugin bzw. Listener, welches auf dieses Event lauscht, den Aufruf abgebrochen hat (mit "setCancelled(true)"), dann wirst du das an der Stelle prüfen können (also isCancelled()" wird in dem Fall true zurückgeben).

In diesem Beispiel ist "evt" übrigens niemals null, da du es ja kurz vorher zugewiesen hast (immer, wenn du eine Variable mit "new" zuweist, dann wird sie grundsätzlich niemals null sein danach - es sei denn, du weist irgendwann explizit "null" zu).

Fragen bzgl. SQL bzw. der Datenbankanbindung sind leider noch etwas schwierig zu beantworten In dem Bereich gibts leider noch ein paar Fragezeichen... denn in der neuen Version haben wir uns für die SQLite Anbindung einen eigenen Wrapper geschrieben, dieser bietet aber bei weitem nicht den Funktionsumfang von JDBC bzw. des java.sql Packages (da war das meiste davon nicht brauchen).

Wir haben da momentan zwei Optionen: Entweder wir bieten weiterhin die Xerial JDBC Lib für die API an (das ist die, die auch die Java Version von RW verwendet) - dann ist der volle JDBC-Funktionsumfang gegeben, allerdings können wir keinen Zugriff mehr auf die Weltdatenbank(en) geben. Oder wir bieten eine eigene, teilweise Implementation von JDBC an, was aber viel Aufwand bedeutet... mal sehen...

In deinem konkreten Beispiel allerdings sehe ich keinen Bedarf, mit einem Blob bzw. SerialBlob zu arbeiten. Im Grunde sind diese Objekte lediglich eine Abstraktion für ein byte[] (welches auch so direkt in der Datenbank gespeichert werden kann, ohne, dass man den Umweg über das SerialBlob Objekt gehen müsste). Die eigentliche Serialisierung der ArrayList nimmt in diesem Fall der "ObjectOutputStream" vor, bzw. konkret der "writeObject()" Aufruf - und da das zum Standard-Java-Repertoire gehört, wirst du das auf jeden Fall auch in der neuen Version nutzen können

Quote from Sandboxgamer

wie geht es mit Blueprint-Update voran? Gibt es bereits Neuigkeiten dazu?

Grundsätzlich funktionieren die Blaupausen schon recht gut Es fehlt noch Feinschliff sowie diverse Optionen um Blaupausen zB nachträglich umzubenennen usw. Was aber recht zeitaufwändig ist ist das Herstellen der Kompatibilität mit Java Blaupausen... vor allem auch passende Ersatztexturen für alte Java Blaupausen zu finden. Das ist leider auch noch nicht ganz abgeschlossen... wir können mittlerweile zwar Java-Blaupausen laden, aber die Texturen fehlen noch

Quote from Deirdre

Der angezeigt Winkel von 343° hat mich auch extrem überrascht, denn wenn eine normale Treppe 45° als Aufgang hat und meine flacher ist, dann wäre eher ein Winkel von ca. 60° anzuzeigen.

Naja, wenn du den Block zB um 45° nach vorne kippst, wäre der Winkel entsprechend auch 45°, doch wenn du ihn 45° nach hinten kippst, dann wäre der Winkel 315° (0° ist äquivalent zu 360°, und 360 - 45 = 315°).

Bei 343° wäre also der Winkel 17° (343 + 17 = 360° bzw. 0°), und 17° ist ja deutlich flacher als zB die Treppe mit 45°

Quote from Deirdre

Wäre das mit der o. g. Spielinfo nicht möglich, diese wenigstens 2 oder 3 Zeilen nach oben zu rücken? Oder muss da extra ein Plugin her?

Das Problem beim Verschieben ist immer, dass das Zusammenspiel mit anderen Elementen dann u.U. nicht mehr ganz stimmt... oberhalb der Blockleiste ist ja die Health-Anzeige / Stamina / O2, darüber der F1-Hinweis und dann folgen die Bau-Informationen... wir könnten da lediglich ein paar feste Positionen zur Auswahl anbieten

Quote from Deirdre

Beim Öffnen des Baumenus bewegt sich die Spitzhacke immer ruckartig nach vorne.

Das müsste nicht unbedingt sein. Das passiert nur, wenn die Picke in der Hand gehalten wird.

Welches Baumenü meinst du genau? Auf welche Taste ist es bei dir gelegt?

Quote from Rüdi

Das ist doch schon länger meine Rede. Es nervt wenn man einen Befehl z.B. 50x braucht und ihn dann auch 50x eingeben muss (beim ändern der Textur oder Farben beispielsweise). Es wäre echt eine Erleichterung wenn sich der erste Befehl speichert, so dass man einfach nur noch auf die jeweiligen Bauelemente klickt und der Befehl wird ausgeführt. Erst wenn man einen anderen Befehl eingibt wird der vorherige so zusagen überschrieben.

Oh, das muss in der Vergangenheit wohl leider irgendwie untergegangen sein, sorry Aber es stimmt schon, dass es durchaus sinnvoll ist, dass der letzte Befehl nach mehrmaliger Eingabe hintereinander trotzdem nur 1x in der History auftaucht

Quote from Deirdre

Für mich ist diese Leiste viel viel zu weit unten. Warum könnte diese Anzeige nicht weiter oben stehen direkt unter Größe. Beim Bauen liegt das Augenmerkt eher auf weiter weg, als nach unten zu schauen. Ich finde die Höhe der Leiste furchtbar tief.

Naja, das ist eher so ein Überbleibsel aus der Java Version (dort standen diese Infos ja auch dort unten)... es unterhalb der normalen Rotation anzuzeigen könnte irritierend sein (zumal diese Infos ja bspw. auch bei Objekten angezeigt werden, also wenn man ein Objekt platziert und ein anderes Objekt betrachtet).

Quote from Deirdre

Ich habe das Nachstellen des Winkels versucht, es sieht aber bei mir anders aus, bzw. wie nutzt man das überhaupt?

Der angezeigte Winkel soll 343° sein, das stimmt mit meiner Treppe allerdings überhaupt nicht überein. setr 343 geht nicht, setr 17 auch nicht.

Oh, das ist ein Missverständnis: Das Spiel speichert nicht die jeweiligen Werte, die mal bei setr verwendet wurden (wenn also ein Block mit "setr 10" und 5x drehen platziert wird [=50°], oder ein Block stattdessen mit "setr 25" und 2x drücken platziert wird [auch 50°], sind beide Blöcke logischerweise identisch). Es kommt dem Spiel nur auf die endgültige Rotation an.

Für den setr Befehl spielt natürlich die derzeitig gewählte Rotation bereits eine Rolle. Wenn du in deinem Fall "setr 343" eingibst, und dein Block noch keine Rotation hat (bzw. du die Rotation einmal mit Backspace zurücksetzst), und dann in die richtige Richtung drehst, dann sollte er exakt die korrekte Rotation haben (nämlich 343°). Wenn dein jetziger Block aber zB schonmal um 10° gekippt wurde, und du dann drehst, wird die Rotation natürlich 353° betragen.

Um an ein bestehendes Bauteil anzuknüpfen bietet sich übrigens das modulare Andocken an (aber nur im automatischen Modus).Alternativ kannst du - wenn du dein Bauteil explizit auf die Rotation eines anderen Bauteils anpassen möchtest - auch die EINFG-Taste drücken, während du das Bauteil betrachtest (dann wird zwar auch die Größe übernommen, aber auch die Rotation). Wenn du nur die Rotation übernehmen willst, kannst du sonst auch den Konsolenbefehl rotation benutzen (auf deinem Bild hat das Bauteil eine Rotation von X 343° Y 0° und Z 0° - also wäre der Befehl "rotation 343 0 0").

Um nun einen Bogen nachzubauen (angenommen, die Bauteile wären mit einem Winkel von jeweils 5° platziert), könnte man wie folgt vorgehen: Man vergleicht die Rotation zwischen zwei Bauteilen (bei Bauteil A wäre dann zB eine Rotation von 150° und bei Bauteil B eine Rotation von 155°) und verwendet dann die Diffrenz für setr (also 155-150 = 5°, ergo "setr 5"). Nun passt man sein Bauteil an das erste Element an (entweder über EINFG, oder mit dem "rotation" Befehl, oder mit dem modularen Andocken), platziert es, und dreht nun in den 5° Schritten.

Quote from Deirdre

Das könnte aber negative Folgen haben. Ich halte das für mich, für die beste Lösung, aber für diejenigen die nicht das Bauen als Hauptsinn in Rising World sehen und mit der bisherigen Demo gar nicht bzw. noch nicht zufrieden sind eher weniger. Für neue, ganz neue Spieler gibt es noch zu wenig Content. Den Zeitpunkt die neue Version als Version 1 anzupreisen, würde ich noch ein bisschen nach hinten setzen.

Klar, so meinte ich das auch gar nicht Die Demo jetzt als Hauptspiel zu präsentieren wäre tödlich - da fehlt einfach noch zu viel. Damit wir die Storepage updaten können, müssen mindestens noch die Weltgenerierung, Wasser (zumindest statisch) und auch Tiere im Spiel sein.

Quote from Dark Megatron

Könnte man nicht eine Angabe bei der Charaktererstellung beifügen. Zum Beispiel 3 grobe Größenangeben wie Klein ( größte Figur passt Aufrecht durch 2 Block, Kriechend durch 1,5 Block), Normal (größte Figur passt Aufrecht durch 4 Block, Kriechend durch 3 Block) und Riesig (größte Figur passt Aufrecht durch 8 Block, Kriechend durch 6 Block)?

Ja, das könnte man theoretisch machen, wobei die o.g. Probleme damit ja trotzdem auftreten würden Allerdings würde ich vmtl. bei einer Größenauswahl ohnehin nicht so krasse Unterschiede erlauben (also dass der kleinste Spieler nur 2 Blöcke groß ist, während der größte Spieler 8 Blöcke groß ist) - dann würden die Größenverhältnisse im MP ja vorne und hinten nicht mehr passen Auch im PVP hätte der 2 Block kleine Spieler deutliche Vorteile ggü. einem Riesen. Und auch sonst würde das viele Ungereimtheiten ergeben (zB wären die meisten Items alleine optisch für den Zwerg deutlich zu groß, und für den Riesen deutlich zu klein usw).

Quote from Deirdre

Das würde aber einen Riesenkreis voraussetzen, eine Drehung von nur 1° setzt ein relativ großes Gebäude voraus.

Eine selbst einstellbare Rotation wäre da doch perfekt, da jeder weiß welche Gradzahl er für seinen Kreis verwendet hat.

Nene, ich meinte damit tatsächlich, dass man die Rotation selbst wählen kann. Die 1° waren nur auf den konkreten Fall von lenko in dem Video bezogen

Gutes Argument, das werden wir mit dem nächsten Update ändern

Auch von unserer Seite allen ein frohes und gesundes neues Jahr 2022!

Quote from paulevs

I think if someone will make some sort of macros plugin for Unity (when API will appear) you will be able to make a command set that will give you wooden blocks stack with same parameters as Java planks have

That's a good point: Planks and beams could be implemented through the Plugin API, or more precisely, it's possible to add blocks to the player inventory with a specific size So if someone really prefers to build with planks, a plugin could be used in that case.

Thanks a lot for your kind words Galochka Happy New Year and all the best to you too!

Quote from agiser

Will the ability to place items be added ?

Yes, that's planned Although I have no ETA for it unfortunately...

Oha, da bin ich ehrlich gesagt ein wenig überfragt Ich habe in den letzten Monaten kaum noch mit Netbeans gearbeitet (in der neuen Version arbeiten wir mit Visual Studio, lediglich für den Java-Teil der Plugin API verwenden wir noch Netbeans)...

Du könntest höchstens einmal auf Tools -> Options -> Editor und dort auf den Tab "Formatting" gehen. Stelle sicher, dass in der Kategorie "Tabs and Indents" ein Haken bei "Enable Indentation" gesetzt ist.

Wenn das nicht hilft, könnte es evtl. sein, dass Netbeans nicht erkennt, dass es sich um ein Java Projekt handelt?

Quote from Deirdre

Ein Befehl wie in der Java wäre gut, allerdings ist eine Ansammlung von Häusern bei einem Haus nicht sehr hilfreich. Wäre es möglich dafür einen Code zu benutzen, wo etwas gebaut ist?

Das könnte u.U. sehr viele potenzielle Orte ergeben, wo etwas gebaut wurde Die Frage wäre ja, was das Spiel dazu als Bewertungsgrundlage verwendet. Wenn es einfach nur alle Chunks sind, die bebaut wurden, dann wird das in den meisten Fällen wohl auch schon sehr viele Ergebnisse liefern... aber auch wenn das Spiel zusammenhängende Chunks zusammenfasst, könnte das verfälschte Ergebnisse liefern, wenn zB irgendwo eine lange Straße (die ja typischerweise viele Chunks durchquert) vorhanden ist... Dazu müssten wir uns einmal Gedanken machen, ob man sowas sinnvoll umsetzen kann?

Eine Lösung dafür wäre ja durchaus die Möglichkeit, Teleport-Punkte festzulegen

Also wir werden mit dem nächsten Update auf jeden Fall eine Info-Box im Hauptmenü anzeigen, deren Content wir dynamisch füllen können Allerdings müssen wir uns da natürlich eher auf kurze und bündige Informationen beschränken, wenn wir den User nicht direkt mit einer "Wall-of-Text" begrüßen wollen

Quote from Avanar

red51 Ich meine ein kleines Fenster im Hauptmenü das mit Trello (oder von mir aus auch nur mit einem Thread im Forum oder einfach einer Liste) verbunden ist und auf dem man sehen kann was für die neue Version noch alles geplant ist an Features.

Das einzige Problem dabei könnte sein, dass es möglicherweise schnell unübersichtlich wird Auf Trello befinden sich ja auch sehr viele umfangreiche Informationen, aber da hat man zumindest den ganzen Bildschirm Platz, um sich alles anzuzeigen (mit der Option zu scrollen sowie einzelne Punkte anzuklicken)... wenn das hingegen in einer kleinen Textbox im Hauptmenü untergebracht wird, dann platzt die wohl schnell aus allen Nähten (und selbst "wissbegierige" User würden wohl das Interesse verlieren)...

Eine Art "Mini-Trello" im Spiel anzuzeigen wäre aber hingegen auch mit enormen Aufwand verbunden

Quote from Hintzi

Tatsächlich kann ich da Yaromid verstehen! Wenn ich jetzt einfach nur nach "Rising World" google und nicht aktiv im Forum bin oder ähnliches steht dort einfach nur das das Spiel seit Dezember 2014 veröffentlicht ist. Viele wissen hier nichts von einer zwischenzeitigen Umstellung auf eine neue Version etc. . Hier wäre es sowohl ingame als auch hier im Forum ganz Nice zu sehen wie der Stand der Dinge ist. Trello ist zwar ganz okay aber so wirklich selbsterklärgend finde ich es nicht ^^.

Ja, das ist allerdings wahr... diese Situation ist alles andere als optimal. Aber ich denke, dass die einzige wirkliche Lösung hierfür sein wird, die Storepage auf Steam endlich auf die neue Version zu updaten, sprich dass die neue Version die Hauptversion wird und man da nicht mehr "im Verborgenen" agiert

Quote from Hintzi

Man muss halt auch sagen das Thema Zeit ist heutzutage wichtig, jetzt wurde auf eine neue Engine gewechselt, um den neuen Anforderungen an Grafik etc. gerecht zu werden, jetzt dauert es überspitzt gesagt noch weitere 2 - 3 Jahre bis es fertig ist bis dahin gibt es längt was neues auf dem Markt

Das sind absolut nachvollziehbare Bedenken, aber glücklicherweise ist das relativ "unproblematisch": Dadurch dass wir jetzt eine der "Mainstream-Engines" verwenden, hat man immer die Möglichkeit, auf dem neuesten Stand der Technik zu bleiben. In der Java Version mussten wir alles selber implementieren, und das war einfach ein enormer Aufwand - alleine etwas scheinbar "triviales" wie Support für die Vulkan API hätte dort viele Monate Arbeit bedeutet, wohingegend dieser Aufwand in der neuen Engine quasi unbedeutend ist. Wir können nun auch "verhältnismäßig" einfach Dinge wie Raytracing, DLSS usw einbauen (zumindest ein Vielfaches einfacher als in der Java Version).

Die neue Version also grafisch aktuell zu halten ist wirklich kein großes Problem. Schwierig wird es wohl erst nach einer Zeitspanne von sagen wir mal 10-20 Jahren, nämlich wenn der Detailgrad von Items oder Pflanzen nicht mehr ausreichen sollte und neue Modelle erfordert. Das ist dann mit mehr Aufwand verbunden, aber an sich auch kein Ding der Unmöglichkeit

Quote from lenko

Deswegen sollte dann hier wohl auch in der Java-Version am Hauptbildschirm ein informatives über die neue Version evtl mit Link stehen.

Ich denke es ist durchaus sinnvoll, wenn die Java Version auch so einen Hinweis bekommt. Wir packen das auch mal fürs nächste Update dazu

Ich bin mir nicht sicher ob ich weiß, was du genau meinst Die Gradzahlen bzw. Drehung eines verbauten Elements werden (beim Betrachten) ja in der unteren linken Ecke des Bildschirms angezeigt, also konkret die "Rotation". Um den Unterschied zw. zwei Blöcken herauszufinden, müsste die Rotation ja eigentlich nur verglichen werden. Oder meinst du noch etwas anderes?

Quote from Ludy

da wär mir ein in game notiz zettel fast noch lieber

Das ist auf jeden Fall noch geplant

Quote from Deirdre

Besser wäre ein Möglichkeit den Winkel durch Ansehen zu erkennen.

Das ist doch eigentlich unten links sichtbar, oder bin ich da gerade auf dem Holzweg?

Danke für das Video, das verdeutlicht die Sache auf jeden Fall schon sehr gut!

Ein automatisches Anpassen der Drehung an einen darunterliegenden Block könnte allerdings etwas schwierig werden... zB wenn die Blöcke nicht ganz akkurat gelegt wurden, oder statt in einem Bogen eher in einem "Zick-Zack-Muster" lägen... dazu müssten wir uns einmal Gedanken machen, wie wir das am besten umsetzen Vielleicht reicht es in vielen Situationen auch, wenn man die Gradzahl "akkumulieren" kann, sprich jedes weitere Element in der Reihe bekommt automatisch +1° bei der Rotation dazu (das würde dann ja auch einen Bogen ergeben)?

PS: Das Krankenhaus sieht schon enorm vielversprechend aus!