Since using Minetest 0.4.16 stable on Xanadu it has been noted that quite a few players are exploiting this feature to cheat on server by running bot-chat-text, opening ANY chest to steal items and of course finding ores without the need for digging... Something has to be done to stop this as it takes the fun out of the game entirely and has players complaining of stolen items...

Personally I would like to see this feature disabled entirely but am aware of specific switches available on 0.5.0 to disable certain components of this, which sadly can be re-enabled by pre-compiling your own minetest client with the changes reset...

Server security is more important,

Adds directional lighting and (very subtle) specular on everything, including models, if shaders are enabled. Model shading requires the models to be properly exported with normals (well, obviously...)

Shading depends on the sun (or moon) angle and changes properly during the day/night and eases smoothly during a dawn/dusk transition.

Before/after screenshot:

I just wanted to check if this already done, or planned, or possible. If not possible i am seriously concerned.

Client-provided clientmods that cannot be prevented by a server creates a huge potential for irritating low-level troublemakers and cheaters on a server, and makes trouble much easier to cause. There are already clientmods being distributed on the forum and servers can do nothing to protect themselves.

Before now you would have to hack a client, now it's as easy as installing a mod. Server admin are already driven crazy by irritating client behaviour and now it will get much worse.

I am not asking for removing the ability to use client-provided clientmods, just a way for a server to prevent any connected clients from doing so, or not allowing clients using client-provided client mods from connecting.

Arguing that 'it is already possible with a hacked client' is no argument, it should not be made easier, and not supported and encouraged by the distribution of clientmods that servers cannot protect themselves against.

I seem to remember someone, maybe sofar, discussing this and getting the assurance that such an ability as i request would be added. Has it been? WIll it be? Why has it not been? @sofar was this you and what is your opinion?

/////////////

Here's a specific example of how this will ruin a survival server ..

The oredetect clientmod already in use effectively makes the world transparent around a player to a certain distance, any node can be detected and its co-ordinates displayed. The server cannot prevent this or even know which clients are using it. Some say the range is limited, however the valuable ores from gold to diamond are only separated by 13-17 nodes, so a detection radius half of this is enough to detect almost all valuable ores around a player.

Players with high standards who don't want to cheat in survival will not use the mod, but then will suspect other players are using it and are gaining an advantage, this makes them feel frustrated. Players with moderate standards will see the advantage other players have and will be tempted to use the mod, the more players that use it the more pressure there is for the rest to use it. Players with low standards will use the mod to cheat, and therefore gain an advantage over other players and are rewarded for their low standards.

The whole concept of MT is that 'you can't effectively see through solid objects', but now an unknown set of players can do this, and the server cannot choose, police or detect this in any way. This creates an atmosphere of anarchy, cheating, frustration, suspicion and mistrust, with the worst players having an advantage and being rewarded, having fun, while the server is ruined for everyone else.

I have read the arguments that CSM is harmless because it can only read map and not write to it, however i have explained above how this alone can ruin a survival server.

///////////////

For some servers unregulated client-provided clientmods is not an issue so let them, but at least allow servers to decide and protect themselves. MT has always been about the server providing and controlling anything of significance, and servers have always been able to protect themselves and police what happens.

If it is not possible to add the abililty i request then the only thing to do is to not allow client-provided clientmods at all, as i understand it CSM was originally intended to be server-provided mods only, for very good reason. CSM will then still bring many benefits and server admin will add the reasonable clientmods that players want, but at least it is in a controlled way, it is known what is provided to all players and no-one can gain a secret advantage over anyone else.

@celeron55 please could you consider this issue?

GitHub is being acquired by Microsoft. That means, while it will probably remain usable for a year or so, it will be changing to discourage participating in free software projects like Minetest. EDIT: and to become more “user-friendly,” that is, featureless full of ads user-tracking, service. So we may have to move somewhere.

By the way, it would be nice if you tweet GH your disappointment on the acquisition (unless you like MS, of course—but then you play MC and not MT, don’t you?)

Reported by NiklasGamerHD ✔ on Discord

Minetest version

0.4.17.2

OS / Hardware

Operating system: Android 7.0 Model: Huawei Honor 6A GPU model: unknown OpenGL version: unknown

This PR implements shadow mapping with PSM (Perspective Shadow Mapping), PCF filtering and "colored shadows". The implementation it's originally based in the XEffects shadow mapping examples.

How this works:

1. To be able to make it work with Irrlicht(MT) the Nodes must be added (and removed ) to a Shadow caster list to cast shadows.
2. The draw function in RenderingCore updated to do the depth pass.
3. Render all the nodes that casts shadow in a RTT. 3.1. Render ClientMap depth every 0.2 seconds to avoid excessive drawcalls. 3.2. Render depth for all dynamic entities 3.3. Mix both depth textures in the Shadow Texture.
4. execute standard DrawAll, with the Shadow Texture attached.

The textures used are (3x): irr::video::ECOLOR_FORMAT::ECF_R32F for depth irr::video::ECOLOR_FORMAT::ECF_G32R32F for depth+color(encoded)

Both in 16bits if configured, but the tests I did, anything below 32bits causes lot's of precision problems.

To do

This PR is Ready for Review.

• [x] Calculate sun POV frustum
• [x] nodes added and removed from shadow caster list
• [x] Render depth pass
• [x] Write node and objects shaders
• [x] Vanish shadow on artificial light.
• [x] "Colored shadows"
• [x] Different quality configurations.
• [x] PCF & Poisson disk filtering.
• [x] Tweak PSM distortion function for every quality.
• [x] Wield items shadows.
• [x] Moon shadows.

Future improvements.

• Check if mesh generation is able to remove the shadows encoded in the map

• Depth shaders using standard MT shader.cpp style (I wasn't able to make it work), so we can make things like shadows for waving plants and leaves.

• Reduce drawcalls.

How to test

Go to settings tabs, enable shaders, select quality from Dynamic Shadows dropdown.

The default values are: Ultra low: -shadow_map_max_distance: 80 blocks -shadow_map_texture_size: 512 -shadow_map_color: false -filter level: 0

Low: -shadow_map_max_distance: 120 blocks -shadow_map_texture_size: 1024 -shadow_map_color: false -filter level: 1

Medium: -shadow_map_max_distance: 350 blocks -shadow_map_texture_size: 2048 -shadow_map_color: false -filter level: 1

High: -shadow_map_max_distance: 350 blocks -shadow_map_texture_size: 2048 -shadow_map_color: true -filter level: 2

Ultra High: -shadow_map_max_distance: 450 blocks -shadow_map_texture_size: 4096 -shadow_map_color: true -filter level: 2

The values Ultra Low and Low only work when the map doesn't have too big elements, and even with normal maps it could have some artifacts.

This PR is high demanding because the amount of drawcalls so it's only recommended for slightly modern hardware.

The configuration can be changed within the "All Settings" section -> shadow

Examples:

Configuration:

Examples:

What does the PR do?

1. ARM64
2. The latest version of all dependencies
3. Build using Linux, Windows, MacOS
4. Build in Android Studio
5. Significant optimization + LuaJIT!
6. ~~Localization support~~
7. Fix language problems in chat, inside the game, everywhere
8. Java part improvement
9. Improving everything you want;)
10. Full ReDo everything from scratch!

Did you know that the Android port in MultiCraft has been rewritten to make it proprietary? Was it spent several thousand dollars and hundreds of hours of work, tests and corrections? And then I decided to publish all the source code under the LGPL license!

Note: comments are accepted only from players and developers with experience in developing for Android. Let mapgen-nerds, trolls and other participants silently. Thanks.

Building on Windows for console lovers right now looks like this. ./gradlew.bat assemblerelease

On Linux/macOS ./gradlew assemblerelease

But the best part is Android Studio. Just open the project, connect the phone and press the Run button and after 2 minutes the game will be installed on your phone! Windows, Linux, MacOS!

What's inside?

