-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sanctum room planner #438
Comments
Thanks for your suggestion. This was also suggested during Sanctum League itself. Back then, I wasn't really confident that I could get it working consistently, but I guess I could look into it and actually play around with it this time. But that'll have to wait until dust settles a bit: I'm still waiting for concrete recombination information to update my simulator, and I want to play more of the league of course. |
I did a bit of playing around and ended with this algorithm, which only uses the paths: I use DBSCAN to cluster the pixels for the paths and intersections of regressions over the path. The trick is to dilate the paths such that I can de-noise since only highly connected clusters can be paths. The least squares term in the regression ensures that it should follow the trend of the path very well. This collection of constants is what I am using currently: I end up with this as the output: 8 rooms and 3 on non-start floor. |
That looks crazy, nice job. I was going to try something different:
I didn't have time to actually test step 2, but it sounds doable in theory (to me at least). If I have some time, I'll do the testing tomorrow. |
I actually got it to work. It spits out a JSON-string, representing columns and the contained rooms. For each room, it lists x and y-coordinates for the overlay I'm going to implement, as well as entrances and exits (all this might change depending on how well the overlay works and whether I need anything else). I changed my plan and took inspiration from slime molds (of all things):
Out of curiosity, how fast is your implementation? Mine takes about 4 seconds at 1440p (img-snippet is 1152x800), which has to be done once at the beginning of the floor. The data then remains in memory and feeds into the overlay. show JSON-string
|
Mine does 1 second at 3440x1440, but it runs in Scala. It is probably significantly faster than AHK because of the runtime. I have a bunch of optimizations I can do, so I think I can get it down to less than 200 ms, since my clustering currently is very naive ( I think the algorithms for path clustering we use are equivalent (slime mold discovery and DBSCAN with optimizations). If the tracing is what takes long you can consider doing a (simple) linear regression after the first bunch of pixels since that should point to the room in the same direction. The paths can overlap with the rooms, so you have to account for that. An early linear regression avoids this issue since it only needs to be confident in the direction to terminate. Here is an example: |
Thanks a lot for your inputs and your worst-case example, much appreciated. I have to admit that stuff goes waaaay over my head. As for the example: I managed to use your screenshot for calibration and testing, and my prototype connected that busy area in the center correctly. I had already implemented some leeway to make it "jump" to distant markers. I just need to tweak it so that the leeway is smaller on the x-axis in order to prevent the tracing from jumping onto a different path altogether. The top-most path to room 5_2 almost connected to the one underneath towards the end because the corner occluded so many pixels. (I just realized that it wouldn't make a difference in this specific situation since both paths lead to the same room.) I tried making it faster by means of "sparseness" (i.e. only scanning every nth line) but refrained from it for the sake of accuracy/consistency. I can still trim the areas that are scanned because they still have rather large buffer zones, but that's something for later stages. |
I got some initial UI/UX testing done today and could need some feedback (colors, transparency levels, and other stylistic considerations are all subject to change):
|
Hey. Thats pretty cool! Do you think it could be a good addition to not count rooms that had been banned (purple)? Does the path to node feature exclude banned rooms? The "show path to node" seems very useful for reveal type strategies. I think I personally would like the reachability paths of a room drawn, since this is probably the most universally useful thing. You usually always want to take the path that allows you to see as many rooms as possible, but sometimes the "best" path is blocked by a bad affliction, or maybe a good room is on an non-optimal path. For optimal route planning (given you have the full room revealed), you'd probably want to with a something like a weighted sum. For example:
Now there are numerous ways to compute this weighted sum, it could be forall rooms, compute the sum of the room types multiplied with the weight, say for coins -> coins -> shop -> shrine:
But there are also other considerations, such as, do I have enough coins for the shop and so on. It gets pretty gnarly and user-specific. Room types don't matter for most players after the first couple of sanctums. In this picture I take blue path since it has same room number as green (R: 12), because it has a tainted pact (the hands) since those can contain divines on floor 4. My point is that selecting the best route for every circumstance is a huge undertaking so making it easier for the user to plan the path might be the best for version 1 of the tool; give the tools and numbers for planning, but not necessarily do the plan. |
Yes that makes sense, good idea. Counting the connecting rooms was the last thing I implemented yesterday, so it doesn't interact with anything else yet.
Drawing the paths has a nice ring to it, but I'd have to figure out how to do that efficiently in AHK (probably draw a transparent bitmap and overlay that) and it would also probably become quite "busy" on lower resolutions (I have to keep everything resolution agnostic). I therefore chose the number-tags as a possible alternative. I photo "chopped" your screenshot to show what I currently have in mind, what it would look like, and how it could be used:
|
There's light at the end of the tunnel. If I find enough time tomorrow, I might be able to release an initial testing version. I have added another little option to manipulate the overlay: you can middle-click rooms to mark the room you're currently in, and the overlay will cull unnecessary information: 2024-08-12.19-47-14.mp4
You can also hold middle-click and hover back and forth between multiple rooms to show and compare their respective reachability paths. I'm still hesistant to implement the full reachability tree, so I guess this could be another possible alternative to that. At this point I would ask "is there anything else you'd want it to do?", but you've shown that you actually already have access to more elaborate techniques and possibilities. So instead: "Is there anything else I could implement that's useful to the average Sanctum runner?" |
I think the features for an initial version are there. More elaborate or specific features will probably become apparent from "daily" usage of the tool; adding too many features to the initial version might be an instance of premature (feature) optimization. |
v1.55.0 is now live. I had to delay it for a day because there were some unforeseen issues at lower resolutions that needed some ironing out. I had to go into more detail than usual in the release notes because this feature can only perform well if the user sets it up correctly, which I feel is almost never the case. You can give it a whirl if you like. |
Been trying to calibrate as best as I could but it still fails the scan on last row of rooms: |
@knot2006 The issue is the icon of dark pact rooms. During calibration, you must have caught some pixel-colors that are also present in that icon: The teal cross signals that the tool recognized a "loose end" there and cannot complete this specific path. You have to reset the pathing calibration by long-right-clicking the |
It would be nice if the tool could show the room reachability for any room. It takes a half minute or so to plan out the optimal path when having All Seeing Eye.
For every next room, a room reachability tree could be drawn with distinct colors. I suppose on hover could also be a implemented, but from my observations it seems that the hover effect ingame might overlay some of the sanctum map in a way that makes image analysis hard.
Furthermore, counting the number of unknown rooms for a given reachability tree would also be a very nice feature.
The text was updated successfully, but these errors were encountered: