Minetest Forums

This PR fixes occasional light bugs caused by the cooling of lava https://github.com/minetest/minetest/pull/4682 but comes at a cost:

"To introduce the new flags I had to increase the map block serialization version, this is why you can not play on your maps on other versions of Minetest after you opened them in this version.
Of course old clients still can play, just the server has to be new to be able to read the map."

If this PR is merged, once you open a world with a server you cannot then afterwards open that world with an older server. This includes singleplayer as that is a server and client running on one machine.

If this does not introduce any other bugs, I would fine with it.

Let me answer with a song

https://www.youtube.com/watch?v=HWPJ8Gvh2C4

I think, progress is more important than backwards compatibility at any cost

I think that less bugs are more important than backwards compatibility.

paramat wrote:. . . you can not play on your maps on other versions of Minetest after you opened them in this version . . . the server has to be new to be able to read the map . . . If this PR is merged, once you open a world with a server you cannot then afterwards open that world with an older server . . .

From a position of complete ignorance on what/why/where ''map block serialization'' is here, just general-principle questions would be :

Does ''server'' include the singleplayer use-case too..?

Are there any feasible longer-term gotchas, unintended consequences, just this side of ''unforeseen'' outcomes..?

Will there be big clear pre-world-launch warnings about irreversibility, like I've seen for various other software over the years..?

Does the change affect the whole (huge) world-database, and if not, could any sort of automatic file-backup mitigate the risk of no-path-back breakage for users wanting to test it..?

Or again, if the huge database is not directly affected, then could there be potentially parallel ways to access the same data, as per the extensions to ISO9660 and hybrid filesystem views of data on optical discs..?

.

CuriousNoob wrote:[
Does the change affect the whole (huge) world-database, and if not, could any sort of automatic file-backup mitigate the risk of no-path-back breakage for users wanting to test it..?

I think, the server admin is responsible by himself for backups or to read the doc BEFORE he upgrades anything.

RTFM first

Discussing on IRC dev channel the devs are thinking this is worth it, the 1st PR will fix more lighting bugs than just large areas of lavacooling, and helps make the 2nd PR more effective.

The first PR (which increases mapblock serialisation version) could be merged as soon as a few days, maybe a week, so this is a warning, and of course if it goes ahead it will be announced here and probably in a dedicated thread in this news subforum.

This does affect singleplayer yes because singleplayer is actually a server and a client running on a single machine.

I'm not knowledgeable about the more technical questions about the world database, maybe others will reply here.

I think you should go ahead and fix the bug. Unless you can find a way to fix the bug without breaking compability (this would be of course the best scenario).
But if not:
Getting rid of annoying lighting bugs is always important IMO, even if you have to break compability sometimes. Bad lighting in Minetest worlds can be very annoying or frustrating.

Also, I think compability shouldn't be too big a concern at this stage. Minetest is still incomplete and has a long way to go, so introducing important features or bugfixes should be expected. I would be more concerned about compability as soon Minetest hits the 1.0.0 milestone or is in beta stage.

But PLEASE add this info in the changelog (or better: in the release announcement) when you release the next version as this is important to know. (Speaking of changelogs, I'm still waiting for the 0.4.15 changelog. :P)

Thanks for asking the community before doing important changes, however.

This PR is now being merged.

I guess it is too late to ask for a length|size field for serialized inventory in the world format? Every other data section of the database has a length|size|or count but not serialized inventory. ha. I don't even care about the contents right now. That's assuming that it is always there too. I just want to skip past it to get to the next nodes' metadata. But if people can write code that reads it and have a working game, I can read it also. IDK when though :)

Best open an issue in the Github Minetest engine webpage.

Where can i find new specifications for 27. map format?
It seems https://github.com/minetest/minetest/bl ... format.txt is for version 25.

paramat, if you raise the serialization version i hope we can move to zstd algorithm for serialization in database, it's a great thing