Drag links when item is dragged

[Dorus]

There where some ideas from discord that i like to put up for discussion:

When you make a link, it's made at the level where the current item is at. When you then drag the (production) recipe to a shallower level the link becomes red because it's now not part of the link anymore.

Proposal to fix this by moving the link with the recipe when you drag it to a shallower level, and that level does not already contain a link.

Pro would be that link become less fiddly in the simple case where you have one link per recipes.
Con would be that having multiple links for the same item could be more difficult.

Also, i think it's better to not let the link drag work the other way around, since then you might accidentally lose top-level links. Thoughts?

[shpaass]

Thank you for the suggestion!

First and foremost, I think this proposal would benefit from a clear use case that shows the benefit of this change. I have many simple sheets and generally stay away from nested tables because of their interactions with the topmost level, so I need an example to understand the benefit of the change.

To understand the scope of the change, one needs to know how an item, for instance linked/unlinked glass, on the topmost level interacts with linked/unlinked glass in nested tables. From what I remember, the logic behind it makes sense, but it is not trivial. If this feature gets a go-ahead, a developer needs to make sure that the logic remains the same.

i think it's better to not let the link drag work the other way around

The goal of the UI is to be intuitive. I think it is not intuitive for such functionality to work one-way.
I think something like below would be more intuitive:

• If dragged when linked, it links when dropped.
• If dragged when not linked, it links when dropped if there is a link about it on that level. It also links if it's on the top level and it's a desired product.
• If dragged when not linked, it doesn't link when dropped if there's no link about it on that level.
• The donor link does not get deleted if there are things left to link.

My general understanding is that the link-drag is almost certain to introduce bugs unless thoroughly tested.
If the implementer of this feature is willing to describe tests and go though them, then I'm not against this feature in general.

[Dorus]

The use case is the typical situation where you have an item linked in a sub-table, and then drag that item out.

This was posted on discord notice how the relesia seeds go red when the production recipe is dragged out of the nested table:

Before

After:

Now you have to manually link the relesia seeds again at the lower level, but also unlink them at the higher level to fix it.

My proposal is, that after the above drag, the link for relesia seeds is also moved to the higher level where the production recipe is moved to.

[shpaass]

after the above drag, the link for relesia seeds is also moved to the lower level where the production recipe is moved to.

In the demonstrated case, you want to unlink the recipe in the nested table.
However, in a hypothetical with another source of ralesia-seeds still in the nested table, I think you'd want to keep the link.
That's another piece of logic to keep in mind for this feature.

[Dorus]

First let me establish some terminology, mostly for myself as i notice i'm confusing myself here.

Topmost level is the highest level, main level. I also call this the shallowest level.
Nested tables are lower, or deeper levels.

To answer your list:
When dragging any recipe that contains no link: Nothing happens with links
When dragging any recipe that contains a link:

1. If dragged within the current level, or onto a higher/lower level but both are within reach of the current link, nothing happens.
2. If dragged to a deeper level that contains a different link, the dragged recipe is linked to the new link. This could result in the old link containing no items, if so it gets deleted.
3. If dragged to a higher level that contains a different link,, the dragged recipe is linked to the new link. This could result in the old link containing no items, if so it gets deleted.
4. If dragged to a higher level that contains no link, nothing happens.

Proposal: For situation 4: If dragged to a higher level that contains no link, move/change/remove+add the deeper link to the new shallower level.

[Dorus]

Also notice the following:
A desired product is always linked a the highest level.
Any other link can have any level. When created it will have the same level as the item that you clicked on, so it will have the level of the highest linked item. However you could move that and all other items at that link level into a deeper level and all items would still be linked, but they would be marked brown instead of blue and the link would now be at a higher level than the highest linked item.
A link with no linked items is automatically removed.

---

My reasoning for not changing the link level when all items are moved to a deeper level, is that you can still move it yourself with a single click by creating a new link at that deeper level, but, you will not get unlinked items when you create a new recipe chain -> move it to a deeper level -> create another recipe at a higher level that needs ingredients already created in the previously moved chain. This is something you'll often do, and rarely will you want to introduce a new link for that sub item.

However, the above does create a more confusing model for linked items. Links are already confusing because they're not displayed in the UI very clear. Especially multiple links of the same item with overlapping levels can be confusing. Secretly moving those links might add more confusion.

[shpaass]

Here's what I think about it overall:

This feature can make the respective part of the code much harder to understand.
My primary concern is to prevent that.
We still have two summary pages, and I have no time to address even that, so I don't want to add more stuff to fix later.

Therefore, I expect the potential PR for this feature to cover the points below.

• The explanation of how the links currently work. Especially the rarely-used parts like brown links. This way, the reviewers would be on the same page about the current state.
• The explanation of what the PR brings, and by that I mean every change in the link interaction. Moving a linked recipe several tables deep, moving brown links, and other things players usually don't do.
• Descriptive method names and variable names.
• Understandable code. No hacks or cut corners.
• Comprehensive documentation.
• A list of what scenarios you tested, so we can check if there are more angles to test.

I don't want our codebase to become unapproachable, so I hope these points could help it to stay at least as approachable as it was before.

[veger]

From want I just read I feel that the link system is 'just' unclear to the users... For me it is clear and it works are I expected. It is pretty technical, but when you understand it is easy enough to use as implemented.

1. each level keeps its own links
2. moving linked items links them to the level they are moved to
3. deeper levels links to shallower level(s)
   (I am not 100% certain to goes to multiple levels/depths but I think it does).

(I think these are all rules for links, at least needed to explain what is going on)

With these foundational set of rules you know what to expect from the links

• blue links all is fine (2 or more linked items on the level which are balanced to 0)
• purple links all is fine, but it has a allowed 'unbalance'
• brown links all is fine, but not linked on the current level but part of the link of the parent level (auto linked)
• red links error:
  • constraints that cannot be solved by the solver
  • only one items linked (basically it could not be solved as well)
  • some other errors? would need to check the code

So yes, moving linked items (often) result in red links, as usually there are no other items to solve/balance it with. Which is IMO a nice feature as it indicates that something is broken and needs fixing. So I see the red color as a guide for me to take care of, usually by relinking so it ties to the lower levels (again), but some other times to add more of the item that level to be able to let it balance again.

I think we talked about adding some legend/popup explaining the colors, but it was not implemented. But I could be wrong.

A simple automated solution would be, remove the link from the item when it moved to any different level. But I doubt this is needed if you know how the linking system works and you let yourself be guided by the colors (and don't see red links as too 'negative' instead)

To summarize, for me the linking system is just fine, but like @shpaass if there is some consistent way of changing it, it would be fine to me.

[DaleStan]

Other than possibly adding of one or more "Delete matching links in all nested tables" buttons (and possibly doing that automatically under certain circumstances), I'm also in favor of leaving the link behavior as-is. Making links move with recipes seems like more trouble than it's worth.

The current behavior is very simple, if not always what the users are expecting: Links never move.

one needs to know how an item, for instance linked/unlinked glass, on the topmost level interacts with linked/unlinked glass in nested tables. From what I remember, the logic behind it makes sense, but it is not trivial.

I'm having trouble making a concise description, but I think Dorus only wants to make links move (or maybe copy?), not change how tables, recipes, and links interact.

A desired product is always linked a the highest level.

This is not actually true. You can add desired products at any level, using the "Add nested desired product" button:

Which raises another test case: If you drag a recipe 'attached' to a desired product link up to a parent table that has a matching link without a desired product, what happens? Also, if both source and destination tables have links, but one has "Allow overproduction" and the other doesn't, what happens? (Nothing is an OK answer, as long as we consciously make that choice.)

When dragging any recipe that contains a link:
...

There are several more cases here: If the recipe is dragged ...

5. to an unrelated¹ table, and the destination table is affected by² a matching link: (Based on 1-3, presumably nothing happens, regardless of which table owns the destination link?)
6. to an unrelated table, the destination table isn't affected by a matching link, and the source link belongs to the source table: (Link is moved? Link is copied? Nothing?)
7. to an unrelated table, the destination table isn't affected by a matching link, and the source link belongs to an non-shared ancestor of the source table: (Link is moved to the destination? Link is moved to the last (most-nested) shared ancestor? Link is copied? Nothing?)
8. to a grandparent (or higher) table that isn't affected by a matching link, and one of the intermediate tables owns the source link: (Based on 4, the link is probably moved to the grandparent?)
9. to a grandparent (or higher) table that isn't affected by a matching link, and one or more intermediate table(s) owns matching link(s) that is/are not the source link: (Merge all the links and move the merged link to the grandparent? Move the source link to the grandparent, promoting it across the intermediate link(s)? Panic and do nothing?)

If links are copied, do they also copy the requested amount, or does that stay with the original link? Does the "Allow overproduction" flag get copied?

While "the users are using it wrong" is almost never right, I think there's just too much here to automatically move links.

Footnotes

1. Unrelated here means any two tables such that neither contains the other. Sibling, cousin, and aunt/niece relationships all qualify as "unrelated" in this context. ↩

2. A table is affected by all links that it contains, plus most links any of its ancestors contain. When traveling from a table to the root, only the first link for a particular Goods will affect the starting table. A table is never affected by links contained by unrelated or descendant (child, grandchild, etc.) tables ↩