[Server] Just Test Tribute

[Festus1965]

I recommend you install rnd's anticheat mod, it deals with these issues quite well ("quite well" is high praise from me in this context)

https://github.com/ac-minetest/anticheat

upps, thanks - how could this have been hiding for so long time even it is older than any of my requests: 6b101b1 on Sep 8, 2017 - I give it a test, just I don't have cheating clones on 5.0.0 now (but just a matter of time, this programmers realize servers with 0.4.x are gone)

[talamh]

I recommend you install rnd's anticheat mod, it deals with these issues quite well ("quite well" is high praise from me in this context)

https://github.com/ac-minetest/anticheat

upps, thanks - how could this have been hiding for so long time even it is older than any of my requests: 6b101b1 on Sep 8, 2017 - I give it a test, just I don't have cheating clones on 5.0.0 now (but just a matter of time, this programmers realize servers with 0.4.x are gone)

I have a heavily modified 5.0 client, what is your server called :)

[Festus1965]

yeah, thanks to VanessaE I lost my Signature, and don't remember what I had in before ...

Server is Thailand Minetest.one (5.1.0-dev)
announced still on same port open, what I have a lot of mismatched clients now ...
... but to be prepared for the future, when cheating clones are coming to 5.0.0 I wanna be ready how it works

[talamh]

yeah, thanks to VanessaE I lost my Signature, and don't remember what I had in before ...

Server is Thailand Minetest.one (5.1.0-dev)
announced still on same port open, what I have a lot of mismatched clients now ...
... but to be prepared for the future, when cheating clones are coming to 5.0.0 I wanna be ready how it works

Thank you, I will check out your server in the next few days.

[iisu]

