Caves should be dark as fook again.

[2d0x]

https://en.wikipedia.org/wiki/Baghdad_Battery

[shubla]

Code: Select all

boolean inDarkness = true;
for(LightSouce s : sources) {
    if(player.getc().dist(s.getc()) <= s.getRadius()) {
        inDarkness = false;
        break;
    }
}

I think this calculation ignoring wall is O(n) with number of light source per player. When you consider that decision on which object to send to player client is already O(n) in number of total object, then I think this one is effectively O(1), since we must look at all object (including light source) anyway. This seem quite cheap to me if we do ignore walls.

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.

It does get quite expensive with walls and objects blocking light. Even without them it still sounds like a very expensive calculation to make.

What gets expensive is lighting textures. Testing lights vs vertices and vectors is relatively cheap in the realm of 3D math. It is only a couple of floating point calculations per wall segment. When it's a 2D map, it's really cheap.

Granted that the server probably doesn't have a GPU on it for optimizing this sort of thing, which would then make such calculations so fast as to be a non-issue.

I would not call O(n) for each light source for each player or O(n log n) for each player "really cheap" calculations if they are done often. It quickly adds up as we may have a lot of players in caves at the same time.

I guess there could be check if player is in darkness or not only sometimes, but I think that would be silly as it greatly reduces the amount of mechanics that you could have for being in darkness.

[Yorla]

Errr, what? What electroplating has to do with light in caves?

[2d0x]

Errr, what? What electroplating has to do with light in caves?

Battery for flashlights ;D Give us the electrification of the caves & Ilyich Lamp in each hut!

[Granger]

To the supporters of the idea: You are proposing to punish people with low fps and poor vision who use light hack (not only them, but still) while you can have it your way just without using the hack. Why are you so cruel?

You might notice that you would still be able to run with a light hack. I also expect that, should darkness enforcement on the server be implemented, the custom clients will, within a few days, have a nice (or not, depending on viewpoint) skynet tactical overlay to mark the dark areas for you.
So no, I'm not being cruel to people with sight issues or shitty computers.

The idea aims at increasing immersion, with the side effects of slowing down early world cave exploration (as you can no longer stroll through a cave with a gearless fresh-spawn), slowing down development of mining operations (for the same reason) and to attach a cost (in the form of an item sink) to living in cave bases (which currently are easier to create and maintain than surface ones).

[Yorla]

Thank you for clarification. I thought you were all for enforced darkness without compromise. Although I think you all are running before the train - we yet have to see the new cave biome and it's new dangers.
And cave bases... Heh, you are forgetting - Jorb lives in there. Not sure he would like to be bothered to pay with item sink for it. I might be wrong of course.

[Hrenli]

Let's be realistic. For those who wants immersion - switch of the map and roll the camera as close to the character as possible. Done.

Everything else is not cheap technically and even if to be implemented would be done in far future. Maybe client rewrite takes so long because Loftar has something for limited view distance in mind but I very much doubt it (as it's either hackable or bring extra load on the server).

[Ysh]

Code: Select all

boolean inDarkness = true;
for(LightSouce s : sources) {
    if(player.getc().dist(s.getc()) <= s.getRadius()) {
        inDarkness = false;
        break;
    }
}

I think this calculation ignoring wall is O(n) with number of light source per player. When you consider that decision on which object to send to player client is already O(n) in number of total object, then I think this one is effectively O(1), since we must look at all object (including light source) anyway. This seem quite cheap to me if we do ignore walls.

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.

[wonder-ass]

To the supporters of the idea: You are proposing to punish people with low fps and poor vision who use light hack (not only them, but still) while you can have it your way just without using the hack. Why are you so cruel?

You might notice that you would still be able to run with a light hack. I also expect that, should darkness enforcement on the server be implemented, the custom clients will, within a few days, have a nice (or not, depending on viewpoint) skynet tactical overlay to mark the dark areas for you.
So no, I'm not being cruel to people with sight issues or shitty computers.

The idea aims at increasing immersion, with the side effects of slowing down early world cave exploration (as you can no longer stroll through a cave with a gearless fresh-spawn), slowing down development of mining operations (for the same reason) and to attach a cost (in the form of an item sink) to living in cave bases (which currently are easier to create and maintain than surface ones).

competition gives life to games with out it this game would be boring. ruining said competition with tedium is not a good way to do it imo. if you want caves to be spoopy and not a good idea day 1 add some strong creatures in the caves (bats are a joke)

[shubla]

Code: Select all

boolean inDarkness = true;
for(LightSouce s : sources) {
    if(player.getc().dist(s.getc()) <= s.getRadius()) {
        inDarkness = false;
        break;
    }
}

I think this calculation ignoring wall is O(n) with number of light source per player. When you consider that decision on which object to send to player client is already O(n) in number of total object, then I think this one is effectively O(1), since we must look at all object (including light source) anyway. This seem quite cheap to me if we do ignore walls.

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.