Thermal Expansion 3.0!!! No More Beta! Thanks KL!

[PierceSG]

Hmm...will the TE3's sulfur be oredict compatible with RC's sulfur?

 

[arthahar]

Hmm...will the TE3's sulfur be oredict compatible with RC's sulfur?

Just checked: in TE3.b8 its compatible already.

 

[Kik]

I've been told it is possible to set or configure your tesseract so that people you designate can tap into your frequencies but others cannot. Is that correct and if so how does that work exactly?

 

[PsionicArchon]

I've been told it is possible to set or configure your tesseract so that people you designate can tap into your frequencies but others cannot. Is that correct and if so how does that work exactly?

While in game type /cofh friend add 'the person's username' without the ' of course. When you click the restricted icon with a heart on it only people added as friends will be able to access the tesseract. It doesn't seem like this extends to frequencies though, only who can or can't actually touch the tesseract.

 

[King Lemming]

While in game type /cofh friend add 'the person's username' without the ' of course. When you click the restricted icon with a heart on it only people added as friends will be able to access the tesseract. It doesn't seem like this extends to frequencies though, only who can or can't actually touch the tesseract.

Yup. There's no great way to set up a small Tesseract "cluster" at this point. We've had a few ideas for it, but it would pretty much require a giant overhaul of how exactly Tesseracts work.

 

[Kik]

Thank you very much for the quick reply. Having lots of fun so far ^_^.

 

[PierceSG]

Thanks again KL for the tip on bare hands right clicking on ducts. :3

 

[PhilHibbs]

Thanks again KL for the tip on bare hands right clicking on ducts. :3

That's one of the advantages of watching Let's Plays. Some say "why watch others playing the game when you can play it yourself", but seeing how things work is the main reason I watch DW20. Especially when there's something as game-changing as a completely new version of TE or TC.

 

[Omicron]

Hey KingLemming, I'd like to talk about ore generation a bit.

In my world, I use CoFH Core to manage ore generation, because it's so powerful and convenient. I generate TE lead and TE silver in two completely different height bands. There's actually a gap of 20-30 blocks between them where neither generates, so I can very easily tell them apart. both ore types had their spawn amounts scaled up from the defaults in proportion to the height band widening they received, to maintain roughly the same mining amounts as per default.

(The largest parts of the world were generated with early TE3 builds, in case it matters - beta 2, 3, 5 or 6b.)

Now, I know from previous versions of TE that lead and silver often generate together in clusters, but here is what I am observing:
- Silver always generates as silver, 100% of the time
- But lead on the other hand more than half the time generates as silver instead

I can reliably go into the proper height band for lead, mine/cavedive for a while, and come out with something like 13 lead and 17 silver (to name a specific example from last night). A single lead vein consisting of for example 7 blocks will turn up to have 3 blocks lead and 4 blocks silver. Meanwhile, the quarry eating through the silver height band down below will spit out 3 stacks of silver and zero lead. As a result, me and everyone else playing on my server is chronically short on lead all the time, while silver piles up uselessly in chests. Lead after all is used for leadstone (and by extension hardened) conduits and energy cells, as well as for opaque itemducts and fluiducts. And it is also required for hardened glass, which you need for the later-game variations of the same. That's a lot of the infrastructure of TE that's absolutely dependant on. Silver, on the other hand... single bars for transmission coils for engines, and the 4 bars needed for a tesseract. That's more or less it.

The issue grows worse if you add other mods, like IC2, while still depending solely on TE's ore generation for consistency. IC2 Experimental requires moderate amounts of lead for nuclear reactor work, while silver is only ever used in one recipe - glass fiber cable, which has gotten so absurdly diamond-expensive that there's almost no justification to ever build more than one or two batches for niche applications. Again you need far more lead than silver, compounding what's a minor issue in TE alone to a much larger one as far as modpacks are concerned.

