Posts by paulevs

    Grass ids are currently between 100 and 145 ^^ The grass type is stored in steps of 5 (100 is regular grass, 105 is arid grass, 110 dry grass, 115 is dead grass, 120 is frozen grass, 125 is forest grass, 130 is jungle grass, 135 is sea grass and 140 is seaweed). The subsequent 4 values describe the grass length (the game uses fixed values depending on the grass type), so for example, 100 is plain grass (no blades), 101 is short grass, 102 is the default grass length, 103 is tall grass and 104 is very tall grass. 105 then is plain arid grass, 106 is short arid grass etc.

    Thank you, I already found that when I placed all possible IDs on map :)

    So basically ores are on 50-55 range (56-99 is reserved)

    Grasses are on 100-144 range (145-200 is reserved, can be used to generate cool red grass on black terrain)

    Water is 201 and 202 (and repeating up to 255, probably other liquids will be stored after it)

    And normal terrain is on 0-31 range. There are also some addional grass entries. All these things will be added as constants in next BlueLib version


    Thank you very much :)

    I have a small note - terrain data stores array capacity between 3 array dimensions and actual terrain data, so most my attempts to write data looked like this before I found the reason:


    So, the terrain data looks like this:

    4 bytesInt size X
    4 bytesInt size Y
    4 bytesInt size Z
    4 bytesArray Capacity
    2 * X * Y * Z bytesData


    Also looks like terrain data is stored with [id-strength] order instead of [strength-id] order (which I noticed during test output), probably this is related to stream order


    Now the last thing that I need to configure is array index order ;)

    how to make large circles?

    Very similar to building normal circles (tutorial), but with larger element sizes. In Unity version it will be much simpler than in Java.

    Elements can connect to each other, so circle radius is not limited. The smallest possible angle between elements is 1 degree, but I can recommend you to have 10-15 degrees to build walls easier later.

    You can make rounded building in any shape that you like:


    Good day everyone, this suggestions thread is about forests.


    So, we already have good forests in Unity version, which are definitely better than in Java version. However, there is still a big room for enhancements as right now they don't look like real forests, and most foliage shading don't look like, well, a foliage, more like a solid objects. When I searched different game foliage implementations I found this thing:


    Comparing this implementation with existing forest I can conclude that there are several things that makes forest look realistic:

    1. Visible plant sub-surface scattering (leaves and twigs). I remember that current scattering is low as it didn't work fine at nights, as a result leaves of trees and bushes looks less like a foliage and more like a solid objects. So, well, I don't know if it is possible to solve at this point, but if it will be solved it will add +50% of realism to the trees. Even cartoon trees looks nice with sub-surface scattering :)
    2. A lot of small plants of different size. Rising World forests already have some, but much less than real forests have. I think that more random grass textures and different height variations of grass will partially fix that (we already have different grass, but looks like only one is generating in the world/in biome). As an addition there can be more bushes, small trees, large grassy plants (like Anthriscus, Chamaenerion, and other tall grasses)
    3. Other small natural objects - fallen branches, tree stumps, roots, twigs, small stones, etc. We already have some, but looks like most of them are generating in coniferous forest while other types of forests don't have small objects


    Small addition about object scattering. I don't know which scatter algorithm Rising World uses at this moment, but I want to suggest two good algorithms of natural scattering:

    1. Poisson Disc, it works fine for limited areas, but require modifications to work in infinity world. It is a good for ecosystem simulations as it can take into account plant size and density. There was an old article about ecosystem simulation
    2. Triangular grid. This is a simple (and cheap) algorithm that distributes object on triangle vertexes with random offsets. Since triangles are just offsetted squares it is very fast, and due to same thing it is easy to make it infinity or limit to area of any size.


    I also hope that with new plugin system we will be able to modify existing ingame objects and their shaders and scatter new objects in the world. In that case it will be possible to alter some assets and enhance forests, or add a lot of different custom plants to them ;)


    P.S.: Please enhance spruce assets, at this moment they are too yellow and don't have enough branches. I think that there are spruces in the world that looks like these, but I like spruces from the forum header much more than assets in the game. Probably I'm not the only one who think so :thinking:


    P.P.S.: If it will be possible to alter assets it will be possible to make nice game stylisations with plugins. Like Cartoony Risen World or Blocky Risen World, or any other variants that can be imagined

    When compiling the game, however, all C# code is turned into C++ via Unitys IL2CPP. It's by far not as efficient as plain C++, but still faster than C# - although that's not the fault of C# (I don't think that C# is considerably slower than Java), actually it's Unitys old Mono implementation that is so slow.

    Thanks for clarification :)
    Do you have plans to turn more parts into C++ code or it will remain C#?

    It's not using the built in enum class, but it works the same, and it's written in Java

    Technically you still can apply it even on Java enums, with using .ordinal() which will return enum index:

    Java
    public enum EnumFruits {
        APPLE, BANANA;
    }
    int weirdData = APPLE.ordinal() + BANANA.ordinal();

    But it will require more additional function callsm while in C languages you can use numbers directly, and cast them to enums too:


    C#
    Direction direction = APPLE + BANANA; // Direction is another enum

    I wouldn't really 'class' a enum as a data structure myself, more a data type

    Enum in Java is an Object, so it is included in data structure. Enums can be parent/child for each other, for example, or have other data types in hierarchy. And they can store data inside (which is a common practice in Java) while they are still an enum.
    Java itself have two types of data - objects and primitives. Enum is object in Java, while in C# it is a primitive, so it will have different behaviour.


    Brief example:
    You have enum of fruits, what will operation like APPLE + BANANA mean?
    In Java: syntax error, you can't use "+" operator on objects
    C languages: That's valid operation, I will just return a number for that

    So if your code in Java have a complicated enum structure it will be hard to port it into C languages, and more important - if this structure is a part of another library that you are using it will become much harder. From both code side and license side, and this is also a RW case as it uses JMonkey Engine, so it is related to JMonkey implementation of things which cannot be ported and must be carefully replaced with analogues


    they can be implemented in any language

    Technically this is true, but only for ideal abstract algorithm (and, I guess, for turing complete language). Most real tasks in huge projects are highly twisted with side libraries, different aspects of specific code language and many many small details. That's also a reason why most banks still use code from 70-80 on Fortran - it is almost impossible to port it on another language


    Addition: Red's post about languages and what parts of RW uses C++

    everything i have looked at about/for unity is c#

    C# is a scriptable language inside Unity editor while C++ is the language of Unity itself. It is possible to write code for Unity on C++, but this is not common practice - C# purpose is to make development simpler, but more limited. C++ was chosen due to two main reasons: it is required for JNI and it is much faster than C#. It is possible to run JNI in C#, but only for android, so most answers if you will ask "how to run Java in Unity" will be "You can't" as it is not completely supported on C# level

    Data structures as you know are the same whatever language you choose to write in.

    This is not correct, different languages have completely different implementation, brief example: in Java enums are objects, in C# it is numbers (which means that they can't store data, but can be casted one to each other and to numbers, same for C and C++), in scriptable languages there is no concept of enums at all. Different languages may have or not have concept of arrays, different indexing, may not have classes, have different ways of inheritance and so on.


    how do you know its C++ and not C#?

    From Red, it was mentioned on Steam and on Forum. This is also an only one choice to make possible run Java in Unity as it will require custom instance of JNI.

    C++ is also a good choice, as while Java and C++ have semi-equal operational time Unity C# was 40-50 times slower (worlgen tests from Steam)

    I'm guessing a lot of the code from Java will have been reused (rewritten) for Unity and improved upon during the rewrite. Java and C# are syntatically very close.

    Most code for current version is C++, not C#, so it will be different. Some parts will be logically equal, but this doesn't mean that they can be ported directly. C++ use many things that Java don't, like pointers, for example. And it requires manual garbage collection, so you will need to check for memory leaks much harder.


    Most old code was also based on JMonkey Engine things (like physics, lights, GUI, and so on), which will require complete replacement on Unity as this is different engine. Some changes related to it you can already see in possible GUI API description

    Please let us know if you're interested in a preview version of the API (specifically for the UI).

    Yes, we are interested in this :)
    Even if API is not complete it is a good way to start adapting to the new API together with new UI experiments


    The Internals class will provide a way to modify the Style of any game UI element. E.g. change the color of the health bar or the background color or image of any game menus.

    Will it make possible to change, for example, inventory size of a player or his hotbar? Or this will only affect visuals and API for inventory interactions will be separated?

    I think that in this case "postponed" just means "delayed do to lower priority". Technically there is a basis for moving structures, it is very similar to how blueprints are rendering before placement, but unlike blueprints together with rendering they should include collider. But this basis is not enough - there should be in-game tools to create these objects, survival-friendly mechanics, craft stations, GUI and so on, and all these things should be done from scratch as we didn't have similar mechanics in Java. So, things that already exists in Java have larger priority then completely new due to version switching

    I think that this suggestion was probably not noticed, so I bump it a bit


    So, small addition - if we will get clear brick texture (without mortar) we will be able to build custom arches


    Header-Shot_Arches_AR2_DSC_0635-scaled.jpg

    Sorry for my late response, I missed that post for some reason :wat: However, are these just blocks? Or is it a different element on the right side (e.g. the backface of a slope or something like that)? Was the element flipped/mirrored?

    These were individual blocks without mirroring, but probably with some rotations. Both surfaces are from stretched cubes. I'm not sure but probably if element is rotated or scaled with certain values it will get inverted normal


    Another screenshot:

    Probably there can be some changes in ores to make a good progression curve (for the future version):

    1. Different starting resource, the best is probably copper or bronze. This should make iron a bit more middle game resource

    2. Ore boulders can be rare, but you can find a small rocks (which will give you one resource during pickup) which will indicate large underground ore vein (same as in Vintage Story, Terra Firma Craft or 7 Days to Die). This will mark startup resources for the player, so it will be not too hard to find them, and this will make them a bit more hard to obtain. This should not be grinding and searching for hours, just a bit more effort to get basic resource


    skip wood tools

    We don't have complete set of wood and stone tools, the only tools from these materials are stone axe and wooden rake. This is not enough for basic building, mining and farming. Tools of the second level are from iron - iron axe, pickaxe, hoe, sledgehammer, scythe and sickle.