Open ofunny opened 4 months ago
Hello, your report will be looked into as soon as possible. Please do not bump this thread and don't post it on multiple platforms.
Thanks a lot for your patience.
FULL server log
On request only
Please fill out the form properly, as leaving out parts such as the logs will also leave out crucial information we need to properly help you.
If you fear sharing logs due to privacy, I recommend using http://mclo.gs, which automatically censores IPs and other sensitive information.
FULL server log
On request only
Please fill out the form properly, as leaving out parts such as the logs will also leave out crucial information we need to properly help you.
If you fear sharing logs due to privacy, I recommend using http://mclo.gs, which automatically censores IPs and other sensitive information.
There are no crucial information in this log and I'm not sharing my full server logs publicly. If you still want it, please get back with a way to send it privately!
Without sharing your logs, we can't provide you any support. Also, logs do not have any form of sensitive information, outside IPs which mclogs is censoring, that would warrant not sending them.
Without sharing your logs, we can't provide you any support. Also, logs do not have any form of sensitive information, outside IPs which mclogs is censoring, that would warrant not sending them.
Logs reveal insides of plugins I'm using, the server itself, some config prints and player and IP names, especially player and IP names, what I'm not allowed to share with any service I have no agreement with or my players consented to under GDPR - this is indisputable. I can pass the information either privately for technical purpose, I can give you selected information from my logs, that you specifically need and as a dev I know, that all you see there is what my server version is, what other plugins I'm using and what libs getting loaded in the beginning and the initial config print of IA, nothing I could not share on request, just not a whole log paste. Especially since there are no error prints.
And again, I'm even willing to share it privately, but I won't break European law, for a problem, that has never existed before. If this is a deal breaker for fixing an obvious plugin issue, so be it.
Logs reveal insides of plugins I'm using, the server itself, some config prints and player and IP names, especially player and IP names, what I'm not allowed to share with any service I have no agreement with or my players consented to under GDPR - this is indisputable.
That isn't quite how the GDPR works. By the logic you give here would MC not even be allowed, given the client is providing the IP to the server too.
I want to mention again that mclogs would automatically censor any IPs and folder-paths, meaning an IP like 127.0.0.1
becomes ***.*.*.*
, so if the GDPR would apply here - which it doesn't - would this not be a violation of it, given the info is properly censored.
Also, there is nothing in your plugins a user here would be interested in stealing, unless you would visibly display sensitive information like database IPs and passwords, which would be a bad design decision on your end.
So, I'm asking you again to just share the logs through https://mclo.gs as we otherwsie can not and will not provide support.
About the client to server issue, well yes, in strict terms you would have to ask your user base to process/forward personal data provided (to which user and ip belongs), otherwise the user and IP, except for technical relevant operations, has to be deleted in time and therefore can not be passed on to third parties like "mclo". Of course there is a user agreement that players first accept if they login to Minecraft itself, that however does not cover me processing data in the mentioned way with 3rd parties.
Since you refuse to ask for selected data or to take the log via a private channel, I sadly have to end the conversation here. I can not operate beyond GDPR or other laws.
Please keep the GDPR and stuff outside of this topic.
However, for certain types like CHERRY, AZALEA, CHORUS_PLANT, RED_MUSHROOM, etc. (have not tested all of them) this does not work at all, not just sometimes, it will always spawn with the default blocks.
This definitely seems to be a bug, I will check out why this happens. Strange because I use the internal game code to spawn trees, so something's wrong. Thanks for the patience!
Thank you, really appreciate that, but it's not urgent at all, using normal TREE types for now what work fine. In case this is server version or API related, I tested it on: Paper version git-Paper-493 (MC: 1.20.4) (Implementing API version 1.20.4-R0.1-SNAPSHOT)
Please keep the GDPR and stuff outside of this topic.
Would not have started it at all, the other contributor just was not willing to get my point of not publicly sharing my whole logs, but I think it's settled now :)
Terms
Discord tag (optional)
ofunny
What happened?
According to https://itemsadder.devs.beer/plugin-usage/adding-content/trees-populators/populator the regular Spigot API enum TreeType represents all trees the attribute
tree_type
would except, also there is a noteHowever, for certain types like CHERRY, AZALEA, CHORUS_PLANT, RED_MUSHROOM, etc. (have not tested all of them) this does not work at all, not just sometimes, it will always spawn with the default blocks.
And two more questions
And a suggestion
Thanks in advance
Steps to reproduce the issue
Server version
No response
ItemsAdder Version
ItemsAdder version 3.6.3-beta-13
ProtocolLib Version
ProtocolLib version 5.2.0
LoneLibs Version
LoneLibs version 1.0.45
FULL server log
On request only
Error (optional)
Problematic items yml configuration file (optional)
Other files, you can drag and drop them here to upload. (optional)
No response
Screenshots/Videos (you can drag and drop files or paste links)
No response