-
Notifications
You must be signed in to change notification settings - Fork 31
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
[Block Request] Add custom filter block for power users #291
Comments
Thanks for your feature request, I really appreciate the effort that went into mocking this up. I've been considering this type of feature for a while now however there are a few different issues that have gotten in the way of me adding it. Here is a general overview of my thoughts on this. The biggest issue is that revealing internal game data to non-op players introduces some security concerns. Both vanilla and mods are known to store sensitive data in NBT. For example I previously caught a lot of heat for including an NBT debugger in one of my mods because it allowed players to access vanilla locked chests and Security Craft systems because they both store their passwords as plain text in the NBT. A smaller problem with this idea is that it goes against the design of the mob filters. They're meant to be simple blocks that players can place together in different combinations to create larger and more complex filtering rules. Another small issue is that while this may be intended for power users everyone will try to use it. This means that a lot of time and polish will need to go into the UI to make it friendly for the average player. This isn't impossible, it's just going to require a lot of additional work and testing. A workaround I have considered is making this a creative mod feature for packs/maps/servers and then let players spawn them in or add their own recipe if they want. My main concern with this is that it's a lot of dev time going to a feature that would only benefit a very small number of players. Another option I have considered is adding support for a mod like ContentTweaker that would allow you to add your own unique mob filters to the game as new blocks. I really like this idea and it wouldn't require much dev time, but I don't think this is the answer players are hoping to hear. A third possible option would be to make an addon similar to Quark's oddities mod that adds weird content that isn't quite right for the main mod. This could also work, but it's something I would need to think more about. In the short term, are there any specific types of filters that you would like to see? I am hoping to do a medium sized content update soon for 1.18.2+ and I could potentially add some specific filter blocks for you. |
Thank you for response. I didn't notice it immediately. I wrote to you, when I wanted to build a sheep color sorting farm. Same could apply to mooblooms for instance, or resource chickens, fish types, mythic mounts etc. Have you considered datapack blocks that would allow custom filters? Thanks again, fantastic mod. P.S. Can one hide filter block? Making it appear like stone, or air? |
Hey. First of all, great and fun mod. I'm enjoying it.
Secondly, I have a request that I really want to happen.
Can you add one more custom filter block for the power users please?
I'd like to be able to do custom filtering based on
/data get entity entity_id
by setting a conditional statement.Here is typical sheep data:
What I'd like to do is this:
The way I imagine filter to work:
Front-end is self-explanatory from the pictures.
Backend:
-use automatic versioning for filters that have the same name:
Have a file with name "versions.json5" that stores the general data, like so:
When you save the filter, it will save it as "filter_name_with_underscores.nextVersion.json5".
Saving will also increment nextVersion in the versions.json5 file.
This I believe is good balanced solution for speed and customizability.
In game the mobs will be checked and tagged by filter block. Tags:
-"filter_name_with_underscores:v2:true" (abbreviation - F:V:T)
-"filter_name_with_underscores:v2:false" (abbreviation - F:V:F)
Check radius (CR) option should be added to main config.
CR is the radius in which the filter block will check if the mob has the tag "F:V:T" or "F:V:F".
2.1. If it has the tag, it will use it to filter the mob.
2.2. If not, then start the tagging process:
2.2.1. Scan mob with "Command:"(ex. "data entity @t" (@t - represents target id)), store the Command result.
2.2.2. Resolve true or false result for each Filter (ex. "F1", "F2", etc.), store the Filtering results.
3.2.3. Resolve "Logic:" statement (ex. "NOT(F1 AND F2)") store true or false Logic result.
3.2.4. Tag mob with "F:V:T" or "F:V:F" depending on the Logic result.
3.2.5. Go back to 2.
This way, the filter block will only check the mob tags, and not the mob data every time the mob enters the CR.
This is just a suggestion, I'm sure you can come up with something better.
Thanks for reading.
The text was updated successfully, but these errors were encountered: