Lack of understanding on how to target a specific receiver

[fcfang]

I'm running this on Spigot : This server is running CraftBukkit version 3026-Spigot-79d53c2-d54b500 (MC: 1.16.5) (Implementing API version 1.16.5-R0.1-SNAPSHOT)

Firstly, thanks for the plugin. I've been searching for something like this for a while. I've tried to look for documentation on this but can't find anything specific to the problems I'm having - no doubt a lack of understanding on how it works.

My config.yml is enclosed.

config.yml.txt

Not sure how to show you my set up other than to do a quick [unlisted] youtube explanation here - https://youtu.be/81IY_pwdpao Apologies for being long-winded...

Thanks in advance for any insights as to what I'm doing wrong.

Frank.

[flokol120]

@fcfang First of all thanks for your interest in the plugin and huge thanks for the detailed description. I am sure I can help you with that. I'm am assuming that the things that you are experiencing are due to your regex sets. Also according to your video it seems that you not fully understood how regular expressions (regex or regexp for short) work. Don't get me wrong; that is absolutely fine as its a rather advanced feature. The first things that came to my mind reading through your sets:

1. Please make sure that you don't have the same items in two sets. This will lead to weird things happening (most likely will sort the items in a random set the item is in) e.g.: .*plate is present two times in your config.yml.
2. Be more verbose/specific! E.g.: You have .plate and .chestplate in different sets (and you don't have them in other sets :P). You are trying to sort a chestplate into you chests but it ends up where the pressure plates should end up. Why? Because .plate just means: "please search for an receiver chest which has an item in its frame which has the word 'plate' anywhere in its id". So if you change .chestplate to ._chestplate (because all chestplates start with _chestplate (iron_chestplate, diamon_chestplate, etc.)) and .plate to ._pressure_plate you'll see that this is working as intended. This pattern applies to many of your sets (I guess you took the wool example and just modified it (again don't get me wrong that is absolutely fine) maybe I should also change .wool to .*_wool as it is more specific :thinking:).

If you want to dive a bit deeper into the whole regex world, maybe take a few minutes to read through here: https://medium.com/factory-mind/regex-tutorial-a-simple-cheatsheet-by-examples-649dc1c3f285

But don't hesitate to ask if something is unclear. (I hope what I wrote is somehow understandable; my English is not the best :P)

[fcfang]

Thanks very much for taking the time to respond. Thanks for pointing out the plate and chestplate regexp. I do actually know how they work having use them with sed, vi (Unix) for many years. I was hoping there was some order in which the set rules are parsed hence I do the chestplate first and then the plates to catch the plates that haven't matched. Does the .*plate being in more than one place possibly explain the shield issue?

I'll parse the sets to clean them up some and then see if it changes anything.

Additional questions:

• Do I have the basic understanding of how a receiver is mapped to a set correct? ie as long as the frame has an element that matches something in a set, the contents of the matching items of a set should be sent to that chest? Also is there any rules for having multiple receiver chests with the same target item (in a frame)?
• Finally, to follow up on the earlier question above, is there any order to the way the sets are parsed (the .chestplate match then falling through to match the catchall .plate).

Thanks again!

[flokol120]

Ah I see in this case you are probably better with regexp than me :P Regarding your questions:

• yes that is correct. If the item in the frame is in a set, this set will be used
• As the regexp set was not implemented by me I can only take a guess at this moment (because I dont have time to look at the code :P): sets are searched from top to bottom and left to right. So in this case the set in the top would always win over the other if both have the same item in it.

I can take a deeper look into this next week if you haven't fixed it by then.

[fcfang]

I think I've got it working.

In my case, my root cause was that I had too many undefined receiver chests. I combined the single chests into doubles, named them and with no undesignated receiver chests, everything works fine.

Thanks for your help.

[flokol120]

Cool! Maybe you would also benefit from the Implementation of #22 :thinking:

[fcfang]

I actually tried that at first (putting multiple frames on a double chest) :) Great minds and all that but I think that would in most cases still end up with too many chests for me. I think the sets functionality works great for me.

I think a slightly more flexible way to enable #22 might be to inspect the contents of each chest and put similar items into them. This would, of course, have a pretty large performance penalty if the code has to do that every time. However, this way gives you the ability to define an unlimited (ok maybe not unlimited) set of items and then perhaps have a way to group multiple chests together by putting the same item_frame item on "grouped" chests. This would get the user out of editing the config.yaml with regexp or name ids and give a more "native" player functionality. I'm not sure how you'd get away from doing the /ics add sender and receiver other than perhaps augmenting gameplay by defining custom items that require the user to build a new tool or chest (in a crafting table) to do the ics add/remove.

Happy to brainstorm more if desired.

[flokol120]

You are absolutely right about the performance concern of this idea. I personally like it that I can see directly what is in a chest by just looking at its item frame. But that is just a personal preference I guess. I'm closing this issue for now as your original point seems to be resolved. But I'll take your idea into consideration when working on #22. Thanks again for your input and interest.