Posts by red51

    Die Taste dafür ist tatsächlich + (und - zum Verkleinern), allerdings ist es wichtig, die Numpad-Tasten dafür zu verwenden (also das Numpad + und -) :)

    Alternativ kannst du das sonst auch in den Einstellungen ändern: Unter "Steuerung" kannst du eine andere Taste für "Plus" und "Minus" in der "Bauen" Sektion zuweisen (in der Java Version hingegen heißt die Option "Raster (vergrößern)" und "Raster (verkleinern)") ;)

    Ja, dafür können wir gerne eine optionale Taste einbauen ;) Ähnlich wie auch beim Ducken oder Zoomen wird es dann zusätzlich eine Taste geben, womit der Voicechat umgeschaltet wird, also pro Druck ein- oder ausgeschaltet wird^^

    wäre es eine idee wenn du einen Reiter "sonstiges" hinzufügst und darin als unterkategorie z.b. "neue objekte" und hier dann bspw. eine geschirrspülmaschine. und auch immer wieder was hinzufügst wenn du neue objekte (oder auch npc modelle, biome, etc.) hinzufügst. also features oder anderes die in ihrem grundsatz schon woanders untergebracht sind auf trello oder sogar schon im spiel sind aber die erweitert werden. das liesse auch spielraum um vorschlägen aus der community raum zu geben. nicht jedem ist klar wie sehr du dich an deiner community orientierst

    Diese Idee hört sich ganz gut an! D.h. du meinst damit eine Liste, die quasi nach einem Update wieder geleert wird, also nur das zeigt, woran momentan gearbeitet wird? Ansonsten wäre ja das Problem, ist dass bisherige Objekte und Items in der Liste fehlen würden (außer wir tragen die alle nachträglich ein, was aber auch wiederum die Übersichtlichkeit einschränken könnte) :thinking: Das könnte manche User irritieren (und den Eindruck erwecken, es gäbe nur ein paar Items & Objekte, nämlich die, die dort aufgeführt sind)...


    Problematisch ist sonst allerdings, dass tatsächlich etwas Aufwand dahinterstecken würde, so eine Liste aktuell zu halten... wir müssten uns mal Gedanken dazu machen, wie wir sowas am besten umsetzen können ^^

    The issue about growing plants that was mentioned in the topic above was indeed supposed to be fixed :wat: Only limitation was that the fix does not apply to plants which were planted prior to the update (i.e. planted before July)...


    Maybe you can try this: if a plant doesn't grow, look at it, open the console and type plantinfo. Does the output contain a yellow line beginning with "SERVER - Plant is growing" at the bottom? If so, it contains the remaining seconds until the plant reaches the next growth stage.

    Sorry für die bisher ausbleibenden Updates auf Trello :/ Das Problem ist leider, dass die Roadmap grundsätzlich nur einen groben Überblick über die Dinge geben kann, an denen wir arbeiten... Besonders kleinere Features sind dort nur schwer (oder gar nicht) unterzubringen. Wenn wir zB ein neues Item einbauen, dann gibt es keinen wirklichen Platz dafür auf der Roadmap. Daher sind dort überwiegend nur die größeren Features aufgeführt. Doch bei Dingen wie den Biomen und Höhlen kommt etwas erschwerend hinzu, dass wir dazu ohnehin noch nicht viel präsentieren können bevor diese Features nicht nahezu fertig sind (denn richtige visuelle Ergebnisse haben auch wir erst dann, wenn die Arbeiten an dem Feature nahezu abgeschlossen sind).


    Nichtsdestotrotz werden wir die Roadmap bald aktualisieren, das ist schon lange überfällig ;)


    Korrigiere mich wenn ich da falsch liege ,aber die Roadmap soll doch dafür sein das man sieht woran du gerade arbeitest oder du du schon fertig gestellt hast ,oder ??

    Die Hauptintention ist an sich, dass man grundsätzlich sehen kann, welche Features geplant sind (und was bereits drin bzw. umgesetzt ist). Aber tatsächlich soll die Roadmap eine grobe Idee davon geben, an welchen Dingen wir derzeit arbeiten. An sich ist das durch die farblichen Markierungen (Gelb) gekennzeichnet. Die Aktivitätsliste hingegen hilft in erster Linie dabei, einzelne Änderungen zu finden (damit man nicht jede Karte immer wieder durchstöbern muss nach potenziellen Änderungen) ^^

    Why this method is actually called lookAt (since there is a method with same name in Transform and it accepts target look point)? In quaternion there is a method called lookRotation, it is probably a better name for it since it clarifies that it doesn't look at position, but instead rotates to some specific direction

    Basically we kept the method names from the Java version (to keep breaking changes as low as possible), and the old API was mostly using the naming convention of the engine (JMonkeyEngine), which also called it "lookAt" ^^


    But actually I wouldn't recommend to rely too much on Unitys API when it comes to Vectors or Quaternions, because Unity works quite different in this regard anyway. Java provides no way to overload operators (so Unity code like "Vector3 c = a - b;" wouldn't work in Java), and in addition to that, Java doesn't have structs like C# - so creating new vectors or quaternions always result in a new object on the heap, which may have performance implications - that's why there are various "local" methods in the vector and quaternion classes, e.g. "add" (which always creates a new vector) and "addLocal" (which updates the original vector) etc.


    The only API part which is directly related to Unity is Style (for UI elements). But apart from that, I wouldn't rely on Unitys API, because it is too different from the Plugin API.

    There is basically no need for this additional math ^^ The lookAt method already does all required calculations under the hood, the only "math" part on your end is to calculate the direction, which is targetVector - startVector, then normalize it. But I forgot that we already have a Utils method for that, as pointed out by noci :saint: Of course you can use that one instead of calculating the direction manually (just bear in mind that the first parameter is the "start position", and the 2nd parameter is the "target position")


    This is a simplified version of my example above (using our utils method, but basically the utils method just performs the math posted above):

    Java
    //Get direction vector
    Vector3f direction = Utils.VectorUtils.getDirection(dragonposition, result.getCollisionPoint);
    //Get your new rotation looking at the direction
    Quaternion rotation = new Quaternion().lookAt(direction);
    //Let the dragon look at this position
    dragon.setLocalRotation(rotation);

    The Quaternion.lookAt() method requires a direction (as unit vector), not a target position (that wouldn't work anyway, because a quaternion just describes a rotation, so it has no "start position"). If you have two vectors (e.g. your player position a and a target position b), and you want to get a vector from a to b, you can calculate b - a. In order to turn the resulting vector into a unit vector (i.e. a vector with a length of 1), you have to normalize it ;)


    So the code could look like this:


    Der Screenshot zeigt tatsächlich noch die alte Java Version sichtbar, wie Deirdre schon sagt ;) Um die neue Version zu spielen kannst du zB dieser Anleitung folgen: https://forum.rising-world.net/thread/11060

    Anhand der Versionsnummer im Hauptmenü kannst du dann sehen, ob es die neue oder alte Version ist: Wenn es 0.9.6 ist, dann ist es die alte Java Version, wenn es (aktuell) 0.6.7.2 ist, dann ist es die neue Version.


    In der Java Version gibt es leider noch kein fließendes Wasser... Im Creative-Modus kannst du allerdings wie folgt ebene Wasseroberflächen erzeugen: Aktiviere die Terrain-Werkzeuge (F5) und wähle dort das Wasser-Werkzeug (5) aus. Betrachte nun die Wasseroberfläche und drücke Enter - nun sollte eine Höhenbegrenzung erscheinen. Solange diese Höhenbegrenzung aktiv ist und du Wasser platzierst, wird diese niemals über diese Begrenzung hinaus gehen. Du kannst also nun Wasser platzieren (linke Maustaste) und damit eine ebene Wasseroberfläche erhalten. Um die Höhe des Tools zu ändern, kannst du Bild Auf und Bild Ab verwenden. Du kannst nach wie vor auch den Bereich mit Numpad + und - vergrößern/verkleiner.


    Alternativ kann sonst auch das Bereichswerkzeug (4) benutzt werden, um einen Bereich mit Wasser zu füllen :)

    Here in Brazil, the most common is ABNT2... but it can vary depending on whether it is a notebook, desktop, or even a MAC OS imported from the USA, for example. Switching to the keys that seem correct here to me can cause problems as they are already technically wrong for me as they are.

    It's indeed a bit problematic if more than one keyboard layout is commonly used in a country :thinking: But changing this behaviour would be a breaking change for existing users (because their key bindings on non-QWERTY keyboards won't work anymore), so there would be a bit more work involved to avoid that situation... unfortunately I have no ETA for that change yet :/

    There are unfortunately two issues when it comes to releasing smaller, more frequent updates: one the one hand, each update release is always a bit time consuming. It includes things like writing posts in the forums, reproducing and fixing bugs etc. Releasing an update usually keeps us busy for 1-3 weeks, depending on how much needs to be done after the update (bugfixes, but also incorporating changes based on community feedback etc). Usually this wouldn't be an issue at all, but as long as the new version hasn't replaced the Java version, all updates for the new version mainly target the existing community (as mentioned earlier in this topic), which has little impact on our sales - and if our financial situation won't improve in the forseeable future, we'll be in serious trouble :silenced:


    On the other hand, not all players are happy about small updates (especially if they're mostly cosmetic updates), at least if there are still other important things missing. Most people want more updates, but they're not necessarily happy about cosmetic updates. If we release a small update now introducing new furniture, for example, some people would complain that we were "wasting" our time by adding these things instead of adding meaningful content like biomes, enemies etc.


    Having said that, these issues aren't relevant anymore once the new version has finally replaced the Java version. That will really take the pressure off us. Right now our main priority is to get the new version ready ASAP ^^

    When translating the keyboard control configuration screen, I identified that the game does not identify the keyboard layout correctly.

    Thanks for the video :thumbup: Basically this is related to how Unitys new input system works: key input is always based on default US QWERTY layout. More precisely, keys are identified by physical location, not by the character that is actually printed on screen.
    Handling it this way makes a few things easier, but it's unfortunately confusing when creating translations for the game... but for the German localization, for example, we simply override the translation text for the original QWERTY key (on a QWERTY keyboard, the key next to L is "semicolon", but on a German QWERTZ layout, the key is "Ö"). So the localization key input.keyboard.semicolon is "Semicolon" in English and "Ö" in German (and for the Brasil localization, you could just set it to "Ç").


    This may still cause trouble in a few rare cases, e.g. if someone uses a different keyboard layout (for instance, a German user who's using an US keyboard), so maybe we will change that in the future.


    Is there a website to create bug tickets for Rising World? Or do I continue posting here on the forum?

    There is no public bug tracker, so it's ok if you continue posting on the forums ;) For specific issues which are hard to describe or if you experience any weird game behaviour, you could also use the "report" feature of the game (just type "report" into console) - but for smaller issues which are easy to describe (e.g. wrong localizations), it's better to just create a post in the forums^^


    There is no string to translate this text on the audio settings screen.

    It's indeed a hard-coded text.. basically it's just there for reasons of copyright ^^


    There don't seem to be any strings for translating the commands.

    Most texts related to console commands are also hard-coded unfortunately... this is something we want to change in the long run, but unfortunately I have no ETA for that yet...

    I'm afraid there is a misunderstanding :wat: Currently we have no plans to release new updates for the Java version anymore, at least no content updates. The new version and the Java version are basically 2 separate games, so if we implement a particular feature in the new version, we basically have to spend the same amount of time to implement this feature for the Java version. Unfortunately we don't have enough resources to work on 2 games simultaneously...


    But once the new version is a bit more fleshed out, it will indeed become the "main version", i.e. it will replace the Java version ;) The Java version, however, will then move to a separate beta branch, so it will remain playable (but it won't get any new features)... the next update will introduce biomes and caves btw (as well as some other new content) ^^

    ich habe Probleme im "Single Player" den Mous-Event abzufangen, im "Multie Player" klappt es, player.setListenForMouseInput(true); wird auch gesetzt.

    Hmm... welches Problem tritt denn genau auf? Wird das Event gar nicht erst getriggert? :wat:


    Wenn ich im MP ein Bundle Lade und es schon geladen wurde dan greift er ja auf den Chas zurück.

    Allerdings scheint das im SP zu einem fehler zu führen.

    Das ist leider ein heikles Thema :/ Dummerweise erlaubt Unity es nicht, ein Asset Bundle mehrmals zu laden... das Problem tritt hier beim Aufruf von "getAllAssetNames()" auf, da dafür ebenfalls das Bundle geladen werden muss (was aber nicht klappt, wenn das Bundle bereits clientseitig geladen wurde). Und es gibt leider keine Möglichkeit, anhand von Bytes (so liegen die Bundles in der API vor) auf ein geladenes Bundle zu schließen bzw. anhand eines bereits geladenen Bundles zu suchen...


    Wir müssen mal gucken, ob wir das irgendwie umgehen können :thinking:


    Ist das von deiner Seite aus Schnell/Einfach zu regeln, oOder wie gehe ich da am besten im Single Player um?

    Ich kann leider nicht sagen, ob wir dafür bis zum nächsten Update eine Lösung haben... dafür müssten wir das Laden von AssetBundles generell umschreiben. Du könntest sonst vll versuchen, "getAllAssetNames()" nur vor dem Verwenden von Asset Bundles aufzurufen (also bevor du das AssetBundle einem Spieler zuweist bzw. ein Modell davon lädst), dann dürfte es diesen Fehler eigentlich nicht geben.

    Unfortunately this is a bug :/ Currently the callback for "showColorPicker()" is never invoked... but this will be fixed with the next update. Sorry for the inconvenience!

    Ark verwendet Unreal (das hat aber eh nicht viel mit der Engine zutun). Allerdings hat Ark bislang einen Umsatz von über $1,3 Milliarden USD gemacht. Die haben also ein paar mehr Resourcen zur Verfügung als wir, ebenso auch Manpower... Ark macht momentan an einem einzigen Tag mehr Umsatz als Rising World die letzten 4 Jahre zusammen gemacht hat.


    Unsere Plugin API ist grundsätzlich erstmal nicht für den Endanwender gedacht, sondern das ist ein Werkzeug für die Modder selber, um Plugins (oder von mir aus Mods) zu erstellen. Wir haben uns den Begriff "API" übrigens nicht augedacht, sondern das heißt einfach nur "Programmier-Schnittstelle". Heutzutage haben mehrere Spiele sowas (mehr oder weniger). Du kannst gerne auch "Mod-Kit" oder "SDK" dazu sagen, falls du das bevorzugst.


    Wenn ein Spiel populär genug ist, dann kommen Mods allerdings von ganz alleine. Spiele wie Minecraft oder Skyrim hatten ursprünglich gar keine Modding-API, doch waren diese Spiele so populär, dass Community-Mitglieder aus Eigeninitiative hunderte oder tausende Stunden damit verbracht haben, durch Reverse-Engineering Mods zu erstellen - trotz 0 Unterstützung durch den Entwickler. Die Community hat bei Minecraft bspw. Bukkit entwickelt, was quasi mit der Plugin API vergleichbar ist. Der Unterschied ist nur, dass es halt nicht vom Entwickler selber kommt, sondern aus der Community. Auch Mod-Loader für viele Spiele stammen ausschließlich aus der Community und nicht vom Entwickler.


    Wir haben die Plugin API entwickelt, um es Leuten einfacher zu machen, Plugins (oder halt Mods) für RW zu entwickeln. Ohne so eine API wäre der Schwierigkeitsgrad, eine richtige Mod zu entwickeln, 1000-mal höher. Das würde effektiv nur bedeuten, dass erst recht niemand eine Mod für RW entwickeln würde (da RW eben nicht populär genug ist).


    Du ärgerst dich über das vermeintlich komplizierte Installieren von Plugins. Effektiv muss ein Plugin eigentlich nur heruntergeladen und ins "Plugins" Verzeichnis des Spiels entpackt werden. Das kann abweichen, wenn der Plugin-Entwickler sich dazu entschieden hat (zB weil ein Plugin abhängig von einem anderen Plugin ist o.ä).

    Wenn die Community mehrheitlich sagen würde, dass sie das manuelle Herunterladen der Plugins zu kompliziert findet und sich dafür einen einfacheren Weg wünscht und das für die Community oberste Priorität hätte (es für die meisten User also zB wichtiger als Biome wäre), dann würden wir alles andere stehen und liegen lassen und sowas zuerst einbauen. In der Realität ist es aber eher anders herum, schon das Plugin-API Update im April hat in Teilen der Community für Unmut gesorgt, weil eben nicht jeder was damit anfangen kann. So wichtig Modding IMHO auch ist, noch wichtiger ist trotzdem, ein vernünftiges Spiel als Grundlage zu haben (damit das Spiel ein gewisses Maß an Popularität erreicht). Ohne ein vernünftiges Grundspiel (bzw. ohne ein Grundmaß an Popularität) wird sich kaum jemand finden, der bereit ist, Mods/Plugins zu entwickeln (egal wie einfach oder kompliziert es ist). Das API Update gab es nur, da der Engine-Wechsel ja eher ein Sonderfall ist und damit Plugin-Entwickler schonmal anfangen können loszulegen. Trotzdem war es sinnvoller, überhaupt erst die Plugin API einzubauen bevor wir einen Ingame-Browser dafür implementieren (der nämlich nicht viel bringt, wenn es eh keine Plugins gibt).


    Wenn wir jetzt aber dringend benötigte Features nach hinten stellen, um einen Ingame-Mod-Browser zu entwickeln (obwohl es derzeit eh nur wenige Plugins gibt), werden wir RW damit kaum einen Gefallen tun.


    Was hat die Anzahl der Entwickler mit der Umsetzung von Mods auf Api zu tun? Das hätte man von Anfang an machen können. Es ist eine Sache der Herangehensweise.

    Naja, was hat das Vorhandensein eines Ingame-Browsers für Mods/Plugins/Erweiterungen mit der Bezeichnung zutun? Ich fürchte, du versteifst dich etwas zu sehr auf die Begrifflichkeiten.

    Und ja, die Anzahl der Entwickler hat einen direkten Einfluss auf den Umfang eines Features. Hätten wir 10 oder 20 Leute, dann würde es einzelne Personen geben, die sich ausschließlich um ein Feature kümmern. Dann wäre zB einer da, der 100% seiner Zeit in einen Ingame-Mod-Browser stecken kann. Bei uns ist es aber so, dass viel zu viele Features auf viel zu wenige Entwickler kommen. Wir können uns gar nicht auf ein Thema konzentrieren, weil eigentlich noch 10 andere Features lange überfällig sind, daher muss alles irgendwie parallel ablaufen (was aber dann nur mit Kompromissen funktioniert).


    Dann liegt es hier wohl an der ewiglangen Erklärungen und andauernden Veränderungen, dass man keine Lust mehr auf Apis hat.

    Welche andauernden Veränderungen? Ich muss nochmal betonen: Die Plugin API (oder Mod-Kit oder das SDK oder die "Creator Suite" oder wie auch immer man es nennen mag) ist nicht für den Endanwender gedacht, sondern benötigt grundlegende Programmierkenntnisse. Es ist das Werkzeug für die Leute, die die Mods erstellen und anschließend (hoffentlich) der Community bereitstellen.

    Ich glaube, hier gibt es ein kleines Missverständnis :saint: Ich habe oben ja nicht gesagt, dass es eine Sortierung nach Klein-/Großschreibung geben wird, stattdessen habe ich nur nachgefragt, ob das so wirklich gewollt ist, denn so eine Sortierung ist schon recht ungewöhnlich. Ich habe lediglich gesagt, dass die Sortierung ab dem nächsten Update Ordner zuerst auflistet, dann Dateien ^^


    Das betrifft aber übrigens nur die Listenansicht auf der linken Seite - derzeit herrscht dort eine strikte alphabetische Sortierung, d.h. Ordner und Dateien wechseln sich ab. Die Intention ist, erst Ordner und dann Dateien (weiterhin alphabetisch sortiert anzuzeigen). Es wird dafür aber auch eine Einstellung geben sodass man auch die derzeitige Sortierung beibehalten kann.


    In der Hauptansicht ist sowas leider nicht möglich, denn liegen alle Ordner ja quasi auf einer Ebene und man klappt sie jeweils ein und auf.


    Ich finde es viel Sinnvoller, wenn im Mittleren Blaupausen Fenster nur der Angewählte Ordner angezeigt wird

    Meinst du das in dem Sinne, dass wirklich nur der aktuelle Ordner dargetellt wird? D.h. wenn ich zB auf den Ordner "Möbel" klicke, ich nur noch den Inhalt von "Möbel" sehe und nicht mehr den der anderen oder übergeordneten Ordner? Und wenn ich dann zB in den Unterordner "Stühle" gehen möchte, ich darauf klicke und nur noch den Inhalt von "Stühle" sehe? Quasi so, wie der Dateibrowser bei Postern (wenn man ein Bild von der Festplatte auswählen möchte)?

    Momentan kann man ja sonst die nicht benötigten Ordner einfach zuklappen (das Spiel merkt sich diesen Zustand auch nach dem Schließen des Fensters) ^^