[Discussion] Modify oregen so every chunk has a valid vein

[richardhendricks]

Currently oregen in gt5u, once it finds a valid mix for a dimension, leaves the chunk empty if that oremix was unable to place any blocks due to height restrictions.

This request-for-discussion is to consider changing it so that if an orevein attempts to place blocks, but was unable to, oregen continues searching for another valid oremix, up to the maximum attempts (currently 256, see below).

Based on my analysis of logs generated for #1909 , about 35% of the chunks at typical overworld height have no oreveins.

GT:NH is a hardmode modpack, we all get that. Tedium is part of the novelty and charm. However, I think that by allowing oregen to leave so many chunks empty, it adds too much disappointment.

Some players are spending hours looking for a specific oremix - a few going into double digits. That's simply not fun. Populating all the chunks raises the chances of finding the wanted ore or at least something else valuable. There are plenty of oremixes. You will still have to spend time looking for specific veins. This will not change that.

There are still major incentives to automate ore discovery and mining. The number of mixes is high enough that locating a specific ore will take time, so automating is still a big advantage.

Analysis is needed to determine how many attempts are needed before a useable vein is found, and how this change will affect the chunk generation time.

If we still want empty chunks, just less of them, we can implement this change but reduce the number of attempts from 256 to something lower after testing.

Side effects of proposed change:

• Longer time for chunk generation because a valid oremix must be found.
• if there is a very empty chunk generated, the oremix will be guaranteed to fit that height.
• if a chunk has no valid stone, it will max the attempts
• oreveins in short areas like Twilight Forest or deep ocean go up significantly. This could be a feature to encourage exploration and development of these zones, and will assist in finding ores that are naturally close to bedrock. I think it adds playability and progression to tell players to search for diamonds/redstone in short areas like deep ocean, or large rifts. Or underneath lava oceans in the Nether for beryllium, sulfur, etc. Versus 'just dig more holes around your whole base'

[bigbass1997]

Would just like to clarify something here, as explained in https://gtnh.miraheze.org/wiki/Ore_Generation#Generation_Process there is no checking for whether the vein is able to generate or not due to height restrictions. The 256 attempts are only for when the randomly selected mix type is not allowed in that dimension. Once a mix is selected and valid for the dimension, the height at which the vein is generated is a completely separate section of code.

In order to implement what you are suggesting, you would need to add some kind of extra check to see if ores can be generated at the selected height, if not then go back and continue trying for other veins, or if not then regenerate the height value and try that again.

[bigbass1997]

Why not just reduce the ranges where mixes generate? Instead of trying to change around the generation code. So for example, the Magnetite mix is set to a range of 60-180. Instead of adding extra checks, etc., how about the range just be shifted down? say in this example to 10-130. This would effectively increase how common this mix is in practice (though of course the weight and thus the chance still remains the same).

[Dream-Master]

Testing new ore mixes cost houres days and weeks to balancing it well. I do it for the Galaxy Space Planets and it cost me Month. If any one will do it sure why not but i guess not many people have endurance to finish it.

[bigbass1997]

Beyond changing the ranges, even though that would very well cause balancing issues as Dream mentioned; I see no real reason to make ore generation "better" in this proposed way. So what if people spend hours mining? Compare even 10 hours of mining to MONTHS of playing the rest of the modpack, and you see that mining is actually an extremely small portion of the modpack.

[richardhendricks]

I like the idea of having certain ores only at high numbers - it makes mountains worth exploring for more than just clay. Really what's needed is per biome oreweights, but that's way more complex.

Ore layer placement in https://github.com/GTNewHorizons/GT5-Unofficial/blob/experimental/src/main/java/gregtech/common/GT_Worldgen_GT_Ore_Layer.java already returns a true/false. Modify it so that the last return is true only when the sum of placecount is > 0.

There would need to be no changes in worldgenerator, since it only sets temp=false if orelayer returns true. Except for maybe decreasing from 256 to something lower after testing.

[ghost]

I am not sure that this the original suggestion is good idea, because the weights then become meaningless when the height of the terrain changes. You could guarantee low height terrain such as under an ocean would contain one of a few near-bedrock mixes. It does not seem in the spirit of the pack to be able to isolate veins by the terrain in this fashion.

[Methes]

Since GT oregen is absolutely dumb and based purely on RNG, where all you can do is just dig down every 3 chunks and pillar back up like an idiot, I am all for making it less of a PITA. Especially at the start of the game when your tools suck and you don't have a jetpack it's just frustrating for me (having played the early game tens of times). I ended up cheating in the new LuV scanner from GT++ and it's sooo much better. Now when I look at the map I can see I would have to dig around 200 holes to get Gypsum. No thank you.

