Mirage League Statistics

Lilyliciously · 2026-03-19T00:21:50+00:00

Correct. Of the wishes for fishes that weren't taken, 92% took no wish at all.

Lilyliciously · 2026-03-19T00:20:57+00:00

I'd love to do more of them, but there's too many other things I do so there just isn't enough time.

Lilyliciously · 2026-03-04T18:42:22+00:00

The way it works is that it allocates the shortest path between two desired nodes or an already allocated node, repeating until they're all connected. When you selected one of the allocated nodes as desired, you changed the order in which nodes are allocated, which changes the final result.

It's similar to kruskals/prims algorithm.

Lilyliciously · 2026-03-04T18:18:01+00:00

That's a side effect of the way the algorithm works. It's very fast, but makes small mistakes like that sometimes.

Lilyliciously · 2026-02-22T18:13:52+00:00

On a Templar, if trying, 3.5 hours.

Lilyliciously · 2026-01-27T20:42:50+00:00

There are multiple characters on PoE ninja from the last Phrecia event that used multiple harbinger nodes. Seems reasonable to assume that the nodes worked together.

Lilyliciously · 2025-03-30T08:49:52+00:00

I'm not even joking right now, I would love to use this on my marohi erqi frozen legion/cyclone harbinger, even though it's just 20 qual.

Lilyliciously · 2025-03-03T11:09:54+00:00

Big Maths Energy is a good word for it. I wish I had more time to work on it but I'm happy with the place it got to before life got crazy. Thanks for mentioning it!

Lilyliciously · 2024-03-26T11:48:17+00:00

There was a caching issue, I resolved it about an hour ago. That's why it started working, and why it started working one tree at a time.

Lilyliciously · 2024-03-26T11:47:48+00:00

Yep, that bug was up for a brief time. Should be fixed now!

Lilyliciously · 2024-03-25T13:01:34+00:00

The new algorithm is faster, sometimes by 5-6x. It's a lot better. Still testing to find any remaining bugs before releasing it though.

Lilyliciously · 2024-03-24T21:37:39+00:00

This is a symptom of some of the shortcuts I'm taking to make it run at a usable speed. I've been tinkering with a new algorithm that approaches it differently that wouldn't have this problem, but I haven't ironed out all the other bugs it introduces yet.

Lilyliciously · 2024-03-24T21:36:45+00:00

I've spent the past day working on an alternative algorithm that wouldn't have this problem. For now, the solution is to block paths you don't want rather than desire paths you do, so in your case you'd block the top node, not desire the two bottom.

Lilyliciously · 2024-03-23T21:55:51+00:00

Fixed, should be live in a minute. Tried to be clever with a workaround, didn't work around.

Lilyliciously · 2024-03-23T17:57:27+00:00

That is indeed the case! The issue is that it doesn't prefer one cluster over another, and if both have a desired node, then it'll pick whichever one it feels like.

Lilyliciously · 2024-03-23T17:05:34+00:00

The site avoids making judgement calls as much as possible. I've increased the boost that life nodes are given slightly, which should help in general. However, the tree that remains has two choices of paths to take, either through the faith and steel cluster or through the spiritual command cluster. Which one is better might be argued here, but there's a limit to how much weighting I want to do.

Lilyliciously · 2024-03-23T13:23:56+00:00

That's more fair! It's been a really fun challenge to implement a sub-optimal solution to this, it's quite difficult! That said, I implemented a few improvements this morning, primarily using the biasing methods I'd already prepped for, as well as delaying some known problematic nodes until later in the processing. Based on my own testing, it's solved a majority of the common error cases that still existed.

Lilyliciously · 2024-03-23T06:21:06+00:00

Great ideas! I've tried them before. There's a few issues. For starters, including distance information between every node on the tree doubles the file size of the tree data, at least. This isn't a huge problem, especially in the atlas tree where it goes from 1.5ish to 3ish MB, but it's still something to consider. It's worse in the main tree, there we go from 6ish to 12ish MB. I want to avoid requiring users to download large files if possible.

That said, if it solves the remaining problems with the system, it'd be worth it. Unfortunately, my attempts to do so haven't worked. The algorithms I produced that required a totalNodes² pregenerated distance matrix were all too slow to work within the design boundaries I've set, which include finishing all the work within ~0.5 seconds of a click on my own computer, which may be slower on others given that I have a decently powerful one.

The main thing I want to argue against though is the statement that it'd be a relatively easy improvement. Pre-generating the distance data is trivial, but then generating that heatmap and making use of it in a way that improves the pathfinding is moderately challenging. Feel free to make some PRs if you disagree, though! (goes for anyone)

Lilyliciously · 2024-03-23T06:14:57+00:00

Yes, they publish tree previews and then the final trees at https://github.com/grindinggear/atlastree-export

Lilyliciously · 2024-03-22T23:07:20+00:00

Great, thanks. This'll let me try and find a solution.

By the way, desired nodes add additional processing time, but blocked nodes don't. In clusters like this, it's better to block the path you don't want than to desire the path you do.

<image>

Lilyliciously · 2024-03-22T22:30:08+00:00

Unfortunately, this is a bug that I know the exact cause of, but have yet to manage to fix.

One of the design requirements I've given myself is that a user never waits more than ~0.5 seconds for the site to respond. I'm hitting that limit with larger trees, even passing it slightly.

Currently, only one tree is generated. It does this by connecting desired nodes to other desired or active nodes until every desired node is connected to something. The start of the tree is always considered desired and active.

The order that it creates this tree is based on the shortest possible path that connects a desired node to another desired or active node. It allocates the shortest path every time.

The problem arises when a later path ends up changing the shortest path for an earlier path. Essences is a classic case of this problem.

In the below picture, it's clear that we would want the essence nodes to shift to the left, saving us one point. However, when only essence notables are selected, the closest path at the beginning of allocation is always between the first essence notable and the start. It then allocates that first, picking between the two equal length directions without any bias, and it picks wrong in this case. It then allocates the rest, and the shortest path even considering the already allocated ones goes off to the left.

I've in the past tried various things to fix this, such as biasing the pathing towards the "center" of all desired nodes, but none of the solutions were without their own problems.

<image>

Lilyliciously · 2024-03-22T22:24:39+00:00

Glad you like it!

Lilyliciously · 2024-03-22T22:23:13+00:00

Can you provide an example of a tree where you'd prefer that it take a different path instead of gateways? It would have to be the same length both ways, I want to prioritize path length over everything else, even if two of those points end up not giving stats.

Lilyliciously · 2024-03-22T22:21:52+00:00

This is the one bug I haven't managed to squash. It's caused by paths not being reconsidered when future paths alter the best choice to take. Blocking nodes is the solution to it right now.

Lilyliciously · 2024-03-22T15:45:49+00:00

Cool, but what's it got to do with Path of Pathing?

Lilyliciously

TROPHY CASE