petrak@'s mods forum

This is part 2 of a series on Daemon Cores.
Part 1 (guide on constructing it): viewtopic.php?t=165

Aside from the regular 1-tick stack preserving Archdaemon, there more interesting ways to use your Daemon Core. I will add more to this post as I create more.

As a reminder, to add a new Archdaemon, we must simply integrate it into the list.

The order in that list determines the order in which they get evaluated. Each Archdaemon must end with a consideration.



1-Tick Stack Preserving

Summary
The classic.

Casts each Daemon in its list every tick and saves their stacks.


Daemon structure
Each Daemon must be stored in the following format:
[Stack iota 1, Stack iota 2, ..., [Hex, Consideration]]

As an example, here is a Daemon counter that reveals its value to the current impetus and increments it.


Anything before the hex itself is considered a part of its stack. In this case, I wished to give it a starter value of 0. Now, all I have to do is add it to the Daemon list for the 1-tick stack preserving Archdaemon, and it should run when I put the focus back in!


Creating the Archdaemon
Although this has already been covered in part 1, I will simply paste the method to create it here. As with most Archdaemons, you have to stare at the item frame in which you will place the focus containing its list of Daemons. Potential uses

• Greater sentinel summoner upon walking too far away from the old one (see above screenshot)
• Automatic Railgun whenever firing an arrow
• Re-cast Anchorite's Flight whenever moving too far from the anchor
• Permanent Zeniths, aura of Nadirs
• Item magnet
• Spam GTP innocent friends to the world border
• Any form of farm, effectively allowing you to create virtual spell circles (will likely cover this in a future Archdaemon)

Hex Delegate Archdaemon

Summary
This is less about casting Daemons and more about facilitating wireless communication with your Daemon Core. This Archdaemon contains a list of hexes, and a list of keys to access them. Those keys can be any iota, so long as it's the first iota in the list in your offhand focus/spellbook.
Think of an Akashic Library that checks your focus instead, and casts a hex from within your base.

The Hex Delegate Archdaemon requires you to only ever store lists in your foci and spellbooks. Use thought-knots for single iotas, as they are ignored.


Delegate structure
The list of delegates is stored as the following:
[[hexes], [keys]]]
As an example, below is a delegate list only containing a hex that mines a block if it finds one with a raycast. This will happen every tick the focus is held.

The key to this hex is the pattern on the right.

Hexes have no special requirements, and neither do keys.
Accessing these is done with the following structure in your focus:
[key, ...anything else]
An example focus holding a key could look like this:

or even like this:

The key just has to be the first iota. The key can also be any iota, which can be used for some shenanigans I will explain in a later section.

Creating the Archdaemon
Similarly to all other Archdaemons, this needs its own item frame. Potential uses

• Wireless control of your base (wireless redstone, hex activation)
• Toggleable hexes that cast every tick (sort of like genie lamps)
• Adding Daemons, queuing hexes.
• Triggering an unbound cleric impetus wirelessly to greater teleport you without item drops.
• Free Akashic Library equivalent.

Compound keys
Now, what if you don't wish to activate these each tick? As I said, keys can be ANY iota. That means they could even be 2 iotas! (In the form of a list). If you store an access pattern and an activation pattern in that list, then your hex delegate removes that activation pattern and saves to your focus, you could create a hex delegate that only triggers once, and then waits for you to save the activation pattern again.

As an example, here is a delegate that saves daemons.

You should be staring at the daemon list for the 1-tick Archdaemon. Now, the key I used is the following:

The first pattern is the identifier pattern - this is unique to this delegate.
The second pattern (the wide Hermes) is the activation pattern - I must save this to the key's list in order to actually save a daemon. This is shared between all hex delegates that implement this mechanism, so I don't have to remember it for every single one.

Here is a list of all my delegates - includes the mining delegate, save daemon, save delegate, enqueue:


I will post more Archdaemons in replies - I don't wish to cram everything into a single post.