[richardhendricks]

That's 10 hours of mining looking for one ore. I'd say the average time spent searching for mining is greater than that. And yes, once you have automation the time goes way down.

The problem is that a starter player has to spend hours looking for ores. This is very discouraging, as Methes points out.

[Methes]

Also isolating veins used to be the fashion with past GT, such as finding Cassiterite in Mountains for example.

[richardhendricks]

@AlphaApotheosis - I think this is a plus, not a minus. It encourages exploration and it helps guide players where to naturally search. It's too bad there isn't a similar sky-mountains for looking for high ores, ie tin for starters.

[ghost]

that's not an isolation though, it's just the only place they can be found.

the mountains still have the same chance as any other chunk to have other ores

[richardhendricks]

Realistically I doubt many bother searching mountains for those ores, since the chance of them spawning in the block is so small. Maybe you get lucky seeing an outcrop as you pass by?

[ghost]

It seems like the real question comes down to, do we want to make the start of the pack easier? Does @Dream-Master want that?

[ghost]

@richardhendricks and yeah, pretty much. Only if we see it on the outside.

[bigbass1997]

When I started this modpack over a year ago, there was absolutely no information on how to mine efficiently; yet new players still played it.. And even now, when people spend hours mining, people still continue playing. So I know full well what a starter player feels... (I have also restarted from scratch multiple times)

Even 24 hours of total mining is nothing compared to the entire modpack...

Also, world generation times are already insane, making them even longer is not helpful.

[Dream-Master]

@richardhendricks lrt spawning ores in high y leves i ok with. Is this fixed with the patch too you pushed eralier? But we talked before about density.

[richardhendricks]

No, the patch did not affect chunks with no ore due to height.

@bigbass1997 So, mining is only a small part of the modpack, so why not make it slightly more enjoyable instead of pure tedium?

If we seriously cared about generation time, I can try adding a measuring harness to find out how long oreveins take to generate. It might be possible to reduce generation time by reordering the if statements in orevein or pulling the most-likely-to-fail out of orevein and into the calling functions so that it isn't even called if a vein shouldn't be placed.

[bigbass1997]

I don't feel it is really that tedious, especially compared to other aspects of the modpack.

How are you thinking you would implement this change exactly?

[richardhendricks]

Also, it's not so much that total hours mining isn't a big deal. It's not like those hours are spread evenly across the whole time you play. Those hours are crammed into two groups, the big one being player start, and the second one every time you need a new material you haven't found. So sure 24 hours isn't much when playtime is measured in months, but 6 hours of halted progress while searching for [ore] is alot to ask for.

[richardhendricks]

Basically, the new orevein worldgen now tracks how many blocks are actually placed. If the total of all vein blocks is zero, return false instead of true. If it becomes a problem that the # of attempts gets too large (Are there any biomes/dimensions where no orevein could ever generate?) we can reduce the attempts from 256. My guess is that typically the # of attempts is low, even for The End which seems to have the least oreweight.

Nether after 32 rolls has a ~10% chance of not finding a proper vein, The End has ~20%.

[richardhendricks]

The 'right' thing to do would be have dimension specific ore generators, but that's a complex fix.

[bigbass1997]

(Are there any biomes/dimensions where no orevein could ever generate?)

Umm void dims and a few others, though GT isn't configured to generate in those anyways, so that shouldn't be an issue.

The other option would be to loop inside of vein generator instead of returning false, though that could still lead to chunks without a vein in them, like if the range of the mix is always above the surface terrain.

Maybe first do a test to see around how many attempts take place for each generation location (maybe find average?). That should help us determine the attempts limit. Otherwise, what you said is what I was thinking would be the process.

[richardhendricks]

Will do.

[draknyte1]

LuV scanner from GT++

When did I add these? o.O

[bigbass1997]

@draknyte1 I believe he was referring to the Detrav mod that adds in a scanner. Maybe he thought it came from GT++ for some reason..

[Dream-Master]

@draknyte1 The Ore scanner mod not from you. We add a modified version from Datrev Mod.

[richardhendricks]

Sorry, will take some time. Consumed with hurricane coverage, and processing some solar photos I took today.

[WarlordWossman]

I think the idea of this is really neat, and yes I also played the early game 10+ times by now. You get used to mountains being empty most of the time so if @richardhendricks can work something out here I would be very glad. Can see how bigbass1997 said that it works in it's current form but if we can improve it - why not. I know some people who stopped because they could not find vein xy. And yeah you can obv test a lot before pushing the changes so comparing how it does will be pretty easy.

