Simplify code

[rom1504]

Might include removing behavior

[demipixel]

What kind of behavior?

[rom1504]

all of them
https://github.com/PrismarineJS/flying-squid/blob/master/doc/API.md#behaviors

I think this complexifies the code without any real usecase

[rom1504]

Well I'll probably let them be for now, but I think we should make flying squid code as simple as possible so people can jump in easily, and this is really bringing complexity.

[demipixel]

I admit, coming back to it, it is a bit clunky. It was mainly built for external plugins (based off of Spigot/Bukkit's method of handling events), however, at the moment, there aren't very many external plugins.

For internal stuff, it could be useful. For example, the vanilla feature where non-ops can't build near spawn would have to be placed in plugins/digging.js without the current behavior (as oppose to it being better placed in a spawn.js or op.js file).

I know, I pressed a little hard on making this become a reality. If we can simplify the behavior without giving up any power/flexibility, I'm totally for it.

As for general simplification, one thing that might help is a bit more organization, since /src/lib/plugins is just becoming a huge list. For example, players.js, login.js, and logout.js have very related functionality, so maybe there's a way to handle that. Also, we have a sign.js, but tons of blocks are going to need to have their own functionality (like furnaces or brewing stands), so we should also have a plugin/blocks folder or something. Perhaps whoever is loading plugins at the moment can load plugins recursively through folders. In addition:

• players.js, these commands should probably be in commands.js?
• Add a quick way to add commands. Commands.js is filled with { base: ..., info: ..., usage: ..., op: ...} whereas a quick player.addCommand(base, usage, info, fn/opt) might "simplify" the code.
• Handle arguments, pass them to parse()/action() (also pass string if they need it, but pretty much every command uses arguments).
• Allow parse() to be a regex. For consistency, we could just return whatever str.match(the_regex) returns.
• weather.js, needs some improvements (and I added the stuff above to show what it might become)

module.exports.player = function (player, serv) {
  player.addCommand('weather', '/weather <clear|rain>', 'Sets the weather.', {
    op: true,
    parse: /^clear|rain$/,
    action (args) {
      serv._writeAll('game_state_change', {reason: (args[1] === 'rain' ? 2 : 1), gameMode: 0})
    }
  });
}

24 to 9 lines (although I admit maybe have 3 strings on one line could make it harder to read). Still a large improvement. Let's get away from commands for now.

Duplicate code is a big one when it comes to simplifying. weather.js is one, another is animations.js.

Back to events for a hot sec, we have some issues referencing events multiple. For example, both placeBlocks.js and useItem.js, immediately upon receiving the block_place event, have:

if (direction === -1 || heldItem.blockId === -1 || !blocks[heldItem.blockId]) return
const referencePosition = new Vec3(location.x, location.y, location.z)
const directionVector = directionToVector[direction]
const placedPosition = referencePosition.plus(directionVector)

To simplify code, we should only listen on the _client in placeBlock.js and have useItem.js listen for the placeBlock event on a player (or we need some kind of other wrapper for _client events).

[rom1504]

rationale for not having behavior can be found in discord flying-squid chat of 24/10/2020
However PrismarineJS/prismarine-design#1 may come first