Add better ways to edit embedded iotas

[cc-aaron]

Bubbling is a great way to modularize your hexes into tinier components. it would be great if one could bubble a value quickly. Take for example a number that you want to implement directly into a hex.

current workflow:

1. you get an abacus and dial it in
2. you you manually push the number from abacus on to the stack, bubble it
3. you add it to a focus that is not used at the moment
4. you add it to the hex in the splicing table
5. you try it out
6. you dont like the number
7. rinse and repeat

workflow if splicing table would allow you to bubble selected iotas:

1. you get an abacus and dial it in
2. you add it to the hex in the splicing table
3. you try it out
4. you dont like the number
5. rinse and repeat

Currently each modification to a bubble is very tidous with needing to exit UI to bubble and unbubble anything.
I might get hate for it but I like to bubble hexes in if statments since they act like a "seperate step" reduce the left and right scroll spam to get back to the end of the hex.
It also makes it less likely to accidentally forget an intro or retrospection.

This has only 18 indexes and I can scroll pretty easily through
If I dont like a part I can just copy it to another focus and work on it until I replace it

This is what the hex actually looks like.
God imagine scrolling to the end of that every time you need to change something

If a bubbling button would be added I would not need to exit the UI to change a bubbled hex

[object-Object]

As a workaround, you could embed the iotas using intro/retro instead of using bubbles. It only adds 3 patterns per embedded iota, and then you can see the iota directly instead of having to manually unbubble it. (I did this in several places in hexxy32, works great with the splicing table.)

[object-Object]

I will say that I'm probably not going to add a dedicated "bubbling button" to the splicing table. It feels out of place to me, and if I add a distinct button specifically for one type of iota from a totally different addon (ie. not from base Hex), that opens the door for a lot of scope creep which I'm not willing to do. I'd probably also need to add a mandatory dependency on whatever mod adds bubbles, otherwise the UI would look weird if the mod wasn't installed.

That being said, I can think of a few ideas to make it easier off the top of my head:

• Add the ability to cut/copy/paste into iotas; for example, cut the contents of a list into the secondary focus, leaving an empty list behind, then paste some new iotas into that list. Then I could add an API for other mods to support this operation on their iota types.
• After Selection and view index should be saved server-side instead of just client-side so they don't reset on reopening the GUI #19 is implemented, add a pattern to get the start/end indices of the current selection for a splicing table, and also allow reading/writing the main item in a splicing table via IoticBlocks. Then players could, for example, implement their own tool to unbubble the selected iota and put its contents into a second splicing table for editing.

I think the second option sounds cleaner to me, but the first would be a bit easier for players to use out-of-the-box.

[cc-aaron]

I can see a bubbling iota button to be out of place.
Especially with the fact that the bubbling is a separate Addon (which I didn't know. sorry about that).

Maybe a lot of feature requests can be solved by adding a "programmable button" that you can program by shift right clicking on a splicing table with a focus (like you do to bind yourself to toolsmith impetus).

If you select iotas and press the button they get pushed to a stack, the hex executes and the returned iotas get put back into the splicing table

This would encourage having multiple splicing tables for different functionalities,
features for other addons can be implemented by having the caster do it themselves.
One could theoretically even make a compiler hex that compiles the macros in the hex to the actual hex.
I think this could be a fun challenge.

I greatly appreciate the splicing table. It truly is something that hexcasting lacked in my opinion

[object-Object]

Implemented in 015b142!