Aura Cascade - Feedback and discussion

[pixlepix]

I've taken the liberty of manually blacklisting aura cascade nodes from the major frames mods (Including TC's blacklist) but it's a game of whack-a-mole. Eventually, I decided that anyone who wants to abuse obscure mods could use a punishment

 

[Lethosos]

Ah... okay, not an issue; I just figure it would be an interesting mechanic to play with sometime since it's practically mid-game Thaumcraft anyways.

 

[tommyTT]

There seems to be a bug when throwing down a bunch of angel steel ingots at once. I had a lot of first degree ingots, but never enough to gain me 9 stacks of eleventh degree ingots. I did a little testing and found this out:

It looks like it looses sight of what ingots already combined and simply does it again, yielding a lot higher degree ingots. It is not very reliable, but 7 stacks of first degree ingots seem to be enough to gain at least one eleventh degree ingot. It should only give you one of the sixth degree. The more ingots you input at once the worse it gets...

I guess I have to throw away my eleventh degree ingots now ...

 

[pixlepix]

Well, that was a weird bug. Fixed in jenkins builds, a CF build should be out tonight with the fix.

 

[UberAffe]

Very cool, let me know further details. For sand generation there are not too many options. Immersive Engineering maybe, but I haven't played around with it, I would guess the machines are not that fast. So in the end, elite factories from mekanism is probably the fastet way.

I watched a the newest video from nonsanity and his violet aura system is very interesting. I switched around a few things and with a long enough warm up phase, it will get to a point where it generates one angel steel ingot per second. It uses a lot of nodes, but nothing to fuel it. I have to test a few more things to see how powerful this can get, but I like the idea behind the concept.

@tommyTT
We had already installed botania as an extra mod for someone else playing with us so I just used botania and cobble gen to make sand.

Question about that violet set up:
How is that aura being dropped at a fast enough rate to make 1 per second. Even with close to 100,000 in one node it still only seems to drop 3-4,000 in 1 second.
Also you can make a much denser node setup by using 1 regular aura node at the dop points and using conserving aura nodes everywhere else. I have a 6x6x7 cuboid of nodes

@pixlepix According to your wiki there should be a max of 2,500 violet aura in one node, it can currently get up to a couple million in one node with ease. Is this a bug or just an outdated description?
link to my reference

 

[tommyTT]

@pixelpix that was fast work, nice!

@UberAffe Oh wow, what a significant mistake, it's of course one ingot per minute, one per second from a passive system would be insane Sorry to confuse you. And of course I'm using the conserving aura nodes, so the entire system is a little bit more accessible. Also I use orange aura manipulators at the bottom to force everything into the drop node. However, that seems to only affect the startup time, not the overall power.

From what I read in the commit log, the behavior of violet aura will be changed in an upcoming version to match that statement and it will completely vanish if it gets above 2600 aura. That will pretty much break this type of setup. Will be interesting to see how to get around this limitation.

 

[UberAffe]

@pixelpix that was fast work, nice!

@UberAffe Oh wow, what a significant mistake, it's of course one ingot per minute, one per second from a passive system would be insane Sorry to confuse you. And of course I'm using the conserving aura nodes, so the entire system is a little bit more accessible. Also I use orange aura manipulators at the bottom to force everything into the drop node. However, that seems to only affect the startup time, not the overall power.

From what I read in the commit log, the behavior of violet aura will be changed in an upcoming version to match that statement and it will completely vanish if it gets above 2600 aura. That will pretty much break this type of setup. Will be interesting to see how to get around this limitation.

As long as the 2600 cap only removes it from one node it really shouldn't be too much of a problem. At least in my setup every "generating node" has at most 1,800 its only the 5 "dropping nodes" which are below the "generating nodes" get above the 2600 cap. So that shouldn't have a significant impact aside from seeing smaller numbers in the "dropping nodes".

BTW my setup is like this:

Spoiler: passive setup

[7x7x8] generating nodes // I said this wrong earlier
[center drop node]
[4 side drop nodes]
[center capacitor]
[4 side capacitors]
[14 open blocks]
[top receiving node]
[4 side receiving nodes and synth]

@pixlepix Question for the pixlepix:
When a node has red aura is it coded to search the area around it for explosions, or does it just have a special interaction when it gets hit by an explosion?
I'm asking because I have been noticing some odd interactions when having multiple nodes with red aura in close proximity but not linked.
I was trying to make a more compact version of tommyTT's tnt setup. I have all the nodes and tnt explosion area's separated by Reinforced Sapphire Glass(which is supposed to stop explosions from reaching blocks on the other side of it). When I run this setup only the two nodes on the North and East side send their aura up.

If you want to try setting it up:

Spoiler: the setup

{layer1
[RSGlass|RSGlass|TNT|RSGlass|RSGlass]
[RSGlass|RSGlass|node|RSGlass|RSGlass]
[TNT|node|synth|node|TNT]
[RSGlass|RSGlass|node|RSGlass|RSGlass]
[RSGlass|RSGlass|TNT|RSGlass|RSGlass]
}
{layer2
[RSGlass|RSGlass|open|RSGlass|RSGlass]
[RSGlass|RSGlass|RSGlass|RSGlass|RSGlass]
[open|RSGlass|node|RSGlass|open]
[RSGlass|RSGlass|RSGlass|RSGlass|RSGlass]
[RSGlass|RSGlass|open|RSGlass|RSGlass]
}
{laver3
[RSGlass|RSGlass|placer|RSGlass|RSGlass]
[RSGlass|RSGlass|RSGlass|RSGlass|RSGlass]
[placer|RSGlass|open|RSGlass|placer]
[RSGlass|TNT|open|RSGlass|RSGlass]
[RSGlass|RSGlass|placer|RSGlass|RSGlass]
}

 

[tommyTT]

The placement of the TNT explosions in my setup is so that you can avoid this exact problem. The nodes search a 3x3x3 and it doesn't matter if there are air blocks or blast resistant blocks in between. I tried many different setups before, but these positions in my setup where the best I found that work reliably with only one specific node. Of course, in theory you could minimize everything to exactly one node and one capacitor anyway. As long as the timing is right and you have enough red aura, you could scale this system up to infinity...

 

[UberAffe]

The placement of the TNT explosions in my setup is so that you can avoid this exact problem. The nodes search a 3x3x3 and it doesn't matter if there are air blocks or blast resistant blocks in between. I tried many different setups before, but these positions in my setup where the best I found that work reliably with only one specific node. Of course, in theory you could minimize everything to exactly one node and one capacitor anyway. As long as the timing is right and you have enough red aura, you could scale this system up to infinity...

I suppose you could put all of that aura into a single node and still use all 5 tnt, it should have the same effect. I might try switching to that, because if I max out my tnt factory I can make about about 10/sec. that would be 200,000 red aura in one of the sides ... I'll have to play around with that.

Side note: if you enjoy playing around with timing/optimiztion you should try your hand at endergenic generators from RFTools

 

[tommyTT]

The question with the upscaling quickly becomes, if you can actually make extra progress from it. Strictly from a coding point of view, there is a maximum amount of progress that can be made, before there is a range overflow, so infinity is rather limited in the java world
I'm currently looking at the efficiency for this system, but the math somehow isn't right. I currently think my system shouldn't make the amount of progress it makes, so either I'm making a mistake, or something is going on, that I'm not considering...

The RFTools generators are definitely on my list, thanks for the tip. At the moment I'm happy with figuring out more in aura cascade.

 

[UberAffe]

The question with the upscaling quickly becomes, if you can actually make extra progress from it. Strictly from a coding point of view, there is a maximum amount of progress that can be made, before there is a range overflow, so infinity is rather limited in the java world
I'm currently looking at the efficiency for this system, but the math somehow isn't right. I currently think my system shouldn't make the amount of progress it makes, so either I'm making a mistake, or something is going on, that I'm not considering...

The RFTools generators are definitely on my list, thanks for the tip. At the moment I'm happy with figuring out more in aura cascade.

The capacitors should be forcing it to drop in 1,000 aura bundles so that should be bypassing the losses you get when dumping more than a progress requires and shooting so much into the capacitor at once also bypasses it cooldown. So this should really only be limited by the max size of int, barring unknown limiters.

 

[tommyTT]

So, I finally figured out, what is wrong with my math. Nothing However the way power is used is actually a little more complicated. So, here is what my problem was:
By generating 1 mio power per second because of the diminishing returns behavior, I should not be able to make more than 6 progress each second. At that point the requirement for the seventh step would be 640k power alone, after already using up 630k for those six steps. The actual progress I'm making with this is actually 15, so more than double the amount of progress. What is actually happening is, that the power from the nodes gets generated on tick 2 and will get divided by two at tick 18. Between tick 2 and tick 17 the consumer can use up the remaining power that is stored on every tick.
In this example, the first tick for power consumption (here tick 2) will indeed stop at the 6 progress and leave 370k of power stored in the node. On tick 3 the consumer once again consumes power, this time it is enough to make 5 progress (next power requirement would be 320k for step 6) which would leave 60k power in the node. Then on tick 4 another 2 progress are made leaving 30k power in the node. At tick 5 we have another round of power consumption and here we can even use up all of the remaining power for another 2 progress leaving the stored power at 0. In total this sums up to the 15 progress per second and all power gets used up completely. So, by accident my system is not wasting any power ...

