Minetest Forums

Hello users,

Minetest next release will be a breaking compat release. We stated it's time to take a break and fix some things and add breaking features to core engine.

First thing server owners should know, we wanted to let a last 0.4.17 happen, which will be a bugfix only release, maintained on free time. We discussed about this but we are not organized on how maintain it separately from master as we are a tiny coredev team :)

In consequence, server owners who uses Github master branch for production servers should now switch to stable-0.4 branch or their server can become incompatible with release clients soon.

Minetest 0.5 needs to be done to fix some old problems on core engine especially on network protocol, which maybe needs a full break. Some packets needs a cleanup because they are not properly sent to server which can cause problems in the future.

Another important point, Master branch now uses C++11 standard. Direct consequence: Windows XP is not supported anymore, and old distros like Debian 7 or RHEL/Centos 6.

Please update to Debian 9 or latest RHEL/Centos 7 if you are on those distributions, if you use Windows XP, Microsoft told you to update years ago. If you compile Minetest from source, you need recent compiler, GCC 5.1 or Clang 3.6 are the minimum on UNIX systems and MSVC 2012 for Windows Visual Studio build.

There are other breaking changes which can happen to master branch, then be careful and don't use on your production builds, switch to stable-0.4 asap. We think we will start to merge breaking compat PR in 1 or 2 weeks.

Thanks for reading.

Final note: i will start a preview changelog on http://dev.minetest.net/Changelog soon

nrz wrote:Windows XP is not supported anymore

M$ again :( draw my money.

Q:
What exactly component will obtained that make MT unworkable on XP ?
Render ? Audio subsystem ? Sockets ?

Why ???

A: c++11

Thanks for the announcement/warning.
Good things to come!

Thanks for the announcement. I think that it's a good step to drop compatibility with old operating systems in favor of using more modern technologies. It will open new possibilities!

What about clients built from master?

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)

And Minetest could be left as the next release (which I think will be deemed as 0.4.17?), fork it, and then begin dev for 0.5.0 as an entirely separate entity, seeing as it will most likely be incompatible with any 0.4.-- builds?

Anyway, just my dopey input.
I am anxious to see what 0.5.0 has to offer

I don`t understand eventually, next version will be 0.4.17 or 0.5.0?

Andrey01 wrote:I don`t understand eventually, next version will be 0.4.17 or 0.5.0?

0.4.17, it will be a release for bugfixes.
then development begins for 0.5.0

I believe that is the plan

Do I have to worry about existing worlds?

So, we will probably stop having any sort of updates after 0.4.17 comes out. At least until we are ready to test the early versions of 0.5.
I say probably stop having updates because there is always the possibility of a fork. :)

Will 0.5.0 bring coloured lighting? and numerous other irrlicht features
Will the code be thoroughly examined to strip out any old bloat/deprecated code in an attempt to increase fps?

I am just saying, if a jump to 0.5.0 is going to be made, and will be a definite incompatible with 0.4.x series, then why not go balls to the wall with it? :P
0.5.0 development should obviously be seen as a chance to really address some deep subjects, with no time estimate given in regards to a release date. Seeing as it will be a major release.

I feel all next versions will come with bugfixes and improvement of engine. At least maybe it`s better than blind permanent adding of blocks and other like ones as it happens in minecraft.

To answer to all, to be clear:

* We will try to do a last 0.4.17 release in stable-0.4 branch which contains bugfix commits only, if we have sufficient hands to handle it. But server owners are encourages to use 0.5
* 0.5.0 will break some things, especially in network protocol. For worlds, i (and some other devs too) prefer keep map compat as it's essential. Lua API server side should not be very modified in breaking methods, but we will add new things.
* For the features in client, we are continuing to improve CSM, and i'm working on a huge client cleanup to isolate irrlicht from MT client far more better than now, permitting to reduce irrlicht dependency.
* For the features in server, currently it's bugfixes but we will add new high level features to enhance and reduce mod code with more intelligent features, it's the goal (NPC API is an example but it's not a draft atm).

So no colored lighting?

Wuzzy wrote:So no colored lighting?

NoShadows more important for playability )

Nyarg wrote:

Wuzzy wrote:So no colored lighting?

NoShadows more important for playability )

How are shadows important for playability? At least colored light could be used to color-code information. Also, I would consider the current lighting system some kind of soft shadows, though maybe not very accurate to real life.

This is possibly the first breaking change, ore "absheight" flag has been removed viewtopic.php?f=18&t=17977

Coloured lighting would be a huge and difficult project and is low priority, it's unlikely to happen or is very distant.

1shoot2kill do you mean you can't post a thread in the news subforum? That's intentional, developers and admin only for good reason.

paramat wrote:Coloured lighting would be a huge and difficult project and is low priority, [...]

a.k.a. "will never be added" :( So sad.

Byakuren wrote:How are shadows important for playability?

Our human visual recognizing system use shadows first for perspective reconstruction.
In simple a shadow have not tint or colorize at this neuroprocessing step.

I wonder why no one way was used for shadow implementing.
One way is using a render and another way make allow dynamic texture using (create and load from hdd when need) on selected node.
I know dynamic texture may be used on entity but entity dramatically drop FPS.

1shoot2kill wrote:I want to post topic in mod release/servers

you've been posting this all over the place, you need to stop

go to which ever section you want to post in, in the top left there will be one of two buttons
"New Topic" or
"Post Reply"

Nyarg wrote:

Byakuren wrote:How are shadows important for playability?

Our human visual recognizing system use shadows first for perspective reconstruction.
In simple a shadow have not tint or colorize at this neuroprocessing step.

But what effect does this have on playability? Yes, it looks unrealistic not to have shadows when our brains are geared to recognize them, but how does it make Minetest less playable? Can you give a specific example of when you were playing the game and shadows would have improved playability in some specific way?

I am very happy with this choice! After so many years, developers have finally decided to break with the past, and redesign the gaming engine.

I have some questions:

- Irrlicht is isolated because you are going to completely remove this render engine. Or to keep it separate and
manage it easier?

- Why did you choose Irrlicht as a render engine? I have basic C++ knowledge, I would have chosen SFML, Glew
(Open GL Libraries), OpenGL Mathematics (GLM). I think it's the best choice.

I'm anxious to see new developments. On github I follow the project and I noticed you are working a lot. Thank you all.

LordStephen77 wrote:I am very happy with this choice! After so many years, developers have finally decided to break with the past, and redesign the gaming engine.

I have some questions:

- Irrlicht is isolated because you are going to completely remove this render engine. Or to keep it separate and
manage it easier?

- Why did you choose Irrlicht as a render engine? I have basic C++ knowledge, I would have chosen SFML, Glew
(Open GL Libraries), OpenGL Mathematics (GLM). I think it's the best choice.

I'm anxious to see new developments. On github I follow the project and I noticed you are working a lot. Thank you all.

For one thing, you would need to implement the whole rendering pipeline with such minimal libraries.

Byakuren wrote:But what effect does this have on playability?

In general:
Improve navigation.
Improve imagination.
At least )