Gradle clones the repository with ready deps (irrlicht, freetype, curl, etc.) Then he will kindly prepare Assets, compressing it into an archive for very fast copying from APK to sdcard Then he will compile Minetest for arm-v7a and arm-v8a Compiles Java code with support for AndroidX and AppCompat for full compatibility with Android 4.1-10 And finally he will create 2 APKs: arm-v7a and arm-v8a (of course, with different assembly numbers, to meet the requirements of Google Play).

Is it long? Let me show the result of a clean build from my PC: BUILD SUCCESSFUL in 2m 19s 48 actionable tasks: 47 executed, 1 up-to-date https://www.youtube.com/watch?v=MJMUhECMPcY Yes, I have a powerful workstation, maybe it will be 1 minute longer on your PC! Enjoy it.

Based on master branch (last commit at the moment).

ARM: https://github.com/MoNTE48/minetest/releases/download/android/app-armeabi-v7a-release.apk (recommended) ARM64: https://github.com/MoNTE48/minetest/releases/download/android/app-arm64-v8a-release.apk

new/changes:

• sneaking won't actually hover you in the air, releasing shift guarantees not falling down (same as in MC)
• sneak-jump no longer goes higher than a normal jump (^ was required for this)
• sneaking no longer avoids fall damage
• you can sneak on partial nodes (slabs, sideways slabs) correctly

downsides:

• sneaking doesn't "go out" as far anymore (0.29 instead of 0.4)
• can't jump when sneaking out as far as possible (breaks the sneak ladder)

This request adds to possibility to colorize nodes dynamically, using hardware coloring.

How to use: Add color = {r = <?>, g = <?>, b = <?>} to your node definition to get static color. Add palette="image.png" to let Minetest colorize the node dynamically based on the param2. You can add color = <?> to any tile too, to overwrite any global behavior (for example to only allow dynamic color for the top tile of grass).

Advantages: Modders will be able to create colored nodes, while Minetest will not create new textures for them in the memory (unlike texture modifiers). This may make framerate higher on worlds that use a lot of colored blocks for buildings. Makes modders able to colorize nodes based on their param2.

Disadvantage: Old clients are "colorblind". They see the textures without colorization. When shaders are disabled, memory usage is increased (Minetest has to store colors as well).

This pull could add particle blend, glow and animation to particle and particle spawners. Solve #4232 How it looks: https://youtu.be/9y-izjlxPmE Test code: http://pastebin.com/URY3QitQ (outdated) Test texture: http://imgur.com/c5sidRL