Have the server send "censored" data in the map blocks its sends to the client. Use a new node "invisible" for the nodes that the player should not be able to see. In the server, calculate which nodes the player should not be able to reach (based on the topology of the terrain and of the player's position in the terrain), and in the map block sent to the client, replace those nodes by the value "invisible".

That's more less what I suggested last year, except my idea was to only care for valuable ores and disguise them as stone until the player is able to see them, based on the player's position and camera angle, if there's no obstruction for the player to see the node.

[Ferret2]

Hello sorcerykid,

Thanks for your reply !

I rewrote the bones mod, and have tweaked it several times to offer a decent balance of challenge and convenience. However, I'd prefer to avoid significant deviations from the expected behavior, particularly anything destructive. That would be unfair to novice players that die of starvation, only to lose have their starter items. Also, I don't want to field endless complaints about missing items :P

It was just a general idea, not aimed specifically at your server. Sorry that I was lazy and posted my idea here instead of searching a more appropriate thread.

What you write sounds completely reasonable.

Thank you for running the server !

[Ferret2]

Personally I don't think modded clients are really much of an issue on well moderated servers, the modders just cant seem to help themselves:

Hi Talamh !

I am new to online gaming in general; this is the first time I'm playing an online game. It is certainly not my intention to tell you guys how you should run things.

The only reason I wrote these things is that I'm somewhat surprised at the quality of software design that is apparently(?) the standard in online gaming. (I am guessing that it is the standard in online gaming, because almost everyone in the minetest community seems to feel OK with it.) I am speaking in general here, about minetest in general, and not specifically about this server. And I mean "surprised" not in the valuative sense, but in the sense of discovering something that is new to me (and therefore interesting).

What I mean is: I'm surprised that almost everyone in the minetest community seems OK with a client-server interaction design where the server sends "everything" (all data, uncensored) to the client, and leaves it to the discretion of the client to be honest and to not actually use that data. To me as a software designer, such a design sounds almost painfully clumsy. This is not meant as dismissive. I do like the minetest game. The idea of the gameplay is very nice. Some aspects of the software seem very well designed (such as the lua modding). The design of the client-server interaction however, I do not feel that that particular part of the design of the software is well thought out.

With a design where the server sends everything to the client uncensored, I think you automatically get these brats who hack their clients. It's a law of nature; vermin grows wherever there is a niche for it. The thing I am surprised at is not that these hackers come in, but that such a well-known and popular game like minetest uses a client-server interaction design that gives hackers so much scope. But I come from outside of the online gaming world. Each world has it own customs and traditions. Probably the gaming world has different traditions (and software standards) than the industrial software world. I am wondering whether online gamers (even the ones who are not cheaters) secretly like the idea of "hacking", and therefore in the software design leave the door wide open for hacked clients?

Please note that my issue is with the design of the software, not with how things are actually run in practice in online minetest games. It may be true that in practice, and on well moderated servers (as you write), hacked clients are not much of a problem. That is very fine and I am glad. I can not help slightly wondering though whether there is a streak in the minetest server operators/administrators that actually likes administrating things, including banning the hackers that appear from time to time, and plugging leaks in rickety software. Maybe running a server would be too dull or too little of a challenge without the hackers? I mean, I'm wondering whether maybe the lackadaysical client-server interaction design in the minetest software is actually an asset rather than a flaw.

That's more less what I suggested last year, except my idea was to only care for valuable ores and disguise them as stone until the player is able to see them, based on the player's position and camera angle, if there's no obstruction for the player to see the node.

Hello Iisu,

Heh, cool !

It's all part of the same underlying idea: Have the server send only data that the client is allowed to see.

I urge you to look on https://github.com/minetest/minetest/issues/6114 at the following two very interesting and excellent posts :

* The post by raymoo from Jul 10, 2017
* The post by beyondlimits from Aug 7, 2017

Both of these develop this same idea. That is where I got the idea from.

[sorcerykid]

Have the server send "censored" data in the map blocks its sends to the client. Use a new node "invisible" for the nodes that the player should not be able to see. In the server, calculate which nodes the player should not be able to reach (based on the topology of the terrain and of the player's position in the terrain), and in the map block sent to the client, replace those nodes by the value "invisible".

A similar concept was suggested by iisu a couple years ago. In simplest terms, it would not be a scalable client-server architecture. The engine would need to recalculate a raycast for every connected player at each server tick to determine what is viewable, while also storing mapblock state information for each client in memory and then sending mapblock state changes to every client. Minetest takes advantage of client-side prediction to lighten the load on the server and to reduce the network traffic. Realistically, what you propose would do the exact opposite in both respects.

Sorry, I don't mean to dismiss your idea wholesale, but it's too inefficient for little gain. This isn't about lackadaisical design. It's about spreading the processing load (aka distributed computing). Minetest clients needn't act as dumb terminals, when they are perfectly capable of full scene rendering and player movement :)

A more feasible way to handle cheating of this nature is to record player activity, and then flag unusually high deviations in digging times. I developed a script that analyzes the debug logs using a fairly sophisticated algorithm. It can detect with pretty high certainty what players are mining with fast, noclip, or long-range. The script first compiles the mining operations (serial digs within a given timeframe) of all players, and then applies a score based on average distance and frequency of digs involving specific valuable ores.

[soupfly]

Hello sorcerykid. My account is deactivated because of inactivity. I would like to reactivate my account. My name on the server is soulwarp.

[Ferret2]

In simplest terms, it would not be a scalable client-server architecture.

Hello Sorcerykid, thanks for your criticism, very good.

I understand what you mean. I had thought about that.

I agree that what we do NOT want is that the server has to recompute a lot of things whenever one player moves a tiny bit or changes their orientation a tiny bit.

Allow me to expand a bit on the idea I had in mind. I think with this idea it would be possible to get most of the desired behaviour (that the server sends to the client only the data the player should be able to see) with relatively little overhead for the server, in the sense that the server doesn't have to recompute things constantly for every little move that every player makes, but only has to recompute some things incidentally, namely when a player digs or places a node at a crucial location.

My idea is based on the topology of the terrain, namely the air spaces that are connected. The complete 3D map of the whole minetest world can be thought of as consisting of two things: (1) the air, and (2) the solid nodes. Where "air" is everything a player's avatar can move through (including water) and "solid" is everything that a player can not move through.

Consider the "air" part of the map. Most of the air in the map would be the air above the surface, which would (typically) be one big connected volume of air. Below ground, there are isolated caves that do not connect to the aboveground air. These are air spaces that are topologically distinct from the aboveground air space and not connected to it. Then there are caves that are connected to the surface, so the air in these caves is topologically the same as that of the aboveground air space. Then there is the air inside houses with steel doors and with no openings that allow access inside. The air inside such a house is also an isolated distinct pocket of air.

For my idea to work, it would probably be necessary to make another step on top of the above picture, namely to also divide up the air spaces in connected cave systems (and in big connected houses) into multiple air volumes, as folllows. Consider a long connected cave consisting of two big rooms A and B, with between them a narrow bottleneck. In this situation the big rooms A and B would become distinct air spaces, with the border between them located at the bottleneck spot. I think finding these distict air spaces divided by narrow bottlenecks can probably be done by running an erosion operation (https://en.wikipedia.org/wiki/Erosion_(morphology)) on the air spaces in the map, and then finding the connected air spaces in the erosion result.

The result of this would be that the air in the map is divided into distinct regions, so that these distinct regions are either not connected to each other, or are connected only by a narrow bottleneck. Each of these distinct regions of air in the map gets its own unique integer label number. This label number is written into all of the air nodes belonging to that region of air. (I.e. the air node labels are stored directly in the map nodes.) Finding the air regions and labeling each air node in the map is done by the server when the map is generated (and when new map blocks are generated).

The crucial property of this air node labelling is that the air regions and the label numbers are the same for all players, and are independent of the location and orientation of the players. The air node labeling is stored in the map on the server (the same map that is used by all players). The map stores no special information about visibility specific to any one player or any one player's current location/orientation.

As long as players do not build or mine, this air region information in the map on the server remains unchanged.

For each player (client), the server knows the position of that player in the map, and the server sends to that client only the map blocks containing the air volume that the player is currently in, censored so that all the solid nodes that are not immediately adjacent to that air volume are replaced by the node value "invisible". (Note that this does not depend on the direction the player is looking in, i.e. in this respect my idea is probably different from the specifics of Iisu's idea.) Therefore, as long as the player remains inside the same air volume, the data that the server sends to the player remains the same. (For very large air volumes of course, the set of map blocks sent to the client needs to be only a subset of that air volume, namely only the map blocks near the player, same as is doubtlessly done in the current software.) Each client is sent only this "censored" data, i.e. data from which the things are removed that should be invisible to that player. Note that the "censoring" means that nodes are made invisible only in the COPIES of the map blocks that are sent to that client. The map as stored on the server is not specific to one client, contains all data, and is never "censored" so that parts are made invisible.

As a result, the client will only be able to see the solid nodes that are adjacent to the air volume he is currently located in. He will not see solid nodes that are deeper inside the rock. And more to the point, he will not see anything of the air volumes that he is not currently located in.

The reason why I suspect it would be necessary to divide large connected cave-like systems into multiple distinct air spaces at the bottlenecks is that it would be probably undesired for example that a player on the surface can see every last corner of large complex connected cave system that is connected to the surface. And similar when a player is below ground in a large complex cave system, I think he shouldn't be able to see the parts of the cave that are far away and located for him beyond one or more bottlenecks.

When a player mines a node in such a way that a bottleneck is widened so far that two previously distinct air volumes become merged, then the server has to re-label the smaller of the two merged air volumes. When a player places a node so that a new bottleneck is created so that a previously connected air volume gets split up into two (or more) distinct air volumes, then the server has to re-label the air nodes in the old air volume. Note that both of these re-labeling operations are local operations, confined to a limited part of the map.

This is only a rough idea. What to do with long straight 2x1 tunnels is still to be solved. (Maybe use a modified erosion operation that mainly erodes corners, and leaves long straight stretches of air nodes relatively intact.)

Please criticize if I am overlooking things.

On top of this making-invisible of distant air spaces, it would still be necessary that the server also checks that players do not move through walls. That should (I think) be simple. Whenever a player attempts to move into another node, the client should request permission to move there from the server. The server already keeps track of the location of each player. When a client requests to move into another node, have the server check whether that move is legal. If the move is illegal, then disconnect the client.

[Ferret2]

On reflection, I now see that the stuff with the erosion and the bottlenecks in my previous post is probably not even necessary.

I think it suffices to simply compute (label) the connected air volumes, exactly as they occur in the actual map on the server, and without prior erosion of the air spaces. (Where "connected" means that a player avatar can pass through, i.e. horizontally the opening must be at least 2x1.)

The client, as usual, request map blocks from the server. The server grants the request and sends the map block (after censoring its contents) only if the map block is not farther than a distance D from the current position of the player. Map blocks that are farther away are not sent (and I think on a request for such a far-away map block, the server should probably disconnect the client).

Such a distance threshold is necessary anyway for handling the large air space aboveground. The terrain above and below ground should (obviously) not be handled differently. With the distance threshold D, the client will not be able to look very far into caves anyway. So the need for the "bottlenecks" (mentioned in my previous post), I think, disappears. This also means that there is no need to handle 2x1 tunnels differently (as I had mistakenly thought before). Everything connected by horizontal 2x1 tunnels and by vertical 1x1 shafts is the same connected air space. So that makes the design a lot simpler and more straightforward than I had thought while writing my previous post.

Note that with this design, it remains possible that a hacked client can look "around corners" inside the same air space. For example in this situation (side view, and assuming that everything is within distance D)

Code: Select all

        . . . . . . . . . . . . . . . . . . .
        . . . . . . . . . . . . . . . . . . .           . = air
        . . . . . . . A . . . . . . . . . . .           x = rock
        . . . . . . . A . . . . . . . . . . .           A = player's avatar
        x x x x x x x x x x x x x . . . . . .
        x x x x x x x x x x x x x x . . . . .
        x x x x x x x x x x x x x x . . . . .
        x x x x x x x x x x x x x . . . . . .
        x x x x x . . . . . . . . . . . . . .
        x x . . . . . . . . . . . . . . . . .
        x . . . . . . . . . . . . . . . . . .
        x . . . . . . . . . . . . . . . . . .
        x x x x B . . . . . . . . . . . . . .
        x x x x x x x x x x x x x x x x x x x


a hacked client will be able to see the point B.

However in the following case where the cave below is not connected to the air space the player is in, the client will not be able to see the cave below, because it will get map blocks in which the cave is censored out:

Code: Select all

        . . . . . . . . . . . . . . . . . . .
        . . . . . . . . . . . . . . . . . . .           . = air
        . . . . . . . A . . . . . . . . . . .           x = rock
        . . . . . . . A . . . . . . . . . . .           A = player's avatar
        x x x x x x x x x x x x x x x x x x x
        x x x x x x x x x x x x x x x x x x x
        x x x x x x x x x x x x x x x x x x x
        x x x x x . . . . . . . . . . . x x x
        x x . . . . . . . . . . . . . . . . x
        x . . . . . . . . . . . . . . . . . x
        x . . . . . . . . . . . . . . . . . x
        x x x x B . . . . . . . . . . . x x x
        x x x x x x x x x x x x x x x x x x x


It seems to me that it is (probably) not very grave when a hacked client can to look around corners inside the same connected air space (up to distance D), because being connected, the player would be able to reach that point anyway. (However maybe it could be serious for traps that rely on things remaining hidden that are out of sight. Such traps, in order to work with hacked clients, would have to be redesigned so that everything that should remain hidden is in a disconnected isolated air space.)

A first easy step would be to implement the checking on the server side for player movement and the checking on the server side that the map blocks that the client requests are within a distance D from his current position. That would already narrow down the scope for hacked clients very significantly.

In such a first implementation, a hacked client would still be able to see (but not move) through walls into disconnected caves and houses that are within distance D. To go one step further and also block the hacked client from being able to see into nearby disconnected caves and houses, the second implementation step would then be to add the air space labeling.

[Master_CJ]

"Access denied. Reason: Protocol not supported." Ideas?

[Festus1965]

"Access denied. Reason: Protocol not supported." Ideas?

wrong client, ... edit: yes that, this server hier is still 0.4.x
a Hello from Thailand / Thomas where you just have been

yeah:
* client 0.4.17.1 - wrong protocol
* client 5.0.0 - Protocol version mismatch. Server supports versions between 13 and 27
We (guess client) only support protocol version 37.

So need to get a client with p between 13 and 27 (between mean from 14 until 26 ?)

[erstazi]

Master_CJ I am getting the same error. I tried even compiling older client and it still errors.
I know 0.4.17-1 worked.
Tried the following with the same protocol error:

• 0.4.14
• 0.4.15
• 0.4.17-1

I tried newer 5.0 and 5.1 and still get the error (thought sorcerykid upgraded to 5.0 but that isn't the case).

In https://servers.minetest.net/list I see the max protocol is 27.

I know for a fact that 0.4.17-1 supports that so something is wrong on the server as other servers that have proto_max being 27 allowed me to connect.

I already PMed sorcerykid about it

Also, for the past hour, no one has been on: http://jt2.intraversal.net/

[843jdc]

I get the same error. I haven't changed anything on my end.
I guess I'm reading a book tonight.

[erstazi]

Oddly enough, there were users showing on http://jt2.intraversal.net/ and https://servers.minetest.net/list but it wouldn't accept even 0.4.13 (tried that as well). Probably bots. Hopefully, sorcerykid sees my PM soon! Stay awesome everyone!

[843jdc]

Welcome to the anarchy world of Minetest.

New people and ideas are always welcome by some people and resisted and scorned by others. From what I've been reading, the developers are in the latter category. And I don't blame them a bit.

A fix for viewing into someone else's locked chests should be relatively easy: if the client isn't used by the chest's owner don't send metadata of the contents.

This ex-admin of Cash's World did NOT enjoy the large number of complaints about hacked clients, bugs with my custom code and bugs in mods provided by other people. I started the server because a server popular with mobile clients shut down and because I got really ticked off at it shutting down a lot without the admin posting a reason to the forums.

I finally got fed up with the hassle and the fact that the server was holding a $2500+ computer system hostage to the Linux platform, on which AutoCAD can't run, and shut the derned thing down. After plenty of notice.

Unkillable players, flying through walls and flying through stone to get to ores are major problems.

I haven't looked at the MT code in at least 2 years. I'm also not a professional programmer and don't consider myself to be an amateur. Just a guy that tries to fix some bugs found.

I agree the server should track player actions much more closely than it does. Servers send out a massive amount of data even for only a few players. But receive a "blip" of data from clients. So tracking players closely will introduce a lot of "player position resets" once the server command finally gets a slot in the transmit queue. Players (ME!) get ticked off fast when that happens often.

Ideas, Dumb and maybe not:
Problem partly caused by the player's ability to change the environment and requiring the server to update the map very quickly for smooth gameplay.
Maybe only show details of items that are close to the player. Everything else is blurred out. But players love to climb tall mountains and see the view :)
Client can store map data locally and use it unless updated from the server.
Initial map data not stored locally is all stone, air, or null.
Server tracks player's position and does not send out map data for local area. Hmm. Not quite right here. Needs to do so but with conditions.
If a node is dug, server then sends out correct node type of revealed nodes. Server and network lag big factor here.
Maybe generate ores as the player digs. Though other players might not see those ores. Player-specific???
I've lost my train of thought on this post. (Might be a sign of age) I've spent enough time on this and refuse to waste any more. Other than to say: "Yes. This game needs a major overhaul of how things are done." Reducing the amount of data that a server sends would be a big step in the right direction.

Better minds than mine want solutions too.

[talamh]

Remember folks this topic is supposed to be Re: [Server] Just Test Tribute

Discussions about how to improve Minetest itself are an interesting but off topic subject and should be posted to the relevant threads.

[843jdc]

Right. Sorry. Interesting, off topic, and a heck of a lot of posts.

[iisu]

Server is dead, mods are asleep. Post off topic.

[erstazi]

iisu: server seems to be somewhat alive. Either bots or minetest clients *are* connecting to it. http://jt2.intraversal.net/

But any client with protocol 13 to 27 (I tried them all) doesn't connect with incorrect protocol. Weird!

Here is a screenshot:

[iisu]

They could be playing on the phone. I won't sink that low to try out the mobile client but maybe someone wants to.

[talamh]

When I get to 5 days without jt2 I tend to turn cannibal, pretty sure iisu would keep for up to 12 months in my deep freeze. What sauce goes best with iisu? pepper sauce or apple sauce, maybe even plum sauce.

Please help me avoid any embarrassing faux pas at my upcoming soiree:

https://www.strawpoll.me/17653179


Edit: fixed typo in poll question.

[aka_anonymous]

They could be playing on the phone. I won't sink that low to try out the mobile client but maybe someone wants to.

I play on mobile and it sucks. And I can't join either.

[iisu]

NOOOO When I get to 5 days without JT2 I turn into a REGULAR PERSON!
@sorcerykid: Save me from becoming another boring blue-collar worker. I don't want to die.