So from the perspective as a world/modpack builder and server admin, the way TE currently generates lead and silver is very inconvenient. Instead of having this 50/50 (or even 40/60?) split of lead but a 0/100 split for silver, wouldn't something like 80/20 for lead and 20/80 for silver be more sane? That would keep the interesting multi-composition ore vein feature while still clearly differentiating the two types and allowing an admin to actually control the amounts via the config in a meaningful way... and allow a player to actually find what he's actively looking for, too.

 

[King Lemming]

Hey KingLemming, I'd like to talk about ore generation a bit.

In my world, I use CoFH Core to manage ore generation, because it's so powerful and convenient. I generate TE lead and TE silver in two completely different height bands. There's actually a gap of 20-30 blocks between them where neither generates, so I can very easily tell them apart. both ore types had their spawn amounts scaled up from the defaults in proportion to the height band widening they received, to maintain roughly the same mining amounts as per default.

(The largest parts of the world were generated with early TE3 builds, in case it matters - beta 2, 3, 5 or 6b.)

Now, I know from previous versions of TE that lead and silver often generate together in clusters, but here is what I am observing:
- Silver always generates as silver, 100% of the time
- But lead on the other hand more than half the time generates as silver instead

I can reliably go into the proper height band for lead, mine/cavedive for a while, and come out with something like 13 lead and 17 silver (to name a specific example from last night). A single lead vein consisting of for example 7 blocks will turn up to have 3 blocks lead and 4 blocks silver. Meanwhile, the quarry eating through the silver height band down below will spit out 3 stacks of silver and zero lead. As a result, me and everyone else playing on my server is chronically short on lead all the time, while silver piles up uselessly in chests. Lead after all is used for leadstone (and by extension hardened) conduits and energy cells, as well as for opaque itemducts and fluiducts. And it is also required for hardened glass, which you need for the later-game variations of the same. That's a lot of the infrastructure of TE that's absolutely dependant on. Silver, on the other hand... single bars for transmission coils for engines, and the 4 bars needed for a tesseract. That's more or less it.

The issue grows worse if you add other mods, like IC2, while still depending solely on TE's ore generation for consistency. IC2 Experimental requires moderate amounts of lead for nuclear reactor work, while silver is only ever used in one recipe - glass fiber cable, which has gotten so absurdly diamond-expensive that there's almost no justification to ever build more than one or two batches for niche applications. Again you need far more lead than silver, compounding what's a minor issue in TE alone to a much larger one as far as modpacks are concerned.

So from the perspective as a world/modpack builder and server admin, the way TE currently generates lead and silver is very inconvenient. Instead of having this 50/50 (or even 40/60?) split of lead but a 0/100 split for silver, wouldn't something like 80/20 for lead and 20/80 for silver be more sane? That would keep the interesting multi-composition ore vein feature while still clearly differentiating the two types and allowing an admin to actually control the amounts via the config in a meaningful way... and allow a player to actually find what he's actively looking for, too.

Here's the problem:

/* LOADING FUNCTIONS */
    void loadWorldGeneration() {

        String category = "world.thermalexpansion";

        List<WeightedRandomBlock>[] oreList = new List[TEProps.Ores.values().length];

        for (int i = 0; i < oreList.length; i++) {
            oreList[i] = new ArrayList<WeightedRandomBlock>();
        }
        oreList[TEProps.Ores.COPPER.ordinal()].add(new WeightedRandomBlock(BlockOre.oreCopper));
        oreList[TEProps.Ores.TIN.ordinal()].add(new WeightedRandomBlock(BlockOre.oreTin));
        oreList[TEProps.Ores.SILVER.ordinal()].add(new WeightedRandomBlock(BlockOre.oreSilver, 90));
        oreList[TEProps.Ores.LEAD.ordinal()].add(new WeightedRandomBlock(BlockOre.oreLead, 80));
        oreList[TEProps.Ores.NICKEL.ordinal()].add(new WeightedRandomBlock(BlockOre.oreNickel));

        if (BlockOre.enable[TEProps.Ores.LEAD.ordinal()]) {
            oreList[TEProps.Ores.SILVER.ordinal()].add(new WeightedRandomBlock(BlockOre.oreLead, 10));
        }
        if (BlockOre.enable[TEProps.Ores.SILVER.ordinal()]) {
            oreList[TEProps.Ores.LEAD.ordinal()].add(new WeightedRandomBlock(BlockOre.oreSilver, 20));
        }
        for (int i = 0; i < oreList.length; i++) {
            CoFHWorld.addFeature(category, oreList[i], BlockOre.NAMES[i], TEProps.oreClusterSize[i], TEProps.oreNumCluster[i], TEProps.oreMinY[i],
                    TEProps.oreMaxY[i], CoFHWorld.ORE_UNIFORM, true, BlockOre.enable[i]);
        }
    }

