Add ability to override "IS_RUNNING_IN_IDE".

[Mickey42302]

I would like to suggest adding the ability to override the "IS_RUNNING_IN_IDE" flag using a system property. Being able to override this would allow players to explore functionalities that are hidden within the game's code.

The patch file I created adds a "paper.enableDevFeatures" system property. When this is set to to true via a startup script, the "IS_RUNNING_IN_IDE" flag will be set to true. This causes a bunch of features to be enabled, including ones that don't have a debug property assigned to them (such as the export sub-commands for "/test").

[Toffikk]

this is missing // Paper comments and also should be condensed into a file patch

[electronicboy]

Also, not really fond of this being called dev features, there is a whole bunch of stuff that could be considered a dev feature and so this is just too loose

[Doc94]

maybe a name most related to the var to change... (the IDE thing) like markUsingIDE, setRunningIDE, debugIDE etc

[Toffikk]

maybe something like enableIdeFeatures? or enableIdeDebug

[Mickey42302]

That sounds like a good name. I also had the idea of naming it "paper.overrideIDEFlag".

[Owen1212055]

Personally, I do not really see the point in this. This behavior is largely undocumented, is there an actual use case that you want here? Rather than just wanting to "explore".

A lot of this logic just opens up break points for debugging.

[Mickey42302]

The use case would be to get access to hidden functionalities that could be helpful, not just break points.

For example, the export sub-commands for "/test" can be used to export structure data to SNBT files. If the "IS_RUNNING_IN_IDE" flag is set to true, you will also be able to use the files with "/place template" (https://github.com/Mickey42302/JavaEditionDevTools).

[Malfrador]

Looking through the usages of it in 1.21.10, there doesn't really seem that much anymore that is hidden behind the IDE flag and not the debug properties.

However its a very small patch and system properties are not really exposed to end-users, so the chance of someone accidentally turning it on are essentially zero. So I personally think it wouldn't hurt to add this, even if it only helps like two people in the end.

[lynxplay]

I don't think "adding for the sake of adding, it is small lol" is a good argument for a flag.
If e.g. the test subcommands are not behind a debug flag (they aren't) we can expand mojangs debug flags here instead.

[Mickey42302]

Yes, that is true. However, as Mojang continues to develop the game, it is very likely that more hidden features will appear in the code. Having a flag which can be used to override "IS_RUNNING_IN_IDE" would make things easier for everyone, as you won't have to code a debug property for every single feature.

Some users may also prefer to have all of the debugging functions enabled, as they can be very useful for content creators/developers.

[jpenilla]

I still agree with lynx and owen, there is not sufficient justification to add this as is. Similar requests have been denied by other modding platforms in favor of specific flags as well.

[Mickey42302]

One of the reasons why people use software like Paper is because they want to be able to customise things to their liking. If someone wants to override the flag, they should have the freedom to do so. Since Mojang is now planning to remove code obfuscation too, it is very likely that more people will become interested in the functionalities hidden within the game's code.

The patch wouldn't do any harm; it only adds a system property. The reason why I submitted the pull request to Paper is so that it could benefit a wider audience. There are lots of projects which are forked from Paper/have Paper built into it.

[lynxplay]

I am all of customization but what you are suggesting is less customization than extending the debug flag system.
You are proposing a single toggle all flag, meaning consumers cannot enable single debugging concepts on their own.

E.g. I only want to enable the export sub commands of the test feature.
Flipping IS_RUNNING_IN_IDE now also does stacktrace walking in profiler runs, might log random warnings about weighted randoms at 0 and whatever else mojang has behind this flag.
The already started moving things behind the debug flag feature, sticking to the single boolean has only 1 advantage: You can be a little lazy when selecting what debug feature you want. Everything else is a downside in my opinion.

[Malfrador]

I like the idea of expanding the debug properties instead. Mainly for the test export feature.
If you want to enable all, the game can print out all flags when starting with -DMC_DEBUG_PRINT_PROPERTIES and you can then just copy/paste.

So assuming everything relevant is behind a debug property, I don't see a reason for IS_RUNNING_IN_IDE either anymore.

[Mickey42302]

Adding more debug properties may be a good idea. Some users may only want certain features.

I still think that the system property should be available as an alternative, though. Even if you do add more debug properties, the game will still have code that checks if "IS_RUNNING_IN_IDE" is true. There will always be people who want the full suite.