[Dream-Master]

@richardhendricks sure no rush. Just let me know when it's done. The idea have more ores in high y level ist good.

[richardhendricks]

OK, I did some testing. It looks like in general oregen on Overworld takes typically 6-8 attempts to find a valid oremix. Sometimes the attempts can go as high as 30. Once it finds a valid mix, the percent of unfilled chunks due to height is around 35% (325 chunks). Sample from logs Line 6506: Generated Orevein:ore.mix.lignite @ dim=0 chunkX=304 chunkZ=304 Secondary=4173,0 Lignite Coal Ore Between=1353,0 Lignite Coal Ore Primary=4189,0 Lignite Coal Ore Sporadic=1383,0 Coal Ore Line 6507: Orevein took 33 attempts to find (no ore placed, this would be an empty chunk)

I have modified the oregen in the attached version so that if it fails to place any ore due to height, it tries to find a new oremix. With the same seed (always -1), sometimes the oregen takes up to 48 attempts to locate a vein. Sample Line 6721: Generated Orevein:ore.mix.lignite @ dim=0 chunkX=-208 chunkZ=208 Secondary=3276,0 Lignite Coal Ore Between=1089,0 Lignite Coal Ore Primary=3349,0 Lignite Coal Ore Sporadic=1048,0 Coal Ore Line 6723: Generated Orevein:ore.mix.gold @ dim=0 chunkX=-208 chunkZ=208 Secondary=1345,1079 Magnetite Ore Between=448,382 Vanadium Magnetite Ore Primary=1413,1192 Magnetite Ore Sporadic=460,316 Gold Ore Line 6724: Orevein took 48 attempts to find

Also, since a oremix has to be completely tried, a chunk may take longer to generate. I haven't tested this yet. Line 6415: Generated Orevein:ore.mix.magnetite @ dim=0 chunkX=400 chunkZ=112 Secondary=1200,0 Magnetite Ore Between=396,0 Iron Ore Primary=1225,0 Magnetite Ore Sporadic=377,0 Vanadium Magnetite Ore Line 6416: Generated Orevein:ore.mix.custom.04 @ dim=0 chunkX=400 chunkZ=112 Secondary=1293,0 Vermiculite Between=425,0 Cassiterite Ore Primary=1251,0 Chalcopyrite Ore Sporadic=435,0 Alunite Ore Line 6417: Generated Orevein:ore.mix.custom.04 @ dim=0 chunkX=400 chunkZ=112 Secondary=1357,0 Vermiculite Between=423,0 Cassiterite Ore Primary=1315,0 Chalcopyrite Ore Sporadic=448,0 Alunite Ore Line 6418: Generated Orevein:ore.mix.iron @ dim=0 chunkX=400 chunkZ=112 Secondary=1313,1087 Yellow Limonite Ore Between=426,345 Banded Iron Ore Primary=1328,1034 Brown Limonite Ore Sporadic=428,240 Malachite Ore Line 6419: Orevein took 22 attempts to find

gregtech-5.09.32.00.zip

Attached pic is a journeymap with deleted non-ores,and a view in-game. It's possible the center of the chunk is empty, for various reasons, such as it being lower than the surrounding chunk that does ore.

The max limit for attempts are still set to 256, because dimensions with low oreweights could have higher numbers before they find a vein.

YMMV. Using this version may cause anal leakage or world corruption. Do not use in production/server environments. Enable debug messages in gregtech.cfg, as given above.

[NNM42]

seed minus one?

[SirFell]

2denseveins

[NNM42]

https://docs.google.com/spreadsheets/d/11crNyEgWJ_rqgdzkUD29vxcZAqH0M-G4MD29Hu2fWEc/edit?usp=sharing

later add moon, nether, twilight, end and mars

[richardhendricks]

@SirAzazel That's kind of the point - we can now control better the vein density.

We can add a global variable to the gregtech config file now to control the ore density, instead of just guessing how dense the oreveins are going to be based on random factors. I'll work on that next, so we can get back the 65% ore density but with a tweakable variable.

[richardhendricks]

@NNM42 - Thanks for work, brilliant stuff.

[richardhendricks]

OK i have checked in a branch that adds a new gregtech.cfg variable oreveinPercentage. Default is 100%. Lowering it controls how much ore spawns.