That's the actual distribution, in the code. It's already 80/20 like you are asking, 10/90 on Silver veins though. So basically the code doesn't support your observations, so I'm not sure what to tell you.

I should point out that you can certainly customize any of the spawn characteristics here, and you could even add a new custom Lead-only vein using WorldCustomGen.txt.

If you're willing to do a massive Quarry sample (I mean like 100s of chunks) and can prove that something is going wrong with world gen, I can take a look at it, but right now there's no reason that comes to mind why this wouldn't work properly.

 

[Omicron]

Hmmm. How very odd. I have no reason to doubt your code quote, but we'd have had to strike a really bad streak repeatedly to get the amounts we're seeing.

Is it possible that moving some numbers outside their expected range causes unusual effects? For example, I am generating lead in a height band where vanilla doesn't even generate terrain in most cases (80-120). And back in 1.4.7 I saw something to that effect when generating copper as one vein per chunk, size 72 instead of the then-default of 8 veins of size 9 (roughly, I slightly adjusted numbers). On paper, that should give roughly similar amounts of copper per chunk, but instead I got the hilarious results of copper veins sized 2,000+ blocks that took a team of 4 people over an hour to mine.

...on the other hand, I moved tin and ferrous even higher up and they don't show abberrant behavior. Hmmm.

Large scale quarry samples might be tricky since my computer is currently pretty much always running the server when it is on, but I'm going to keep a record of any lead deposit I can find and of any future quarry sites. If nothing else, your post has at least given me hope that we might just be hitting an extremely freaky outlier on the probability curve.

In the meantime, I guess it's time to check whether Thaumcraft 4 can still do lead transmutation...

 

[MigukNamja]

... to check whether Thaumcraft 4 can still do lead transmutation...

Possible, yes, but not cheap. You will be burning a *lot* of Metallum (*cough* excessive silver *cough*) in the Crucible to turn 1 lead nugget into 3 lead nuggets. Expect lots of the purple taint liquid. I have a Crucible in its own Mystcraft Age for similar Crucible-spam purposes, like making stacks of Thaumium.

As for me, I didn't have a silver "problem" since I needed even more Silver than lead to make a Factorization solar boiler setup on the roof of my TE3 building.

 

[Omicron]

Admittedly, Factorization will consume silver for breakfast, yes. I suppose if we had it in our pack it would be less of an issue... though we'd still be short on lead, since Factorization also gobbles that up

 

[MigukNamja]

KL,

Correct me if I'm wrong, but when CoFH ore worldgen is enabled, *both* of these will be added to the list:

oreList[TEProps.Ores.LEAD.ordinal()].add(new WeightedRandomBlock(BlockOre.oreLead, 80));
...
oreList[TEProps.Ores.LEAD.ordinal()].add(new WeightedRandomBlock(BlockOre.oreSilver, 20));

What's the difference between WeightedRandomBlock(BlockOre.oreLead, 80) and WeightedRandomBlock(BlockOre.oreSilver, 20) ?

Specifically, how does WeightedRandomBlock know to fill in the rest with ? Is it possible WeightedRandomBlock is filling in oreSilver, 20 with 20:80 Silver:Silver ?

 

[Golrith]

Hmm. Always wondered why Lead/Silver always seemed to generate together. Now I know.
I don't notice it so much now that I use custom world gen, with most of the ore generation moved to there.

 

