Gehennom level with no maze #56
Comments
entrez
added a commit
to entrez/xNetHack
that referenced
this issue
Nov 8, 2021
For mazewalk to work properly, random rooms in maze levels must be placed so that the walls are on even coordinates (so that they line up with the walls of the maze). check_room was adjusting the positioning and size of the rooms without adhering to those rules, leading to rooms that were offset from where they should be. This could also cause doors to show up in weird places, because door placement in maze_add_rooms used the original lx,ly,hx,hy from before the room size/position change by check_room. I think this issue is related to copperwater#56; the leftmost room in the screenshot has an invalid y-coordinate; that may be the cause of, or at least a contributing factor to, the problem with mazewalk.
entrez
added a commit
to entrez/xNetHack
that referenced
this issue
Nov 8, 2021
For mazewalk to work properly, random rooms in maze levels must be placed so that the walls are on even coordinates (so that they line up with the walls of the maze). check_room was adjusting the positioning and size of the rooms without adhering to those rules, leading to rooms that were offset from where they should be. This could also cause doors to show up in weird places, because door placement in maze_add_rooms used the original lx,ly,hx,hy from before the room size/position change by check_room. I think this issue is related to copperwater#56; the leftmost room in the screenshot has an invalid y-coordinate; that may be the cause of, or at least a contributing factor to, the problem with mazewalk.
|
Very interesting... I was just able to reproduce it. Similar setup where the mazewalk starts wedged between a room and the edge of the map. Pretty sure I understand what is going on here now.
|
entrez
added a commit
to entrez/xNetHack
that referenced
this issue
Nov 9, 2021
walkfrom's recursion worked in such a way that it could go back to every level _but_ the very first position it started from, which meant that if it started in a spot where its first move could put it in a position where it became stuck between a room and a corner of the map, the rest of the map would go unfilled. This behavior can be reproduced consistently by placing a room with roompos.x = 5, roompos.y = 3, then starting the mazewalk with mm.x = 3 and mm.y = 5. Adjust walkfrom so that it doesn't irrevocably commit to a direction before recursing, which should solve this problem. Fixes copperwater#56.
entrez
added a commit
to entrez/xNetHack
that referenced
this issue
Nov 9, 2021
walkfrom's recursion worked in such a way that it could go back to every level _but_ the very first position it started from, which meant that if it started in a spot where its first move could put it in a position where it became stuck between a room and a corner of the map, the rest of the map would go unfilled. This behavior can be reproduced consistently by placing a room with roompos.x = 5, roompos.y = 3, then starting the mazewalk with mm.x = 3 and mm.y = 5. Adjust walkfrom so that it doesn't irrevocably commit to a direction before recursing, which should solve this problem. Fixes copperwater#56.
entrez
added a commit
to entrez/xNetHack
that referenced
this issue
Nov 9, 2021
walkfrom's recursion worked in such a way that it could go back to every level _but_ the very first position it started from, which meant that if it started in a spot where its first move could put it in a position where it became stuck between a room and a corner of the map, the rest of the map would go unfilled. This behavior can be reproduced consistently by placing a room with roompos.x = 5, roompos.y = 3, then starting the mazewalk with mm.x = 3 and mm.y = 5. Adjust walkfrom so that it doesn't irrevocably commit to a direction before recursing, which should solve this problem. Fixes copperwater#56.
entrez
added a commit
to entrez/xNetHack
that referenced
this issue
Nov 9, 2021
walkfrom's recursion worked in such a way that it could go back to every level _but_ the very first position it started from. This meant that if its first move could get it stuck between a room and a corner of the map, the rest of the map would go unfilled. This behavior can be reproduced consistently by placing a room with roompos.x = 5, roompos.y = 3, then starting the mazewalk with mm.x = 3 and mm.y = 5. Adjust walkfrom so that it doesn't irrevocably commit to a direction before recursing, which should solve this problem. Fixes copperwater#56.
|
I hate how referencing an issue makes my obsessive force-pushing even more obvious |
entrez
added a commit
to entrez/xNetHack
that referenced
this issue
Nov 10, 2021
walkfrom's recursion worked in such a way that it could go back to every level _but_ the very first position it started from. This meant that if its first move could get it stuck between a room and a corner of the map, the rest of the map would go unfilled. This behavior can be reproduced consistently by placing a room with roompos.x = 5, roompos.y = 3, then starting the mazewalk with mm.x = 3 and mm.y = 5. Adjust walkfrom so that it doesn't irrevocably commit to a direction before recursing, which should solve this problem. Fixes copperwater#56.
entrez
added a commit
to entrez/xNetHack
that referenced
this issue
Nov 10, 2021
walkfrom's recursion worked in such a way that it could go back to every level _but_ the very first position it started from. This meant that if its first move could get it stuck between a room and a corner of the map, the rest of the map would go unfilled. This behavior can be reproduced consistently by placing a room with roompos.x = 5, roompos.y = 3, then starting the mazewalk with mm.x = 3 and mm.y = 5. Adjust walkfrom so that it doesn't irrevocably commit to a direction before recursing, which should solve this problem. Fixes copperwater#56.
entrez
added a commit
to entrez/xNetHack
that referenced
this issue
Nov 10, 2021
walkfrom's recursion worked in such a way that it could go back to every level _but_ the very first position it started from. This meant that if its first move could get it stuck between a room and a corner of the map, the rest of the map would go unfilled. This behavior can be reproduced consistently by placing a room with roompos.x = 5, roompos.y = 3, then starting the mazewalk with mm.x = 3 and mm.y = 5. Adjust walkfrom so that it doesn't irrevocably commit to a direction before recursing, which should solve this problem. Fixes copperwater#56.
|
While fixes to maze+rooms bugs like entrez's are appreciated, I am not planning on personally putting any effort into fixing them since the plan is to give Gehennom a substantial overhaul that doesn't involve mazes (planned for version 8.0 currently; upcoming version is 7.0.) That said, if there's a PR that fixes this, I'll merge it. |
copperwater
pushed a commit
that referenced
this issue
Feb 16, 2022
For mazewalk to work properly, random rooms in maze levels must be placed so that the walls are on even coordinates (so that they line up with the walls of the maze). check_room was adjusting the positioning and size of the rooms without adhering to those rules, leading to rooms that were offset from where they should be. This could also cause doors to show up in weird places, because door placement in maze_add_rooms used the original lx,ly,hx,hy from before the room size/position change by check_room. I think this issue is related to #56; the leftmost room in the screenshot has an invalid y-coordinate; that may be the cause of, or at least a contributing factor to, the problem with mazewalk.
copperwater
pushed a commit
that referenced
this issue
Feb 16, 2022
walkfrom's recursion worked in such a way that it could go back to every level _but_ the very first position it started from. This meant that if its first move could get it stuck between a room and a corner of the map, the rest of the map would go unfilled. This behavior can be reproduced consistently by placing a room with roompos.x = 5, roompos.y = 3, then starting the mazewalk with mm.x = 3 and mm.y = 5. Adjust walkfrom so that it doesn't irrevocably commit to a direction before recursing, which should solve this problem. Fixes #56.
|
Fixed on the 7.0-savebreaking branch. It will not be fixed in 6.3. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A filler level in Gehennom generated with no maze, only solid rock and a few rooms.
I've occasionally seen a single room fail to connect properly with the maze, requiring me to dig in or out, but this is the first time I've seen no maze at all. I used a stethoscope to search for secret passages all around the room with the upstair, then dug a few tiles to the right before reading a mapping scroll.
My best guess as to the cause is that the tiny room in the lower-left was supposed to be the maze, but somehow it stopped generating past a few tiles. That guess is based on that it's too small to be a normal room, but it could be a short piece of maze hallway.
The text was updated successfully, but these errors were encountered: