Allow custom weights for paths?

[Smashman]

Perhaps we could have a system allowing for custom weights, rather than just 0 and 100.

Or perhaps we could make it so the weight for more common aspects is higher, which would make it automatically use rarer and higher tier aspects less often?

[chrisbecke]

Better weighting:

1. Process all the basic vanilla items to compute the total aspects that can be gotten from scanning blocks and items. This is a convenient natural weighting that assumes all aspects are obtained from scanning the world. It doesn't really account for mods...
2. Compute the "cost" of every aspect as the # of base aspects that must be combined to produce it. Each aspect could then be given a weight that is w=T-c+1. Where T is the largest computed cost, and c is the computed cost of the aspect being considered. This gives instrumentum a cost of 11 base aspects that must be combined, so the base aspects would have a weight of about 16 (assuming that 15 is the largest cost found) and instrumentum would then have a weight of 5.
   This assumes the majority of aspects come from deconstruction (and that deconstruction is on an item that favors each aspect equally).

[ythri]

I don't think the first approach would work well, firstly because it doesn't account for mod items, scanning of nodes (from which you get a whole lot of basic research aspects), the deconstruction table or the bonuses given by shards and book cases near the research table (which I used surprisingly often). Also, it would be alot of work. Finally, you would also need to consider, how often these aspects are really used for fixed price researchs (aka easy mode) - if an aspect is fairly common, but used in large quantities in fixed price research it might still be better to use different aspects for the research game when you have the choice.

The second approach seems quite good though: Give each aspect the weight of the number of base aspects used (I guess a small modification would be needed, lets say taking the square root, otherwise it would rather take 10 base aspects instead of once instrumentum, which seems rather extreme). Also note, that the weights are the other way round: Higher weights mean that the aspect should be avoided, lower weights mean they are preferred (so the weight is actually more like a "cost").

However, even this approach does not account for what the user actually has. If he does have tons of instrumentum, why should the tool give him longer chains of base aspects instead of a shorter chain that uses the instrumentum aspect with its high weight? Sure, it highly unlikely that one has too much instrumentum (stupid research, using instrumentum just about everywhere), however, the same holds for metallum, which is composed of 4 base aspects I believe, and is incredibly abundant, or different aspects that can be different for every person.

My original plan was to somehow use weights, thats why the algorithm was coded to support them natively. However, letting the user to give weights for every aspect is of course not going to work. Nobody wants to put in a value for each aspect individually before being able to search for connections. Thats why I settled with uniform weights for now, my idea was to use the tool incrementely. Ask for a connection, and if it contains aspects that you are currently low on, you can simply deactivate them and search again for slightly longer, but possible better aspect chains. This is extremely simple.

So, before introducing custom weights, I would want to discuss two questions: Are they really going to improve the tool? Or are they introducing new problems and make it more difficult for users that have non-standard aspect distributions? And second (what you are already discussing): How to implement the custom weights as good as possible. My current idea would be to have a small text field next to each aspect to show (and also individually edit) the current weights, but also have two (or more) buttons to set common weight distributions: uniform weights (i.e., weight 1 to every aspect, as it is handled now), weights based on rarity, number of base aspects or whatever. That gives everyone the choice to use the system he likes, but also makes the interface less intuitive.

Well, I'm interested in hearing your opinions.

[chrisbecke]

I don't know how your weights work. The usual way I have been exposed to weight based choices is bigger is better. Which means a weight of 0 means never.

What happens at the moment if we click on an aspect is it gets toggled on and off. If there was a "weight increment" dropdown, that could be set to, say, "100" (by default) then each click would increment the weight of the clicked item by 100, and as you would modulus 100 any value >100, on the 2nd click the value 200, would wrap back to zero, causing the weight to cycle between 0 and 100 (one of which would mean never). Choosing a different value as the increment would let us with a few clicks, 'dial in' a relative weighting quite quickly - which could be displayed as a numeric overlay.

This skips the text box and general clutter, but makes it a bit harder to set up exact weights.

Actually, as soon as the page is refreshed, all the weights are going to be lost. Is there any way to make the page read a user provided wighting file? Then the weighting UI is simply: choose from one of these templates, or choose "custom...", which would choose a txt file with the users weights in it. That makes the weights easy to reset up when the page is reloaded.

[chrisbecke]

One could also borrow an idea from the competition and display more than one result:

http://tc.yunoplay.net/

Or make it so that clicking on an aspect in a result list, generates an alternate list without that specific aspect. That way one doesnt have to spend time setting up weights. One can simply say, nah, try again without that.

[chrisbecke]

Costs (and hence weightings) are computed as a function of supply, and demand.

supply = (qty available from scanning blocks and items) + (weighted probability of finding them on nodes) + (weighted relative ease of making them via combinations from points aquired via deconstruction)

demand = (qty required for purchased research) + (how many research A to B paths the aspect occurs on)/(the number of alternatives at that point).

[chrisbecke]

I computed the deconstruction table costs of each aspect in base TC. Making 1 point of Meto costs 24 primal essentia points!

Aspect Sum Component Component Aer Aqua Ignis Ordo Perdito Terra
Meto 24 Messis Instrumentum 2 7 0 3 2 10
Fabrico 21 Humanus Instrumentum 2 6 0 3 2 8
Pannus 15 Instrumentum Bestia 2 4 0 3 1 5
Lucrum 14 Humanus Fames 2 4 0 1 2 5
Machina 13 Motus Instrumentum 2 3 0 3 1 4
Messis 13 Herba Humanus 1 4 0 1 1 6
Telum 12 Instrumentum Perdito 1 3 0 2 2 4
Tutamen 12 Instrumentum Terra 1 3 0 2 1 5
Instrumentum 11 Humanus Ordo 1 3 0 2 1 4
Perfodio 11 Humanus Terra 1 3 0 1 1 5
Humanus 10 Bestia Cognito 1 3 0 1 1 4
Corpus 7 Mortuus Bestia 1 2 0 1 1 2
Alienis 5 Vacuous Tenebrae 3 0 0 0 2 0
Cognito 6 Terra Spiritus 0 2 0 0 1 3
Sensus 6 Aer Spiritus 1 2 0 0 1 2
Auram 5 Praecantatio Aer 2 0 1 1 1 0
Examinis 5 Motus Mortuus 1 1 0 1 1 1
Spiritus 5 Victus Mortuus 0 2 0 0 1 2
Arbor 4 Aer Herba 1 1 0 0 0 2
Bestia 4 Motus Victus 1 1 0 1 0 1
Fames 4 Victus Vacuous 1 1 0 0 1 1
Praecantatio 4 Vacuous Potentia 1 0 1 1 1 0
Tenebrae 4 Vacuous Lux 2 0 1 0 1 0
Herba 3 Victus Terra 0 1 0 0 0 2
Iter 3 Motus Terra 1 0 0 1 0 1
Limus 3 Victus Aqua 0 2 0 0 0 1
Metallum 3 Terra Vitreus 0 0 0 1 0 2
Mortuus 3 Victus Perdito 0 1 0 0 1 1
Sano 3 Victus Ordo 0 1 0 1 0 1
Viniculum 3 Motus Perdito 1 0 0 1 1 0
Volatus 3 Aer Motus 2 0 0 1 0 0
Gelum 2 Ignis Perdito 0 0 1 0 1 0
Lux 2 Aer Ignis 1 0 1 0 0 0
Motus 2 Aer Ordo 1 0 0 1 0 0
Permutatio 2 Perdito Ordo 0 0 0 1 1 0
Potentia 2 Ordo Ignis 0 0 1 1 0 0
Vacuous 2 Aer Perdito 1 0 0 0 1 0
Venemun 2 Aqua Perdito 0 1 0 0 1 0
Victus 2 Aqua Terra 0 1 0 0 0 1
Vitreus 2 Terra Ordo 0 0 0 1 0 1
Aer 0 0 0 0 0 0 0
Aqua 0 0 0 0 0 0 0
Ignis 0 0 0 0 0 0 0
Ordo 0 0 0 0 0 0 0
Perdito 0 0 0 0 0 0 0
Terra 0 0 0 0 0 0 0

[MentalMouse]

The thing is, weights are only relevant if you have a choice which way to go, which is nearly a minority situation. The simplest tactic I've found to force a path through certain aspects is to pick one step myself at either end, then ask for the new shorter path between the new endpoints

While it's not quite weights, one thing that would be mildly helpful, would be for the tool to mark (perhaps with an asterisk) spaces where you're going from one aspect back to the same. For example, Aer * Aer, where the asterisk can be any aspect containing Aer -- the algorithm can still pick one, but would also mark it just to highlight that this Tempestas could just as easily be Arbor, Vacuos, Motus, etc.

[metarmask]

Actually, as soon as the page is refreshed, all the weights are going to be lost. Is there any way to make the page read a user provided wighting file?

Even easier would be to use "local storage" which is already built into your browser. 😄

[mickdekkers]

@MentalMouse I strongly agree with your second point, the aer * aer thing would be very helpful.

@metarmask use of localStorage does seem like a good idea, but it would still be good to have a way to export / import any settings.

[AnrDaemon]

The presumption that basic ("vanilla") aspects are always available is just not true, and it greatly diminishing the utility of your tool. I was constantly running out of a single primal aspect, and I had to manually draw solutions on paper, because Helper always tried to route everything though it, even multiple times in a single solution.

[chrisbecke]

The presumption should be that the Deconstruction table is going to be the principal source of new aspects. Especially with TC addons, typically a lot more research is added than research points on items.
As such, the obvious weighting is, really, just the cost of producing the aspect. Ignis would have a weighting of 1, vs Instrumentum, which would have a weighting of ~24 (being the number of primal research points needed to be combined to make 1 point of instrumentum).

[AnrDaemon]

Deconstruction table is the WORST possible solution. It is extremely boring and frustrating.
I had to use automatic clicker just to save my monitor from a flight to the floor.

[chrisbecke]

AutoIT for the win. Theres a different solution?

[AnrDaemon]

Yes. Allow splitting aspects in research interface and recover one of its parent aspects with certain probability.
When you have 100+ of given compound aspect you can't use for anything, it quickly grows frustrating.

[chrisbecke]

Well yes. But thats a feature request for TC. The point is to make this tool as useful as possible given the current (imo broken) state of TC's research point generation.