[Adopted from #6537]

• Remove hard-coded association of dig and place actions, with LMB and RMB respectively.
  • These actions are still bound to LMB and RMB by default.
• Allow binding actions to mouse buttons.
• ObjectRef:get_player_control now returns dig and place fields. Note: The old LMB and RMB fields still exist alongside dig and place, to ensure backwards compatibility.

Tested, works. This PR is ready for review.

Video demonstration

https://youtu.be/0Ca7nEMiq_U

How to test

• Suggested keymap to test this PR:

  keymap_place = KEY_KEY_L
  keymap_dig = KEY_KEY_X
  keymap_inventory = KEY_LBUTTON
  keymap_jump = KEY_RBUTTON
  

• Tweak repeat_place_interval, and test it by selecting a place-able item (e.g. a node), pointing at a node, and holding down the "place" keybind.

Due to code changes around keypress detection, it's advisable to also test various digging, placing, use-ing, and secondary_use-ing scenarios, and carefully observe that nothing has broken. Note that this PR doesn't modify any part of the actual digging and placing, even in a subtle manner. So if a change is noticeable, please do let me know.

I've excluded the docker build since it would probably require a modified Dockerfile, and Ccache did not work with macos and VS 2019 builds for some reason.

• Goal of the PR: Speed up the CI
• How does the PR work? It uses the github action cache together with Ccache to re-use previous compilations.
• Does it resolve any reported issue? Yes, it resolves #11667.
• Does this relate to a goal in the roadmap? I don't think so.
• If not a bug fix, why is this PR needed? What usecases does it solve? The usecases are already mentioned in the Issue.

How to test

• Fork this branch
• Enable github actions on the fork
• Wait until the action for the forked branch completes
• Do a change in, for example, the build.yml workflow file, create a commit and push to the forked branch
• Wait until the action for the forked branch completes
• Compare the times between the first and second github action runs

Minetest version

Minetest 5.6.1 Android

OS / Hardware

Operating system: Android 6.0.1 (SDK/API lv 23) CPU: MediaTek

GPU model: Mali OpenGL version: ES 3.1

Summary

I see these error text keep appearing after some seconds, not only this world but other too and i dont see something like this happen in 5.5 or 5.4

Steps to reproduce

i dont know, try:

1. Install Minetest 5.6.1 on Android
2. Create a world and join
3. wait some seconds... (if still not, try build something)

Problem

AFAIK, on magnification, the purpose of bilinear filtering is to make images blurry (aka smooth). (And on minification, it can maybe be useful to avoid certain types of aliasing if you're moving the camera, though I'm not sure if that's really the case if we also have mipmapping enabled.)

However:

• Most subgames and mods in minetest use 16x16 textures, and a blurry style is not wanted. We even have a texture_min_size setting (default is 64) to avoid blurriness to some degree, this is ridiculous.
• Whether bilinear interpolation is enabled or disabled for a surface should be decided by the modder (or texture-pack creator), and not globally by the player. This is a violation of minetest's design to give the server control over content. I.e. a modder or texture-pack creator might want to enable it if it's a high resolution texture with smooth gradients.
• Bilinear filtering can make some things more complicated. Ex1: Edges of sprites with transparent pixels look different if alpha mode clamp vs. blend. Ex2: Texture atlases are probably not as easy with bilinear filtering.
• Also, we don't currently allow to set e.g. GL_NEAREST_MIPMAP_LINEAR minification filtering (choose nearest from mipmap level, and lin interpol between 2 levels, aka trilin without bilin). (Which should be the default imo.)

Solutions

Change irrlicht to allow to set any texture filtering mode, and minification and magnification separately. Then, always keep the mag filter at GL_NEAREST (we don't want blurriness after all). Add a setting to change the min filter freely. (Alternatively, interpret the current mipmap, blin and trilin settings to choose the filter. (Though trilin without bilin is technically not to be called "trilinear", but rather "linear".)) And remove the ugly hacks, like texture_min_size.

Alternatives

Remove the bilinear filtering setting and all our hacks associated with it. The downsides overweight.

Additional context

See also: https://www.khronos.org/opengl/wiki/Sampler_Object#Filtering

Minetest version

Minetest 5.6.1 (Linux)
Using Irrlicht 1.9.0mt8
Using Lua 5.1.5

Summary

server_description = foo is set in dedicated server conf, but it is not shown in the client's favorite list

Steps to reproduce

configure a server, add IP to client

collisionMoveSimple as reported in the profiler (F6) mixes client and server calls, which is both incorrect and not useful.

This PR simply reports them separately.

How to test

Start any game in singleplayer mode, open the profiler, see how you now see collisionMoveSimple separately for client and server.

This is inspired by portal-based occlusion culling technique (https://www.youtube.com/watch?v=8xgb-ZcZV9s).

Every mapblock side is treated as a portal, and the map is walked recursively through the portals. Simple logical rule appled - a 'far' side of a mapblock is visible if :

• If adjacent 'near' sides are see-through (block is not occluded, and adjacent block does not have a solid side)
• If opposite 'near' side is see-through, and it overlaps the 'far' side (so called dominant axis in the look vector)

A side is traversed if it's visible and not fully solid, otherwise it's marked as opaque for the next mapblock.

To do

This PR is Ready for Review.

How to test

0. Configure server parameters to send more blocks by default:

max_block_send_distance = 40
max_block_generate_distance = 40
block_send_optimize_distance = 40
client_unload_unused_data_timeout = 6000
client_mapblock_limit = -1
max_simultaneous_block_sends_per_client = 80

1. Enter MTG and set view distance to 400-600
2. Enable F6 profiler and F5 graphs
3. Flip between /set occlusion_culler new and /set occlusion_culler old
4. Mark the change in updateDrawList value, MapBlocks drawn, Time non-rendering and jitter %
5. The game must work more smoothly even with large number of mapblocks loaded.