Plugin structure

[hugeblank]

allium-cc had an interesting structure, but I just don't think it makes much sense. I propose a new structure that's more normal:

directory structure:

/plugins
  /<unique directory name> (can be a .zip)
    /<other directory(ies)> (will be ignored by allium, but may be used by this plugin [exclusively])
    main.lua

main.lua structure

main.lua will have to have a method on_initialize that will be called by the loader. This method will be required to return a namespace id, a plugin version (semver 2.0.0 spec), and an optional human readable name. Eg:

function on_initialize()
  --<logic registering commands, threads, and the like>
  return "allium_stem", "0.1.0", "Allium Stem"
end

Future considerations

• Plugins that may offer an API
• Plugins that depend on other plugins (and preventing cycles)
• Should plugins have a shared _G?

A more broad discussion that I think would be helpful is to take a look at allium-cc's register API. What should I keep and what should I scrap from that logic? For reference an example plugin using the allium-cc standard can be found here

[hugeblank]

An alternative:

function on_initialize()
  --<logic registering commands, threads, and the like>
  return {
    namespace = "allium_stem", 
    version = "0.1.0", 
    name = "Allium Stem"
  }
end

was suggested in the Fabric community discord, I do like that substantially more. Multiple returns aren't the smartest in this case.

[hugeblank]

I don't think I'm going to go with the on_initialize function. It'd make much more sense to just have the file return it.

[hugeblank]

Current prototype follows the directory structure in the initial report. The only difference is the namespace value is now just id.

[vico93]

Can the folder name, in theory, conflict with Cardboard (port of Bukkit API to Fabric)?

[hugeblank]

Can the folder name, in theory, conflict with Cardboard (port of Bukkit API to Fabric)?

Yeah, that was brought up by someone somewhere else. I was advised to change the directory name from plugins to scripts. The latest commit addresses that.

[vico93]

A totally 💩 idea, but why not calling Allium plugins "tektites"?

Not referencing Tekkit, the old jury-rig to run mods, but Tektites, a type of melted rock that have some theories of origin, from being a ordinary space rock to be return ejecta from meteorite impacts, in Earth or even in the Moon.

Well, you know... Lua... Moon in romance languages... Moon is a huge rock in space... Tekkites can be, at least partly from there too.... totally horrible concept, but...

[vico93]

Can the folder name, in theory, conflict with Cardboard (port of Bukkit API to Fabric)?

Yeah, that was brought up by someone somewhere else. I was advised to change the directory name from plugins to scripts. The latest commit addresses that.

That's the problem. All this generic terms, from plugins to scripts (CraftTweaker), are already taken up by other mods. And always have a small chance an user will try to use both at same time. Thats why i came up with an idea of different term.

[hugeblank]

A totally hankey idea, but why not calling Allium plugins "tektites"?

Not referencing Tekkit, the old jury-rig to run mods, but Tektites, a type of melted rock that have some theories of origin, from being a ordinary space rock to be return ejecta from meteorite impacts, in Earth or even in the Moon.

Well, you know... Lua... Moon in romance languages... Moon is a huge rock in space... Tekkites can be, at least partly from there too.... totally horrible concept, but...

:joy: that's definitely an idea. Might be me being pedantic but the word 'tektite' just doesn't roll off the tongue the same way that I think 'plugin' or 'script' does.

Can the folder name, in theory, conflict with Cardboard (port of Bukkit API to Fabric)?

Yeah, that was brought up by someone somewhere else. I was advised to change the directory name from plugins to scripts. The latest commit addresses that.

That's the problem. All this generic terms, from plugins to scripts (CraftTweaker), are already taken up by other mods. And always have a small chance an user will try to use both at same time. Thats why i came up with an idea of different term.

Hurm. That's unfortunate. I guess I could make the directory just allium.

[vico93]

Yeah, allium seems to be the way. If the mod name was also space-related the tektite thing could made some sense. But since it's not, is better to stick with allium for that. Similar stretegy of how KubeJS handles its "plugins" (uses kubejs folder in the root of the game directory).

[hugeblank]

Changed plugin structure again! Now instead of returning the 3 values in a table, a json file under the name manifest.json must be provided in the same directory as main.lua. It's contents should match the old setup.

[hugeblank]

In #11 I proposed that we move the manifest.json to allium.mod.json in a directory called resources. I see myself following through on this, so any objections should speak up

[hugeblank]

Alright I think we're settled on a structure:

allium.script.json

{
  "id": "namespace_identifier",
  "version": "1.0.0",
  "name": "A full name for your script!",
  "entrypoint": "path/to/script.lua"
}

id is a unique identifier that should match the regex pattern [a-z0-9_] verison is a version number that should match the semver 2.0 spec name is a human readable name of your script entrypoint defines the path to the script from within the unique directory that the entire script package resides

directory structure

using above allium.script.json as an example

/allium
  /My Basic Script
    /resources
      allium.script.json
      /assets
      /data
    /path
      /to
        script.lua

assets and data are where you'd put your resource/data pack resources for your mod, or to override minecrafts.

You can see from the note above that the entrypoint, path/to/script.lua has the same parent directory as resources: My Basic Script

IMO this is a pretty well established standard and I don't see it changing much after this. The bigger priority now is getting this established on a wiki. Time to close this!

[Merith-TK]

for the plugin name, just call them "petals"

allium is a type of flower,

[vico93]

/allium
  /My Basic Script
    /resources
      allium.script.json
      /assets
      /data
    /path
      /to
        script.lua

IMO this structure is a kinda... confusing. I looked through some mods .jar i had in my modpack and all of them have assets and data subfolders in the root folder, and code could be also at the root as well, no need to nest it (at least the old CustomStuff 2 scripts had this same strutcutre).

[hugeblank]

IMO this structure is a kinda... confusing.

You'll be happy to hear that the structure has fundamentally changed, unlike what I said on closing this issue.

/allium
  /My Basic Script
    manifest.json
    /assets
    /data
    /path
      /to
        script.lua

for the plugin name, just call them "petals"

I like this, but I also have mixed feelings on coining a term for what is essentially, well, a script.

[vico93]

You'll be happy to hear that the structure has fundamentally changed, unlike what I said on closing this issue.

That's interesting.

[Merith-TK]

personally I think manifest.json should use toml or yaml or an easier format like

#toml
name="A full name for your script!"
version="1.0.0"
id="namespace_identifier"
entrypoint="path/to/script.lua"

#yaml
name: A full name for your script!
version: 1.0.0
id: namespace_identifier
entrypoint: path/to/script.lua

[hugeblank]

@Merith-TK I like the idea of offering options, if you want to contribute yaml/toml manifest searching/parsing feel free to. I'm preoccupied with more pressing features at the moment. In the likely event you can't either, open a new issue so we can track it.

[vico93]

personally I think manifest.json should use toml or yaml or an easier format like

#toml
name="A full name for your script!"
version="1.0.0"
id="namespace_identifier"
entrypoint="path/to/script.lua"

#yaml
name: A full name for your script!
version: 1.0.0
id: namespace_identifier
entrypoint: path/to/script.lua

I think the idea here is to make scripts the most similar to regular mods as possible. Plus, like hugeblank said, the issue with parsers.

And, to be honest, burn YAML with fire (let it die with Spigot...)

[fatboychummy]

I like this, but I also have mixed feelings on coining a term for what is essentially, well, a script.

It's not just a script though. You have assets and everything else. It's a full-on plugin which just uses a lua script to control what it does.