[ENGINE] Plugin overhaul (packaging, conflicts, cache)

[Promises]

Game Engine Feature Description

Example: As a plugin developer, I expect to be able to be able to hook into the player init event. is to rebuild them as "packages", where each plugin is a folder, the folder has a manifest, and folders for: action hooks, configuration (npc/spawns/items configurations), and a folder for cache files. in the cache files folder you would have one folder for each index and the data inside them, when the server loads the plugin it should add these files to the fileserver for the clients to update.

The manifest: the manifest will have a small description of the plugin, booleans for what it includes (cache, hooks, configs), collisions ("collides: "skill_1" if it cannot exist with other plugins that override skill_1), it can depend on other plugins ("depends_on": "item_pack_osrs_180").

Acceptance Criteria

• Plugins as self contained packages
• Loading configs from plugins
• Loading cache data from plugins

Additional Information

Please do discuss these suggested changes, as they are not small

[Promises]

This could be used to completely replace a skill, for example firemaking is quite useless, but a skill to create magic equipment (like smithing for melee and crafting/fletch for ranged) could be quite useful, but in that case you would not want there to be any other plugin that adds the skill firemaking.
this feature would make it possible to create custom items for use in the plugin, custom npcs as tutors/masters, custom areas for quests related to the skill(even as separate plugins that depend on the main skill plugin), action hooks for the skill itself, and configurations for all the added data.

[Promises]

Additional suggestion based on this issue:
Packet definitions based on a plugin, ("collides":"base_packets"), which could enable users to just drop a plugin in to connect a new client revision.

[SchauweM]

I'm not too sure about creating our own manifest file for this. Shouldn't we use package.json for all this metadata? that way plugins can be published on NPM & dependencies can be managed by NPM. In the package.json file we could then add the rest of what you're purposing.

I love the rest of the suggestions

TLDR: dependencies should be managed by NPM, all other stuff can be written in the package.json file IMO

[SchauweM]

Is #226 now a blocking dependency or is it the other way around?

[Promises]

#226 will allow disabling plugins without removing them, in that way we can ship some creative stuff, but keep it disabled

[Tynarus]

Going to request "Loading cache data from plugins" be stricken from the list, as we need to further our filestore system to make something like this possible. We can split it out into a spike, what says you @SchauweM ?

[Promises]

@Tynarus Id say this whole pr is focused on loading cache data from plugins, and without that part, the way plugins work now is fine.

[Promises]

Id like to add an example layout of a plugin:

└── wintertodt.plugin
    ├── config
    │   ├── items.json
    │   ├── npcs.json
    │   └── npc-spawns.json
    ├── data
    │   ├── maps
    │   │   ├── 1.dat
    │   │   └── 2.dat
    │   ├── models
    │   │   └── burner.dat
    │   ├── npcs
    │   │   └── wintertodt_beast.dat
    │   └── widgets
    │       └── burner.dat
    ├── hooks
    │   └── wintertodt-minigame.hook.ts
    └── wintertodt.manifest.ts

[Jameskmonger]

One clear distinction I see between an example like above and our current state is that, in the example above, the configuration data is a distinct child of the plugin. Currently our config lives at the root level

I can see a risk with a setup like above where data becomes duplicated throughout the project (with everyone defining their own rs:.... for the same pieces of information)