Posts by red51

    Sorry for my late response! :saint:


    I wouldn't necessarily recommend to work with individual quaternion values directly (i.e. the x, y, z and w values). There is really no need to understand the complex math voodoo behind them. If you just want to set rotation values directly (i.e. a rotation around the x, y and z axis), you can just use "euler angles" - the API has a fromAngles() method for that where you can set the pitch, yaw and roll.


    In your case it looks like you want to align something to the ground normal? This is a bit more complex, but you can just use vector math for that (which is much simpler and more comprehensible than quaternion math). Basically you just have to calculate a new direction vector (aligned to the ground normal) - this can be done by calculating the cross vector of the normal and forward, then use that to calculate the cross vector of the normal. The resulting vector can be used as direction for the Quaternion.lookAt() method (but it's necessary to provide an up vector then, which is just the normal in this case):


    We can add a new util method with the next update btw which can produce an "aligned direction" ;)

    Wir können mit dem nächsten Update einen neuen Befehl swapsize einbauen, mit welchem die Größe zweier Achsen beim aktiven Bauteil miteinander vertauscht werden kann :) Also würde zB swapsize x z die X und Z Werte eines Bauteils tauschen (Z ist dann so lang wie vorher X und X so lang wie vorher Z). Natürlich könnten zwei beliebige Achsen verwendet werden (zB Y und X oder Z und Y usw). Das wäre vmtl. momentan die einfachste Lösung ^^


    Eine eigene Taste dafür hätte allerdings wieder die Einschränkung, dass man die Achse nicht angeben könnte (falls man zB X und Y tauschen wollte)... das Spiel bietet aber die Möglichkeit, dass man eigene Konsolenbefehle auf Tasten legen kann. Du könntest also eine beliebige Taste raussuchen und ihr dann zB den Konsolenbefehl "swapsize x z" zuweisen. Das ist in den Steuerungseinstellungen zu finden (ganz unten). Leider gibt es derzeit einen Bug, wodurch der Konsolenbefehl selbst dummerweise nicht gespeichert wird (die zugehörige Taste wird allerdings gespeichert). Das beheben wir mit dem nächsten Update, aber bis dahin kannst du ihn manuell setzen mit dem Befehl setoption customcommand1 <befehl> (also zB setoption customcommand1 size 2 2 2, um auf Knopfdruck "size 2 2 2" auszuführen). Anschließend noch einmal saveoptions eingeben, damit das in der config gespeichert wird ;)

    Hello everyone, could you clarify why blueprints can only be made larger or smaller and cannot be lengthened or widened.

    Unfortunately blueprints can't be resized per axis because that wouldn't work as soon as the blueprint contains any rotated elements (or more precisely, as soon as not all blocks have the same rotation or are axis aligned). This image tries to illustrate the problem:


    On this image, we have two blocks - the big diagonal one (1) and the small one (2). The blue line illustrate the blueprint itself. Left is the default blueprint, on the right is the blueprint resized along one axis (the X axis). Block 1 has a rotation of 45°, while block 2 has no rotation. Resizing the blueprint along the X axis works fine for block 2, but will stretch block 1 - unfortunately this is something the game cannot represent (right now construction elements only store a local scale along X, Y and Z).


    Unfortunately this is tricky to solve: While we could store an additional scale with an arbitrary rotation, we would run into problems again if such a stretched element gets stored in another blueprint, which is then resized again using a different rotation.

    That permission file looks fine to me, so that should work. However, unfortunately the ingame permission dialog does not show image permissions yet, that's why they're missing there... thanks for bringing this to our attention, we'll fix that with the next update! But this doesn't affect the actual permissions at all, so the image permissions should still work :)

    You can basically ignore these warnings ;) The game prints a warning if it tries to read a setting from the world database which doesn't exist. There are a few settings which are read from the database, but not yet set by the game when creating a world (e.g. "spawnclothes").

    Actually we're not using any assets from that pack :D The game indeed uses some stock models, although we created most models ourselves (or hired a freelancer artist back then). When it comes to coding or any game behaviour, we don't use any assets at all - everything is created from scratch. In fact assets which have any behaviour (like the motor boat you've mentioned) wouldn't work in RW anyway, because RW is built in a server-authoritative way (i.e. a multiplayer game where the server makes all decisions). Basically the typical simplistic "scripting" way in Unity (using so called MonoBehaviours) is bad anyway (that's why Unity decided to move away from it and created DOTS back then, although progress is extremely slow there and it's barely production ready), so RW is created differently (RW doesn't use DOTS, but it's built in a similar way).


    About the textures, the Java version indeed used many textures from textures.com ^^ The new version has more complex PBR materials so we mostly used different sources for that^^

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

    Ja, es scheint als würde er garnicht erst Getriggert werden.

    Merkwürdig... ich konnte das bei mir irgendwie nicht reproduzieren :wat: Dein Code sieht eigentlich korrekt aus. Vll hing es aber auch mit einem Bug zusammen, den wir zwischenzeitlich möglicherweise bereits behoben haben... ich teste es nochmal, wenn ich eine aktuelle gebuildete Version zur Hand habe ^^

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