Posts by Miwarre

Does anybody know if sleeping has any effect on character stats? I noticed it does not affect health (I hoped it did), but affects hunger and thirst; I make a point of sleeping a little each in-game night, for the sake of realism, but at the surface it seems just wasted time; am I overlooking something? (of course, I am speaking of sleeping while in MP; is SP, sleeping almost does not take time).

Quote from Bogus

You mean only certain biomes in a world set ?

Yes, while exploring a new world, I find that some biomes go on for a looong while, other are smaller and occasionally some span only a few chunks. I cannot link specifically to biome types, as I do not have a statistically relevant base, but I noticed this quite clearly. Next time, I'll try to get some solid figures.

Quote from zfoxfire

Code-wise, a modifier such as a filter for biomes or make them larger should not be hard. It wouldn't be different I'd imagine from the modifiers such as world type or ore quantity and whatever future ones will come but my question is, why limit the biomes? The biomes are massive to begin with so there's plenty of space to do whatever you want.

I know that biomes keep repeating once you go on enough. But this is not the same as having a larger, contiguous area of a given biome.

About they being big, it occurred to me to see the biome changing after only a few chunks, in particularl for 'green' biomes (grass, meadows, pine forest, mixed forest, ...). Maybe I have only been unlucky and just crossed the corners (but I took care to go along X and Z axes), maybe they might indeed be small occasionally.

As currently the servers are not very crowded, this is not an issue now. But once the servers will start to be more frequented (we all hope this will happen, don't we?), it might become difficult to fit a multi-player settlement in those smallish areas.

Anyway, thanks for your comments. M.

Quote from red51

It's not really a bug, so I guess we have to rewrite that part in order to "fix" it. Since it's indeed only a small issue (and we have to concentrate on other features at the moment^^), we will probably fix it somewhen in the future (maybe when it comes to fine-tuning in general)

As there is another, quite reasonable, way to achieve the same result (which I was not aware of), it no longer seems to me that any fix is necessary.

Thanks, M.

Quote from zfoxfire

I think that the original intention of the rake was that it would add/remove dirt in your inventory as you lower/raise terrain. I'd love for the rake to operate a bit quicker. Personally what I do is I use a pickaxe to remove most of the dirt in an area…

Can you imagine? I didn't think about dumping a dirt block in strategic points. Obvious, once someone tells you! This shows how inexperienced I am with RW. Thanks!

Just musing, no clear idea yet. My experience with RW is still limited and then I thought to seek the advice of the more experienced.

1) The current biome implementation includes all biomes in each world, just go on enough in a direction and you cross each of them. This is nice to add variety to a single world and, in perspective, may allow for future relationships between different settlements in different biomes (desert settlements exporting dates and importing tomatoes...). OTOH, it possibly limits the possibility to expand a given civilisation which applies to a specific biome. It also seems to me biomes might have quite different sizes (not sure, but I got this impression by the time it takes to cross each one) and some seem smaller.

2) Would a single-biome world make sense? (for instance, the biome choice could be an option of the world creation dlg box)

3) Or would it make more sense to keep the multi-biome context, but making each bigger?

What do you think? Thanks, M.

Quote from red51

Exactly. But maybe this can be changed in the future <img src="https://forum.rising-world.net/wcf/images/smilies/smile.png" alt=":)" />

Thanks for the reply. Not a big issue, at the moment, but in the future it might be nice to lift this limitation, also because there seems to be little reason ('in-world' reason) for it (mostly an implementation complexity?).

Did I not find it, or the server list in the MP screen of the client cannot be sorted by ping? I assume this to be a rather common and useful sort, isn't it?

Quote from zfoxfire

From a programmer's perspective, I totally agree that backend changes should take highest priority but I think at this point there's going to be a holy war if we don't get water soon

Indeed, indeed! Water should be there! Because it is nice to have and to look at and because it is an important piece of the backend too! Relatively high priority, without dropping anything else for the sake of it!

Quote from zfoxfire

An overview of what is planned still can be found here:
<a href="https://www.rising-world.net/en/page/more/features.html" class="externalURL" rel="nofollow">rising-world.net/en/page/more/features.html</a>