Sample output with debug=true: Generated Orevein:ore.mix.copper @ dim=0 chunkX=-16 chunkZ=-208 Secondary=1654,1393 Iron Ore Between=557,433 Pyrite Ore Primary=1618,1208 Chalcopyrite Ore Sporadic=566,349 Copper Ore Orevein took 2 attempts to find Skipped chunk, not 3x3 center @ dim=0 chunkX=-16 chunkZ=-192 Skipped chunk, not 3x3 center @ dim=0 chunkX=0 chunkZ=-224 Skipped chunk, not 3x3 center @ dim=0 chunkX=0 chunkZ=-208 Skipped chunk, not 3x3 center @ dim=0 chunkX=0 chunkZ=-240 Skipped chunk, not 3x3 center @ dim=0 chunkX=0 chunkZ=-192 Skipped chunk, not 3x3 center @ dim=0 chunkX=-16 chunkZ=-176 Skipped orevein in this 3x3 chunk! @ dim=0 chunkX=-16 chunkZ=-160 RNG=79 %=75 Skipped chunk, not 3x3 center @ dim=0 chunkX=0 chunkZ=-160 Skipped chunk, not 3x3 center @ dim=0 chunkX=0 chunkZ=-176 Skipped chunk, not 3x3 center @ dim=0 chunkX=-16 chunkZ=-144 Skipped chunk, not 3x3 center @ dim=0 chunkX=-16 chunkZ=-128 Generated Orevein:ore.mix.lignite @ dim=0 chunkX=-16 chunkZ=-112 Secondary=3027,0 Lignite Coal Ore Between=1026,0 Lignite Coal Ore Primary=3053,0 Lignite Coal Ore Sporadic=1005,0 Coal Ore Generated Orevein:ore.mix.apatite @ dim=0 chunkX=-16 chunkZ=-112 Secondary=759,676 Apatite Ore Between=258,221 Phosphorus Ore Primary=752,591 Apatite Ore Sporadic=238,120 Pyrochlore Ore Orevein took 7 attempts to find Skipped chunk, not 3x3 center @ dim=0 chunkX=-16 chunkZ=-96 Skipped chunk, not 3x3 center @ dim=0 chunkX=0 chunkZ=-144 Skipped chunk, not 3x3 center @ dim=0 chunkX=0 chunkZ=-128 Skipped chunk, not 3x3 center @ dim=0 chunkX=0 chunkZ=-112 Skipped orevein in this 3x3 chunk! @ dim=0 chunkX=-16 chunkZ=-64 RNG=82 %=75 Skipped chunk, not 3x3 center @ dim=0 chunkX=0 chunkZ=-80 Skipped chunk, not 3x3 center @ dim=0 chunkX=0 chunkZ=-96 Skipped chunk, not 3x3 center @ dim=0 chunkX=32 chunkZ=-32 Skipped chunk, not 3x3 center @ dim=0 chunkX=48 chunkZ=-32 Skipped chunk, not 3x3 center @ dim=0 chunkX=48 chunkZ=-48 Skipped chunk, not 3x3 center @ dim=0 chunkX=32 chunkZ=-48 Skipped chunk, not 3x3 center @ dim=0 chunkX=48 chunkZ=-16 Skipped chunk, not 3x3 center @ dim=0 chunkX=80 chunkZ=-16 Generated Orevein:ore.mix.custom.04 @ dim=0 chunkX=64 chunkZ=-16 Secondary=1433,0 Vermiculite Between=500,0 Cassiterite Ore Primary=1477,0 Chalcopyrite Ore Sporadic=466,0 Alunite Ore Generated Orevein:ore.mix.gold @ dim=0 chunkX=64 chunkZ=-16 Secondary=1095,894 Magnetite Ore Between=364,278 Vanadium Magnetite Ore Primary=1040,804 Magnetite Ore Sporadic=361,222 Gold Ore Orevein took 23 attempts to find

(this build also includes cleanroom debug messages, enable in gregtech.cfg)

gregtech-5.09.32.00.zip

[draknyte1]

This would probably be a nice addition to the main branch.

[mura3277]

As @draknyte1 says, please consider opening a PR on Blood's repo.

[richardhendricks]

I already have a fork of the GTNH GT5U, so I can't fork the Blood repo. Attached is a patch diff if anyone wants to fork Blood's repo, apply the patch, and do a pull request. It is based off the 73662e53 commit to unstable branch.

patch.zip

[NNM42]

raw logs: https://drive.google.com/drive/folders/0BwbIR6GyGDSRWmE0NlpaWnUtclU?usp=sharing

2richardhendricks:

1. can you add "append" mode for GT log file?
2. to log writing info about vanilla DIM's
3. oregenerator try place ore into possible empty chunks after restart minecraft. Do you think three attempts is enough?

