Added tracers to SearchHack

[cdxc]

Description

Added an option to the SearchHack module that draws tracers to the blocks the user is searching for. I also changed the default block to nether_portal, since its the most wildely used in this type of hack.

Without tracers cheked:

With tracers checked:

[Lamby777]

epic gamer

[cdxc]

one year aniversary of this pull request, still nothing. i made a perfectly useful feature just out of my love for free software and this client. i wanted to help, i helped. what i do now? idk! cry? cry a lot? sure. but my tracers still won't be in the master. i could have just not done it. but i have. you could at least tell me my code was shit, but nothing :((((

[Lamby777]

No clue why, this would be a really useful change.

[FlorianMichael]

I also like the function and find it a pity that Alexander doesn't look at most pull requests or doesn't merge them, but that seems to be a general thing with him and is nothing personal.

[github-actions[bot]]

This pull request has been open for a while with no recent activity. If you're still working on this or waiting for a review, please add a comment or commit within the next 7 days to keep it open. Otherwise, the pull request will be automatically closed to free up time for other tasks.

Pull requests should be closed if:

• They have been superseded by another pull request
• They are out of scope or don't align with the project
• They have become obsolete due to other changes
• They have bugs or conflicts that won't be resolved

[Lamby777]

still relevant (though has merge conflicts)

[Alexander01998]

Hey @Lamby777,

Thanks for showing interest in this pull request. However, given that the original author has been inactive since mid-2022, I think it's unlikely they'll come back to resolve these merge conflicts.

Also, I'm a bit concerned about the performance implications of adding tracers to Search, given that Search is designed for high performance while scanning for massive amounts of blocks. Adding a tracer line for each located block would be extremely slow at that kind of scale.

Lastly, while it's great to have options, the featured portal-finding use case for this PR seems somewhat redundant now that we have a proper PortalESP hack. If you have any other use cases for tracers in Search, feel free to share them.

Given these points, I think it's best to close this PR. While the idea of adding tracers to Search is not completely off the table, I'd prefer to implement them from scratch instead of trying to resolve the conflicts in an old PR.

[cdxc]

hello, don't know if i can still write here, but i'm back and willing to discuss this.

some users use this hack to find blocks and in lower quantites, and most other clients offer this feature under the search hack, so i see no reason why not at least offer this as a togglable feature.

The nether portal is just an arbitrary block which i've seen as the default in other clients.

Also what excactly do you mean by "implementing them from scratch"? To make another seperate hack Tracers or something? i would be willing to do any of this.