@pixelpix Is this behavior how you wanted the diminishing returns to act? To me it feels like there is a break condition missing and the consumers should only use up power on a specific tick.

 

[UberAffe]

So, I finally figured out, what is wrong with my math. Nothing However the way power is used is actually a little more complicated. So, here is what my problem was:
By generating 1 mio power per second because of the diminishing returns behavior, I should not be able to make more than 6 progress each second. At that point the requirement for the seventh step would be 640k power alone, after already using up 630k for those six steps. The actual progress I'm making with this is actually 15, so more than double the amount of progress. What is actually happening is, that the power from the nodes gets generated on tick 2 and will get divided by two at tick 18. Between tick 2 and tick 17 the consumer can use up the remaining power that is stored on every tick.
In this example, the first tick for power consumption (here tick 2) will indeed stop at the 6 progress and leave 370k of power stored in the node. On tick 3 the consumer once again consumes power, this time it is enough to make 5 progress (next power requirement would be 320k for step 6) which would leave 60k power in the node. Then on tick 4 another 2 progress are made leaving 30k power in the node. At tick 5 we have another round of power consumption and here we can even use up all of the remaining power for another 2 progress leaving the stored power at 0. In total this sums up to the 15 progress per second and all power gets used up completely. So, by accident my system is not wasting any power ...

Where are you getting the information for your math/tick from?

 

[pixlepix]

New build is up, lets see you guys try and break this one!

 

[Wraithflay]

New build is up, lets see you guys try and break this one!

Oh no, now you've gone and challenged people on the internet, we just know this is going to end poorly. xD

 

[tommyTT]

@UberAffe I read the source code and yesterday I even did some debugging because I couldn't figure it out. With that it quickly became clear why it is happening.

@pixlepix This diminishes the rate of my system tremendously and makes it also very inefficient. At the moment I don't see a way to get around these new restrictions, so the only hope now is to scale out, not up (to use a technical term).

 

[UberAffe]

@tommyTT I disagree with simply saying that machines should only consume power on a specific tick, I think being able to take power on "any" tick is important, especially for the flux node. I do agree that "resetting" mid second is probably unintended/oversight. Once the diminishing return calculation determines it can't make another progress, it should not consume any more power during that second.
Unfortunately this seems like it will severely limit the viability of a single node with a lot of red aura and tnt.

@pixlepix Assuming that this wouldn't be too difficult to change, could the trigger for the red aura be altered to "when hit by the explosion from an identified tnt block" from "when an identified tnt block explodes". The reasoning behind this is that there are multiple mods that have use for in-world tnt use and it would be nice to be able to isolate area's.
For example Reinforced Sapphire Glass, stops explosions from passing through it, which makes it very un-intuitive for the red aura to still absorb it. This is not really a problem so much as something that I think could be more intuitive.
On a similar note: I have noticed that the burning pumps seem to be able to pick up coal from 4-6 blocks away even when there is a burning pump in need of fuel directly adjacent to where the coal was. Could the pickup/absorption of the pumps be coded to be line-of-sight and a smaller radius of pick-up. And again this isn't really a problem, just something that I feel could be more intuitive for the user.

 

[Zandorum]

Ok so, the titles of alot of the stuff in your mod freak me out. It's a title, each word should be capitalized. I cant use the mod because it urks me so much, If I changed it myself and gave you the lang file would you implement it? example: "Angel's Steel of the elventh degree" should be "Angel's Steel of the Eleventh Degree".

 

[tommyTT]

Ok so, the titles of alot of the stuff in your mod freak me out. It's a title, each word should be capitalized. I cant use the mod because it urks me so much, If I changed it myself and gave you the lang file would you implement it? example: "Angel's Steel of the elventh degree" should be "Angel's Steel of the Eleventh Degree".

If this is your problem with this mod, you can never EVER look at the Essential Craft 3 book!

@UberAffe I haven't used the fluxing node, so I can't tell how that is affecting it. The changes of course make it so one system won't cut it, at least not that I have found so far. Overall I feel like there should be another element implemented to give more control over the aura, especially with the violet aura change. There is no way to detect when the dissipation is about to happen because the comparators have a very coarse scale.

 

[Zandorum]

If this is your problem with this mod, you can never EVER look at the Essential Craft 3 book!

@UberAffe I haven't used the fluxing node, so I can't tell how that is affecting it. The changes of course make it so one system won't cut it, at least not that I have found so far. Overall I feel like there should be another element implemented to give more control over the aura, especially with the violet aura change. There is no way to detect when the dissipation is about to happen because the comparators have a very coarse scale.

I've looked at it, I'm not fine with it but I'm more fine with it there than on actual Items because I constantly have to see it when its on items.