This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
Challenge 1 math helped with narrowing the X range to where X velocity reached 0 within the target range. Challenge 2 just went with a brute force using generated rows. Ended up generating ~2bil rows (65GB of data) and letting it run for 30 min. An iterative macro probably would have been the smarter choice. Could have just counted every time there was a match instead of storing all that memory.
I manually tinkered with the starting velocity ranges in the Generate Rows tools. I was surprised by some of the options that worked.
Since the latest valid velocities came from iterations 250 ish, I made the assumption (validly, for my puzzle input) that those still running after 1000 iterations would not make it into the target. These rows were probably still iterating because I set my possible y velocities too high.
Graphing the target helped me estimate the best starting velocitiesWorkflowIterative macro
Part 1 can be done use the knowledge for projectile motion, mins y for me is -248, so the downward max velocity should be -247 at returning to y = 0. Then just a arithmetic sum to go up to find max height.
Part 2 is brute force to run through all combination. Inner macro calculates the trajectory for a given starting velocity up to boundary condition. Then outer macro filter the ones reaches the target. ~ 8mins runtime.
I used generate rows, for positive y velocities I was able to easily extend the input from part 1, as only x velocities in the range 11 : 14 were possible, then for the negative y velocities knew you could get direct hits with the the velocities matching the x,y position, so it was a case of working back from there and finding the valid rectangles that worked. I was able to work out that there wasn't going to be anything in a particular range so was able to narrow down significantly the number of velocities to try. I could have worked out what would be valid but it was quicker just to leave the workflow running on the reduced set. Converting the velocities to x,y spatial points and you get a nice plot of all the possible valid points after 1 iteration.
In terms of the mechanics, a batch macro to pass each velocity in one by one.
And an iterative macro for calculating the points
Chris Check out my collaboration with fellow ACE Joshua Burkhow at AlterTricks.com
Took quite some time with pen and paper to understand the going up and down (and finding the n(n+1)/2 sequence again). The iterative could be replaced with a generate rows, but didn't think it's worth it as it takes just 2 sec to run. The limits for the rows -- X: initial velocity must be at least 1 --otherwise the probe just drops--**, and at most Xmax; Y: initial velocity must be at least ymin (and it reaches to the bottom of the target area in 1 step) or at most -ymin (and it goes up, up, up, down, down, down, and reaches the bottom of the target area one turn after going through y=0) **could be better narrowed down based on the minimum speed needed to reach Xmin and stop there, but it just adds a few rows.
Then just update every iteration the velocity and position, discard anything that is outside of viable trajectories (e.g. too far away already), output anything inside the target area and keep running the rest
Mine is not efficient in any way, but I got to the answers (and solved parts 1 and 2 with the same workflow). If I have the energy, I'd like to make it run in under 5 minutes, but I've got too many rows generating at the moment.