Open AJMansfield opened 6 months ago
So basically what you want is a --chain
option (I think "force" is too vague), which would force the cracker to search for solutions with a minimum of 1 item throw?
So basically what you want is a
--chain
option (I think "force" is too vague), which would force the cracker to search for solutions with a minimum of 1 item throw?
That's a much better name for it, I'd fully support calling it --chain
.
Conceptually though, this isn't actually about the number of throws, but the fact that the enchantment seed cracker won't try to set up a favorable future enchantment seed if it judges the current enchantment seed to already be favorable.
That current behavior is certainly a good, user-friendly default: optimistically checking if the current seed is already favorable makes low-level enchants much simpler to get (i.e. ones you just need the right bookshelf count for), and it prevents players from being misled by the prompts if they run the command a second time.
But when chaining, whatever the current seed is it's already reserved for a different item -- and the cracker just needs to skip that optimistic check and set up a favorable next seed regardless.
I've looking through the code a bit, and I suspect that the way to avoid this optimistic check would be to make a change here:
for (int i = Configs.enchCrackState == CrackState.CRACKED ? ManipulateResult.NO_DUMMY : 0;
Where for chaining enchants, that loop needs to always start from 0 regardless of the crack state, instead of sometimes starting from ManipulateResult.NO_DUMMY
(i.e. -1).
If I had build tooling set up to test it I would -- but I'm not familiar enough with this codebase to know how to implement the glue parts of the change (argument parsing and passing that information from the command handler to the enchantment cracker, etc).
I'd be happy to write documentation for the --chain
option if/when it's added, but I don't think I'm likely to have the time to figure out the other technical details to be able to submit a PR in any particularly near future.
When performing a large number of enchantments, it's useful to be able to use each manipulated enchantment as also the "dummy enchantment" that buffers another manipulated enchantment seed for the next enchantment after it.
In some cases though,
/cenchant
will "discover" that the currently-buffered enchantment seed already has the requested enchantments and won't manipulate the next seed after it. This makes it impossible to chain together enchanting two of the same item, and makes other cases like doing both a chestplate and leggings or both a diamond tool and the book needed to get Efficiency V, somewhat unpredictable and frustrating.To be clear: enchantment chaining does already usually work for dissimilar items, especially when enchanting items that have a much wider range of possible enchantments. And the exp savings are significant: it only takes 168 exp for each additional Level 30 item after the first when chained, instead of the 218 exp required if doing separate dummy enchants for each. Especially in the early game with slow farms like skeleton spawners, that 50 exp difference amounts to significant time savings.
What I want is some type of config toggle or parameter that will force
/cenchant
crack another player seed that'll buffer into an appropriate enchantment seed -- even if it already has an enchantment seed buffered that can do the requested enchantment.For context sake, here's a more explicit description of enchantment chaining technique, along with an explanation of the underlying theory for why it works in the working cases and why it doesn't in the non-working cases.
Here's a scenario where the command lets me chain enchants the way I want to be able to generally:
Here's a scenario where the command does not allow chaining enchants the way I want to, but would allow it if there were this sort of "force" config or parameter: