flying-squid icon indicating copy to clipboard operation
flying-squid copied to clipboard

Make internal plugins optional

Open rom1504 opened this issue 10 years ago • 2 comments

See https://github.com/PrismarineJS/prismarine-server/blob/master/example/server.json#L37

rom1504 avatar Sep 01 '15 19:09 rom1504

I think voxel plugins are really nice https://github.com/deathcap/voxelmetaverse/blob/master/index.js They have a loadAfter for dependencies which is nice https://github.com/voxel/voxel-furnace/blob/master/furnace.coffee#L11

Making flying-squid closer to this modular model would be really nice.

rom1504 avatar Jan 19 '16 22:01 rom1504

Maybe could use the voxel plugins system https://github.com/voxel/voxel-plugins directly? I haven't tried using it for other purposes outside of voxel.js (except in the test suite), but it doesn't have any actual voxel engine dependencies, could possibly be used independently if it makes sense. Or if it could be generalized further, I'd be interested in having something in common for both voxel.js and flying-squid if there is interest.

The other main benefit of voxel-plugins besides the loadAfter dependency topological sorting is enable() and disable(); it is modeled somewhat after Bukkit plugins with onEnable/onDisable, except my goal was from the ground up to support enabling/disabling all or most plugins, in order to allow more dynamism during gameplay and development/administration. There are some complications loading arbitrary plugins remotely in the browser (including the browserify build step), but on the server-side I think this would be easier, server administrators could easily /enable or /disable or /reload plugins etc, through this common interface. voxel-plugins also has the notion of plugin configuration, which is just JSON, like you have here: https://github.com/PrismarineJS/prismarine-server/blob/master/example/server.json#L39-L42

deathcap avatar Jan 29 '16 18:01 deathcap