What's Minetest still missing over Minecraft?

[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:

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...

[rubenwardy]

There has been progress recently in the dev chatter about meta. A patch has been made which increases fps in Vanessa's spawn area from 3fps to 50fps. All due to meta causing mesh updates when it should not.

[Linuxdirk]

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

It is, since I’m not talking about mods but about the vanilla “Minetest Game”.

[benrob0329]

@single player lag

I don't know what the problem is, but I'm running MT on a ~2ghtz laptop (quad core but MT doesn't take advantage of this yet), running GNOME. The only time I ever get any noticeable lag in single player is when I have heavy mods installed.

Not only that but Minetest 0.5.0 is promised to have less noticeable lag because of a better network protocol and client protection.

[nomohakon]

Dont know where to put it, but can minetest server just send ingame time and a map instead of sending map with precalculated light values? If its already done, tell me, so i stop asking stupid questions.

[Sokomine]

Regarding lag when interacting with chests: In my experience, the best way to get lag (even in singleplayer) is to just update the formspec of a node and wait for that to be displayed for the player. Normal, non-locked chests are usually fast enough because there's client prediction of what will happen. Locked chests got slow when that hide-the-content-"feature" got added. In recent times they felt less slow. The build chest in handle_schematics gained a lot of speed when interacting with it in singleplayer after I switched from just-update-metadata-formspec to showing the formspec directly to the player after receiving a command.

[Don]

Regarding lag when interacting with chests: In my experience, the best way to get lag (even in singleplayer) is to just update the formspec of a node and wait for that to be displayed for the player. Normal, non-locked chests are usually fast enough because there's client prediction of what will happen. Locked chests got slow when that hide-the-content-"feature" got added. In recent times they felt less slow. The build chest in handle_schematics gained a lot of speed when interacting with it in singleplayer after I switched from just-update-metadata-formspec to showing the formspec directly to the player after receiving a command.

I have used machines(formspec) in a number of my mos. I would love to hear how I can make them faster. If you have any ideas I would appreciate it.

[Sokomine]

I have used machines(formspec) in a number of my mos. I would love to hear how I can make them faster. If you have any ideas I would appreciate it.

It's faster if you use minetest.show_formspec(playername, formname, formspec) whenever receiving input instead of meta:set_string("formspec", new_formspec_string). At least that's so for me. And it applies mostly to formspecs with input (buttons, forms) in singleplayer. I'd love to hear which experience other players/modders have gathered in that regard.

[Don]

I have used machines(formspec) in a number of my mos. I would love to hear how I can make them faster. If you have any ideas I would appreciate it.

It's faster if you use minetest.show_formspec(playername, formname, formspec) whenever receiving input instead of meta:set_string("formspec", new_formspec_string). At least that's so for me. And it applies mostly to formspecs with input (buttons, forms) in singleplayer. I'd love to hear which experience other players/modders have gathered in that regard.

Thanks. I will give it a try and see if it is faster.

[4aiman]

It's faster if you use minetest.show_formspec(playername, formname, formspec) whenever receiving input instead of meta:set_string("formspec", new_formspec_string). At least that's so for me. And it applies mostly to formspecs with input (buttons, forms) in singleplayer.

Actually, ^this may be the reason I didn't see any fs delays during last year.
I play MGC 99% of time and it uses minetest.show_formspec for updating forms.
First I used the func to enable sorting buttons but eventually got used to it and now every other "update" is done via it.

[lisacvuk]

If minetest had hardware lighting and re-done textures, none would play Minecraft. I believe hardware lighting should be a priority. It would make the game look a lot better, and add options for colored lights, and light effects.