Posts by Miwarre

For the moment being, I am not concerned with a number of points you quote ('riding' the boat, boat hitting underwater rocks and so on); they need to be solved of course, but I concentrate in distinguishing between the inside and the outside of the boat to make it empty of water. Let me see if I understand you correctly (and putting aside leaks, they are not the most important point; we may even assume boats never leak, no matter their design):

IIUC, you say: when placing the boat, any point which is above an underwater piece of the boat is 'inside' the boat and is therefore clear of water. This is a nice approach (which does not take into account rudders, propellers or bulbs, but these are possibly secondary details). The biggest shortcoming I see is that this assumes the boat is never going to tilt, but it is always displacing 'flat' on the water, so that the boat model Y axis is always pointing straight up and never slanted.

Even under those assumptions, one can imagine that a reasonably shaped boat is not going to be made of cubic blocks, but of planks, arranged in either a horizontal sequence of 'ribs' or a vertical sequence of 'bands' (and possibly both); each rib or band will be made by several planks each with a different 3D orientation and each plank, in principle, can be partially below and partially above the floating line. If this is not considered quite accurately, it is possible to end up with portions of 'world chunks' filled with water inside the boat and/or void of water outside the boat. So, it seems to me even this approach turns out not so simple and quick. Am I overlooking something?

Forum members keep posting screen shots of wonderful creations, but I still seem unable to solve an apparently simple problem: putting a roof on top of a building.

First of all, at least in my country (Italy), roof slopes average around 20° (raging approx. from 16° to 25°); this is way below the 45° slope easily obtainable with blocks. For a simple, rectangular building, I tried both the 4-side roof and the 2-side roof solution using wood planks, but I could achieve neither. The discussion below assumes 1 block is 50cm.

The 2-side roof in itself is easy to build with planks to whichever slope one likes. The problem is to fill the triangular 'hole' remaining between the roof and the building walls at the sides. The top angle of this triangle is 180° - 20° * 2 = 140° (for a 20° roof slope) and the less acute triangular plank one can make has a 90° top angle (<= triangle 1 block wide and 1/2 block high); more than 90° seems impossible (yes, I know that triangle plank is not officially supported, but what anybody else does to achieve this?).

The 4-side roof, in principle, could be made by tessellating each side with triangular planks (alternating one row of up-pointed triangles and one row of down-pointed triangles, as triangles can only be isosceles and cannot be wider than 2 blocks = 1 m).

The shortest triangle is 1 block high (= 0.5 m) and, of course, would give a roof slope of 0°, which is not good! The minimum height increment is at 0.55 m, which gives a roof slope of 24.62°, almost at the maximum, but still acceptable. However, this raises two problems:

1) the nearest plank slope achievable by plank rotation is 25°, which seems quite near, but over the full height of the roof it accumulates to a noticeable gap between the edges of the roof sides.

2) the X, Y and Z displacements from one row to the next are irrational and I found it impossible to place the second row decently contiguous with the first (and the third with the second and so on): the result looks more like a casual patchwork than a reasonable roof.

Am I forgetting / overlooking something? How do other users approach this issue?

Thanks, M.

Hoping it can be useful for somebody, below there is a component function (so, not a complete script) which returns the player heading as a route number, as used in aircraft / ship navigation (N = 360, E= 090, S = 180, W = 270 and other in between). There is plenty of script examples into which to plug this function and have an on-screen output.

Notes:

1) The function accepts as parameter an event, of the same type of the events passed to many on<Event> callback functions.

2) It is customary to represent routes as 3-digit number with 0 padding (as in 090 for E); the function just returns an integer, to be formatted at wish.

3) For N only 360 is normally used, never 000. The function returns 360 if coming from W and 0 if coming from E; adjust if this disturbs you.

4) I exceeded with comments to clarify the steps; reduce them, if you prefer.

5) Even if the scripting framework is going to change to Java, for a purely computational function like this, conversion should be straightforward.

-- global variable: 180 / PI to convert radians to degrees
rad2deg    = 57.295779513;


function playerHeading(event)
    -- Get the rotation of the player
    local playerRot    = event.player:getViewDirection();
    -- x- and z-components of the viewing vector
    local rotX        = playerRot.x;
    local rotZ        = playerRot.z;
    -- if the viewing vector is not horizontal but slanted up or down,
    -- the x and z components are shortened: scale them up until
    -- they are the catheti of a triangle whose hypotenuse is long 1
    local scale        = math.sqrt(rotX*rotX + rotZ*rotZ);
    local scaledZ    = rotZ / scale;
    -- get the angle and convert to degrees
    local heading    = math.acos(scaledZ) * rad2deg;
    -- hdg is correct from N (0°) through E (90°) to S (180°)
    -- then, when view is toward W, it decreases down to 0° again
    -- when view is toward W, correct by taking the complementary angle
    if rotX > 0 then
        heading = 360 - heading;
    end
    -- round to integer
    heading    = math.floor(heading + 0.5);
    return heading;