[King Lemming]

Hmmm. How very odd. I have no reason to doubt your code quote, but we'd have had to strike a really bad streak repeatedly to get the amounts we're seeing.

Is it possible that moving some numbers outside their expected range causes unusual effects? For example, I am generating lead in a height band where vanilla doesn't even generate terrain in most cases (80-120). And back in 1.4.7 I saw something to that effect when generating copper as one vein per chunk, size 72 instead of the then-default of 8 veins of size 9 (roughly, I slightly adjusted numbers). On paper, that should give roughly similar amounts of copper per chunk, but instead I got the hilarious results of copper veins sized 2,000+ blocks that took a team of 4 people over an hour to mine.

...on the other hand, I moved tin and ferrous even higher up and they don't show abberrant behavior. Hmmm.

Large scale quarry samples might be tricky since my computer is currently pretty much always running the server when it is on, but I'm going to keep a record of any lead deposit I can find and of any future quarry sites. If nothing else, your post has at least given me hope that we might just be hitting an extremely freaky outlier on the probability curve.

In the meantime, I guess it's time to check whether Thaumcraft 4 can still do lead transmutation...

Well the 1.4.7 thing still happens, because numClusters needs a rename. That's actually the diameter of the ore vein, the way vanilla does it. Kind of a little bit stupid. I may add a new gen algorithm that is much more true to the naming.

I'll maybe tweak lead to be 20% in silver veins.

KL,

Correct me if I'm wrong, but when CoFH ore worldgen is enabled, *both* of these will be added to the list:

oreList[TEProps.Ores.LEAD.ordinal()].add(new WeightedRandomBlock(BlockOre.oreLead, 80));
...
oreList[TEProps.Ores.LEAD.ordinal()].add(new WeightedRandomBlock(BlockOre.oreSilver, 20));

What's the difference between WeightedRandomBlock(BlockOre.oreLead, 80) and WeightedRandomBlock(BlockOre.oreSilver, 20) ?

Specifically, how does WeightedRandomBlock know to fill in the rest with ? Is it possible WeightedRandomBlock is filling in oreSilver, 20 with 20:80 Silver:Silver ?

You're wrong, but I'm not even sure how to correct you here. Like, I'm sort of confused about where you are being confused with this. Yes, it adds both to the list. Lead at 80% and Silver at 20%. It knows what to add because they are explicitly being added.

If either one is disabled, then the way the weighted list works means that it'll roll 0-79 for lead veins or 0-89 for silver veins, and it's still proper.

 

[MigukNamja]

I'm sort of confused about where you are being confused with this

Sorry, should have been more clear. What does it generate (put in the world) when the roll fails ? Does it simply not replace the stone with Silver or Lead ?

So, this:

if (BlockOre.enable[TEProps.Ores.SILVER.ordinal()]) {
oreList[TEProps.Ores.LEAD.ordinal()].add(new WeightedRandomBlock(BlockOre.oreSilver, 20));
}

Would result in Lead vein blocks being replaced with Silver 20% of the time, i.e. 0-19, correct ? Otherwise, if 20-99, then it stays as it was, i.e. Lead.

However, prior to that, this would have already reduced the Lead vein to 80/20 Lead/Stone:

oreList[TEProps.Ores.LEAD.ordinal()].add(new WeightedRandomBlock(BlockOre.oreLead, 80))

So, the end result is actually 1 - 0.20 - (0.2 * 0.8) = 64% lead. The total lead vein is thus 64% lead, 20% silver, for a 16:5 = 3.2:1 Lead:Silver ratio for lead veins rather than 80:20 = 4:1 as the target.

Silver, OTOH, is 1 - 0.10 - (0.1 * 0.9) = 81% silver. The total silver vein is thus 81% silver, 10% lead, for a 81:10 = 8.1:1 Silver:Lead ratio for silver veins rather than 90:10 = 9:1 as the target.

Hence, more silver than lead than expected. Or, to rephrase that, a lower ratio of lead to silver than expected.

 

