Conversation
|
Thanks for working on this! I'm a bit concerned about the fact that having multiple "inbound" portals causes the calculation to slow down. I wonder if there is a way to make this more efficient? Also, I wonder what will happen if one of the perimeter portals is marked as "inbound". The perimeter portals are typically where most of the outbound linking occurs, so I fear that marking a perimeter portal as "inbound" will crash the entire algorithm! |
|
I think the main reason of the increased calculation time is when you have two "inbound" portals that will optimally connect with each other. At least this is the case I observed. I've added the inbound flag to a portal that was a perimeter one, and it worked :) It might reduce the optimization related to minimizing walking around the plan, but from logical perspective (correct me if I'm wrong) it doesn't really matter if the perimeter portal has links incoming/ongoing. |
|
This is the plan that took forever to complete (I actually interrupted it after like 5 mins). Two perimeter portals flagged as inbound prevent the proper closing of the complete shape, therefore I think it will reach the limit of iterations and end with error |
|
Hi, any progress on this one? I know, I don't have as much time for personal projects as I'd like to ;) Also I have some more ideas for possible PRs, will there be any interest in them? |
Decided to test my idea from #33 , and it works as expected :)
PR adds support for
inboundflag, which sets the maximum outbound links for a portal to 0, effectively forcing the algorithm to create only inbound links from other portals.The plan supports only one inbound portal, otherwise the calculation takes forever to complete (if it completes at all).
The flag is exclusive with SBUL, raising the necessary error.