@shartte https://github.com/AEModernMCPort/Applied-Energistics-2/pull/75#issuecomment-241380201
I thought about FeatureFactory, but have still not made up my mind about the interaction between Registration, FeatureFactory, and ApiBlocks. I think we first need to decide whether we keep how the API is currently exposed to Plugins or not. If we decide to do anything differently, I'd do that in a subsequent change.
Regarding the long lambdas: Agreed, should go with method references in those cases.
Energy Cell: We can clean that up, but that was not introduced in this PR, so I would do it subsequently.
> @yueh https://github.com/AEModernMCPort/Applied-Energistics-2/pull/75#issuecomment-241382857
> No idea about the API, too. But mostly about the external part. Like should we keep a static instance() or inject it into any mod annotated with @AEAddOn and let them deal with it.
> There might be even some issues as AE disables certain items after the registration, when they are already present like silicon.
> But honestly I have no idea, if there might be issues. It is probably nothing anyone ever used.
>
> Clearly offtopic, but I have a particular large backlog of what would still be needed in general for AE.
> But I am not really convinced about how to handle it in terms of project management. Like adding all issues here is not really the option once we merge it back and could loss that information or at least be in an inconvenient location
> @shartte https://github.com/AEModernMCPort/Applied-Energistics-2/pull/75#issuecomment-241383813
> Regarding the API: I checked out what JEI does and it does seem elegant. They use the FML provided ASMTable to find all classes in all all mods that are annotatd with @JEIPlugin and then instantiate them, and pass the JEI API instance to the newly created instance.
>
> Right now the biggest issue with the static instantiation is the fact that when the API is instantiated, it creates the block/item definitions, and that currently needs access to the FeatureFactory to build the bootstrapping tasks. This also immediately breaks once something outside of AE accesses the API before we do pre-init, because the config is not loaded at that point.
>
> Removing the static access to the API and instead opting to expose it to plugins once we have explicitly initialized it would solve this. But if possible, I'd like to separate something like that from this PR and discuss it separately, since it does have bigger implications. AE itself uses the static API entrypoint extensively and that would also need to be changed.
> @yueh https://github.com/AEModernMCPort/Applied-Energistics-2/pull/75#issuecomment-241394134
> The instantiation part might be a bit tricky due to how broken the class loading with forge can be. It works for JEI because it a special plugin and not a normal mod. Also the object can be thrown away afterwards as it was only used to register recipes (it more similar to our own registration process).
> We probably need something like @AEAddOn to indicate a mod is an AE AddOn and require them to implement something like an AEApiConsumer, who gets passed the API after it is constructed. As the addon needs to keep a reference to it, we cannot really construct that class and leave it to the GC and hope the addon dev somehow ensure that the reference is not lost.
>
> The general process should probably be
> 1. Load config
> 2. Bootstrap API according to the config
> 3. Announce API publicly
> 4. normal pre/init/post part
>
> Having the blocks/items as part of the API also allows addons to rely on them being there, without having to resort to some loading order conflicts/magic when a mod needs to be loaded before AE for whatever reason but still depend on some AE2 parts.
>
> The only issue I would see with is, is the removal of duplicate items. If I am not completely wrong, it is done during post init.
Elix-x
commented
7 years ago
From #75...