Thank you, I was aware of this list (which perhaps would benefit from an update: it still list things like animals, biomes, etc. as still to implement). Still some of the items in it could probably be left to modding (like for instance a full-fledged (rail-)road system, once the programme supplies the concepts and the behaviour elements).

Quote from zfoxfire

Right now the game is just too early in development for modding to be feasibly. Once the API is finalized then we should see some mods roll out.

Indeed! For this reason, I believe that the implementation of the API should have a relatively high priority. For more than 15 years, I have been a developer of add-ons (the term 'mod' was not fashionable yet...) for Microsoft Flight Simulator, after having been instrumental in understanding how create them and in pushing MS to open the architecture. Add-ons were the primary reason of the longevity of MS FS (almost 20 years in production and 10 versions) compared to all the other flight simulators. Another genre and another time, of course, still I see some similitude and I hope this could apply to RW too.

Thanks for the reply, Bogus.

Things are getting more and more 'interesting'. As at least '\' seemed to work, I removed the EN(US) kbd, as it was messing with other things and, lo!, '\' no longer works!

Anyway, I tried with the following setting in config.properties:

input_console=KEY_BACKSLASH
input_console_alt=KEY_SLASH

and KEY_SLASH ('/') does work even if, on my keyboard layout, it is a shifted character.

I thought it might be useful to know for other with a similar problem.

While using the rake to raise the terrain (right click), I noticed it is possible to fill holes and straighten 'jagged' border, but it seems impossible to complete a shape once all the jags are rectified. For instance, assuming I managed to have a 'hill' (say, just one block high) of this shape:

____
|    \
|     \
|      \
|       |
|       |
|_______|

there seems to be no way to complete the rectangle raising the missing corner. Did I overlook something? Is it a known limitation? Is it by design?

Thanks, M.

The idea is appealing. I would set the spawning rate and probability relatively low, though.

Also it raises the need for some kind of protection. Simply adding chest locks would not be enough, as mice can easily make holes into the wood, if something attracting is inside. Also placing chests in places inconvenient for humans is often no barrier: living in the countryside, I can assure you that they find a way to get there even in the most strange places.

Then? Some horrid chemical? magic spells? rely on metal chests?

Just for the record, while its manifacturing started in Ancient Egypt and Egyptians found a lot of uses for it given its availability, papyrus was not exclusive to Ancient Egypt. For instance, it was used as a writing support in most of the Roman empire up to some centuries A.C.

So, it might be a less specialized suggestion than expected...

Just read a bunch of posts with suggestions. Most of them are meaningful/sensible/interesting (some seems a bit too niche, but.. who am I to tell?), however I have the feeling that many would be quite suitable for a plug-in (or a mod, if you prefer the term). Also, in consideration that the coming switch to Java plug-ins may bring quite powerful possibilities.

So, my question: shouldn't perhaps the core development focus in adding basic features and elements AND in providing a flexible, (and possibly performant) way of creating plug-ins, more than in adding an infinite (but never complete) collection of ready-made 'thingies'? By elements, I do not only mean objects you can place, but as well process steps and (mechanical and biological) behaviour patterns, which could be chained and built-upon by plug-ins.

I think this could allow a more consistent and efficient 'core game' (by spearing dev resources), providing a more robust and polished user experience, even if basic; to which plug-ins could add any sort (many sorts?) of bells and whistles.

A couple of examples. I read many posts asking for a more hostile environment (or with more hazards); personally, I don't like zombies, monsters, demons and 'final bosses' (there are other games for this kind of things) and, if implemented, I would like an option to disable them: for me and for all the other persons with similar tastes (I am sure I am not the only one!), that development effort would have been wasted. Or the other way around, for things I may like and other may find disturbing or distracting. Other posts ask, for instance, for electricity: very nice, but technology is wide, deep and tall! What about the countless chemical reactions, metallurgy processes, nuclear technology, and so on? What about the innumerable forms of life which exist in this planet (or can be thought of)? Once this "slippery slope" entered, there is no end and there will always be some (some? A lot!) missing pieces.

If the plug-in framework could be developed enough to allow a fair part of this to be implemented in plug-ins, the load of implementing specific details could be moved to plug-in developers and the dev team could concentrate on the 'important' stuff.

Just rambling, no well defined strategy, of course. But perhaps it might give someone some idea...

Thanks for reading,

M.

@red51: thanks for the reply and for taking care of this small problem. I did some tests and something strange seems to go on as far as keyboard mngmt is concerned.

The original config.properties files has
input_console=KEY_GRAVE
input_console_alt=KEY_BACKSLASH
(which I'll summarise as "KEY_GRAVE / KEY_BACKSLASH")

Your suggestion is correct in principle as, with the Italian kbd layout, ALTGR + ^ generates the GRAVE character in all text editing programmes. However, in RW, it does nothing. Note that the backslash (\) is directly on keyboard, but it also does nothing. So, I tried modifying the config.properties file, looking for non-problematic key strokes first (using JMonkey symbolic names, correct?).

A -- I tried both KEY_U / KEY_BACKSLASH and KEY_BACKSLASH / KEY_U and:
*) KEY_U does work
*) KEY_BACKSLASH does not

B -- With both KEY_U / KEY_COMMA and KEY_COMMA / KEY_U:
*) they both work but
*) using them to close the console back, the used character is entered into the console and then the console itself is closed (this was not happening in the above setting).

C -- With both KEY_BACKSLASH / KEY_APOSTROPHE and KEY_APOSTROPHE / KEY_BACKSLASH:
*) neither works

Now the fun part!

D -- I reverted to original settings KEY_GRAVE / KEY_BACKSLASH (and its swap KEY_BACKSLASH / KEY_GRAVE) and:
*) KEY_BACKSLASH now does work (KEY_GRAVE does not, at least the AltGr + ' combo does not)
*) and, again, using it to close the console, it leaves a '\' character in the console before closing it.

So, while I can consider the issue solved in practice, as now at least '\' does work, it is probably the case to investigate a little what is going on in kbd mngmt, as:

• the original setting was not working out of the box, but started working after the config.properties file was modified and then reverted;
• as more kbd short-cuts will be needed, sooner or later some of these problematic key strokes will have to be used;
• I doubt this problem is specific of the Italian kbd layout: it possibly affects any (many? most?) non-US keyboards.

Anyway, thanks for the great support!

M.

System: Linux Mint 17.3 (based on Ubuntu 14.04 LTS), 4-core i5 3.33 GHz, 12GB RAM, ATI HD 5770 w/ 1GB RAM, 2 x 1280x1024 monitors: monitor 1 at the left and monitor 2 at the right.

Steps to reproduce issue:
1) Enter full-screen mode (or start-up in full-screen mode): a full-screen window is created on monitor 1, mouse capture works fine and the view direction can be rotated at will.
2) Alt-Tab to another application.
3) Alt-Tab back to Rising World: the full-screen mode is correctly restored in the monitor 1 and everything works, except that mouse capture is lost. I.e.: by moving the mouse to the right (toward monitor 2), eventually it exits from monitor 1 into monitor 2: a standard mouse cursor appears in monitor 2 and view direction cannot be controlled any longer. To maintain standard behaviour, one has to bring the mouse pointer back into monitor 1 and be careful never to leave it.

Windowed mode works fine.

This issue is not really severe and it only shows up in full-screen+multi-monitor setups, I assume; however it is annoying and breaks the game playing flow. If more info is needed, I can probably provide it.

As this is the only bug I encountered in ca. 40 hours of playing RW, I think it to be surprisingly stable for an Alpha! Kudos to the developers !

Quote

It should be the left of the 1 which I guess on Italian keyboard is \ or |

The key at the left of top row '1' is '\' ('|' if shifted) indeed. But it does nothing. Thanks for the suggestion, though.

My setup: Linux Mint 17.3 + Italian keyboard. In this keyboard layout, '~' (tilde) and '`' (grave) are not present, '^' (caret) is present, but is a shifted character. In short, none of them can be used to open the console. I tried switching to the English US keyboard layout and they do work as advertised.

However, it is rather inconvenient having to set multiple keyboards up and to switch from one to another in order to access the console.

I hope something can be done to improve the matter.

Thanks,

M.

P.S.: I tested only the single player mode, but I assume it is the same in multi-player mode.