Implement better support for filterscripts

[Southclaws]

I'm thinking this can pull the FS as a normal dependency to <server root>/dependencies/ then build it as a package with the output being <server root>/filterscripts/<name>.amx while switching out the filterscripts entry in memory before generating the server.cfg (same as plugin binaries using depstrings).

I'd like some input from the community now that sampctl is spreading more. How would you prefer filterscripts are handled? What commands and functionality would you find useful?

[Southclaws]

Someone mentioned y_master and integration with this, that could be done too...

[Y-Less]

Someone

Who do you think that was? :D

[Southclaws]

Not sure, I think their name has a Y in it though...

[Southclaws]

From some discussion today:

It would make sense to group Filterscripts into "dependencies" along with how plugins have been with #165. This would make Filterscripts into just another thing you depend on which would be downloaded to the dependencies directory along with all the Filterscript's dependencies.

The only question is, how to signal to sampctl that a specific dependency is a filterscript? I was thinking of an fs: prefix but that seems a bit too "special case" as it would be the only usage of that syntax currently.

Another issue is that there may be packages that are both Filterscripts and libraries - I want to do that with my object-loader project so people can use it as a filterscript or use the API in their gamemodes for more advanced use-cases. So this kind of rules out a true/false flag that authors can add to pawn.json.

Another possible way I've just thought of is introduce the idea of "flags" to dependency strings. Similar to the fs: prefix, but actually a space-delimited list of tokens after the dependency string:

"dependencies": [
  "Southclaws/samp-object-loader:^1.2.3 filterscript"
]

Spaces are invalid in the dependency string format anyway so splitting on them would be easy and not breaking in any way.

[Misiur]

Is this implemented yet?

[Misiur]

Also would this support local dependencies for dev build?

[Southclaws]

No this isn't implemented yet.

[n0bodysec]

Maybe sampctl p buildfs <fsname/all> with a custom pawn.json inside filterscripts folder.

It should be something like this:

"dependencies": {
	"fs-1": [
		"author/repository1",
		"author/repository2"
	],
	"fs-2": [
		"author2/repository1",
		"author2/repository2"
	],
}

Another way is supporting "custom crafted comments" inside filterscripts (something like clang-format comments), so you get rid of pawn.json file.

/* sampctl-dependencies:
	"author/repository1"
	"author/repository2"
*/

Currently I'm using a custom Python script to compile the filterscripts.
Here's the code if annyone is interested: https://gist.github.com/n0bodysec/30b1158b72f482ecbf087b19b29febb7

[ADRFranklin]

I already have a plan for how I am going to implement filterscripts and it's nothing like this. I am planning to add it to the build section of the pawn config file.

As for remote repositories, I also have a plan for that. I plan to start working on this over the next week or two.

[Y-Less]

I am going to implement filterscripts

I don't believe you.

But if you ever get to this and prove me wrong, could you look at #327 at the same time please?

[ADRFranklin]

it's already part of the changes I planned to make.

[Southclaws]

The focus is essentially to drop the idea of "gamemodes" and "filterscripts" entirely and just have "scripts" - which can be in (and output to) any arbitrary directory.

[Misiur]

That's amazing, where I can read the discussion about it?

[Southclaws]

Unfortunately, it's buried in the Discord...