ok, thank you for the confirmation. without that i wouldn't have been able to ask the actual "questions":
(since im no coder, i have to continue to use the figurative speech)

• Assumptions:
  so - currently, each "tile" represents a "pixel" of a rather large uncompressed bitmap (2048x2048) depending on the bit depth, you probabyl have something like a few identification bits for the ore type, and the others for the actual amount (like hue and saturation of a picture).

  That way you cannot have more then one ore type per tile if they are all in one "picture" (which i assume is the case atm), and even "empty" tiles consume memory.

  You also cannot identify ore deposits as "one entity" after their random creation, nor can you apply additional "data" to a deposit, like a "creation date" or such, because you would need to write that into each pixel and that would blow up the memory usage again.

• Question
  If my assumptions are right, my question would be - could you modify that system so mineral data is stored like a in a vector image, that handles individual ore deposits as entities?
  That way you would be able to handle them with greater flexibility, adding attributes to deposits.
  each coordinate on the map could contain multiple ores, while keeping filesize low.
  

Just imagine the possiblities:

• adding "depth" attribute to HDT - small deposits easy to be found on the "surface", or huge deposits so deep down that you need a mining tower to access them.

• Revamping the geoscan accuracy system, so instead adding (noob unfriendly) static noise, it affects which deposits your able to find.

• Easy identification of half-mined deposits that should be purged at some point

• certain geoscanner charges could count whole deposits instead of just single tiles *hint*

• Variable Isotope spawn rate per ore

• Having a "center" coordinate for each deposit would also make it easier to script Niani NPC Mining operations

• ... im sure your creative minds would find even more advantages

adding your post up, it seems its a post for the sake of a post...

and i dont know what you did add up - after all its a question to the coder DEV, who is the only one who can answer it.

Most, if not all what you describe can be done with a bitmap just as fine. A 2048x2048 bitmap with a few spots on it consumes probably less than a hundred kilobytes, which is stored server-side anyway (would be disturbing if it isn't).

Keep in mind that I'm no coder either.

But common sense tells me that there is really no point in using vector formats for mineral fields if the end result has to be a grid due to the tiled nature of the terrain. If you can mine the tiles of a field in a random manner, eventually that will become a noise pattern. And noise is much harder to store in a vector format than in a bitmap.

So I guess what you propose is to not have an island-sized mineral map, but instead have smaller individual mineral maps laid over the map at the proper coordinates?

wow, almost exactly two years between the last DEV Comment in here, and the announcement to put it onto the server

http://forums.perpetuum-online.com/topi … ld-system/

I suggested a similar system that can go well with this change i guess. ^