What's Minetest still missing over Minecraft?

[Casimir]

Looking at the screenshots just saw two things that make MC look good: The local shadows are much stronger, making the blocks look more defined and 3-dimensional (probably what rubenwardy refereed to). The fog looks more like real fog, they do it with a little bit more darker gray, where in MT it is plain white. Together with the textures it looks quite flat, bright and has little contrasts.

And yes; all the UI things in MT are horrible to make and define.

[Linuxdirk]

In Minetest you’ll see a more or less abrupt brightness change on nodes (it’s even worse when moving and new parts of the worlds are loaded).

This happens only with shaders disabled. With shaders enabled, the day-night transition should be entirely smooth.

Then it’s broken. (Maybe by design)

Lights are also (very slightly) colored in Minetest.

Ok, where? To me it all looks the same more or less bright.

[jp]

Lights are also (very slightly) colored in Minetest.

Ok, where? To me it all looks the same more or less bright.

https://github.com/minetest/minetest/bl ... #L129-L146

[SegFault22]

The "game" as a whole is partly the "engine code" which facilitates things being added to the game and making stuff work, and partly the "stuff code" which adds stuff into the game by using the engine code.

Minecraft has some useful API features which facilitate adding a lot of stuff to the game, but it isn't possible for users to add things to the game without changing the engine code. Mod loaders like Forge have come along which makes it a lot easier to change or add stuff - but changes have to be done to the game's engine code in the process of installing Forge code, in order for most of the features to work.

Minetest has a less-developed API for adding stuff to the game, but you can add stuff by creating more stuff-adding code or changing the existing code, rather than having to modify the engine code in order to be able to add or change more stuff than is included by default.
Minetest's APIs need more development - in order to give modders more advanced options for adding stuff to the game, make existing systems for adding stuff run smother and support more advanced stuff, and make some existing systems simpler to use for certain applications. For example, adding an explosion event/ranged damage API (for triggering an explosion at a position) would be very useful for creating logical explosive nodes (such as dynamite, nukes, etc.), which deal ranged damage to entities and nodes upon detonation, while also being able to cause other ranged status effects which may be possible. Also, code for adding lots of similar items in the subgames could be simplified very significantly, by making functions that speed up creating items made of similar material, or creating many similar items.
Then, it will start to be possible to add more full-featured mods, adding lots of advanced, complex stuff without having to do too much hackish Lua implementation - like each mod with Explosives adding its own explosion system, or mods adding lots of similar items and nodes by using many separate minetest.register_item() and minetest.register_node() function calls with a lot of unnecessary duplicate code (which makes the Lua files hundreds of lines long, in some cases). That will bring Minetest closer to being over Minecraft, but it wont be more better than Minecraft until many more mods adding new stuff are created and developed.

[Linuxdirk]

Lights are also (very slightly) colored in Minetest.

Ok, where? To me it all looks the same more or less bright.

https://github.com/minetest/minetest/bl ... #L129-L146

And can we see it within the game or does it only works when resource hogging shaders are enabled?

[4aiman]

Concerning lighting

I'd say that's the "supported devices" feature.
So far there is an official Android client which can't use shaders and some low-end PCs which can't do that either.
I doubt devs would render those unsupported, so all that stuff (coloured lights) should work w/o shaders too.

Minecraft looks good even on minimal settings.
What I can't get is "why C++ code loses to the Java one"?

For example, adding an explosion event/ranged damage API (for triggering an explosion at a position) would be very useful for creating logical explosive nodes (such as dynamite, nukes, etc.)

A perfect copy of Minecraft explosions is doable in Lua right now.
There's nothing "hackish" in using Lua instead of C++ (or else we'd be forced to acknowledge that *any* Lua mod is hackish ;).
That includes blast resist and exposure-based damage calculation for entities.
If I did that using the description from the official wiki, then there are many others who also can.
The only thing you'd miss would be throwing back a player.
But that's a whole another story of where MT sucks.
(Now there IS a REALLY hacky workaround, but it's way too glitchy when playing on a laggy server.)

[Furikawari]

Because AFAIK Minecraft is built directly on top of OpenGL. And please, it's 2015, the debate C++ vs Java is really old dated now (and it's really a feature user dont give a sh** about - and in fact it's what makes Minetest LESS moddable)...

[4aiman]

The only one debating here about "C++ vs Java" is you ;)

My point is if that can be done in Java (MC uses LWJGL to be precise), then why not do that in C++?
I doubt Irrlicht can't provide us with everything needed for OGL.

The tricky part would be to make that work for different renderers (DX, OGL/ES/ES2, SW, BV)

[Furikawari]

Maybe unlike you I read a big part of this thread ;)

And yes, obviously Irrlicht must have some limitations that you won't have when using OpenGL directly (LWJGL is just a wrapper around OpenGL, not a full engine).

[rubenwardy]

resource hogging shaders are enabled?

I imagine that you use a integrated graphics card, or a simulated one - shaders take processing away from the CPU and into the GPU, so should make the game faster. However this may not be the case in Minetest, there may be implementation issues. Correct me if I'm wrong.

[jp]

And can we see it within the game or does it only works when resource hogging shaders are enabled?

That's a shader file, so only when shaders are enabled.

[4aiman]

Maybe I know better what I've read and what I haven't :)
But you're right, once this thread turned into YAMHW (yet another Minecraft holy war) I've left it and re-entered just a couple of days ago.

I still think that Irrlicht's behaviour here is strange. (It's not like I'm able to "fix" that or anything.)
IMHO, it would be so much easier if we had a single GL instead of the variety Irrlicht supply us with.
At least then there would have been a reason to use some patches for Irrlicht.

[Linuxdirk]

I imagine that you use a integrated graphics card, or a simulated one

Nope, just an older one.

And can we see it within the game or does it only works when resource hogging shaders are enabled?

That's a shader file, so only when shaders are enabled.

So I have to wait until my new computer arrives … :( Hopefully this week!

[ArguablySane]

A perfect copy of Minecraft explosions is doable in Lua right now.

Not quite. When someone lights a block of TNT in minecraft, this information is sent to the client which can then start counting down. When the timer reaches zero, there's no apparent delay because the client can make a pretty good guess of what's going to happen. The client renders an explosion effect and throws objects away from the blast almost instantly. When the next update from the server arrives, only very minor corrections will need to be made to player/entity positions and velocities, so the player won't notice.

In minetest everything is done server side. When the TNT explodes there's a slight delay between the server simulating the explosion and the client finding out about it. Depending on your ping to the server, this could become very noticeable. Also, as you say, there's no good way to simulate knock-back of the player, and I'm not aware of any way to do things like shake the screen either.

[AnxiousInfusion]

Hello all,

Just a quick thought: having to install mods to have something that starts to be interesting is not a user-friendly approach. It bothers me as a developper (to have to install mods), so I can't imagine how many people stopped after trying a few minutes... For example, no mob is just not acceptable imo.

+1

There needs to be a complete feature set which is consistent across all users by default. Why must those who want to run a vanilla game or server suffer through finding all the right mods? And let's be honest here, most mods (for any game, not just Minetest) are amature, inconsistent and at risk of falling out of being updated.

[rubenwardy]

as said in IRC:

<rubenwardy> I think that Minetest Engine should be a base for (sub)games, not for modding. The point of a game is to be fun, and yet we force users to download mods and do the work themselves to make it fun. We end up with an Engine and no good, complete games.
<rubenwardy> Modding should still be possible, but it should be used to add, eg, area protection and utils rather than gameplay features
<rubenwardy> or to extend a subgame without editing the subgame
<rubenwardy> the issue is what we do with Minetest Game.
<rubenwardy> There should be two core developed subgames. One is minimal and intended to be used to make your own subgame
<rubenwardy> the other should be a default Minetest Game which is playable enough already
<rubenwardy> The current philosophy is that by making a bare minimum game, players are forced to download mods to make it fun. If we had a complete subgame, players would download new subgames in order to get variety and refresh the fun-ness of Minetest.

[4aiman]

Not quite. When someone lights a block of TNT in minecraft, this information is sent to the client which can then start counting down. When the timer reaches zero, there's no apparent delay because the client can make a pretty good guess of what's going to happen.
...
In minetest everything is done server side.

It is clear enough I was talking about re-implementing the algorithms, not the client/server relations.

Also, I didn't notice you saying you'd like to add client-side explosions prediction.
I must apologize, if you really did.

But the client-side prediction won't fix lags.
If ping time is too high, then one should change the server or his/her ISP.
I'd rather like to see no effect at all than to find out myself dead (upon trying to collect some ores in the hole the explosion left) when the server will perform its "little corrections" and will cause me damage.
The same goes for chests: you pick some items and go away 100 nodes only to realize that a "little correction" thought your stuff is still in the chest and you-taking-it event never happened...
(MT is much more honest here - it won't take you yous stuff w/o you noticing you can't).

I've played Minecraft with ping of 1.1 second to 2.5 seconds, so I know what I'm talking about.

The current philosophy is that by making a bare minimum game, players are forced to download mods to make it fun. If we had a complete subgame, players would download new subgames in order to get variety and refresh the fun-ness of Minetest.

But the rule is: "one dev against a new feature and it won't be added". (The same goes for new devs).
We can't possibly change the rules that easily.
Because of the rules themselves.

So... what are we going to do?
Proller made it's choice and created Freeminer.
I've made mine.

What about the rest of the community?

[Ferk]

But the rule is: "one dev against a new feature and it won't be added". (The same goes for new devs).
We can't possibly change the rules that easily.
Because of the rules themselves.

Probably, the smoothest way to transition from this would be to include a new game by default (since this kind of seems agreed on, or at least 1 year ago a vote was started in the forum to include one), and use a more permissive policy for this new game.

Then develop further that new game and let minetest_game usage be anecdotic (kind of how minimal is now).

Or properly advertise minetest as primarily an engine and not a game. Link to several standalone downloads of games that bundle the minetest engine in the download page. Instead of just hinting that "subgames" exist and giving a link to the forum.

Perhaps it even makes sense to link Freeminer and Magichet in the download section as games that use the minetest engine, instead of making them look like they are competition.

Maybe minetest_game shouldn't even be included in the download of the engine itself, and have it instead be just an entry in a new interface in the start menu that allows you to search, download and update available games (this could be kept as a lua table hosted in a git repo that the clients could download periodically to keep updated.. similar as to how things like npm, homebrew, pip and other software distribution systems work)

Not bundling minetest_game would give better chances for other games to play on the same conditions, and would make people realise that it's not that minetest lacks stuff, but that one of its games (the one named 'minetest_game') is more of a playground for developers to base other games in.

Imho, something that is designed for developers shouldn't be included by default on a download page designed for end users.

About your reasons for the fork:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

+ added more fields to the physics_override. Now one can set fall tolerance, attack and digging times multipliers. (despite protocol bump, MGC client is compatible with MT servers)
+ created a new menu, with additional features (like merging favourites with public list) which is much more pretty and MC-like than MTs or even FMs (subjective ;)
+ added the ability to set moon and sun textures just like skyboxes - run0time&per-player (a friend of mine joked about the fact with "Oh, kewl!! Now the server would go down depending on a phase of a moon...").
+ merged  Zeg's slippery feature
+ make on_use to be called on RIGHT click (allowing to dig with food in hand)
+ removed death screen (now MT has a setting to disable that too)

Of course there are many tweaks like more informative debugging, changing default settings, ect were applied.
Sometimes to speedup the android build, sometimes to shrink the size of a debug.txt (I don't want and I don't know how to fir Irrlicht bugs for that matter).

In my opinion, those are all good changes that I don't see how anyone would want to reject. In fact, at least one of them (the death screen removal) was already included in some way after all.

Maybe the most controversial one is the right click on_use for food, but I don't think anybody can argue against the inconsistency of having the left-click do a completely different thing when you have food in the hands. All other items are used for digging when you left-click, no matter how squishy they look. It makes the control scheme very inconsistent to have the food be eaten when you press the button that has always meant "dig/hit what you are pointing to".

Maybe I'm wrong, but I have the feeling that minetest engine development can still work well under the current policy without the need of a fork. The most important missing features are mostly not there yet just because of lack of manpower/time, not because there's no intention to do them (or at least that's the impression I've gotten in the short time I've been around). I doubt they would reject pull requests that add a decent API for mobs in the engine, for example.

I suspect that most of the burden and the pressure is given to minetest_game. And in a way, I can understand the conservationism of the dev team, considering that the goals for this game are unclear, it's so full of possibilities that it made sense for them to turn it into a "base" for mods.. so they don't include anything that can conflict with stuff that could be further developed in more specialised mods.

The problem is that if it's just a base, then it should be treated as a base for developers to download and use, and not distribute it to end users as if it was a full game.

[benrob0329]

@AnxiousInfusion Minetest is a mod, and MT game is ment to be a lightwait base. Though I too would like to have a more complete official game, perhaps having a complete base is the best option.

I personally think that MT should have stuck with just being a game, by now it could be quite decent and less hackish. But that's not my decision to make. (Yes, I know about Voxelands, and that game has some really cool features, but it's just not Minetest)

Hopefully 0.5.0 will have the major lag reduction and client prediction we've all been promised.

[rubenwardy]

Minetest is not a mod, it's an engine and a subgame combined (Minetest Engine + Minetest Game).

[benrob0329]

Right, but I'm saying that MT game, or any subgame is really just a collection of mods, so by adding more you are just adding to the game.

[Linuxdirk]

Speaking of Voxelands: If MT had a decent modding API Voxelands could be a subgame instead of a fork.

[ArguablySane]

It is clear enough I was talking about re-implementing the algorithms, not the client/server relations.

Also, I didn't notice you saying you'd like to add client-side explosions prediction.
I must apologize, if you really did.

But the client-side prediction won't fix lags.
If ping time is too high, then one should change the server or his/her ISP.
I'd rather like to see no effect at all than to find out myself dead (upon trying to collect some ores in the hole the explosion left) when the server will perform its "little corrections" and will cause me damage.
The same goes for chests: you pick some items and go away 100 nodes only to realize that a "little correction" thought your stuff is still in the chest and you-taking-it event never happened...
(MT is much more honest here - it won't take you yous stuff w/o you noticing you can't).

I've played Minecraft with ping of 1.1 second to 2.5 seconds, so I know what I'm talking about.

The inventory interfaces to things like chests can lag even in singleplayer. That is simply unacceptable in any modern game. I shouldn't be having to wait after each inventory action just so the game can catch up. Look at any of the minetest let's play videos and you'll see the same problem.

Obviously if you're dealing with a ping of more than 1 second then you're going to have a bad time regardless of anything the game does to compensate, but for more realistic pings of ~200 ms then it can make a big difference in user experience. If you really wanted to harden the system against extreme lag then it could refuse to close the inventory interface until all operations had synchronised with the server. It could even offer a choice of whether to enable client-side prediction in the client settings.

[Furikawari]

I would remove the 'can lag', to me interacting with chest ALWAYS have lag, whatever comp I use.

[4aiman]

Not always, Furikawari.
I've no lags on local server while I'm playing alone.
The more there are players - the more it lags - even with the smallest pings while playing over a LAN.
Enet-driven network protocol (used in Freeminer) gave me a better user experience than MT's one.
But that is subjective.

Also, +1 for moving minetest_game out of the official bundle.



@ ArguablySane,
Refusing to close FS is a good idea on its own, but then another problem arises: What if some mob attacks you while you can't close FS? Server run mobs and it won't know you're not moving because of waiting for a sync and not because you want to be killed.
A client can be made to send some kind of request for inventory sync, but what if that request won't reach the server?
And even if it would, we'll have yet another network protocol message and even more traffic which needs to be dealt with in realtime. Wouldn't that add even more lags?

Don't get me wrong, I'm all for client-side APIs.
It's just the more-or-less-precise client prediction is not that simple to achieve, imho, and any step in that direction should be made very careful.

Oh, and please, don't treat me as a complete newb.
I've seen enough problems with Minetest servers.
I know that lags are something that was there since the times I've joined the community.
For example, 0.4.13 is way more lag-less than 0.4.3. Back then i7 quad-core CPU + 16GB RAM could hold only 6 players online w/o any serious lags.
So, there's a great improvement which has been achieved.

But there's no prediction that will work for everyone.
I'd say that any "prediction" is a workaround.
However, I can't think of a better way to help at least *some* players.

Sadly, those are only talks.
MT needs action.
Client-side modding or prediction is not something I can code right now.
But I'm doing what I can.
Maybe by the time I'm done with what is more important for me, there will be some more improvement.

[Furikawari]

I play solo and I always have lag while interacting with chest.

[Linuxdirk]

Yes, since I first tried Minetest around a year ago this always annoyed me. Regardless if single-player on an high-end machine or multiplayer on my slightly older computer – Interacting with chests, furnaces, etc. always has noticeable lag between 2-5 seconds.

[jp]

Interacting with chests, furnaces, etc. always has noticeable lag between 2-5 seconds.

That's not necessarily the unique engine's fault, though.

I take the example of a mod that you extensively use : Crafting Guide. Have you looked at its code actually ? It represents ~2500 lines of code (!) and its slowness is due to handling a shitload of metadatas to a node whenever you operate on its formspec. Usually we use a detached inventory for this purpose (like Unified Inventory does efficiently), but not a node.

Well, we ought not deduct a weakness of Minetest before ascertaining that the mod is not sloppily coded...

[4aiman]

Come to think of it, roughly a year ago there were lots of complaints that mobs do not only slow down the server, but also affect formspecs. I didn't notice any of that, though.

But there's a good way to test what causes lags - the "minimal" game.
Add the mod in question to minimal (+dependencies) and check the time it takes to open any formspec.

[Furikawari]

Interacting with chests, furnaces, etc. always has noticeable lag between 2-5 seconds.

That's not necessarily the unique engine's fault, though.

I take the example of a mod that you extensively use : Crafting Guide. Have you looked at its code actually ? It represents ~2500 lines of code (!) and its slowness is due to handling a shitload of metadatas to a node whenever you operate on its formspec. Usually we use a detached inventory for this purpose (like Unified Inventory does efficiently), but not a node.

Well, we ought not deduct a weakness of Minetest before ascertaining that the mod is not sloppily coded...

I'm a newcomer, I played few days ago without mods and I got lags with chest. And as said above, it's really easy to test...