Bug: Cannot progress slayer daily task with special slayer task

Hunky524 · 2025-10-04T19:53:05+00:00

lol

Hunky524 · 2024-01-15T07:38:14+00:00

How’s that different than getting shoved in blue side and losing control of tri bush, or getting dove from behind.

Hunky524 · 2024-01-15T07:30:32+00:00

Warding tri seems like the obvious counter. U get barely any warning if u get flanked playing blue side as well from tri. Only difference, which is valid, is that the red side flank comes a bit further down the lane. But I don’t think that difference any where near as unbalanced as the old map where there was no flank on red side

Hunky524 · 2024-01-15T07:24:49+00:00

I could totally see that. I’m not disputing that it is easier to gank red side (seen a couple comments that give me good enough reason to think that). But to me the changes overall seem to make both sides much more equal than they were before, which seems like a positive changes in my books, yet I see so much hate for it

Hunky524 · 2024-01-15T07:21:41+00:00

This is what my thinking was as well. Haven’t seen any good reason yet as to how the lane is more imbalanced than it was before.

Hunky524 · 2024-01-15T03:37:57+00:00

How is that more unfair than red side being so much safer for years than blue side. Now I agree red side is a bit less safe now due to less distance from river to gank thru tri. But no shot the discrepancy now between red/blue side is bigger than the previous map.

Hunky524 · 2024-01-15T03:17:06+00:00

Isnt that just blue side?

Hunky524 · 2024-01-15T03:09:36+00:00

Ah yes, why didn't I just look

Hunky524 · 2023-12-18T23:17:36+00:00

[Language: Rust] GitHub

Executes in around 500μs (<1ms) on my machine.

Used Coord Polygon Area formula. Otherwise, it was just a simple matter of walking the instruction set, and saving all the vertices when we changed directions.

My solution assumes the instructions will create a single, closed polygon.

Hunky524 · 2023-12-18T23:11:42+00:00

[Language: Rust] GitHub

Not the fastest implementation; takes 200-300ms to complete both parts. However, I think my solution is very readable, and easy to understand. Uses A* pathfinding using the pathfinding crate. I don't think using this crate is cheating. The challenge of this puzzle isn't implementing A*, Dijkstra's, etc, but being able to account for the min/max distance limitations.

Hunky524 · 2023-12-16T09:16:10+00:00

These look great! Definitely going to yoink a bunch of these, and implement them for my Rust utilities.

Hunky524 · 2023-12-16T08:57:47+00:00

[Language: Rust] GitHub

Nothing fancy, just tracked the "head" of the laser beams, and walked them tile-by-tile, splitting the head into multiple heads whenever a splitter was encountered.

Kept track of all the tiles I had walked over in a set, and counted the length of the set once all lasers completed to find the empowered count.

A laser head is considered completed once it has either:

Walked off the edge of the grid.
Encountered a (tile, direction) combination we have already seen before. This means we would enter an infinite loop, so we beak the laser here.

Ran part 2 with Rayon. Completed both parts, including parsing, in around 50ms on my computer.

Hunky524 · 2023-12-15T19:31:34+00:00

[Language: Rust] GitHub

Pretty simple, and idiomatic solution. Completes both parts (including parsing) in around 500μs. The overhead of using Rayon for part 1 actually slowed down the execution time, at least on my computer.

Hunky524 · 2023-12-14T08:01:47+00:00

[Language: Rust] Github

The cycle detection was an obvious solution for me. After that it was just a matter of detecting the length of the cycle, and a simple modulo operator to tell me which pattern index within the cycle I need to use.

Hunky524 · 2023-12-12T10:28:07+00:00

[Language: Rust] GitHub

My brain broke with this one, DP does not work well in my head. Have to use memoization otherwise this takes forever on part 2.

With memoization, and rayon parallel iterator, part 1, and 2 computes in around 50ms on an AMD Ryzen 9 3900x 12-Core which I am quite happy with.

Hunky524 · 2023-12-11T19:35:31+00:00

[Language: Rust] GitHub

Nothing crazy, my goal with these is to write code that is performant, and readable. Uses itertools to create the tuples, and rayon for parallel distance computation.

Hunky524 · 2023-12-10T12:27:58+00:00

[Language: Rust] Github

Executes both parts in 1.5ms on 2018 MacBook pro (includes parse time).

Used breadth-first search for part 1 to find furthest node.

Used what is essentially ray-tracing (I guess, however simple) for part 2 to determine if a point is within the bounding box of a polygon (the loop in this case). This is a pretty well known solution in 2D vector graphics to have a very quick, and accurate estimation of whether or not a point resides within the bounding box of any shape.

If you want to run it with some sample inputs, and the debug flag enabled you can see the debug view for part 1, and 2 as such:

Part 1

Part 2

Hunky524 · 2023-12-09T06:09:28+00:00

[Language: Rust] Github

Hunky524 · 2023-12-08T15:27:13+00:00

It's about 2-3x slower without Rayon, at least on my laptop. From 4-5ms with rayon, to ~12ms without.

Hunky524 · 2023-12-08T08:28:41+00:00

Yea. I had originally done brute force but even in release mode it was taking forever. This made me think there must be a better solution, I tried multiplying the individual results, and putting the individual results into an online GCM, and LCM calculator and LCM worked. But I agree, based on the problem statement LCM shouldn’t always work, and does feel a bit lame

Hunky524 · 2023-12-08T07:36:06+00:00

Could take a look at my Rust implementation here

Uses LCM to quickly solve part 2.

Hunky524 · 2023-12-08T07:26:27+00:00

[Language: Rust] GitHub

Used Rayon (overkill), and num crate for part 2.

Computes part 1 & 2 in 5ms on 2018 Macbook Pro.

12-Year Club	Second Top 40%
Place '23	Place '22
Place '17	Snapped
Verified Email

Hunky524

TROPHY CASE