Should hidden levelsets be visible with Developer Mode?

[provigz]

Releated to #2140.

Currently, levelsets that have hide-from-contribs set to true, are not visible in contrib levels, which is great. But what about developers or more advanced players? They may want to edit one of the Story Mode levels, gain access to the "Test" and "Misc" levels, etc., without having to edit the info file of each levelset. This should make it easier for them. Do you find this idea good, and do you have any further suggestions on how it should work? Awaiting your feedback. Thanks!

[Semphriss]

Personal opinion: Levels that are meant to be hidden from contrib levels have this option enabled because it does not make sense for them to be displayed at all. Most of the hidden levels are either not meant for user usage (test levels) or are available elsewhere (main menu level, story mode). Users who wish to open and edit those manually mean to edit the game, which is relevant for modders and game designers; those should have no problem with navigating in the game files, so having them to either a) edit the world info files, as described, or b) copy the world folders to their local data folder manually, or c) invoke the game from the command line to edit levels shouldn't be a problem.

Related: Should add-ons be displayed in the level editor? (This might be better suited in a separate discussion)

[provigz]

Most of the hidden levels are either not meant for user usage

Developer mode isn't meant for regular users anyways, but rather more advanced ones or developers. Not sure if it's a problem, maybe you mean that the levels also aren't suitable there, even with that in mind?

Users who wish to open and edit those manually mean to edit the game, which is relevant for modders and game designers; those should have no problem with navigating in the game files

I agree with this, but having them accessible from developer mode makes it a little easier to access them (in my opinion).

[Semphriss]

Developer mode isn't meant for regular users anyways...

If developer mode wasn't meant for regular users, it wouldn't be in the game.

...having them accessible from developer mode makes it a little easier to access them...

Editing the Story Mode or playing a test level is not a daily operation for an end user. Which exact use case warrants increasing convenience to that extent?

[Zwatotem]

If developer mode wasn't meant for regular users, it wouldn't be in the game.

I don't think this reasoning makes sense in this case. Mind that the game is still in the early access. There is a lot of bugs, and developer mode helps diagnosing them to regular users or overcoming them, instead of waiting for the fix and playing on nightly. Of course bugs are not meant to be there for regular users and they are still there 😄.

Developer mode as the name suggests is ment for developers, (so I would say not only programmers, but all contributors) and it helps them do their job more efficiently. I know there are other ways, to get to hidden levels, but there are really other ways for all of things, that these tools provide, it's just that it's more convinient that way, and we value our time.

I also think it would make less potential level contributors from resigning out of frustration.

Finally a little detail: you wont forget to switch back hide from contribs flag if you never changed it in the first place.

[Semphriss]

Mind that the game is still in the early access

Two things:

1. Let's settle this once and for all: It isn't. Does it feel like so because the version still has a leading 0? Or is it because the Steam version is marked as such? Because from a user experience POV, I can guarantee you that SuperTux is not an "early access" - people even scolded us about it¹. We have plenty of users, we have plenty of features, enough so that everybody can enjoy it to the same extent as any other complete game. SuperTux hasn't passed 1.0.0 yet because no developer had the gut to declare that SuperTux is a complete product, which it is already. But ever since Milestone 1 was released, SuperTux is very much a complete product. Looking at the amount of people talking about 0.1.3 - the scale of the distribution alone should show that SuperTux is already well established. SuperTux isn't the only project with this problem, and this is very much a problem (this website will explain it better than I ever can).
2. A simpler one: If we want SuperTux to be an established game once again, then we should develop towards a stable game, and not use the main repo as a sandbox - that's what personal forks are for. Not against you, but I find it particularly annoying when bad design is covered up under the easy excuse of "but it's still in development so it doesn't matter ¯\_(ツ)_/¯", that mindset just justifies any bad design decision and it harms stable progress for the game.

¹:

Of course bugs are not meant to be there for regular users and they are still there.

I'm not sure how that compares with the current proposed feature. Bugs are meant to be removed, not added... Is it because not being able to access certain level files is buggy behavior? I doubt that would be the case, given the key is called "hide-from-contribs"... Or is it in comparison with the hidden worlds themselves? But once again, the solution that corresponds to "remove a bug" would be to remove the worlds...

Developer mode as the name suggests is ment for developers

Let's be real: Who does not enable developer mode? Level designers do, speedrunners do, even the average user may want to.

Developer mode is called as such because (I presume) originally, developer mode was indeed meant for developers. However, over the time, the "developer mode" grew to be more and more useful even for the average user; may it be the cheat menu, the debug menu (collision checking), or mostly, the console: Who didn't feel it was weird to not see that message in the console when a level was saved?

If the developer mode was meant only for developers, then it wouldn't be included in widely distributed builds. It'd be restricted to Debug builds, or there would be a CMake kill switch for it. The absence of such a switch shows it: this feature can and will be used by everybody. Therefore, either it should be designed with everybody in mind, or, if we really don't want the public to use it, it should be retracted from public access. (Needless to say, I would highly object to retracting a feature that users could already enjoy for years.)

I also think it would make less potential level contributors from resigning out of frustration.

It would be interesting to see how frequently that happens. I don't contest their existence, but generally speaking, when fixing a problem, it's easier to do when we can get feedback from the people who encounter the problem.

Finally a little detail: you wont forget to switch back hide from contribs flag if you never changed it in the first place.

You will, however, forget to undo all your changes on those levels. Remember that SuperTux doesn't have Git bundled in it, so there's no turning back after edits are saved.