Skip to content
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

very_basic_overworld_wither_cage_finder is outdated #372

Open
flyingitalianman opened this issue Apr 21, 2023 · 5 comments
Open

very_basic_overworld_wither_cage_finder is outdated #372

flyingitalianman opened this issue Apr 21, 2023 · 5 comments
Labels
bug Something isn't working

Comments

@flyingitalianman
Copy link

flyingitalianman commented Apr 21, 2023

Describe the bug
In "very_basic_overworld_wither_cage_finder.sc" there is this line:

scan(center_x, 4, center_z, radius, 0, radius,

It has a few issues:

  1. it ignores the "center_y" given as input
  2. since 1.18 bedrock is no more between 0 and 4 in the overworld

Expected behavior

  1. I would expect "center_y" to be used, rather than silently ignored
  2. I would expect to be able to run it between -64 and -60 in the overworld as a minimum, as well as between 122 and 127 in the nether
@flyingitalianman flyingitalianman added the bug Something isn't working label Apr 21, 2023
@rv3r
Copy link
Collaborator

rv3r commented May 10, 2023

The script does have "overworld" in the name, so making it work in the nether would require either a name change or just making a new script, but the y coordinate part should be easy.

@rv3r
Copy link
Collaborator

rv3r commented May 10, 2023

Although in the video gnembon specifically states that it is meant to find a very simple structure, so I would hesitate to change this script and instead just make a new script. Even if I did allow the y values to vary, what use would a 3x3 of bedrock at y = -64 (overworld) or y = 0 (nether) serve?

@flyingitalianman
Copy link
Author

  1. the fact that you don't understand the use of finding this structure, does not mean that this is exactly the use this script was made for originally (finding possible wither cages between y=0 and 4, see the line I quoted)
  2. the fact that "overworld" is in the title does not mean that this would not be useful in the nether
  3. as it stands it is usable only in pre-1.18 versions, I am asking to at least update the values to 1.18 and after ones. Since the original was looking between 0 and 4, the new values would be -64 and -60. If you think we should change it to -63 and -59 instead, gnembon is the person to ask, not me.
  4. if the y value keeps being hardcoded, remove it from the inputs. If the y value is in the inputs, I want it to be used, I do not want to be tricked.

@rv3r
Copy link
Collaborator

rv3r commented May 11, 2023

I suppose I should be clearer. Since this was originally an example script, I am personally opposed to making major changes to this. I think that people who view the script after watching the video that describes it should see something close to what was presented in the video. I would be completely fine with a new script (perhaps just named "wither_cage_finder.sc") that fulfills your requirements.
In response to your comment:

  1. You are probably right to not limit what the user can do, since they might need the structure for something else. I didn't take enough time to think about what you said.
  2. I can see how this would be useful in the nether, and I think if a new version of this app was made, it should absolutely include this functionality.
  3. I agree that apps should generally be kept up to date, but making a new one to take its place is also an option. Regarding the searched y-values, please note that scan() uses the second y-value (0) as the range, not the other limit. Thus, as stated in the video, this script currently checks only y = 4. Moreover, as far as I know, y = -64 in the overworld and y = 0 and y = 127 in the nether are all bedrock (unless removed by the player), so the script would return every block at those y values. If you want that to happen, that can be done, but I want you to think about this fact.
  4. I agree that inputs should either be used or not be present in the command. I think this happened because it makes more sense to people to input x, y, and z values, not just two of those.

@flyingitalianman
Copy link
Author

sorry, I thought I replied.

I see your points, and yes, I was wrong in reading the scan() line.

Fine in having a new version for me. I would propose:

  1. rename the current one to make clear is pre-1.18
  2. remove center_y from its input
  3. make a new one where center_y is used

I could probably post here in the comments a code suggestion for the new version later this week if it's fine for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants