almost infinite map

User avatar
Walker
Member
 
Posts: 145
Joined: Tue Oct 03, 2017 09:22
In-game: Walker

almost infinite map

by Walker » Sun May 12, 2019 05:15

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 ;)
 

User avatar
Walker
Member
 
Posts: 145
Joined: Tue Oct 03, 2017 09:22
In-game: Walker

Re: almost infinite map

by Walker » Sun May 12, 2019 05:16

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;)
 

User avatar
Walker
Member
 
Posts: 145
Joined: Tue Oct 03, 2017 09:22
In-game: Walker

Re: almost infinite map

by Walker » Sun May 12, 2019 05:18

voxelproof wrote:
Walker wrote: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.
 

User avatar
Walker
Member
 
Posts: 145
Joined: Tue Oct 03, 2017 09:22
In-game: Walker

Re: almost infinite map

by Walker » Sun May 12, 2019 05:19

Linuxdirk wrote: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.
 

User avatar
Walker
Member
 
Posts: 145
Joined: Tue Oct 03, 2017 09:22
In-game: Walker

Re: almost infinite map

by Walker » Sun May 12, 2019 05:20

ShadMOrdre wrote: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.
 

User avatar
Walker
Member
 
Posts: 145
Joined: Tue Oct 03, 2017 09:22
In-game: Walker

Re: almost infinite map

by Walker » Sun May 12, 2019 05:21

Linuxdirk wrote: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 ^^
 

User avatar
Walker
Member
 
Posts: 145
Joined: Tue Oct 03, 2017 09:22
In-game: Walker

Re: almost infinite map

by Walker » Sun May 12, 2019 05:23

ShadMOrdre wrote: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 ^^
 

User avatar
Walker
Member
 
Posts: 145
Joined: Tue Oct 03, 2017 09:22
In-game: Walker

Re: almost infinite map

by Walker » Sun May 12, 2019 06:03

Desweiteren könnte man ja mit der Namenskonvention gleich weitere Feature hinzufügen, wie Dimensionen, mehrere Maps pro Welt etc. diese werden einfach als ebenen in die Weltstruktur hinzugefügt ...

ich habe z.B. für ein eigenes Programm folgende Konversation benutzt:
Code: Select all
tilefile$ = worldpath$+"/d"+Str(dimension)+"/s"+Str(escX)+"/ss"+Str(escY)+"/x"+Str(x)+"/y"+Str(y)+"/z"+Str(z)+".sqlite"
// z.B. tilefile$ = "/home/knoppix/.puretest/worlds/testword/d1/s-3/ss5/x43/y-400/z0.sqlite

man sieht schon, das man quasi beliebig viele Verzeichnis-ebenen dazwischen knallen kann ;)

natürlich könnte man erstmal mit X/Z anfange ( wie im ersten Beitrag beschrieben ), mann kann das System aber auch für spätere Erweiterungen offen halten, solange mann eines beachtet: Neu Features brauchen IMMER eindeutige bezeichnungen ( "d", "s", "ss", "x", "y", "z" usw. )

wenn man also z.B. folgende Struktur, aus dem ersten Beitrag, hat:
Code: Select all
map+13-21.sqlite

dieser wird nun in eine Verzeichnisstruktur übersetzt:
Code: Select all
map/x13/z-21.sqlite

nun wird eine Y-Dimension hinzugefügt, wobei Meinetest merkt, das es in den "x??"-Verzeichnissen keine "y??"-Verzeichnisse gibt und demnach alle Unterverzeichnisse in eine Unter-ebene verschiebt:
Code: Select all
mkdir /map/x13/y0
mv map/x13/z-21.sqlite map/x13/y0/z-21.sqlite


und nun entscheidet sich das Minetest-Team, Jahre später, noch Dimensionen, wie Hölle und Himmel, hinzuzufügen ...
kein Problem, die neue Verzeichnis Struktur heißt einfach "d".
dabei merkt Minetest wieder ... "d??" gibt es unter "map" nicht ... also updaten:
Code: Select all
mkdir /map/d0
mv map/x13/y0/z-21.sqlite map/d0/x13/y0/z-21.sqlite


Und so weiter und so fort ^^

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

Furthermore, one could indeed add more feature with the naming convention, like dimensions, several maps per world, etc. these are simply added as levels in the world structure ...

i have e.g. used for its own program the following conversation:
Code: Select all
tilefile$ = worldpath$+"/d"+Str(dimension)+"/s"+Str(escX)+"/ss"+Str(escY)+"/x"+Str(x)+"/y"+Str(y)+"/z"+Str(z)+".sqlite"
// z.B. tilefile$ = "/home/knoppix/.puretest/worlds/testword/d1/s-3/ss5/x43/y-400/z0.sqlite

