Faust

A Faustian bargain. A deal with the devil.

What is it, precisely, that makes a Fasustian bargain Fasustian? Any bargain involves exchanging X for Y, and that’s cool. But a Faustian bargain is more than simply an unfair or ill-considered bargain. It’s more than simply that X was actually worth more than Y. It’s that X was the thing that gave Y its value. That when you surrender X to get Y, Y becomes worthless because you have surrendered X.

Wilde (I think) does this in “The Gift”. The classic is the exchange of your soul for power. Once you have surrendered your soul, any power you might wield you only wield at the command of the one to whom your soul now belongs.

Awesome as Y might be, if you surrender the entire point of having Y in order to get it, then you have made a bad bargain.

More Minecraft

This is going to get very freaky, very weird. Oh, maybe not for people who already have a particular kink – people with lisps, Haskel programmers. But everyone not already an FP weenie will need to take a shot of espresso and/or whiskey.

Ok.

So, the build described on my previous post does indeed process astral sorcery crystals. But building all of those chains of NBT variables is a pain. Wouldn’t it be nice if there was a function that would simply get the size and cut of a crystal, nested all the way down in those NBT tags? Well, you can build them.

There are a couple of things to know. First, all of the built-in operators can be turned into an operator variable using (obviously) the operator entry in the portable programmer. You can then use the apply operator to give that variable some parameters, and it works the same as if you had simply used the operator.

Second, FP languages have an interesting method of handling functions with multiple arguments. In principle, a function only ever has one argument – it maps one thing onto another thing. So how is something like, say, addition done? Say we want to add 100 and 200. Well, the + function takes one integer argument. So when you give it a parameter of 100, it returns a function that adds 100 to things. This function is then applied to the second argument, giving you the 300 you wanted.

In Integrated Dynamics you can totally do that, you can take a function taking three arguments and bind something to the first argument, giving you a function (an operator) that takes two arguments. And so on.

I suppose the third thing to note is that all the things I am interested in start at a tag named ‘tag’. That is, various things give you back various types of lists and NBTs. The outer layers are specific to entities, inventories, blocks. For instance, an entity reader gives you an NBT that talks about the location and orientation of the entity, the inventory reader gives you an NBT talking about which slot in the inventory an item is in, the grindstone just starts at the top level, because it’s not done as a cointainer. The stuff common to these containing the astral sorcery gear starts at ‘tag’, wherever that might be. From that point you walk down: tag, astralsorcery, crystalProperties, size/collectiveCapability/purity.

So what I really want is a pair of functions which, given an NBT with a ‘tag’ entry, walk down to the integer ‘size’ entry and return it.

Let’s see how deep the rabbit-hole goes.

Walking down the tree

First, create an NBT object with that ‘tag’ at the top level. For instance, if your entity reader has a crystal floating in front of it, grab the entity aspect of the reader, then use entityNBT and then NBT.tagNBT to grab the ‘Item’ entry out of that tag. You could build a function to do this, but for now I am not going to bother.

I label the item variable ‘crystal’, its NBT ‘crystalNBT’, and the Item entry of that ‘crystalItem’.

This gives us an NBT with the structure that we will be working with – it’s our test data.

Next I use the portable programmer ‘Operator’ function to get two operators: ‘reduce’ and ‘NBT NBT Value NBT’. Yeah, I know. I label these λreduce and λgetNBT.

I then create a list of string containing the values ‘tag’,’astralsorcery’, ‘crystalProperties’. Case-sensitive, remember. I label this tag2cp.

Now at this stage, we can get the inner NBT fairly easily without needing λreduce. Create a variable ‘reduce(λgetNBT, tag2cp, crystalItem)’. This will use the reduce function to walk down the list of strings applying the λgetNBT operator each time, starting with crystalItem. At the end of the list, it will have reached the target NBT.

You can achieve the same effect using the apply3 operator: ‘λreduce apply3(λgetNBT, tag2cp, crystalItem)’.

But I don’t want a variable that extracts the stuff out of crystalItem, I want a function that will extract out of any suitable NBT.

Making the treewalk into an operator

To do this, I ‘λreduce apply(λgetNBT)’ to get another variable which I name ‘λnbtWalk’. This is a function that takes two arguments – a list of string and an NBT. It will walk down any NBT with a list, returning the final NBT.

I then create a variable ‘λnbtWalk apply( tag2cp)’, which I label ‘λnbt2cp’. This is a function which, given an NBT, will return that final NBT containing the crystla properties (if it’s there, obviously).

When you create a variable ‘λnbt2cp apply(crystalItem)’ and drop it into a display, well blow me down if it don’t display that inner NBT containing the stuff we want. Let’s label this variable ‘cprops’ for now. We wont need it in the final result, but it’s handy for testing the next bit.

Getting the integer

Now, we can’t use the λnbtWalk function to get all the way down to size and cut, because these are integers and the λgetNBT function will return nothing.

So, we create an operator variable out of ‘NBT NBT Value Integer’ and label it ‘λgetInt’. You can apply an NBT and a string to this to get an integer from inside an NBT. The problem is that the arguments are around the wrong way. If you used ‘apply’, you’d have to bind the NBT first and you’d get a function that would get any integer out of some particular NBT if you give it a tag name. NOt what we want.

So, create a new operator using ‘flip(λgetInt)’. This gives us the get Int function with its arguments swapped. I name this ‘λgetInt_YX’, with the idea that function arguments are usually named ‘X’, ‘Y’ in that order.

Create a string ‘size’ labelled – ohh, I dunno – ‘size’. At this stage, you can create a variable ‘apply2(λgetInt_YX, size, cprops)’ and drop it in a display, and you should see an integer. And not just any integer, but the size of the crystal sitting in front of the entity reader.

Now create a new variable ‘λgetInt_YX apply(size)’. This gives you a function returning the size value from any NBT that it is passed. I label this ‘λgetSize’.

Putting it together

And to put it together, we use the pipe operator: ‘.’. Simply λnbt2cp . λgetSize’ to give a new operator, which I label ‘λnbtSize’. And this is the magic, this is the thing we are trying to build. It’s a function taking one argument – the top level astral sorcery NBT containing a ‘tag’ entry, and returning the size of the crystalProperties NBT buried three levels deep. Try it! Create a variable ‘λnbtSize apply crystalItem’. Drop it in a display, and you should see the size. Naturally, you will want to make ones for purity and collectiveCapability (which I always label ‘cut’) as well.

From here

From here, you can, well, do stuff. Turn ‘entity->get(‘Item’)->λnbtSize’ into a single operator, if you want.

But the real thing is building predicates. With these functions, you can now build a predicate ‘crystal has size 900’ by applying 900 to the == operator and piping λnbtSize into it. This can be used in item exporters and importers as a filter. Stuff like that. I’m not going to rebuild my setup using this method, but the business of sorting out completed crystals from ones still needing to be cut could have been done that way. If it were the case that you could put multiple crystals in the one growth pool, and you want to pull out the ones that are ready, then that’s the way to go.

Anyway, that’s what it took to make this happen in my creative test world. Haven’t used it in survival, yet, but that’s how it’s done.

Some minecraft

This post attempts to describe my setup for growing maxed-out astral sorcery crystals using integrated dynamics and integrated tunnels.

To make all this work, we use several ID channels. Each channel has a single chest or fluid tank. The components work by exporting and importing crystals between appropriate channels.

Starlight

Run fluid pipe from beneath your lightwell into a tank. If you are using Thermal Dynamics for this, it must be at least hardened or it will break (starlight is extremely cold). You will need a servo, because lightwells don’t auto-extract. Attach a fluid interface to the tank – my setup uses channel 0.

Channels

Add three chests to the network each with its own item interface on channels 1,2, and 3. Channel 1 will be for crystals needing to be grown, channel 2 for crystals needing to be cut, and channel 3 for completed maxed-out crystals.

Budding off new crystals

Create a spot for the budding pool. This spot will have an entity reader, a world fluid exporter, and an world item importer. Easiest way to to this is to place a solid block, put the components on that, then break the solid block.

Create a fluid variable from a bucket of starlight. This goes in the place fluids aspect of the fluid placer, using channel 0. This will keep the block full of starlight as it is used up.

Throw a celestial crystal with a purity of 100% in the pool. To get one of these, go through the process manually: you only need to do it once.

Make a variable from the ‘entities’ aspect of the reader. This will be of list type. Make an integer variable from the len of that list. Make a constant variable 1. Make a boolean variable that is true when the list length > 1. Put this in the ‘pick up all item entities’ aspect of the world item importer. Set the channel to 1 (or 2, that also works). The rate does not matter, because each crystal counts as its own stack.

