One Native Code to Rule Them All#2951
Conversation
octylFractal
added
type:tech-debt
github-project-automation
bot
moved this to In progress
in Octy's All-in-One Task List For EngineHub
|
|
||
| @Override | ||
| protected void loadExtra() { | ||
| creativeEnable = getBool("use-in-creative", false); |
There was a problem hiding this comment.
If we're making this shared, is there a point in not just having these in the base properties class?
Realistically the cheat-mode option here is more tied to "Integrated vs Dedicated server" rather than platform too, so I wonder if it makes sense to have some separate shared config for those two
| return this.config; | ||
| } | ||
|
|
||
| protected void setupRegistries(MinecraftServer server) { |
There was a problem hiding this comment.
I am semi concerned about just how tightly we're tying it to how NF/Fabric currently work. Eg, when it comes to registries we've in the past expressed interest in moving these to platform registry events etc.
I'm just a little concerned we're going to end up in spots where it's significant work to override something on a per-platform basis because of how closely we're tying it all to current behaviour
| public Set<SideEffect> applySideEffects(BlockVector3 position, BlockState previousType, SideEffectSet sideEffectSet) { | ||
| worldNativeAccess.applySideEffects(position, previousType, sideEffectSet); | ||
| return Sets.intersection(FabricWorldEdit.inst.getPlatform().getSupportedSideEffects(), sideEffectSet.getSideEffectsToApply()); | ||
| return Sets.intersection(CoreMcPlatform.SUPPORTED_SIDE_EFFECTS, sideEffectSet.getSideEffectsToApply()); |
There was a problem hiding this comment.
Is this necessarily safe in multi-platform scenarios?
| /** | ||
| * Common adapter methods for platforms sharing native Minecraft code. | ||
| */ | ||
| public final class CoreMcAdapter { |
There was a problem hiding this comment.
Can we please have this extended on both the Fabric & NF end to reduce confusion by API users? IMO CoreMC is an implementation detail, and users should still expect a "FabricAdapter" or "NeoForgeAdapter" class to exist, even if they delegate to CoreMcAdapter
| private final SimpleLifecycled<ListeningExecutorService> executorService; | ||
| private final Map<Platform, Boolean> platforms = Maps.newHashMap(); | ||
| private final Map<Capability, Platform> preferences = new EnumMap<>(Capability.class); | ||
| private final ImmutableMap<Capability, SimpleLifecycled<Platform>> preferences = Stream.of(Capability.values()) |
There was a problem hiding this comment.
Have these lifecycling changes been tested on other platforms? (Bukkit, etc)
2 participants
One native code to rule them all,
one native code to find them,
One native code to bring them all
and in the darkness bind them.
Merges most of Fabric and NeoForge into core-mc. This new project is just Fabric without the Fabric Loader or API, giving us a clean Minecraft dependency to build off of.
In the future, parts of this may be applicable to Paper as well. However, due to the nature of their patches, it's not as easy to assume that it builds cleanly. It may be necessary to instead copy sources to Paper to be compiled against it directly, to ensure there's no missing signatures or other incompatibilities.
See
worldedit-core-mc/README.mdfor a better way to inspect the diff here.