Minetest Forums

By the way, what does "-dev" mean in end of number of version? Unstable version or what?

Andrey01 wrote:By the way, what does "-dev" mean in end of number of version? Unstable version or what?

"development" (unstable, yes).

As I understand it, the "dev" tag refers to a pre-release that is ahead of the current stable branch, and is thus unstable.

What I find very confusing is why development on Minetest 0.5.0 isn't tagged as "0.5.0-dev", but instead maintains the version number of the previous stable release, 0.4.16.

GreenDimond wrote:

sorcerykid wrote:How did you download a Minetest 0.5 client? The core devs haven't even announced the release of 0.4.17 yet.

0.4.16-dev is the equivalent of 0.5.0 because of the breaking change. The player model change that paramat was talking about is already part of 0.4.16-dev. 0.4.17 may or may not happen.

@sorcerykid: That's becaue 0.5.0 is not released. Some idiots use the name 0.5.0 anyway. Which is wrong!

@all: Please do not use the version number “0.5.0” or any “stable” version number to refer to an in-development version, it's wrong and confusing as hell! (as proven by the previous couple of posts). Also, please do not invent version numbers out of thin air when they don't even exist.
Just wait until 0.5.0 is officially announced, only then it is valid.

The current in-development version is 0.4.16-dev and should only be called this way (or by its commit ID). Stable version numbers (i.e. without the “-dev”) should never be used for anything else but a stable release.

The “-dev” means that it can refer to any state of development (i.e. commit) after the stable version 0.4.16, but before the next stable release. “-dev” is not stable, so pretending that it is (by assinging it a version number of your own choosing, like GreenDimond does) is completely wrong!
The versions without “-dev” should only be used for the versions which got actually officially announced.