end

Quote from Meltron

The problem I have with most suggestions is, that their time is yet to come

Indeed, and I assume most of the proponents know about this, but as dreaming comes at no cost... Still, when the time comes for some addition with a significant effect on the game dynamics, I believe that balance, playability and tolerance for different tastes and gaming perspectives should remain in the mind of the developers (whom I trust completely) and of the users asking for additions!

I might be wrong, but I have the impression that discriminating the inside from the outside of any reasonably shaped boat/ship moving around (to keep it free from water) is going to be quite heavy computationally (and detecting leaks is going to be very heavy!).

As a reference, currently the code does not stops light flow (which is comparable) even within orthogonally placed walls/planks.

More ramblings, this time about 'realism'. As usual, comments, integrations, criticisms are welcome!

The quest of 'realism' looks tricky to me. On one side, it is intriguing: reality is in fact our ultimate meter for any 'simulation'. We like that things behave in a 'realistic' way: things have a weight and fall down (including ourselves and our breakable legs), fruits ripen, water flows (it will sooner or later, willn't it?), doors turn and you cannot pass through walls. So, we likely appreciate that a game like RW will mimic as many aspects of reality as faithfully as possible.

On the other hand, reality is HUGE, hugely DIVERSE and hugely COMPLEX. And the quest for 'realism' is doomed to fail or at least to fall short, VERY short (hugely short), of its target, no matter of the efforts spent.

Partly because each simulation has a limited amount of resources available. But also because not everything can be simulated. And this is my MAIN POINT.

I'll use orienteering as an example. Walk in a countryside and, with a little care and paying some attention, you can usually place yourself reasonably well. Noises, scents, distinctive alignments (or misalignments) of things, the specific shape of a tree, the specific colour of a rock and so on; if you are in an unfamiliar terrain and know you have to come back, even without compass, clock and field for your mobile, with some care and taking some notes, usually you can rescue yourself (unless you are harmed or impeded).

Some of these details cannot be simulated (or are very hard to simulate) by any computer programme; some are quite hard to simulate specifically in a procedurally generated world (like RW's). Estimating angles is one thing when all you have to do is to turn your head and another when you have to rotate the POV of a camera, as in any 3D simulation (this is why looking for a specific point is harder when looking in a binocular); same for guessing distances.

This means that navigating a simulated terrain is HARDER (possibly much harder) than navigating a real terrain. And to keep a 'realistic' difficulty level, some 'unrealistic' help (or short-cut) needs to be added! Which one to add might be a matter of personal attitude and taste, but some must be! The same effect rapidly escalate when more structured tasks are involved.

How does this apply to RW? For all the frustrations, limitations, waiting time which a yet-to-finish programme cast upon us, we are in the privileged position to look at its growth with some margin of influence on it. It is obvious that RW is going to be more 'realistic': I believe it QUITE important to remember that any increase in 'realism' requires a corresponding increase in 'unrealistic' helps and props, otherwise the result will be unbalanced and that we keep confronting our 'realism' requests with this necessity.

Thanks for reading, M.

P.S.: The above thoughts derive mostly from my experience as a programmer in the flight simulation field. It is well known that piloting a general aviation craft is HARDER than in reality (but less risky! ) and piloting a simulated helicopter is MUCH harder than in reality (which is not easy to start with), because in a simulation we lack a number of hints our body and our senses collect from the real environment which the simulation does not (possibly cannot) convey. The example is quite specific, but I believe a general pattern can be extrapolated.

This sub-forum abounds in nice, interesting, enticing suggestions. While almost any and each of these suggestions make sense in itself, I would like to raise a few words of caution. Of course, these are just MY very subjective opinions and I am interested in reading other opinions.

Complexity: The more complex the world around you, the more complex becomes interacting and coming to terms with it. This is of course positive in itself, as it makes the game more interesting and involving. But:

1) More choices mean more complex UI: more menus, more short-cuts, more actions (mouse or whatever) to learn (and remember!).

2) A more elaborate crafting tree, (including cooking, fishing, farming, herding, etc.) means the character progression becomes slower and sequences of steps harder to remember.

3) Same for a more proactive environment (both on the hostile and friend sides).

The cumulative effect of all this is a steeper learning curve before the game become really involving as well as makes easier to forget some (essential?) detail, if one does not keep playing the same game every day. Consequence: more users lost along the way (as an example, let me quote Wurm, which in principle I like and try to play every now and then and I never remember what is where and how to reach this or that (relatively simple) goal).

So, I believe that:

A) OF COURSE, the game has to be expanded above the current, preliminary, level, but actual playability for the 'average' user (opposed to the power, dedicated, user) has to be kept in mind.

B) Each of the expandable sides listed above (UI, crafting, environment, ... more can be added) may attract someone and repel someone else.

I for one, should I be forced to spend a sizeable part of game time and/or having to band with other users (and what about single players?) in order to dispel hordes of ferocious beasts, gangs of evil bandits and gaggles of voracious rodents, before having the opportunity to dig for ores and collect supplies to craft components to build my/our villa/village/castle, possibly subject to earthquakes and other disasters, I would quickly loose interest in the game but I would miss the beautiful landscapes, the nice construction and terraforming system and so on (and the water!!! ).

In summary:
A) Balance between enticing richness and overwhelming complexity.
B) Trying to make the different sides of the complexity not (or not all) mandatory for the playability of the game.

Finally -- and sorry to repeat myself --, I believe mods/scripts/plug-ins (whether by third parties or 'official') can be part of this, leaving the addition of specific challenges and distresses or of specialized tasks to them, for the users liking them.

Thanks for reading these ramblings, M.

Detaching the bed frame from the mattress (and pillow!), so that one can make his own frame with planks and beams in a specific style seems an excellent idea to me too.

However -- and sorry to repeat myself --, more cultural variety (for beds or for other elements) in the ready-made pieces needs some care. No matter how many cultural variations will be added, some will lack; this would add a significant burden on the development team for minute details, each of which is likely to be used by a tiny minority of the users.

This seems to me a perfect use case for mods, assuming the mod/script/plug-in framework will allow to use custom meshes, as I believe it should (eventually).

Ok, if 2) is a known bug and will be fixed, it's fine!

Of all the short-cuts listed in 1) and 3), IIRC only [Right Ctrl] appears in the Settings dlg box. I have no problem in editing a setting text file, but I know from personal experience that:
1) settings and configurations not exposed through a specific dlg box can result in increased user support load;
2) many users do not even look at the settings dlg box and therefore a consistent default set of short-cuts is important for the user experience.

Not urgent, of course, but sooner or later it will become relevant...

Thanks,

M.

Thanks for the reply. The whole now makes sense and shows that it has been throughout reasoned. It will probably require a change of perspective from my part, but this is not necessarily a bad thing!

While pulling the few hairs remaining on my head trying to place blueprints, luckily I discovered this thread (thanks to @Ruxandra for raising the topic and to @red51 for the answer)!

Now, I notice:

1) To "freeze" a blueprint you are placing, [Left Click] is used, while to freeze construction elements [Right Ctrl] is used.
2) To raise / lower a (frozen) blueprint, [NumPad +] / [NumPad -] are used, while with (frozen) construction elements [PgUp] / [PgDn] are used

Also, with the terrain tool:

3) in Mode 1 (Add/Remove), [Left Click] adds and [Right Click] removes, while in Mode 2 (Smoothing), [Left Click] smooths by removing and [Right Click] smooths by adding.

Is there a reason behind this discrepancies?

(Aside: Some of the short-cuts listed above can be customized, other cannot. Even assuming in the future all short-cuts will be customizable, a consistent default set of short-cuts is important for the user experience and to ease the learning curve)

This is the stair with the correct calculations:

The stair is adjusted to really have a slope of 30° (horiz. step: 30 cm, vert. step 17.5 cm => slope: 30.26°, which is near enough) and the bottom plank sloped at 30° quite nicely matches it. Steps have a little overhang: the front overhang is intended, the other are supposed to be hidden by the building walls.

Thanks to the new construction system, making this stair has been quite fast, once fixed the project. THANKS RISING WORLD!

Thanks for your reply, @Deirdre.

In fact, I re-evaluated all my reasoning and I found it WRONG! In fact, having horiz. steps twice as long as vert. steps DOES NOT mean the stair has a slope of 30° at all! Doing the correct calculations shows that my stair has a slope of ca. 26.57°, while the sloped brownish plank has a slope of 30° indeed!

So, Rising World is RIGHT and I was WRONG! Sorry for the noise!

M.

This surfaced during some tests for making stairs. The test stair below has been made with vertical white planks 15 cm high and horizontal black planks 30 cm deep:

(Notes: all sizes assume a block size of 50cm and all placements have been done with the default rot., size and mov. steps of 15°, 1.25 cm and 5 cm respectively).

As horiz. steps are twice the vert. steps, the stair should have a global slope of 30° (sin 30° = 0.5). However, when I added as a reference the reddish plank through the stair with a slope of 2 rotation steps ( 2 * 15° = 30°), it did not match the stair slope. In fact, as the slanted plank spans 7 horiz. white planks and 6 vert. black planks, it has a slope of approx asin ( 7 / (2*6) ) = 35.7°, rather than 30°. (Just in case, the stair is oriented N - S, starting at N and raising toward S and all planks have been rotated around one axis only).

Now, the difference is too large to be a consequence of rounding / conversion errors. I repeated the tests four times, trying to be as careful as possible. It might depend on something I did or on some issue with rotation commands.

Suggestions are welcome!

Thanks, M.

Thanks for the clarifications. If it is intentional, by definition it is not a bug. This means there are reasons behind this, perhaps involving the balancing of the user experience or something like. Still it looks a bit strange to me: on an MP server, time looks to me like an "external resource" which should not suffer alterations.

In fact, I can imagine in-game time being (eventually) the same across all servers (if actual sync is problematic, deriving the in-game time as a function of the server system time should be enough, as system time is itself usually synchronized to some external reference). If and when time will be relevant (seasons, moon phases, cyclic or timed events, ...), knowing their timing in advance could allow a better planning of player actions... But this is just my opinion of course!

Thanks, M.

Quote from red51

Unfortunately I was not able to reproduce this issue Does it only happen when going to bed at evening (i.e. earlier than 0 a.m)? To you play regular singleplayer, or are you eventually running a LAN server (the red button in sp menu)? Do you play in Survival or Creative mode?

Well, I did some more tests.

1) When it happens (see below), it happens if starting sleeping before 0:0 AM (it does not happen if starting sleeping at =:01 AM or later)

2) IT DOES HAPPEN with ONE of my worlds (seed 2950725939522, Time "28.3.0 4:8:0.49202484") in Survival mode.

3) IT DOES NOT HAPPEN with ANOTHER (same seed, Time "6.1.0 17:12:0.17675006") in Creative (which I did not run for long, as you can see)

4) IT DOES NOT HAPPEN in another local Survival world I just created (seed 389982143520592, Time "4.1.0 8:0:0.9141446").

5) I did not try what happens by changing mode while in-game through the console command.

6) Locally I always use single player mode, never "Open to LAN", so I don't know if this is relevant or not.

7) It also happens in both servers I tried at some extent. Just for the record, they are "[DK] RisingAge" and "- Mixeland -" (I don't know their seeds; both are running since a while).

No idea if the seed and / or the game time are relevant, but I kind of suspect game time has a role in this...

This is about multi-player mode; for a single-player discussion see Night-through sleeping in single player: 5 days?.

If one goes on sleeping in multi-player, the outcome if different according there are other players or not:

• If there are other players, the sleeping goes on indefinitely in regular game time.
• If one is the only player of that server, the sleeping quickly goes through the whole night and in a few (real time) seconds one awakens at the morning, exactly as in single-player mode.

Note that the case 2. is affected by the same 5-days-later bug described for the single-player mode.

Is this difference intentional?

Thanks for the reply.

Quote from red51

But since plant growth or spawn/despawn behaviour only depends on realtime, it's not affected by that.

Do you mean that things go on (for instance plants grow) even when the game is not running? Better than I assumed or expected! (Of course, I imagine that things do not really go on, but rather the game will 'catch up' at next restart. isn't it?)

This thread is about sleeping through the whole night in single-player mode. I have some observations about MP too, but I'll use another thread. As it is well known, in SP mode, activating sleeping and waiting, quickly moves you through the whole night to awake at 7:45 of the morning.

HOWEVER, according to the data in the F3 screen, it is NOT the morning of the next day, but the morning of FIVE days after (for instance, if you start sleeping at 23:00 of 01/01/0001, you do not awake at 07:45 of 02/01/0001, but of 06/01/0001).

1) Is this intentional?

2) Does this affect the whole game timing, for instance plant growth? item re-spawn? something else I cannot think of?

Quote from zfoxfire

I believe that sleeping does randomly heal broken bone stat but currently the broken bone stat doesn't have any negative impact on survival. The other use of course is that sleeping in a bed will update your spawn point.

Thanks. Almost all my characters have broken bones (I seem to happily keep falling in any hole!), but so far none healed, my regular sleeping schedule notwithstanding; perhaps it takes really long... Indeed, this has no effect on character performance, still that icon bothers me nevertheless...