you can already see that you can pop almost any number of directory levels in between;)

Of course you could start with X / Z first (as described in the first post), but you can also keep the system open for later extensions, as long as one notes: New features ALWAYS need unique identifiers ("d", "s", "ss", "x", "y", "z" etc.)

so if you following structure, from the first post, has:
Code: Select all
map+13-21.sqlite

this is now translated into a directory structure:
Code: Select all
map/x13/z-21.sqlite

Now a Y-dimension is added, where Meinetest notices that there are no "y??" directories in the "x??" directories and therefore shifts all subdirectories to a sub-level:
Code: Select all
mkdir /map/x13/y0
mv map/x13/z-21.sqlite map/x13/y0/z-21.sqlite


and now, years later, the Minetest team decides to add dimensions like hell and sky ...
no problem, the new directory structure is simply called "d".
while Minetest notices again ... "d??" there is not under "map" ... so update:
Code: Select all
mkdir /map/d0
mv map/x13/y0/z-21.sqlite map/d0/x13/y0/z-21.sqlite


And so on and so on ^^
 

User avatar
Walker
Member
 
Posts: 145
Joined: Tue Oct 03, 2017 09:22
In-game: Walker

Re: almost infinite map

by Walker » Sun May 12, 2019 07:07

wichtig hierbei ist natürlich, EGAL was hinzugefügt wird, minetest muss es immer aus sicht des Spielers / der Clienten abstrahieren:
X/Y/Z = originale ingame position ( auch inerhalb einer SQLite-Datei ) ... x/y/z/d = Verzeichnisstruktur
Code: Select all
X += x*65535
Y += y*65535
Y += d*65536*65536
Z += z*65535

Code: Select all
// posX/Y/Z = absolute Position
// worldX/Y/Z/D = Werte von den  Verzeichnisstrukturen
// innerX/Y/Z = Werte innerhalb der SQLite-Dateien
//
// D = dimension ( hölle, himmel, ende, usw. )
//
posX = worldX<<16 | (innerX + 32768)              // da die X-position innerhalb einer SQLite nicht von 0 sondern von -32768 startet
posY = worldD<<32 | worldY<<16 | (innerY + 32768) // da die X-position innerhalb einer SQLite nicht von 0 sondern von -32768 startet
posZ = worldZ<<16 | (innerZ + 32768)              // da die X-position innerhalb einer SQLite nicht von 0 sondern von -32768 startet


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

Of course it is important, what is added, minetest always has to abstract it from the view of the player (s):
X/Y/Z = original ingame position (also inside a SQLite file) ... x/y/z/d = directory structure
Code: Select all
X += x*65535
Y += y*65535
Y += d*65536*65536
Z += z*65535

Code: Select all
// posX/Y/Z = absolute position
// worldX/Y/Z/D = values from the directory structures
// innerX/Y/Z = values within the SQLite files
//
// D = dimension (hell, heaven, end, etc.)
//
posX = worldX<<16 | (innerX + 32768)              // because the X-position within a SQLite does not start from 0 but from -32768
posY = worldD<<32 | worldY<<16 | (innerY + 32768) // because the X-position within a SQLite does not start from 0 but from -32768
posZ = worldZ<<16 | (innerZ + 32768)              // because the X-position within a SQLite does not start from 0 but from -32768
 

User avatar
paramat
Developer
 
Posts: 3333
Joined: Sun Oct 28, 2012 00:05
Location: UK
GitHub: paramat
IRC: paramat

Re: almost infinite map

by paramat » Thu May 16, 2019 21:50

'almost infinite' is a nonsense phrase =)
 

User avatar
Walker
Member
 
Posts: 145
Joined: Tue Oct 03, 2017 09:22
In-game: Walker

Re: almost infinite map

by Walker » Fri May 17, 2019 02:34

"almost" means, that you can reach over 32^3 and more blocks
to travel this distance ( without cheating ) you need ... nearly forever ?
so yes, if you starts from center, the map feels "infinite"

^^
 

User avatar
Pyrollo
Member
 
Posts: 263
Joined: Mon Jan 08, 2018 15:14
Location: Paris
GitHub: pyrollo
In-game: Naj

Re: almost infinite map

by Pyrollo » Fri May 17, 2019 08:19

