Caves should be dark as fook again.

[Ysh]

Player moves. It's O(n) being done every server-tick for every player that is in cave, because the state of being in light or not may change as the player or light sources move. I am also pretty sure that the server currently does not iterate through every object that is near the player every server tick.

I do not consider this point. Do you know when or how does server evaluate when to send object? It seem to me that object changed/removed messages are sent at consistent positions, which I think will imply that it is not checking my position on timer, but rather every time I move. If this is the case, then I think my point still stands. I admit that I do not study this game that closely though.

It will probably check characters position. But it will not iterate through objects that often.
When characters position moves, so that it will unload/load new areas with objects, it will tell the client to remove objects from areas that client should see no more, and load objects from areas that client will now see.
Each object will only be iterated once when the server sends them. And once when the server tells client to unload them. Of course, sometimes objects positions or other data about them may change, then server will send that to the client, but only for that 1 object that changed.

So then your guess is server have world subdivided into some low resolution ''visibility grid.'' Each visibility grid tile will know which object is within it. When player moves, server checks if player position changes visibility grid and then removes objects within grid that have left range and add new objects for grid that have entered range. This seem to be reasonable system to me, and if this is the case then I do agree it seem this problem of light source is not so trivial.

[Granger]

So then your guess is server have world subdivided into some low resolution ''visibility grid.'' Each visibility grid tile will know which object is within it. When player moves, server checks if player position changes visibility grid and then removes objects within grid that have left range and add new objects for grid that have entered range. This seem to be reasonable system to me, and if this is the case then I do agree it seem this problem of light source is not so trivial.

Given what can be derived from how the world behaves the server stores the map in minimap sized tiles (visible through how decay, biome growth and forage respawns behaves) while batching of object updates to the client happens using a smaller grid (visible when using a non-default :cam and moving around).

But the granularity the clients get their updates in is irrelevant to potential server-side light level checks.

[vatas]

I remember hearing about "exploit" people used before client night vision: making shit ton of alts and having their HFs act as light source in caves. This would be bit more time-consuming because you'd have to build Beacon for every alt, but still doable.

Forcing characters to crawl speed on darkness and making them unable to see forageables would be somewhat sensible compromise. Making character's trip for concussion sounds neither reasonable or realistic.

[Ysh]

But the granularity the clients get their updates in is irrelevant to potential server-side light level checks.

Topic of technology feasibility is relevant to topic of implement suggesting.

[Granger]

But the granularity the clients get their updates in is irrelevant to potential server-side light level checks.

Topic of technology feasibility is relevant to topic of implement suggesting.

What I said was that the way the client is updated (which you talked about) is completely irrelevant when it comes to the question of the computational cost for checking if (or how well) the character is lit.

[Ysh]

But the granularity the clients get their updates in is irrelevant to potential server-side light level checks.

Topic of technology feasibility is relevant to topic of implement suggesting.

What I said was that the way the client is updated (which you talked about) is completely irrelevant when it comes to the question of the computational cost for checking if (or how well) the character is lit.

If it were the case that this lighting calculation can piggy back off of existing client update, then this will establish there is no question of technology feasibility. In this case it is not irrelevant at all. Of course, this case is not reality, but I did not know this when I make those postings! This is why I make them, so that we can have some discussion and the participant can become enrich by it.

[Vassteel]

I would like a toggle for cave darkness for aesthetic reasons


thank you make it happen jorb, loftar.

[Avu]

I suggest the darkness lovers lead by example and cut themselves from the power grid. The side effect will be of course they stop being able to make the game more tedious...

[rhzk]

viewtopic.php?f=40&t=63830