Posts by red51

A small new update is available now!

    I wonder if we will still be able to make these kinds of adjustments in the new Unity version.

    Yes, the new version still stores all definitions in a database file ;) It's located under "Rising World/Data/StreamingAssets/definitions.db" and can be opened with any SQLite editor. This time there are actually even more definitions exposed in that database (like weather settings).

    Once NPCs are implemented, the definitions table may look different compared to the Java version, but you will still be able to change the animal behaviour, reactions etc ^^


    I also wonder where I should post that question in the forums. Lol.

    You can post any questions regarding the new version in this section (which is specifically about the new version): Discussions (English)

    Könnte man die Blockierung für Türen wenigstens für den Kreativmodus aufheben, Button oder sonst irgendeine Einstellung.

    Wir könnten dafür eine Spieleinstellung anbieten, ähnlich wie bei der Schwerkraft von Pflanzen und Objekten. Zumindest solange, bis auch wirklich runde Türen verfügbar sind :thinking:


    Das Licht ist auch ein Problem, siehe Waschmaschine. Man wird mir nicht glauben, dass ich ca. 2 Stunden damit verbracht habe die Kleinteile genau einzupassen, da ich eigentlich da sehr genau arbeite und solche Stellen für mich Pfusch sind. :( Wie man sehen kann, ist mir das nicht ganz gelungen

    Welches Problem gab es denn dabei genau?


    Ich kann nur sage, ich bin zwar mit den Lichteffekten sehr zufrieden, aber mit den Ungenauigkeiten überhaupt nicht.

    Auf welche Ungenauigkeit beim Licht beziehst du dich dabei?


    Am Licht schalte ich immer herum, ich baue sehr oft mit weißen Wänden und es mit hellem, sehr hellem Licht extrem schwierig zu bauen, lange hält man das Licht nicht aus. Selbst mit 0 Uhr und Licht, was in der Java-Version wunderbar funktioniert hatte, geht das in der Unity-Version leider nicht.

    Meinst das Creative-Mode Licht (L)? Davon kann die Licht-Stärke in den Spieleinstellungen (unter "Verschiedenes") eingestellt werden, nämlich bei "

    Creative-Modus Licht Intensität". Hilft das evtl?


    Das Dimmen und Verändern der Farben mit dem Leuchtmaterial/Blöcken ist schwierig. Manchmal trifft man die Stelle, an der das Licht geändert werden kann sofort, ein anderes Mal ist das Finden dieser überhaupt nicht möglich.

    Normalerweise sollte es ausreichen, den Leuchtblock genau anzuschauen, damit das Radial-Menü verfügbar wird. Schwierig wird es lediglich, wenn die Oberfläche des Leuchtblocks genau an der gleichen Position wie die eines anderen Blocks liegt - hier hilft es meistens, wenn der Leuchtblock zumindest ein winzig kleines bisschen heraussteht.

    Es wäre durchaus denkbar, dass man bspw. einen großen Steinblock herstellen könnte, welcher dann mit Hammer & Meißel bearbeitet werden kann. Unter der Haube würde sich dieser Steinblock wie normales Terrain verhalten, jedoch mit deutlich höherer Auflösung (sodass ein "Block" darin zB nur 0,01 x so groß ist wie bei regulärem Terrain). Müssten wir mal ein wenig mit herumexperimentieren... ich packe es aber mal auf unsere Todo-Liste :)

    Having an easy way to create custom structures which would then be used by the world generator to spawn them as dungeons would be a great feature. If we add something like that, it will probably rely on blueprints. But unfortunately I can't say much about such a feature at this stage... it's definitely our intention to provide easy ways to customize the game, but I can probably say more about this once the new version is a bit more fleshed out :)


    Another thought, would it be possible to have a cauldron over a fire and when the player clicks on the large spoon leaning against the cauldron they taste the brew.

    When it comes to cooking (and/or alchemy) it is our intention to implement it in an interactive way - so probably it will actually work like that :D

    Oh, das ist eigenartig :wat: Auf jeden Fall schonmal danke für die Logs!

    Also wann tritt das genau auf, bzw. wann drückst du Enter, um mehrfach zu connecten? Connectest du direkt via IP auf den Server, oder ganz normal über die Serverliste (also Doppelklick auf den Server)? Drückst du dann unmittelbar Enter, oder erst im Ladebildschirm, oder sogar erst nachdem du gespawnt bist? Ich konnte das bei mir leider nicht reproduzieren, aber es scheint so, dass lt. Logs der Server 3x das "Connect" Packet vom Client erhalten hat... Das können wir auf jeden Fall verhindern, allerdings wäre es auch interessant zu wissen, was auf Clientseite genau passiert. Falls das bei dir nochmal auftreten sollte, kannst du dann evtl. auch noch einen Report senden (also einfach "report" in die Konsole eingeben und absenden)? ^^

    12. Hide world loading from player

    This is on our to-do-list :D


    13. Add possibility to move item on hotbar by pressing numerical key

    I saw that feature in some other games and it is much faster than drag-and-drop item on hotbar, probably some players will like this more than cursor item movement

    Oh, this sounds interesting! Could you elaborate on that? Is this supposed to move the currently equipped item to a particular hotbar slot (e.g. when pressing numpad 1, the currently equipped is moved to the 1st slot, pressing numpad 2 moves it to the 2nd slot etc)?

    red51 : Danke für deine Antwort. Wie kann man ein byte[] in eine Datenbank speichern?

    Wenn du zB ein PreparedStatement verwendest, kannst du einfach via setBytes() ein byte[] übergeben. Ein Blob ist im Grunde nichts anderes als eine Hülle um ein byte[] ;) So könnte das zB in der PluginAPI aussehen (angenommen die Column "data" wäre hier in der Datenbank vom Typ BLOB):

    Java
    byte[] bytes = ...; // <- Dein byte-Array mit irgendwelchen Daten
    Connection con = db.getConnection();
    try(PreparedStatement stmt = con.prepareStatement("INSERT INTO `MyTable` (`id`, `data`) VALUES (?, ?);")){
    stmt.setInt(1, 42);
    stmt.setBytes(2, bytes);
        stmt.executeUpdate();
    }


    Wenn du hingegen Daten aus einer Tabelle auslesen möchtest, bietet ein ResultSet entsprechend auch eine getBytes() Funktion.

    Das Grid ist bei der Terrainbearbeitung viel zu weit oben. Damit kann man nicht genau arbeiten. Außerdem fehlt die Angabe der Oberkante Höhe.

    Die Terrainbearbeitung bzw. man sieht erst etwas wenn sich das Raster höher über dem gebauten Boden befindet.

    Ja, das stimmt allerdings... das tritt momentan nur im gebuildeten Spiel auf (also dass das Raster überall gleichermaßen sichtbar ist), daher müssen wir nochmal genau prüfen, warum das so ist :thinking:


    Ich habe hier ein paar Texturen aus der Java-Version ausgesucht. Meine Priorität war, ob diese Texturen oft verwendet wurden/werden und ob sie im großen und ganzen für alle Bau- und Dekomöglichkeiten geeignet sind. Eine Texture mit Kacheln kann nicht als untere Leiste oder Sockel an einem Haus verwendet werden, das würde sehr seltsam aussehen.

    Danke für die Vorschläge! Mal sehen was sich machen lässt ;)

    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 :thinking: Dann würde man die von lenko erwähnte Einstellung bzgl. Hunger/Durst natürlich entsprechend mitberücksichtigen.


    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? :wat: 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.


    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.

    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)?


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

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


    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 ;)

    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 ^^


    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 :saint: 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... :silenced:


    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 ;)

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

    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 :drunk:

    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° ;)


    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 :thinking:

    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 ^^

    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).


    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.

    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.


    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 :thinking: 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).