Works great in Linux!! And the textures are nice! Happy Holidays!
Posts by LordFoobar
A new update is now available, introducing seasons and more!
-
-
We are still tinkering with reflective materials. However, actual reflections (except glossiness/specularity) have a major impact on performance, especially since these reflections need to be computed in realtime in Rising World. We have added screenspace reflections, which aren't that costly (in terms of performance), but they have some visual limitations. In the long run, that could be replaced by raytracing.
Actual mirrors, on the other hand, are different. They also require realtime reflections (and we can't work with screenspace reflections here), but since they only consist of a single surface (and it's unlikely that people place lots of them in their house), it's definitely something we take into consideration
In short, mirrors (as objects) may be added in the long run, but when it comes to reflective materials, we will rather stick to some basic reflections here.
Yes, that's planned It's our intention to add snow to higher elevations, and that would also affect the player temperature.
If you guys work on mirrors, please, PLEASE, allow implementing portals they're literally based on the same techniques.
-
Do you refer to a french localization of the game? This is definitely planned in the long run Unfortunately we can't add any other languages than english or german at the moment since we would have to rely on external translators in that case...
Make the translation files available on Github and behold the power of the open source community.
-
We're moving to Unity because Unreal did not have support for Array Textures (which are crucial for a game like Rising World). For the new version we will drop OpenGL support and target DX11/12 on Windows, Vulkan on Linux and Metal on Mac Although it's very likely that Vulkan will also be optionally available in the Windows version of the game.
Thank you for the info! Can't wait to see the first demo!
-
@wesleybruce: Thanks for the DxDiag! Your machine should be definitely capable of running the new version However, if the new version (or the playable demo) is ready and you experience any performance issues, please let us know
Aren't you using Vulkan with Unreal?
-
@wesleybruce: If you can run the current version of the game, it's very likely that you can also run the new version of the game In the worst case, you have to disable certain graphics effects. As @joni909 asked, your system specs would be very helpful in this case
As long as you still offer the game cross platform (I'm on Linux) I do not care about specs; all computers eventually need to be replaced, and upgrading a system is not that expensive. At some point, we need to move forward.
-
At some point, I'd like to test the new engine, and I am certain others will also want that as well.
Luckily, Steam has that feature
Beta testing, I call shotgun.
-
although this does open up a lot of possibilities it also causes a problem. Some of my builds are too large for one bp so I have had to use up to 8 bp to cover the whole build. It has been easy to reassemble the building because the blocks have been fixed to the grid. If blocks are able to be placed in any location as are beams it will be much harder to reassemble the buildings.
One solution may be giving us a choice if we want to place a bp on or off the grid.
I believe blueprints will not be restricted to size, but to the content of materials (i.e. positionss and material types,etc.), and I guess it could even be possible to "align" blueprints much like how many vector image editors allow grid and image alignments. Another solution could be to automatically generate multiple blueprints for one build, and let the game reconstruct them automatically.
-
Thats...awesome, and opens up a great deal of creative possibility!
Yes, like physics for blocks and construction elements
-
I believe most Linux players have Vulkan-enabled hardware. If not, a video card upgrade is quite cheap. In any case, Any computer that do not support Vulkan will probably die out by the time this game releases with the new engine, so having both OpenGL and Vulkan is a waste of time IMO.
-
For blocks, you need that big hammer. Use it to "destroy" the block and you will get a pickable block.
For building elements, i.e. woodplanks, you can use the crowbar to remove them into your inventory.
Nice! Thank you for the info.There should be some info text whenever such block/element is destroyed, so the players knows what tool to use. These info could be enabled/disabled in the options.
-
just long press on "f" key, you will take in yopur inventory the station
I found that out some time after creating this thread. Just press the action key longer, until it picks up the item (I personally did bind it to "E" because it's shorter for my index finger). I tried to pick up blocks, but it didn't work.
-
I'm not sure if this has been discussed, but it is something that I'd find most useful; there should be some way to pickup an item previously placed. For example, placing a crafting station should allow to pick it up and reposition it somewhere else. Currently, all we can do is destroy it and build a new one.
-
In singleplayer, the despawn times can be changed in the settings (see "Miscellaneous" -> "Corpse Despawn Time"). In multiplayer it can be changed in the server.properties file, as mentioned by @yahwho
The default value is set to 30 minutes (1800 seconds), but around 1 year ago, we had a much smaller default value (5 or 10 minutes). If you still have an old "config.properties" file in your game directory, there is probably still that low value set (while we may change certain default values with a new update, we usually never touch existing settings).Alternatively you can check the "Keep Inventory" box in the settings, then you won't lose your inventory upon death
The problem is that I was playing on someone else's server, and there was no one around. I actually have no idea what the timeout is/was. I still find it cheap to have the inventory lost. Anyway. Perhaps this is out of your control, but still pisses me off, and does not encourage me to launch the game to waste my time like this.
And another point I forgot to mention; I was cooking some meat and there are absolutely NO WAY to tell if the meat is ready, but to look at it until it is cooked. And the time period between "cooked" and "burned" is very small. In other words, I burn the meat 50% of the time. On the other hand, as I was cooking the meat during the day, but then night came, I could not see if the meat was cooked because of the fire (and the meat is grey or something against the light of the fire), so I had to pick up the meat, notice that it was still raw, place it back, and had to wait again..... The time seemed to be reset!! Holy Crap! It took nearly half a day to cook the damn thing! Should be able to have some gauge, or some idea of when the meet'd be cooked. For example, have the character make a sound (like sniffing for smell) when the meat is ready, or whatever... better yet, have indicators saying that the meet is "rare", "medium", "cooked", etc. or something. It's just annoying.
-
I hadn't played this game for a while, so I fired it up about three hours ago.
Many things changed. Things got a little more complicated, and confusing. I spent a while figuring out how I could craft a chest (it was a basic crafting thing before if I remember correctly). And I just exited the game about 5 minutes ago out of frustration (again).
Pros
- Lots of new content, animals, crafting, etc.
- New ambiance music is nice
- Freezing over night is annoying, but realistic and nice
- Hunger does not go down as fast as before, and it avoids spending countless hours looking for food all the time
- Bleeding eventually stop, so when I got attacked by a bear, I did not just die out of my blood (though came very close to)
Cons
- Confusing crafting. I actually have ideas about that, but considering how my ideas felt in deaf ears before, meh (prove me wrong, @red51)
- I killed the damn bear, but by the time I went empty my inventory I came back (about 3 minutes)... the damn bear's body was gone!
- I placed some rocks to fill a hole... felt through anyway (the rock) and died with inventory full of things I had spent precious time collecting. When I came back (2 minutes later) my body was NO WHERE to be found. I lost everything. (I did quit at this point)
I did not play longer to evaluate anything else. It was pretty much : spend 3 hours crafting and collecting ores and resources, making tools, etc. then I died and lost EVERYTHING. It takes too long to craft some damn storage!!!
Anyway.
-
am i understanding you have a area called Bobbinfish's ? and that it does not save or it disappears or something like that ?
if so the problem is with the ' try not to use things like ; ', . in the names keep them simple and it should be fine.The problem is most likely because you do not escape the name of the area when you save it in the DB....
Have you heard of SQL injection?
-
Good thoughts. Let's see what red's opinion is on this
[snip]
What I did to prevent this was to add the whole GUI panel as an attribute (player.addAttribute(panel)) to each player when they log in to the server so this way all players have their own instance of the GUI and when I update/change it in some way for one player it doesn't update for all others.
Yeah, the problem is that changing the UI component also means breaking all plugins, this is why I proposed the "uix" (or any other different namespace) name for this implementation. Much like how Java had AWT, then switched to a different framework called Swing later on.Of course, I fully understand the extra weight that this adds to the API, but I really think that this is for the best. And the game is still in alpha, let's not forget that. Changes are bound to happen, and better so early on than later.
Setting player UI to attributes is one thing that gave me a hint of the problem with player UI binding (and how plugins need to manually propagate and sync UI with the player...).
-
This is what I would have expected in a base UI component API for this game (note that I do not have the full implementation code source, so implemented what I managed to get from the decompiler)
Java
And I would propose a few other methods to access various information about the player's screen. My goal is for this game to be easy for people coming from desktop UI design to actually work with something that is widely used, screen coordinates. Having a better API, with more control over positioning and sizes, plugins can use more responsive layout designs. (For example, changing the size of the fonts, making panels bigger when displaying lists in larger resolution, etc.)The argument of keeping a Cartesian coordinate system (vertical axis pointing up, as it is in OpenGL) based on texture mapping is not a strong one. Once the element is vertically positioned using a screen coordinate system (vertical axis pointing down, as it is for nearly all UI frameworks... because this is how humans read, from top to bottom), and it's size set, finding the proper x and y to lay out the texture is trivial. However, laying out a complex UI where elements are arranged from last to first is awkward for the designer. In short, there is no real reason to have a Cartesian coordinate system for UI design, especially when it has no bearing whatsoever on laying out textures during the rendering phase.
Also, note that the base element does bind with one player, and one player only. Why? because there is no sense in having a hierarchical object on the server (where the UI is declared) whose order is not in sync with the structure on the client (where the UI is rendered). For example, a checkbox component child to a panel does not have the same state on Player1 than on Player2, so why would the parent panel be updated on both players at the same time? If UI elements are properly cached on the client and synchronized with the server, there shouldn't be memory leaks and performance should not be impaired by it whatsoever.
** Edit **
A keen eye will have observed that I did not import PivotPosition, and this is because I added some constants to it, in order to facilitate positioning of some elements :Java -
BTW: nevermind also that the mouse coordinates are using the same screen coordinates (i.e. 0,0 is the top left corner) But, hey! whatever, right?
-
tbf I have no idea why you are finding this an issue. It is really not that hard to figure out where the coordinates are, just a matter of willingness to get used to a different system.
The most straightforward way to design anything imo is bottom to top and left to right, I find the top to bottom to be the "weird" wayWhat plugin have you coded that uses the GUI API?
Also note that nearly half of the the listed plugins that do have a GUI are written by Miwarre... And only 2 or 3 others are significant enough that a change would break their UIx. All the others are basically only labels and single menu panels.