The result is that the crystal in the pool will be grown, the starlight replenished as needed, and when a new crystal buds off, it will be put in the chest on channel 1.

Growing the crystals

Make another pool. This one needs a world fluid exporter exporting starlight from channel 0, an entity reader, a world item exporter, and two world item importers.

As with the budding-off pool, read the entities aspect to get a list variable and use the ‘is empty’ list operator to get a boolean variable (easier than len()==0). This goes in the ‘place all item entities’ aspect of the world item exporter, which must get its items from channel 1. The effect of this is that it will pick out a crystal from the ‘needing to be grown’ chest whenever there is no crystal in the pool.

And now it gets a little complicated. 🙂

Take a variable off the ‘entity’ aspect of the reader. Make a variable entity off this using ‘entity NBT’, to give an NBT object. Create String variables with the strings ‘Item’, ‘tag’, ‘astralsorcery’, ‘crystalProperties’, ‘size’, and ‘collectiveCapability’. These are probably case sensitive.

Using the NBT.tag function, create a series of variables drilling down the NBT tree -> ‘Item’, ‘tag’, astralsorcery’, ‘crystalProperties’, then on that final NBT create two integer variables using NBT.integer for ‘size’ and ‘collectiveCapability’. Use your labeller. In my setup, I label the ‘collectiveCapability’ variable to ‘cut’, and the ‘size’ variable to ‘size’, duh.

Create two integer variables with values 100 and 900 (assuming we are making celestial crystals. You’d use 400 for regular crystals … but why would you bother? You only need one to start with). Create three boolean variables size==900 (which I label ‘big’), cut==100 (which I label ‘perfect’), and cut!=100 (which I label ‘imperfect’).

Create a variable using the && operator for ‘big && perfect’. This goes in the ‘pick up all item entities’ aspect of one of the world item importers and should import into to channel 3. This is the output.

Create a variable for ‘big && imperfect’. This goes in the ‘pick up all entities’ aspect of the other world item importer and should import into channel 2.

The end result is that whenever this pool is empty, a crystal will be placed into it from chest #1 and the crystal will be grown until it has size 900. At that point it will get put either in chest 2 or 3 depending on whether is it properly cut or not.

Cutting the crystals

Place a grindstone. This will need 3 player simulators and a block reader. Place another chest with an inventory reader, an item interface, and an item exporter. The item interface will be on channel 4.

Take a variable from the ‘inventory empty’ aspect of the inventory reader. I label this ‘4empty’.

Take a variable from the Tile Entity NBT aspect of the block reader on the grindstone. Make string variables ‘tag’, ‘astralsorcery’, ‘crystalProperties’, ‘size’ and ‘collectiveCapability’ (or re-use the ones you already have).

As with the growth pool, descend the NBT tree on the grindstone to get integer variables for tag.astralsorcery.crystalProperties.size and .collectiveCapability . I prefix all the label names with gs_ for ‘grindstone’, and so these two variables get labelled ‘gs_size’ and ‘gs_cut’.

Use the NBT.hasKey(‘tag’) operator on the root tile entity NBT variable to make a variable named ‘gs_hasCrystal’, and the negation of this to make a variable named ‘gs_noCrystal’. This works because the ‘tag’ NBT entry on the grindstone is only present if there is a crystal in it (there is no ‘Item’ entry because the grindstone is not an inventory – that’s why you need player simulators).

Make a boolean variable labelled ‘gs_perfect’, from ‘gs_cut == 100’. Make another boolean variable ‘gs_imperfect’ from ‘gs_cut != 100’.

Make a boolean variable ‘gs_toosmall’ from ‘gs_size < 100'. I use 100 because a single pass of the grindstone takes less than 100 size off a crystal, and I already have an integer variable with a value 100, so I can re-use it 🙂 .

Make a boolean variable 'gs_done' from 'gs_toosmall || gs_perfect', and a variable 'gs_notdone' from '!gs_done'.

On the item exporter on the chest, have it 'export all items items' from channel 2 with the condition 'gs_noCrystal && 4empty'. This will place one and only one crystal needing to be cut in the chest when the grindstone is empty. Because the item interface on the chest is channel 4, and the item exporter takes from channel 2, the crystal is moved from channel 2 to channel 4 of the system.

