You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This gets you the best of both worlds, with regards to path safety and optimality (i.e. having load boundary cutoff on for most of the time), but still preventing oscillation (between the best loaded point, and the cache-edge of the workaround path) if a backtrack beyond the load boundary is required (which happens ALL THE TIME in 2b2t spawn lol), because a backtrack DISABLES load boundary cutoff! And yet we still have all the safeguards (cost verification lookahead, maximum cost increase limits, etc) to make that one-time cached path safe. I think cutoffAtLoadBoundary should default to false, but if you turn it on, there should be a second option, defaulting to true, that overrides that cutoff to false if the best path involved any backtracking.
The text was updated successfully, but these errors were encountered:
This gets you the best of both worlds, with regards to path safety and optimality (i.e. having load boundary cutoff on for most of the time), but still preventing oscillation (between the best loaded point, and the cache-edge of the workaround path) if a backtrack beyond the load boundary is required (which happens ALL THE TIME in 2b2t spawn lol), because a backtrack DISABLES load boundary cutoff! And yet we still have all the safeguards (cost verification lookahead, maximum cost increase limits, etc) to make that one-time cached path safe. I think cutoffAtLoadBoundary should default to false, but if you turn it on, there should be a second option, defaulting to true, that overrides that cutoff to false if the best path involved any backtracking.
The text was updated successfully, but these errors were encountered: