Preface

If you don't know what this library is, here's a quick rundown:

FallFlyingLib is a lightweight library to provide compatibility between mods that implement Elytra alternatives. This library takes inspiration in PlayerAbilityLib.

Bad Mixins and Callbacks might make a Elytra alternative stop working. This library exists so that all modifications can be made from a single place.

This issue is meant to discuss the imminent rewrite of the FallFlyingLib. This library is due a rewrite since a few days after it was written.

Regardless of the outcome, Version 2 will remove the "hide capes/elytras" methods. This will most likely be moved into a "PlayerVanityLib" or something alike, but is out of the scope of this conversation.

The topics below handle different parts of the library, and can be implemented regardless of other topics in this same discussion.

And lastly, discussion and opinions are more than welcome here.

Topic Nº1: Extend PlayerAbilityLib?

Making FallFlyingLib a PlayerAbilityLib was already considered, discarded, considered again. This approach has it's pros and cons.

The pros:

• A lot less code to manage in general.
• A cleaner, already known code interface.
• It would force the fall flying ability to be cached in advance instead of pulled every tick. And that probably is faster.

The cons:

• FallFlyingLib would be required to implement it's own client-to-server synchronization.
  • PlayerAbilityLib interfaces are server-side. This means that most likely FallFlyingLib interfaces would be server-side as well.
    (Trying to use PlayerAbilityLib in client-side results in a exception!)
• Compatibility with Vanilla and Mixin-based Elytra mods would probably suffer even more.

Topic Nº2: Overwrite Elytra behaviour?

While a really controversial thing to do, this would let FallFlyingLib have greater control of the code, and implementing clean-room solutions instead of hacking a broken solution.

Currently, the latest branch of FallFlyingLib sorta does this overwrite, but this version wasn't published.

Just for clarification: The overwrite isn't a @Overwrite but a @Redirect on the initAi method call at the tickMovement function.

The pros:

• Solutions can be implemented with actual clean, decent code.
• Fixes and compatibilities with other mods can happen at library level.

The cons:

• Vanilla Elytra behaviour would have to be implemented back in.
• Mods which don't use FallFlyingLib would just break.

V2 is here 🎉