• Publish PR to GitHub Packages

Last commit published: d2b5348857ba3b5c9d0f134f8f2c35be833cba29.

repositories {
    maven {
        name 'Maven for PR #1167' // https://github.com/neoforged/NeoForge/pull/1167
        url 'https://prmaven.neoforged.net/NeoForge/pr1167'
        content {
            includeModule('net.neoforged', 'testframework')
            includeModule('net.neoforged', 'neoforge')
        }
    }
}

mkdir NeoForge-pr1167
cd NeoForge-pr1167
curl -L https://prmaven.neoforged.net/NeoForge/pr1167/net/neoforged/neoforge/21.0.48-beta-pr-1167-pr-experiment-flag/mdk-pr1167.zip -o mdk.zip
jar xf mdk.zip
rm mdk.zip || del mdk.zip

I'll admit I'm mildly confused what this feature flag is supposed to be for -- and it definitely needs a better description in-code so modders know when to use it. Is it just a generic catch-all for "experiment" stuff within mods? How should a user know what to expect if they turn it on? What's an "experimental mod item" and how does it differ from a normal old experimental mod feature which is off by default but enable-able via a config? I'm not saying I'm entirely against this idea, I just think it's not at all clear -- to modders or to users -- what the flag is actually for as described in code and in-game descriptions.

PR has been updated to include javadocs and testmods, it also now depends on #1187 to allow generating the testmod & neoforge builtin packs better

Thanks for adding the docs. My opinion here, for whatever that's worth, is that:

• I would like more clarification within this PR about why modders can't use configs to solve the issues this can solve -- currently that part isn't really clear, and you can do a lot with configs nowadays. Furthermore, if there's only a few things that are the sticking points to using configs, it may be worth looking into if we can make it possible for modders to have more control over those things through a different approach. So documenting the limitations is important.
• in my opinion, for this to be useful at all there should be a neo-provided way for modders to tell users what things that flag will enable for that mod, instead of relying on each mod documenting it however -- at the absolute minimum in a nice summary view somewhere in the log or something, but preferably somewhere the user can see when enabling the flag. Not sure how possible that is. Without some system for this, you're expecting every mod out there that uses this to, like, listen to the server starting, check for the feature flag, and log some info if it's enabled which is a lot more complicated than just logging on config load or whatever.

I would like more clarification within this PR about why modders can't use configs to solve the issues this can solve

The issue with configs is they can be set via a modpack, which is not ideal for something which should have some user input/confirmation. Users should be changing the state of feature flags not third parties.

you also cant simply override isEnabled to return a config boolean value
as that causes all kinds of desync issues, look at my original PR it attempted to do this and failed

FeatureFlags also have abunch of short circuiting if statements and checks throughout the game, making things like recipes, tickers etc not register/be ignored for disabled elements, which would be a pain for modders to have to implement via mixins and such for their configs

in my opinion, for this to be useful at all there should be a neo-provided way for modders to tell users what things that flag will enable for that mod

its possible to build a list of what elements require a specific flag, but i dont know how useful that would be to a end user, other than that afaik theres not much else could be provided to user

the experiments screen doesnt have enough context to provide any meaningful information, nor can it be given any more information than it already has afaik

but if this is preferred i could maybe look into having a tooltip shown or log flagged entries to console

Logging entries is, imo, a bare minimum if the flag is meant as a non-mod-specific catch all. Otherwise any crash report modders get with it on is useless cause we don't know if other mods are doing experimental stuff. Still a bit confused about why configs can't be used -- to address some of your points, if a mod pack is enabling something that the config says it probably shouldn't be, that's their issue. There's probably a mod out there to automatically enable feature flags too, for folks wanting bundles in their modpack or whatever. Any sort of datapack stuff can totally be controlled by a config without issue -- just use an overlay in the mod data with a condition controlled by the config. Besides that, is the issue one of syncing what stuff should be considered enabled? Given that doing the same sorta thing that feature flags do there, given a server config, is a common use case outside of experimental features, it may be worth looking for a more general solution there. Wanting to enable/disable an item or group of items based on a server config setting isn't an uncommon use case.

Still a bit confused about why configs can't be used

So, there are a few reasons, and the TLDR reason is that it is SCATTERED through MC's handling requiring a mod dev to basically reimplement all of feature flags to get sorta the same functionality:

• In order to disable a block/item, you typically need to override isEnabled. this affects placement and interaction logic, but this is called also during data gen to use a particular feature flag to ensure everything is generated for a particular set of flags. Because of that, it becomes a rather non-sensical thing to try to move from that point, as the goal is to have a per world config (so in this case a server config) and that isn't generated at the time of data gen (since there is no world) where as a feature flag is, and the system can inquire, based on a flag if it should generate the loot. This however, does not work for things by just saying "false" as files are missed in generation resulting in errors in generation. Now a mod dev needs to, not only override the method and plug in their config, but now also handle some arbitrary data gen step for genning files that respect an arbitrary config. This includes things like drop tables from blocks, entities, but also recipes and other acquisition methods.
• Disabled blocks/items via the override are not necessarily hidden from Creative menu. This is something that the flag handles automatically, but without, the mod dev needs to do special casing on those items.
• Recipes are either always generated or now need a mutation to support this generation as mentioned from before to listen to a config. Feature Flags because they generated with the isEnabled(set) pull a set of data relevant to the flags.
• I haven't looked deeply on how, but feature flags also prevent /give from even auto completing your item.
• Likely several other places I haven't looked into

While I would adore a requiresCustomModFlag(MyFlag) or even requiresModSpecConfig(MyBooleanConfig) that is not something that is as trivial as you are I think assuming. Genuine question, have you tried using a feature flag on the mod side. While configs are indeed powerful, you are asking basically a reimplementation for each modder who would want this, and that is a rather involved process not just a few lines.

What I believe is the right approach. Have a persistent flag in Neo that is disconnected from vanilla's flags as a start. Then eventually a config or Modded Feature Flag (separate mirrored system) like approach for being able to use a config or similar as simple to use as a feature flags, on top of this PR. The two systems are not mutually exclusive and would solve a problem more immediately with this. I've tried to use configs multiple times to solve this problem, it is non-trivial. Especially when compared to adding or removing requiredFeatures(EXPERIMENTAL_FLAG)

I do understand the concerns you have, but the alternatives are either use bundles (which people are already abusing), or to use a "config system" with no actual implementation thought up passed a conceptual "configs are powerful" and seemingly no actual understanding of what all a FeatureFlag provide. If you can provide a neo built in solution that is requiresConfig(MyConfig) then the config argument has a lot more merit, but a persistent flag is still useful.

It should be possible to abuse the isEnabled checks to disable something based on a config.

Go ahead. If you can match the result of a feature flag 1:1 them I'm for it, but after trying multiple times and trying to explain that it is not that simple, I'll let you experiment 😂

The issue with configs is they can be set via a modpack, which is not ideal for something which should have some user input/confirmation.

What specifically about this PR is actually going to stop a pack maker from force enabling the flag with a tiny mod shipped with the pack and thus, impose the “experimental” features on users? Once they learn there’s hidden content behind a toggle, they will get a modder to make and release a mod to turn on the flag. Now they have all the features on and no way to pick and choose what they specifically want.

I don’t see this going the way you all want it to go. The whole premise of this PR hinges on that

a. Players and packmakers will actually listen or read the warning and not use it. You’re putting so much effort into telling players to not use it that, just don’t add it in first place

b. That modders will actually use it for truly game breaking experimental and not Easter Egg/stable pre-release of features. Because when they do so, players and pack makers will try to get those stuff.

c. And that actual modders and play testers want ALL possibly broken experimental stuff enabled in a modpack. This makes Mod A testers testing mod compatibility of the flagged stuff from Mod A next to impossible if a bunch of other mods in the pack has broken features that break the world.

I don’t see actual benefits. Just footguns everywhere

We should probably do a quick feasibility study on how hard it would be to write our own, more dynamic feature flag system (that does not need to load before registries), and then patch it in everywhere that vanilla's is currently called. If that is not very many patches, there is no reason not to just do that, and have proper mod-specific feature flags, rather than dealing with the compromise of a global flag.

I really don't think this is useful.
As a player, I have no idea what this enables or disables, so why would I ever enable it?
Even if a modder tells me "If you want X, enable experimental mod features!", how would I know that doesn't enable 20 other experimental features from other mods that I would not want?