Long story short:
- Current stable version is 0.4.16
- Current developer “version” is 0.4.16-dev
- Any version with “-dev” is not really a version because it does not pinpoint any particular stage of development. Any commit between the previous stable release and the next stable release could be meant!
- Next stable version will probably be 0.5.0 (but that's not 100% sure)

sorcerykid wrote:How did you download a Minetest 0.5 client? The core devs haven't even announced the release of 0.4.17 yet.

"0.4.17" should really be called "0.4.16.1". We are currently working towards 0.5, but will backport bug fixes to the 0.4 line. ie: "0.4.17" will be a fixes only release.

1337 wrote:Please put Minetest up on itch.io and Game Jolt!!!! PLEASE!!!

They both have awesome clients with easy installation and auto-update and a massive community between each platforms.

I don't think that'd be a good idea. Though both of those sites have decent clients and all that, but, I don't think they'd be good places to "release" the game, if a Minetest 1.0 is reached.

I personally would suggest either Steam, or, the Minecraft method, which is to just have the minetest.net website (Which already exists, simplifying the process.), and have the game available there.

Perhaps a launcher could be made one day, to provide updates? You know, if you were running on 0.4.15, using the (theoretical) launcher, either a notification could pop up telling you there's an update, or it could update automatically when you press "Play".

Just my opinion, I'm already fine with how Minetest works right now. Except the password system, I'm really hoping that can be improved some day.

paramat wrote:I've noticed people are making suggestions for 0.5, it's too late,
we already have a huge amount of work to do for 0.5,

I already posted a reminder with some old suggestions (mostly about ui, and the server-list).

Also, 0.4.16 still crashes when shift-moving stuff between inventories - is that fixed now ?

Wuzzy, please don't use personal attacks.
That aside, you're right.
@paramat, that is awesome. Finally we can make dragon mods!

GreenDimond wrote:

paramat wrote:old clients will not be usable with new servers (and the other way around).

Incorrect..
I can connect to the HOMETOWN server with the new client. It just bumps the player model/selection up by one block (just a visual change), and the F7 camera is offset.

The offset player is what i mean by 'unusable', no-one would accept playing MT with a vertically offset player.

sorcerykid wrote:[Am I to understand that if a server owner updates to version 0.5, then they will lose players with version 0.4 clients? Similarly, if a player updates to version 0.5, then they will no longer be able to connect to any version 0.4 servers?

For the first few months, such an abrupt transition is sure to alienate many players. This impact would be most significant in the case of unofficial builds for mobile devices (such as Multicraft) for which a 0.5 compatible release could take months.

You understand correctly.

I see no alienation, some servers will continue to use 0.4 for a while, some servers will update to 0.5.0. Players can have 2 versions of MT to access both types of server.
We respect MultiCraft, but some of the other Android clients are either illegal, or lazy sloppy copies or scams, or bring problematic players to servers, we don't care much about those. Players can use the official MT Android app instead.
Many of the Android forks will be able to update to remain compatible and this might have the good result of killing off the more lazy ones.

0.4 to 0.5 is a big change and disruption is intentional, it is allowing us to fix and clean up some things. The disruption argument could have been used against 0.4 but 0.4 was a good move obviously.

For when you can, make node properties changeable in game, please. This would open up a whole new realm of possibilities.

Question: will sofar's entity_ai mod make an appearance in 0.5???

One thing I'm actually hoping for in 0.5 or later versions is smoother player movement in multiplayer. It looks kinda janky at times, and is quite annoying if you're in a PvP situation or are just trying to keep track of where a friend is. I've seen it in lots of servers, so I'm not sure if it's a server problem or just the game, but I hope it's implemented if it is a problem with the game.

I'm imagining that's one of the things client-side modding/official hacked client support was meant to fix.

i agree we should switch to 0.5.0-dev and 0.4.17-dev for both minetest branches, it's confusing to have 0.4.16-dev whereas 0.4.16 is released

* 0.5.0-dev
* 0.4.17

(Just my two cents;)

edit:

TumeniNodes wrote:Just a personal view, I honestly do not understand why anyone would use dev builds for a server, or personal use, unless they are involved with development, testing, or modding (but even for modding seems a bit senseless to me, as mods should be built for a stable system, meant for using on a stable system)

They don't call it Minetest for nothin'!

can somebody answer my question? (its a few posts above this one)

Probably not, it still needs lots of work, plus we need to create the mobs themselves.

ThatOneChris, jumpy player movement is an inevitable result of network lag in multiplayer, it's not solvable, only by faster communication between server and client, so is an internet speed issue.

paramat wrote:Probably not, it still needs lots of work, plus we need to create the mobs themselves.

ThatOneChris, jumpy player movement is an inevitable result of network lag in multiplayer, it's not solvable, only by faster communication between server and client, so is an internet speed issue.

Seems to happen even when both me and a friend have great connection. I won't question it, though, it probably is connection speed.

paramat wrote:Probably not, it still needs lots of work, plus we need to create the mobs themselves.

ThatOneChris, jumpy player movement is an inevitable result of network lag in multiplayer, it's not solvable, only by faster communication between server and client, so is an internet speed issue.

Jumpy movement is usually caused by network jitter and latency, both of which can be compensated for if the client sends higher resolution movement info and the client delays the application of position updates of other players (giving slack time to figure out how fast interpolation should be).

Yeah i'm no expert on network stuff so Byakuren is probably right.

Byakuren wrote:

paramat wrote:jumpy player movement .. result of network lag in multiplayer

network jitter and latency, .. can be compensated for
if the client sends higher resolution movement info and
the client delays the application of position updates of other players

In pvp-situations, that means you would get a much smoother display of how some other player
stabs you to death, outruns and evades you faster (because your reactions are slowed down :).

Would you prefer that ?

Byakuren wrote:

paramat wrote:Probably not, it still needs lots of work, plus we need to create the mobs themselves.

ThatOneChris, jumpy player movement is an inevitable result of network lag in multiplayer, it's not solvable, only by faster communication between server and client, so is an internet speed issue.

Jumpy movement is usually caused by network jitter and latency, both of which can be compensated for if the client sends higher resolution movement info and the client delays the application of position updates of other players (giving slack time to figure out how fast interpolation should be).

The issue is that Minetest uses extrapolation not interpolation IIRC. With interpolation, the movement is considerably smoother unless the latency exceeds the sync time, which is usually 0.2s

rubenwardy wrote:

Byakuren wrote:

paramat wrote:Probably not, it still needs lots of work, plus we need to create the mobs themselves.

ThatOneChris, jumpy player movement is an inevitable result of network lag in multiplayer, it's not solvable, only by faster communication between server and client, so is an internet speed issue.

Jumpy movement is usually caused by network jitter and latency, both of which can be compensated for if the client sends higher resolution movement info and the client delays the application of position updates of other players (giving slack time to figure out how fast interpolation should be).

The issue is that Minetest uses extrapolation not interpolation IIRC. With interpolation, the movement is considerably smoother unless the latency exceeds the sync time, which is usually 0.2s

Minetest uses interpolation for displaying player movement, it's just that the player positions are not timestamped or buffered so the game has no idea how fast to move the player.

hajo wrote:

Byakuren wrote:

paramat wrote:jumpy player movement .. result of network lag in multiplayer

network jitter and latency, .. can be compensated for
if the client sends higher resolution movement info and
the client delays the application of position updates of other players

In pvp-situations, that means you would get a much smoother display of how some other player
stabs you to death, outruns and evades you faster (because your reactions are slowed down :).

Would you prefer that ?

I'm not sure what you mean. A delay of 0.2s like rubenwardy suggests would only be a huge deal in something like a FTG, and any disadvantage is shared with the other player because you are both playing the same game.