suggestion for future ores

[hotblack desiato]

in the past few months,at least two mods were added (applied energistics and xycraft), which added new ores. with xycraft, soaryn asked for early implementation because of his new ores, which should spawn, and which would be important soon. and applied energistics solved the problem by using nether ores in the future (or should I say, it shifted the problem to another position)

so, in the future, there will be more mods which add new ores. and the problem is always the same: those new ores always generate only in new chunks, not in the already generated ones.

so how about this: you allocate 100 block IDs to those future ores, give them different densities, veine sizes and different levels where they spawn. and they should look like smoothstone and turn into regular cobblestone when mined (irrelevant which miningsystem it is). and if a new mod gets added to the pack, you just swith a lever (in the settings) and the block-id switches from smoothstone to whaever the mod wants it to be, allowing that there is a new ore in an already generated chunk.

just already mined ores would be lost, as they turn into cobblestone during mining (like normal stone).

 

[maniacpsycho]

or just quarry destroy a new mystcraft age, after just an hour on a new world you should have the resources for a mining turtle at the very least, and if you are in an established world you should have the resources for pretty much anything, only problem with this is servers that limit/ ban mystcraft ages

 

[hotblack desiato]

or for players who play minecrack (no mystcraft installed).

I know, that it's always possible to open a new mystcraft world (if mystcraft is installed and allowed), or travel 1000 blocks farther away from the base. but still, it's somehow annoying if a new mod is added to one of the ftb-packs and you need to remember where is the new ore and which places are old.

it would not solve the problem for already existing worlds, the existing chunks don't have those new ore-blocks, but it would at least solve the problem for those chunks, which are generated after implementation of that feature.

a funny side-aspect would be: after implementation, abandoned strip mines would be interesting again, because they offer access to newly activated ores.

 

[maniacpsycho]

I do actually like this idea, I was just giving an alternate solution to the issue without resorting to yet another mod and would you believe I had no idea mindcrack does not have mystcraft,I have only used dw20 before switching to ultimate minus gregtech and nether ores

 

[RetroGamer1224]

not a bad idea but 100 block IDs for ore is a bit much. Maybe twenty but even that is pushing it. I don't forsee any reason to set aside that many ids. Heck if you want put them in the nether so when they won't be in the overworld right away.

 

[hotblack desiato]

because mods could also need rare ores. so, level 1-18, and like gregtech-iridium really rare.

this way, for several different needs, there should be ores available on different levels, different veine-sizes and differend amounts.

even if you just define common-uncommon-rare, large, medium and small veines and high level, medium and low, that already reduces the amount to 10-11 IDs per combination.

that would already reduce the amount of new ores very drastically.

on the other hand, there are 4096 possible block-IDs, and the ore dictionary reduces the needed amount of new ores (the standard metals of the periodic table should be covered by these ores)

 

[RetroGamer1224]

How do you figure roughly nine variables influence block ids so much? Now I am new to coding but it seems to me that the new ore can be coded with all those variables and still only take one block id.

 

[hotblack desiato]

it's just a new ore added to worldgen. worldgen gets the information from the config file where a block with a certain ID should be created. and worldgen creates it. worldgen doesn't know that these blocks are placeholders, and that processing the unused placeholders just creates cobblestone.

it's (in this example) just 3 variables with 3 possible values per variable. even 500 possible ore-IDs should work (with much finer possible adjustments), as memory consumption and calculation doesn't depend on the different block-IDs but on the amount of blocks loaded. even air blocks take the same amount of space. regarding calculation speed, the only problematic ore right now is this quartz crystal of xycraft, which emmits light inside it's pocket. it's like these crystals of thaumcraft2, which emmitted light too, but additionally they calculated their growth...

 

[RetroGamer1224]

Soo wait. Do you want worldgen to place 500 block ids with cobble "just in case" a new ore is added? Nope sorry that just doesn't compute.

 

[hotblack desiato]