[NNM42]

hm... another dim's write aka "0" (ower)... 03.log - this a Twillight.

[richardhendricks]

1. I don't know if that's a good idea, it could cause log files to blow up to large numbers. Why do you think that would be useful? I don't know enough about Java to make it append, but the code is in GT_Mod.java lines 141-151.

2. I am not sure what you want here? A separate log file? The dim is already reported in the debug messages.

3. Can you clarify what you mean here? Is the oregen trying to add ore to a chunk that was already generated? Or you want it to do that?

Hmm...Now that Twilight log is interesting. It is actually hitting the 256 attempt limit in several chunks. If you wouldn't mind, could you visit some of these and report what you see there? Are they deep water chunks with no stone?

No orevein selected! @ dim=0 chunkX=-400 chunkZ=688 No orevein selected! @ dim=0 chunkX=-448 chunkZ=688 No orevein selected! @ dim=0 chunkX=-496 chunkZ=688 No orevein selected! @ dim=0 chunkX=-688 chunkZ=880

It's over a fairly large area.

I am also curious about this one:

Generated Orevein:ore.mix.magnetite @ dim=0 chunkX=-496 chunkZ=928 Secondary=1071,10 Magnetite Ore Between=372,2 Iron Ore Primary=1060,2 Magnetite Ore Sporadic=389,2 Vanadium Magnetite Ore Orevein took 210 attempts to find

Based on all the other veins failing, that looks like a floating island in the sky since this mix is 60-180. Do those exist in Twilight Forest? And yet a few chunks away, we get the opposite

Generated Orevein:ore.mix.diamond @ dim=0 chunkX=-640 chunkZ=928 Secondary=592,2 Graphite Ore Between=206,0 Diamond Ore Primary=631,0 Graphite Ore Sporadic=197,0 Coal Ore Orevein took 122 attempts to find

The average number of attempts in TF is pretty large due to the narrow range of heights. Retrying a valid vein will definitely have an impact on chunk time. It might make sense to limit the max number of attempts to 128 or even 64. Next step is to add timing information to chunk generation so we can understand how much of an effect it has.

A possible solution is to separate out the "attempts to find a valid oremix" from "attempts to use a valid orevein". We could limit the 2nd to a reasonable amount, like 2 or 4 or 8. Trying to place veins 35 times and failing is probably going to suck on potatoes.

[NNM42]

upd info You may see "screens".

How long need gen map?

may be for new session mc rename old log, example "fml-client-N.log" Twillight, Moon, Mars — it's all write to log how "DIM0"

PS: And i want chunkY to logs.

[richardhendricks]

Yeah I'm not familiar with how to get the real dimension info, I'll see if I can add something better. What do you mean chunkY to logs? The vertical start of the orevein? I can add that if you like.

This is all with seed -1 right?

[NNM42]

as deal, seed for test minus one. -1.

[NNM42]

q"the vertical start" - yep.

[richardhendricks]

OK I found how to get the dimension name, and added the Y coordinate for the Orevein print, so you can see why your vein failed to populate. This has been rebased to the latest 2.0.0 source tree on the GTNH fork.

gregtech-5.09.32.03.zip (set debugOrevein to true in gregtech.cfg)

Sample output:

RUN WorldGen chunk x:22 z:31 SIZE: 1 ADD WorldGen chunk x:21 z:32 SIZE: 1 ADD WorldGen chunk x:22 z:32 SIZE: 2 Generated Orevein:ore.mix.sulfur chunkX=352 chunkZ=496 chunkY=10 Secondary=1160 Sulfur Ore Between=441 Pyrite Ore Primary=1214 Sulfur Ore Sporadic=260 Sphalerite Ore Dimension=Nether Orevein took 9 attempts to find dimensionName=Nether

(confirmed working in TF, didn't try planets or asteroids or End)

[NNM42]

mb this help you: https://github.com/MCServerTools/ServerTools-CORE/blob/5c7cef2c7005b0fe200a3838a4c134f1dad05e6f/src/main/java/info/servertools/core/command/CommandWhereIs.java#L64

B:debugOrevein=true
B:debugWorldGen=true

--

for Moon, Mars, Makemake, Asteroids,etc. (galaxy space dims) - don't write debug info.

[NNM42]

UDP data for DIM0(OVERWORLD) Map size 4096x4096 blocks, oremix spawn 99.8%. for oremix maybe needed reconfigure Y spawning... https://drive.google.com/open?id=0BwbIR6GyGDSRWmE0NlpaWnUtclU

[NNM42]

Q: what DIM need next?