almost infinite map

[Walker]

original Thread: viewtopic.php?f=5&t=9183

i havent´n read the complet thread, sorry, but i have a nice idea ^^

Minetest storages MULTIPLE map.splite(s) ^^

like so:

if your starting the game, minetest create map.splite and fill it with data
intern minetest handle the map als sector 0/0

if the player reach Y to 31000 or -31000, that is the and, like now

BUT: if the player reach X or Z by 31000 or -31000, minetest a a new File
e.g. the player reach the point (0,0,33000), minetest div the 33000 by 32768, this is 1 and a rest of 232
extern mintest say player is at (0,0,33000) but intern minetest create a secound file with this schema:
map(-/+)%02dX(-/+)%02dZ, in this e.g. map+00+01.sqlite and put the player in this file to (0,0,232)

i you think, "hey, this sounds like Sectors", yes, this is, what i want ^^

the Map has intern secors by 16x16x16, but the map itself is also ONE sector of 65536x65536x65536
and can dynamicly put together by the Server in X and Z dimensions ;)

------ Da mein Englisch SCHEIßE ist nochmal in Deutsch ^^ ------

Ich hab den gesamten Thread nicht gelesen, sorry, aber ich hab ne gute idee ^^

Minetest speichert MEHRERE map.sqlite(s) ^^

so ungefähr:

wenn du das spiel startest erstellt minetest eine Datei map.sqlite und füllt sie mit Daten
intern behandelt Minetest diese Map als Sektor 0/0

wenn der Player, in Y Richtung, 31000 oder -31000 erreicht ist schluss, so wie jetzt ja auch schon

ABER: wenn der Spieler in X oder Z Richtung 31000 oder -31000 erreicht, erstellt minetest eine neue Datei
z.B. der Spieler erreicht den Punkt (0,0,33000), dann teilt Minetest die 33000 durch 32768, das sind 1 und 232 rest
nach außen sagt Meinerest, der spieler ist bei (0,0,33000) aber intern erstellt Minetest eine zweite Datei nach folgendem Schema:
map(-/+)%02dX(-/+)%02dZ, in diesem Beispiel map+00+01.sqlite und setzt den spieler in dieser Datei nach (0,0,232)

wenn sie jetzt denken "hei, DU ARSCH, das hasst du ja bei ikea geklaut", dann lies den Englischen text
... ... ...
wenn sie jetzt denken "hei, das klingt ja wie Sektoren", ja, dass ist das, was ich möchte ^^

die Map hat intern Sektoren von 16x16x16, aber die Map selbst ist halt auch NUR ein Sektor von 65536x65536x65536
und kann vom Server dynamisch in X und Z Richtung zusammengesetzt werden ;)

[Walker]

because the map files internally are still the same, they are 100% COMPATIBLE, the server does it all by itself, and since sector 0/0 is called simply map.sqlite, existing maps can be opened and if the borders are not exceeded, new maps can also be opened by old server;)

[Walker]

i this idea really SO bad ?

or just no one had read this thread ?

*cry*

[voxelproof]

because the map files internally are still the same, they are 100% COMPATIBLE, the server does it all by itself, and since sector 0/0 is called simply map.sqlite, existing maps can be opened and if the borders are not exceeded, new maps can also be opened by old server;)

I get the idea, but it's been already discussed in some thread a year or more before. Your proposal is tantamount to multi-dimensional worlds, with particular dimensions (map.sqlite data) accessible from the in-game level. It'd be very interesting of course but as far as I recollect the discussion there's some essential technical obstruction making it infeasible atm. The same idea implemented to creating coherent large flat one-dimensional worlds would moreover need general overhaul of map generation algorithms and this makes this all the more difficult to achieve.

[Linuxdirk]

This would cause 0,0,0;0,0,0 (or whatever the separator instead of ; will be) being a valid position causing everything what was done so far break.

Since devs fear even minor breakage this won’t never happen.

[ShadMOrdre]

This can easily happen, with full dev support, provided the following condition can be at least somewhat provided.

1. Provide sample code that the core devs can test, and perhaps approve. Follow all coding guidelines set forth by the dev team, and create a pull request. Some of this could might even possibly be handled simply by reworking the SQL code. This might be one of the ways to avoid breakage, and could see the quickest implementation. If you instead code this in C++, if you can avoid breakage, you could see rather quick adoption of the code. If the only solution is in fact breakage, then the code would only be merged into the next major release development branch.

The reason for the existing limits is a 32bit/64bit thing. With some reworking of some critical parts of the engine and perhaps the database, I believe this could be achieved.

I thinks it might be easier than we think, if enough of the right folks just think it through. The devs are already pretty swamped, so if something like this were to happen, it is going to have to be one of or a team of us to simply make the code and pull requests.

[Walker]

This would cause 0,0,0;0,0,0 (or whatever the separator instead of ; will be) being a valid position causing everything what was done so far break.

Since devs fear even minor breakage this won’t never happen.

eben NICHT
1. währe es nur 0,0;0,0,0, da die Sektoren NUR in X und Z Richtung vorgesehen sind ( wobei natürlich Y auch implementieren könnte, stell ich mir aber mit den Biomen schwierig von, die mögen Höhenlagen außerhalb von +/-31000 bestimmt nicht ... keine Ahnung ^^ )
2. ist das nach außen transparent, das heißt, die Syntax ist weiterhin x,y,z nur das x und z größer beziehungsweise kleiner werden können

die Einteilung in Sektoren soll ja das Backend ( die Engine ) ALLEINE machen, also On-The-Fly ^^

--------- [ Google Translate ] ------------

just NOT
1. It would only be 0.0, 0.0.0, since the sectors are ONLY in the X and Z directions (which of course could implement Y as well, but with the biomes I find it difficult to think of those that like altitudes outside of + / -31000 certainly not ... no idea ^^)
2. is this transparent to the outside, that is, the syntax is still x, y, z only the x and z can be larger or smaller

the division into sectors should make the backend (the engine) ALONE, so on-the-fly ^^

[Walker]

This can easily happen, with full dev support, provided the following condition can be at least somewhat provided.

1. Provide sample code that the core devs can test, and perhaps approve. Follow all coding guidelines set forth by the dev team, and create a pull request. Some of this could might even possibly be handled simply by reworking the SQL code. This might be one of the ways to avoid breakage, and could see the quickest implementation. If you instead code this in C++, if you can avoid breakage, you could see rather quick adoption of the code. If the only solution is in fact breakage, then the code would only be merged into the next major release development branch.

The reason for the existing limits is a 32bit/64bit thing. With some reworking of some critical parts of the engine and perhaps the database, I believe this could be achieved.

I thinks it might be easier than we think, if enough of the right folks just think it through. The devs are already pretty swamped, so if something like this were to happen, it is going to have to be one of or a team of us to simply make the code and pull requests.

ich denke auch so,

jedoch weiß ich ich nicht, wie weit die Limitierung auf 16bit vorgetrungen ist, wenn es wirklich nur durch die Schnittstelle zum Backend begrenzt wird, ist es ein Leichtes

Wenn die Engine aber die 16bit interpretierung im gesammten Code hat ( z.B. durch Bitshifting-Methoden, die nur auf 16bit ausgelegt sind ), wird das ganze schon schwiriger ^^

------ [ Google Translate ] -----------

I think so, too,

However, I do not know how far the limitation has been made to 16bit, if it is really limited only by the interface to the backend, it is easy

But if the engine has the 16bit interpretation in the whole code (for example, by bit-shifting methods, which are only set to 16bit), the whole thing gets more and more busy ^^