Regarding to the amount of work that should be needed to make that change, does the gameplay worth it ?
A "simple" rework of the map format and coordinate (which would be IMO much simpler that a complex tiled system of databases) to have larger worlds could have the same effect.

Anyway, when you look at a server map, 90% of it is unexplored. For me, it means that the map is fairly large enough for a good gameplay.

For me axes of improvement would more be in "multiple dimension" / parallel worlds. And even that could be achieved without increasing the map size (with horizontal slices).
[ Display Modpack ] - [ Digiterms ] - [ Crater MG ] - [ LATE ]
 

User avatar
voxelproof
Member
 
Posts: 769
Joined: Sat Aug 05, 2017 08:13
Location: Europe

Re: almost infinite map

by voxelproof » Sun May 19, 2019 08:09

paramat wrote:'almost infinite' is a nonsense phrase =)


Mathematically, yes. But there's a point of using term of 'infinity' on psychological grounds anyway. I argue that 'practically infinite' (open in-game worlds or any other content) means 'not practically explorable within a player's lifetime'. Since current MT worlds are definitely 'practically explorable' they don't fit the definition. A different matter is for what sake such enormous spaces should be implemented; sometimes (and predominately) it may be counterproductive from the point of view of player's experience. Very often overly spacious worlds create different curious psychological effects -- feeling of 'emptiness' (when content doesn't fill them sufficiently) or desolation (what can be perhaps best understood when playing Space Engine -- the tremendous available space makes unprepared wanderer feel lost).
>>>there is life beyond the Cube>>>
 

User avatar
Hume2
Member
 
Posts: 233
Joined: Tue Jun 19, 2018 08:24
Location: Czech Republic
GitHub: Hume2
In-game: Hume2

Re: almost infinite map

by Hume2 » Sun May 19, 2019 19:14

paramat wrote:'almost infinite' is a nonsense phrase =)

It does make sense. For example, in physics, almost infinite resistance means that the resistance is so big so it can't be measured by used device. Almost infinite means that something is so big that it can be aproximated by infinity for easier calculations. It can also mean that it is known to be finite but it is so big so it can't be measured by the used method.
If you lack the reality, go on a trip or find a job.
 

ShadMOrdre
Member
 
Posts: 248
Joined: Mon Dec 29, 2014 08:07
Location: USA
GitHub: ShadMOrdre
In-game: shadmordre

Re: almost infinite map

by ShadMOrdre » Mon May 20, 2019 06:05

Almost infinite and gameplay value.

Almost infinite isn't even good enough for those of us who like to simply explore spaces from time to time. Some of us want truly infinite for reasons that go far beyond using MT as a simple game engine. MTs potential is not realized by ANY of us. As a DB backend, a concept entirely out of scope with MT as a game engine, MT has the potential to excel in ways that Oracle and MS would drool over. Yes, I know that MT uses SQLite. This is not lost on me. I've spent years in the industry, as a db pro. It's in the processing. Maybe as middleware. But still valid. Just think....

As for gameplay value, well, if you are playing a non-game, with non-game play value, then adding anything to nothing will still result in nothing, IMHO. Don't get me wrong here. MT Game does what it is supposed to do, (Display the potential of MT and maybe attract MC expats), and it does so well. It is light, and is a fairly good representation of MTs capabilities as a MC like game engine. MineClone does the same.

In my lib_ecology mod, I have just provided a quick, lag-light way to provide up to 25600 ecosystems, simply for those of us who want to see more "world" than that which seems to be geared towards regurgitated minecrap gameplay. I have a feeling, if I actually generated that many ecosystems, I would not be able to see them all on a single map, only being able to explore some of them in certain worlds, depending on elevation and things like that.

MT is an AMAZING engine, capable of processing data quite capably and efficiently. Limiting it to only providing MC style thinking, and thus gameplay, is missing the point entirely, IMHO.

MT is capable of a depth that a Java based MC would never be able to provide. MS misspent $2b on that one.
MY MODS: lib_ecology lib_materials lib_clouds lib_node_shapes ---- Inspired By: Open Source Virtual World Simulator Opensimulator.
 

twoelk
Member
 
Posts: 1280
Joined: Fri Apr 19, 2013 16:19
Location: northern Germany
GitHub: twoelk
IRC: twoelk
In-game: twoelk

Re: almost infinite map

by twoelk » Mon May 20, 2019 15:05

paramat wrote:'almost infinite' is a nonsense phrase =)


maybe
"only limited by available hardware"
might be a more realistic goal
 


Return to Feature Discussion



Who is online

Users browsing this forum: No registered users and 1 guest