I just wrote, that even 500 different block ID's for future ores would not damage the system.

the problem is just, if a ore adds special calculations like light or liquids which flow around in caves.

 

[Adonis0]

I quite like this idea, and see the logic in it.
However, I have a feeling this idea will hit the brick-wall of "but we have other options already.."

 

[RetroGamer1224]

They do have other options. Some ids can be reserved but that means a mod is already in the works (with forge) but by the beard of Lucifer just setting aside a huge chunk of ids is a bit much. I can see maybe twenty but the mod already did that when joining forge. If stand alone then why me worry?

 

[hotblack desiato]

but look at ftb-mods and ftb-lite. they don't have matching block-IDs, preventing people from transferring their lite-worlds to the other ftb-packs. so it's the task of the mod pack maintainer to manage the block-IDs. and if a certain array of block ID's is just assigned to some ores that might be added in the future to that modpack, everyone knows which ID-range is tabu. that eases planning for everyone. those who add mods to the pack aswell as those who stay "vanilla"-ftb.

I know that modders usually try to lower the amount of used block-IDs in order to prevent ID-collisions, and that they take care of each other (more or less)... and that this idea is quite the oppsite of the regular concept. but the other side of the medal is just, that a widely explored world would not contain new ores. I already saw and read complaint treads here, because people couldn't find AE-quartz. that stuff is really common in my new ultimate world.. and it's just annoying for others who make an update to their already existing large world, suddenly being forced to move the mining system to a new overworld area (or even a new mystcraft world), just to get the new stuff.

so, I really doubt that it hurts, if these IDs are allocated to new and yet undefined ores.

by the way, with that ore dictionary of the forge system, everyone trying to register a new copper or silver or else would just be blocked... there is already copper or silver ore. those would not add ned ores of the same type. although this is some work of the modpack-creaters.

 

[MagusUnion]

by the way, with that ore dictionary of the forge system, everyone trying to register a new copper or silver or else would just be blocked... there is already copper or silver ore. those would not add ned ores of the same type. although this is some work of the modpack-creaters.

Which, in alot of cases, defeats the purpose of adding in new ores in general...

In some cases, it could be better to extract resources from pre-existing rock/ores, instead of trying to 'add more to the field'. One of the things that I do like from Gregtech is that he was smart enough to add chemical extraction of a few common materials to get to uncommon micro samples within them. Course, I really do hate his hard renewable energy nerfs, hence why I don't use it..

Plus, with Ore Dictionary, there's no reason to add a single new 'ore block'. Afaik, you can write a recipe that calls for any item that has the 'tag' of the material that you need (Copper, Tin, etc). That way, if you have a mod like Metallurgy that adds tons of new materials, you can just use it to write your mod recipes around (could be mistaken with this idea, however)...

 

[egor66]

Server admin can reset chunks.

 

[Adonis0]

Server admin can reset chunks.

Did not know about this, are they able to choose which specific chunk, or is it just like a server reset?

 

[Sinnaj63]

Server admin can reset chunks.

And this chunks contain your base.

 

[Silent]

Did not know about this, are they able to choose which specific chunk, or is it just like a server reset?

MCEdit allows you to crop the world if i remember correctly

Sent from my GT-I9300 using Tapatalk 2

 

[Adonis0]

MCEdit allows you to crop the world if i remember correctly

Sent from my GT-I9300 using Tapatalk 2

How I understood it, MCedit didn't really agree with FTB, because it got confused by all the new block ID"s and so you'd end up with things like a tree shaped vein of redstone, with redstone torches up the middle because it didn't like a new type of tree that was added

 

[Silent]

How I understood it, MCedit didn't really agree with FTB, because it got confused by all the new block ID"s and so you'd end up with things like a tree shaped vein of redstone, with redstone torches up the middle because it didn't like a new type of tree that was added

Hm I assumed if you left that area alone it will leave the IDs

Sent from my GT-I9300 using Tapatalk 2