Open Promises opened 3 years ago
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.
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.
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
Is #226 now a blocking dependency or is it the other way around?
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 ?
@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.
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
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)
Game Engine Feature Description
Acceptance Criteria
Additional Information