Posts by red51

Quote from Foxnyu

And if we export it .OBJ, the same thing would happen or we would already have the possibility of changing it as we want

Meshes (which is what the .obj file represents) can be resized per axis, because they don't contain blocks etc, instead they just contain the individual vertices But when exporting the blueprint to .obj, the game does not use this file (it's just there if you want to load the blueprint in an external tool, for example).

Blueprints don't store meshes, instead they only store the individual construction elements - this is much more memory efficient compared to storing a whole mesh: For instance, a single block consumes roughly 100 bytes, but if it was a mesh, it would be between 2 and 8 KB (depending on the shape). Large blueprints would easily exceed 100 MB and more in size.

When placing a blueprint, the game just places the individual construction elements. While the game still bakes all elements in a chunk to a single mesh (for reasons for performance), this is no longer related to a blueprint and therefore cannot incorporate the blueprint scale.

In theory we could overcome the scale limitations, but that requires some work (and would unfortunately open a new can of worms)

Quote from paulevs

In my example above I used default lit shader. That actually happens to both default and custom shaders - they just don't receive scene environment light

Yes, it happens for any shader, but I just meant that we could fix it retroactively if the element uses the default HDRP lit/unlit shader The game has its own copy of that shader in cache (which includes all necessary shader variants), so we could basically just replace the shader manually when loading the prefab. But of course that doesn't work for custom shaders, so it would be only a partial solution

Der commands Befehl gibt in der Tat sämtliche Befehle aus, die es gibt (mit Ausnahme ein paar versteckter Befehle). Was wir einbauen könnten wäre, dass die Eingabe des "commands" Befehls zusätzlich die Liste in der Zwischenablage speichert (sodass man das einfach in ein Textdokument einfügen könnte).

Quote from Deirdre

Den Befehl disableobstruction wird nicht mehr mit Hilfstext angezeigt. Könnte man diesem ebenfalls eine Tastenkombination zuordnen?

Es gibt keinen solchen Befehl. Du meinst vmtl. edit flag disableobstruction, um dieses Attribut zB einer Tür zuzuweisen? Die Konsole zeigt leider keine individuellen Hilfstexte pro Parameter an (sondern in dem Fall nur den allgemeinen Hilfstext zum "edit" Befehl). Man kann aber grundsätzlich sämtliche Konsolenbefehle einer Taste zuordnen. Oder anders gesagt: Alles, was du in die Konsole eingeben kannst, kann auch einer Taste zugewiesen werden.

Quote from SonoBionda

Are your admins also entered in the server properties with their UID?

That could explain why nothing that is in the permissions arrives there (I once had problems with the instant digging command; everyone could do it, except me as an admin)

Yes, if you're a server admin (i.e the UID is set up in the server.properties), the permissions are overridden - as long as "Permissions_AdminsFullPermissions" is set to true in the server.properties (which is the default setting). To disable this behaviour, you can set "Permissions_AdminsFullPermissions" to false

However, when it comes to image permissions, admins don't have an upload limit by default (so even if you're an admin and "Permissions_AdminsFullPermissions" is set to true, you should still be able to upload an infinite number of images)^^

Quote from Deirdre

Instant digging command? Which command?

She was referring to the instantdigging permission (which is available in multiplayer for both creative mode [in the creative section] and survival mode [in the general section])

Sorry for my late response! It looks like that Unity is apparently stripping some shader variants when building the asset bundles (which are required to receive ambient light correctly)... I don't think we can fix that ingame (e.g. when loading the plugin), unless the default HDRP lit/unlit shader is used, so this needs to be done when building the bundles. I'll take a closer look at this issue and report back once I have a solution

Quote from paulevs

in my experiments I noticed that all scripts attached to objects are not exported. Probably objects don't receive environment information due to missing HDRP scripts?

The reason is that the game uses IL2CPP, which doesn't support scripts loaded from asset bundles unfortunately (which is a pity)... but it's not causing this issue. HDRP only uses specific scripts for certain components (like cameras or lights), but they should still work in asset bundles.

Sorry for my late response!

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 have a direction and a normal vector (both unit vectors!)
Vector3f direction = ...;
Vector3f normal = ...;

//We have to calculate a new direction vector
Vector3f newDirection = new Vector3f(normal);

//Get cross product of normal and direction
newDirection.crossLocal(direction);
//Get cross product of the result and normal
newDirection.crossLocal(normal);

//Use new direction for lookAt method (combined with normal as up vector)
Quaternion rotation = new Quaternion().lookAt(newDirection, normal);

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

Quote from Foxnyu

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

Quote from Avanar

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

Quote from TheKing

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)

Quote from paulevs

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

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

//Our target position
Vector3f targetPosition = result.getCollisionPoint();

//Our start position (e.g player position)
Vector3f startPosition = player.getPosition();

//Calculate target-start to get a direction vector from start to target
Vector3f direction = targetPosition.subtract(startPosition);

//Normalize the vector, i.e turn it into a unit vector
direction.normalizeLocal();

//Create a quaternion looking at this direction
Quaternion rotation = new Quaternion().lookAt(direction);

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