Make an 'item' variable from any celestial crystal.

On the first player simulator on the grindstone, have it 'click item' using the celestial crystal item variable. Channel 4, right-click true, and check NBT to false (otherwise the crystal needing to be cut must be identical to the crystal you made the item variable with). This will place a single crystal from chest 4 into the grindstone, but because the chest only has a crystal when the grindstone is empty, it will not continuously right-click the grindstone and potentially ruin the crystal in there. In effect, what is happening is that chest #4 is used to overcome the problem that we cannot put a boolean on the 'right click with item' aspect of the player simulator. The presence or not of a crystal in chest 4 serves as that boolean.

I have just been watching direwolf’s youtube video. I was not aware of the tiny chest. Using one of these would make this system simpler, as you do not need the 4empty mechanism to ensure that the chest only has one item in it. You still need the gs_noCrystal so that it only gets filled when the grindstone has no crystal in it.

On the second player simulator, make a variable ‘gs_hasCrystal && gs_notDone’ and put it in the ‘click empty’ aspect. This will turn the grindstone until the crystal is too small to grind anymore or the cut is 100.

On the third player simulator, make a variable ‘gs_hasCrystal && gs_done’ and place it in the ‘click empty’ aspect with sneak == true. Set the channel to 1. This will pick up completed (or incomplete cut too-small) crystals and put them back in the bin of crystals to be grown.

The end result is that whenever the grindstone is empty, a crystal is right-clicked into it from chest 2 via chest 4. This gets empty clicked until the crystal is either perfect or too small to grind anymore. At that point, the third player simulator sneak-clicks it back into inventory #1, from where it will make its way to the growing pool.

General notes

And that’s it.

I use a separate variable store for each of the three processes – they’re not that expensive, and it helps with keeping things organised. Labelling the variables is also indispensably helpful when using the programmer. Label the strings, too.

Playing New Horizons III, I find that ID occasionally jams. This tends to happen when I reload the game, and when I AFK away at my main base which is several chunks away (my AS setup is in a sparkly star zone). To fix this, my variable stores are connected to the rest of the system via an extra length of logic cable. I find that breaking and then replacing it un-jams things.

I sometimes find that the World Item Importer on the budding pool fails to import an item. This leaves two crystals in the pool, and astral sorcery will only grow crystals if there’s just one. To fix, pick up both crystals and chuck one back in the pool. The other you can just put in chest 1.

Growing crystals is slow, but this system means you can AFK and come back to three or four maxed-out celestial crystals. One of these will make 11 lenses. The waste crystals that you got from creating your initial 100% pure crystal can be thrown into the lightwells.

And you can add more pools for growing and budding by making a new variable store, making a new set of variables for the pool, and importing/exporting to the existing chests. I’m finding that neither growing nor budding is obviously the critical path – budding is slow because once the crystal gets to 900, it will still be a couple more cycles before the crystal buds; but growing is also slow because after the crystal is grown to 900, cutting will reduce its size and it will need more growing anyway.

In the image at the top of this post, crystals are moving from right to left through the system, because that’s how I wound up building it.

The display reading 799 shows the size of the crystal in the budding pool. It will hit 900 and stay there until the crystal splits, at which point one of the smaller crystals will be removed and one will remain to be grown up to 900 again.

The displays reading 824 and 100 are the size and cut of the crystal in the growing pool.

Not visible in the image are two more displays showing the size and cut of the crystal in the grindstone. These are normally 0, because grinding happens very fast and the grindstone is usually empty.

The displays are not necessary, but they are kinda cool. They are also helpful in that you can see if the system is jammed or not – when it becomes jammed, the displays read 0 even though there should always be a crystal in the budding pool.

If you don’t want to build the full system, I’d suggest that the grindstone displays make it so much easier to grind crystals. Player simulators are expensive, so doing the grinding manually is an option – just come back to the setup every now and again and grind the crystals in chest 2. The displays make it a simple matter to just right-click that grindstone until the numbers are improved, and then it’s back into chest 1.

Personally, I think AS should be nerfed with the rule that if you bud off a new crystal from a celestial crystal, the new, purer crystal should just be a regular one. But as it is, with this system you can have a chestful of maxed crystals AFK.