Doomsday Engine

I've been wondering if Dday should remove Snowberry from the very first 1.16 unstable build, irrespective of whether all of it's features are easily accessible via Ring Zero or the Taskbar (all of Snowberry's features are accessible in some way by Dday or the command line)? There are some features of Dday I wouldn't suggest doing such a thing with, but I debate that with this feature and it's 'state', that it might be beneficial?

To give the new UI a public testing so to speak; currently I think Snowberry means that 99.9% of users will completely bypass Ring Zero and the Taskbar.

I have to admit that I'm not sure under which tracker issue that discussion on dropping Snowberry belongs?

Dropping Snowberry is (IMO) the single most important near-term milestone that we've yet to reach. Its not simply a case of some users having trouble with it. Until we get rid of Snowberry the majority of users will bypass the home screen, not encounter the task bar and consequently overlook the majority of what we've been working on over the past few years. Snowberry has now long overstayed its welcome.

The fact that several add-on formats are only understood by the front end (!) is a significant hurdle. While one can argue that Snowberry is already unnecessary and can be skipped, this rather depends upon the add-ons you use. The average user does not understand how to repackage add-ons like the jDRP so they can be used without Snowberry. Therefore, using Doomsday without Snowberry is not an option for some people. (Logically speaking, Doomsday is currently dependent on Snowberry, meaning its not accurate to describe it as a "front end" as such).

danij wrote:

The fact that several add-on formats are only understood by the front end (!) is a significant hurdle.

I fully understand where yourself is coming from with this, but I also think it needs to be noted that the only released mods, that I can think of, that ever used these formats were the three main model packs?

These could probably easily be re-packaged as standard pk3's with additional smaller pk3's for the optional alternate models offered by a couple of them?

I think the Snowberry specific add-on formats could be pushed way down the list of requirements (i.e I would separate supporting them from loading standard pwads and/or pk3's and move it far far lower down the list of priorities with the UI.

Snowberry’s predecessor Kickstart also had its own add-on format (ksa files). Neither Snowberry or Doomsday itself has ever added backward compatibility support for that (i.e something like a decade later or so) and there has never been any issue raised by users to my knowledge.

This is because it was only used by a couple of released add-on’s in its time (as far as I am aware), one of which was the Doom model pack, which was updated to a Snowberry add-on format, which as mentioned above, has in hindsight, been similarly underused.

The point I’m making is, consider cutting the Snowberry add-on formats completely, as an un-successful evolution and don’t worry about supporting them in modern Dday (not to say Dday shouldn’t try a new add-on format again in future of course)?

vermil wrote:

I've been wondering if Dday should remove Snowberry from the very first 1.16 unstable build, irrespective of whether all of it's features are easily accessible via Ring Zero or the Taskbar (all of Snowberry's features are accessible in some way by Dday or the command line)?

I agree with both of you that Snowberry needs to go soon. In practice the way I see this playing out is that we just remove it from the unstable builds (of the next stable release), accept that certain addons will be temporarily unavailable (in a GUI-only usage scenario), and then start rebuilding the required features into the engine.

Naturally we can't release a stable version without Snowberry until all the major addons are again supported. However, I don't see adding support for the Snowberry bundles as a major obstacle -- after all, they are mostly containers for PK3s with some lightweight configuration.