[MigukNamja]

For Lead veins, the equation thus might be:

100 - S - (S * L) = 80

If we set L to 80, we get:

100 - S - 80S = 80
20 - S = 80S
20 = 81S

S = 20/81 =~ 0.25

Similary, for Silver, we get:

100 - L - 90L = 90
10 - L = 90L
10 = 91L

L = 10/91 =~ 0.11

Would this work ?

/* LOADING FUNCTIONS */
    void loadWorldGeneration() {

        String category = "world.thermalexpansion";

        List<WeightedRandomBlock>[] oreList = new List[TEProps.Ores.values().length];

        for (int i = 0; i < oreList.length; i++) {
            oreList[i] = new ArrayList<WeightedRandomBlock>();
        }
        oreList[TEProps.Ores.COPPER.ordinal()].add(new WeightedRandomBlock(BlockOre.oreCopper));
        oreList[TEProps.Ores.TIN.ordinal()].add(new WeightedRandomBlock(BlockOre.oreTin));
        oreList[TEProps.Ores.NICKEL.ordinal()].add(new WeightedRandomBlock(BlockOre.oreNickel));

        if (BlockOre.enable[TEProps.Ores.LEAD.ordinal()]) {
           oreList[TEProps.Ores.SILVER.ordinal()].add(new WeightedRandomBlock(BlockOre.oreSilver, 90));
           oreList[TEProps.Ores.SILVER.ordinal()].add(new WeightedRandomBlock(BlockOre.oreLead, 11));
        } else {
           oreList[TEProps.Ores.SILVER.ordinal()].add(new WeightedRandomBlock(BlockOre.oreSilver, 90));
        }

        if (BlockOre.enable[TEProps.Ores.SILVER.ordinal()]) {
           oreList[TEProps.Ores.LEAD.ordinal()].add(new WeightedRandomBlock(BlockOre.oreLead, 80));
           oreList[TEProps.Ores.LEAD.ordinal()].add(new WeightedRandomBlock(BlockOre.oreSilver, 25));
        } else {
           oreList[TEProps.Ores.LEAD.ordinal()].add(new WeightedRandomBlock(BlockOre.oreLead, 80));
        }

        for (int i = 0; i < oreList.length; i++) {
            CoFHWorld.addFeature(category, oreList[i], BlockOre.NAMES[i], TEProps.oreClusterSize[i], TEProps.oreNumCluster[i], TEProps.oreMinY[i],
                    TEProps.oreMaxY[i], CoFHWorld.ORE_UNIFORM, true, BlockOre.enable[i]);
        }
    }

 

[Plumarr]

As I understand the code the roll are not necessary on [1-100] but on the sum of the weight factors.

So, when a lead cluster is generated there is a roll [1:100] for each block and if the result is <= 80 it's a lead block and otherwise a silver block. Same principle for the the silver node : if the roll <= 90 it's a silver block, otherwise it's a lead block.

If the silver ore is disabled, there will only be roll [1-80] when placing a block in a lead cluster. And there rules hasn't changed : if the result <= 80, it's a lead block that's generated. As all the rolls will be <= 80, the cluster will be full of lead.

 

[MigukNamja]

I think you're confunding node and block.

As I understand the code, when a lead cluster is generated there is roll [1:100] for each block and if the result is <= 80 it's a lead block and otherwise a silver block. Same principle for the the silver node : if the roll <= 90 it's a silver block, otherwise it's a lead block.

Not sure where you're getting the "otherwise it's an X block" logic from. I believe the "other" kind of block is stone the first time and possibly the 2nd time as well, not necessarily lead/silver. Also, keep in mind the list is run in a serialized fashion. If CoFH oreGen is enabled, then the main silver and lead vein gen will run first, resulting in 90% silver for silver veins and 80% lead for lead veins. *Then* the optional CoFH 10% and 20% code runs on top of (after) that. Hence, my question earlier about oreList[].add .

Possibly looking at compound probabilities than simple probabilities.

But, need KL to verify.