Open TechnicJelle opened 11 months ago
Maybe just require BMAreaControl to use the area config from it? Oh, and also add an option to use BMAreaControl area settings into config. But the most important filter is null text checker, 100% sure. There are a lot of empty signs in mobfarms like "ffffff". "wwww", etc. But mostly with no text at all or just spaces :)
I am leaning towards integrating LuaJ for this, to allow users to script exactly which signs they want to keep and which ones they want to remove. Perhaps I'll include some templates that can be easily used or adapted.
Regarding your suggestion of using BlueMap Area Control areas, I don't think I would be doing exactly that, due to wanting to keep my add-ons as independent of each other as possible. Instead, I'll try and see if I can add a way to filter out the signs from un-rendered areas on the BlueMap itself. This should have effectively the same effect. Likely with the [BlueMapMap#getTileFilter()](https://bluecolored.de/bluemapapi/latest/de/bluecolored/bluemap/api/BlueMapMap.html#getTileFilter()) method.
I may have to make this add-on softdepend
on BMAC, though, to ensure that it loads after BMCAC, so BMAC has the time to set up its tile filter first. (But not any actual interaction code)
Or I just add a 10-second delay before this plugin starts the sign extraction process. Maybe that'll be simpler...
LuaJ for this, to allow users to script exactly which signs they want to keep and which ones they want to remove
In Overviewer there was an option to filter signs via a python function added to the config or so. As a temporary solution I made this script for myself to filter the results
import json
with open('markers world original.json', 'r',encoding='UTF8') as file:
data = json.load(file)
filtered_signs = {key: value for key, value in data['signs']['markers'].items() if ((value['position']['x'] > -4600.0 and value['position']['x'] < 7000.0 and value['position']['z'] > -3500.0 and value['position']['z'] < 1600.0) and value['position']['y'] >= 60.0)}
data['signs']['markers'] = filtered_signs
with open('markers world.json', 'w') as file:
json.dump(data, file, indent=2)
Yeah I also just checked the Overviewer docs, to see what they used, and indeed, they use Python. https://docs.overviewer.org/en/latest/signs/ I think I'll also use Python then, to keep it simple for people to switch to this. And I don't necessarily mind using Python for this either, as it's a fine language for scripting stuff like this
I've been experimenting with Jython a bit, and from my first tests, it seems pretty cool, but it does inflate the size of the plugin to like 50 megabytes, from the half a megabyte that it currently is...
And it also doesn't seem to want to properly compile. It runs fine in IntelliJ, but when I package up the plugin as a .jar, and try to run it, it doesn't work; it can't find the Jython Script Engine. It's most certainly in there, though, as the jar has bloated to the aforementioned 50 megabytes.
I've found an alternative Python runtime for Java: https://github.com/oracle/graalpython When I tried it out just now, it was a LOT simpler to integrate and package up, and I have now succeeded in running Python code on my Minecraft server!!
However, this comes at the cost of a ridiculous jar size of 124.4 megabytes... :scream:
I am considering using Groovy instead of Python. All these giant jar sizes are making me depressed. Groovy should be a LOT more reasonable. @ShDis, what would you think about this? Do you think it'll be easy enough for people who are used to Python to pick up Groovy?
I've never heard of Groovy before (okay, maybe 1 time or 2, sounds familiar). But I don't think that's the problem. There are no other similar tools to solve the "sign problem". So any solution is great, even a 124mb size (honestly, I don't really care about its size because my server folder without backups is about 130gb). If the solution is on Groovy - good, then I'll learn how to use it. And if it's easy to use, the solution will be twice as good :з
But as a "half-programmer", I really like the way you try to make the implementation as good as possible
I'd like all the things I make to be as simple as possible for people to use, while still allowing advanced users the power they need, as well :)
I've been playing around with Jython again this evening, without much success, sadly. Although I have been somewhat convinced to have the scripting feature as like, as addon. So by default, it just works like this, but if you download the Jython jar and put it into the config directory, it'll load it, and run the filter script. Only, I've not been successful in loading the jar file dynamically, yet. It's proving a lot more challenging than I'd hoped.
Oh my goodness, I have finally got it to work!!! It's printing stuff from a Python script, running on my test server! :partying_face:
With a million thanks to Blue for sending how he does it!
We are back in business! :sunglasses: I'll go to sleep now, but I'll try and get a prototype of filtering working soon!
I recently made an addon for displaying entities on the map, which used a HOCON configuration file for its filters. It did not use a Python script. I suppose it could technically be called a DSL.
This was surprisingly not too difficult to make.
I suspect it'd be a ton faster than a Python script. It just has to load the config file once, after which it can just run it as fast Java code, instead of having to call into Python for every single sign.
I also hope it'd be a bit more accessible and less daunting for people.
So I think I am scrapping my plans for Python scripting integration, and I will do what I did for that addon.
Perhaps through some sort of scripting? That seems awfully complicated, though...
Perhaps just a black/white-list, like BMAreaControl has is already enough..?
Please feel free to comment on this issue with your own thoughts on this!