Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Yes

No

Other (leave comment)

Not sure

[voliol]

This is a thread about specifically changing the wiki's namespace/starting a new one for the Premium release. The main thread for discussing how to improve the wiki is here.
If you don't bother reading all this there's a TL;DR at the bottom of this post.
Preface: I've been involved in the DF community for some 6 years, all of which I have used, and several of which I have edited the wiki. However, I am not an admin of the wiki, nor was I present when some decisions were made. If you are/were and I am clearly wrong, and I hope you understand it stems from ignorance rather than malevolence. Also, do reply.
If you ever used the Dwarf Fortress wiki, you might have noticed that the article you were looking at had its name prefaced by "DF2014". This is a so-called "namespace", a designation by the wiki describing what kind of article it is, in this case one related to the set of DF versions called "DF2014". There are other kinds of namespaces as well, for e.g. mods and tutorials. The users, files, wiki templates and categories also technically exist on their own namespaces. But for the sake of simplicity, "namespace" will from now on refer to the version-related namespaces, and only them.

There are five namespaces used for articles in the DF wiki: 23a, 40d, v0.31, v0.34, DF2014. By tradition, these all correspond to a subsequent set of DF versions that are backwards compatible; if you were to start a save in the earliest version of the namespace, and transfer it to the last version, it would still work. Of course, some features may not work perfectly when doing this, but you can still open the save, without horrible horrible corruption*. The upside to having these namespaces on the wiki is pretty clear, if anyone ever wants to play an older version of DF, they can still use the wiki, as it preserves old info. That said, each namespace should encompass about as many minor versions and range over approximately as much time, as each other. Let's see:


Hmm...

Spoiler: an extra graph (click to show/hide)

Oh. Oh...

Let's talk about DF2014. July 7, 2014 the "world activation" release came out. Suddenly, the world would be active even past world-gen. Wars, successions, births and deaths continued as you played. You could even retire and unretire your forts! As it was a major release, which broke save-compatibility, a new namespace was created on the wiki: DF2014. The release was well-awaited, and people updated the new namespace accordingly. As the years went on, new releases were dropped, all bringing features of their own; 0.42, 0.43, 0.44, 0.47. But even as this namespace grew bigger than any before it, no new namespace was created. After all, none of the new releases broke save-compatibility, and that the criteria for a new namespace, right?

Let me be frank, the wiki is currently in quite a dire situation. There are multiple reasons, such as it being hyped up too much, and these (and how to solve them) are discussed in the main "Let's fix the wiki!" thread. However, from my own observations, and experiences in editing the wiki, one cause is bigger than most of the other: the curse of the DF2014 namespace. Simply put, a lot of things has changed over the years, and they are all crammed into DF2014. As a wiki editor, you have to add whatever is new, but also preserve how it worked in previous versions; the DF2014 namespace must encompass all those versions, after all. This is a pain. Sure, there are wiki templates to mark the articles up, telling the reader what version the feature was added/changed in. I am not opposed to them by principle, but the over-usage of them creates a very messy wiki, that is tricky to read.
There is a reason the namespaces were created in the first place, it is to ease the editing process, and make the articles cleaner. Lets admit it, we have failed to keep up with that reason, instead relying on the "didn't break saves" mantra. It worked well to begin with, but the namespaces were never supposed to survive this long.

At this point, some of you might have discovered a discrepancy in my graphs, probably those of you who looked at the extra graph under the spoiler tag. That's right, I'm only counting the days between the first and the last version that belongs to the namespaces. A more accurate representation of the longevity of the namespace would be the time between their first release, and the first release of the next namespace. The ridiculously short v0.34 gains another 2 years this way.

Spoiler: for the curious (click to show/hide)

But when is DF2014 going to end? Using the current criteria, after the Big Wait. During the Big Wait, Toady will work on the Myths&Magic release, but also a map rewrite. This map rewrite will finally break the saves, and so a new namespace will have to be created. The Big Wait comes after the villains 2 + army release(s), which comes after post-Premium stress fixes, after the initial Premium release. Let's estimate that to an optimistic three years, two for the Big Wait and one for the rest. Insert the numbers and...

Frig.

Premium also brings its share of problems: non-ascii graphics, new players, and a gui rewrite.
Considering the non-ascii graphics may very well become the main way of playing, the wiki should reflect this by using images from Premium along with the ascii ones. However, having these non-ascii graphics on pages equally meant for pre-Premium DF2014 would be strange.
Regarding the new players, I believe they will like the wiki. Even as I criticize its current state, it is a very useful tool, especially for teaching the basics. I am very hyped about this, as new players => bigger community => more possible wiki editors**. However, there will be confusion surrounding the "old version" templates. After all, there's no reason to believe older versions will be released on the Premium platforms, so for them 0.40-0.47 will all be pre-release versions they have little interest in. Of course, the wiki should not be exclusively for Premium newcomers, but it should recognize their needs.
But perhaps the biggest challenge to the DF2014 namespace is the gui rewrite. While it is at my time of writing this unknown exactly what the gui rewrite will entail, I think it is safe to assume, that at least half of the articles referring to gui features would have to be rewritten to ways that covers both the old and the new keybindings. It would be confusing to the new players, and frustrating for those wanting to play an older DF2014 version.

But it doesn't have to be all bad. With the premium release, we have been presented with a great starting point for a new namespace. Is not a full graphics rewrite and a release to two new platforms more significant than a mere save-breaking update? Do updates that break save-compatibility matter at all anymore? Well, probably yes, but we should have a new namespace for Premium. Creating a new namespace then also solves the issues Premium brings; post-Premium graphics will only be in the post-Premium namespaces, new players won't be bothered by version-specific markdowns if these don't exist in the namespace they are using (at least initially), and the gui won't have to be explained twice.

All that said we should also reconsider the criteria for creating new namespaces, so the circumstances don't repeat. I personally think the first Myths&Magic release should be worthy of a new namespace, but I don't really have any general thoughts on this.

TL;DR:

• The DF2014 namespace is already older and more massive than the other wiki namespaces.
• This is because a new namespace is only added when save-compatibility is broken.
• Because of this, it is difficult to edit/update.
• This will get even worse if we wait for the Big Wait to end.
• The new Premium players should get a fresh start.

So we should:

• Start a new namespace with the release of DF Premium.
• Reconsider the criteria for starting a new namespace.

*The 23a namespace does not adhere to this rule, it has multiple save-breaking versions within it. Instead, it encompasses the earliest days of DF, the 2D versions. Some corruption bugs in early v0.34 and DF2014 also broke saves, but these were fixed within weeks of the initial new-namespace-release.
**I am also hyped for all the other goodies these new community members will come up with: stories, mods, and art. But that is beside the topic of this thread.

[voliol]

[Reserved]

[Starver]

For my part, I don't see a problem with the suggestion.

Though the two approaches I see being useful give different kinds of work to maintain:

* DF202x namespace pages feature SomethingAsSteamGraphics.png alongside SomethingAsVanillaGraphics.png as illustration of every (trivial) feature (entire screenshots might be exemptable?). Or, where the latter is text anyway, like the standard "stockpile and use" montage illustration inthe top corner of a material page, PNG and as-is. This so neither usage-base has to go to too much effort to understand the other format. (May even encourage cross-migration in both directions.)

* Much as there is a "Simple" wikipedia based off the standard one, provide DF202xSteam and DF202xVanilla as information mirrors (a lot of automation is possible, if only minor pandering-to-the-other-group alterations need to be made, and calls to maintainers to check-and-resolve necessary synchronies). With no judgement made as to which is the 'Simple' one, as arguments can be made either way.


I think the former, but it may be too busy in places.

My reasoning is that we don't anticipate much functional difference between both DF202x(Whatever) gameplay variations other than graphics. But although we haven't catered for any particular (or set of) popular 3rd-party tilesets, there is going to be two distinct visual requirements atop the Quick Start Guide, the aforementioned material-appreciation page or a creature guide. Entirely new splits may need to be considered in actual tileset explanations (though maybe symmetric "<this> <equivalent to that> <description>" lines could work where it's not too much one-to-many in vanilla (probably).

It's work any-which-way. But apart from entirely splitting support wikis amongst relative devotees (or letting a Steam Community one organically arise from scratch, with heavy cribbing allowed), which is even less efficient a way to deal with it, I can't see any way to do it without disadvantaging whole swathes.


On the basic question of "it may not be save-breaking time, but it's long overdue for at least psychological reasons", I definitely agree anyway.  For this reason, I don't propose dualling DF2014 and DF202xSteam (or a variant of the latter name) as parallels, if using the paralleling option. Start afresh as we mean to go on.


(ETA: Final suggestion - actually don't use DF202xWhatever name for namespace. Like Microsoft basically abandoned year-labelling (after Windowses '95, '98, maybe Millenium and definitely 2000; though Office and other suites continue/continued longer). Because some (later) new users arriving to the brand in 2022 or later might be put off by a 2020/2021-named version, for example, whatever the timepoint involved, not yet knowing that the latest non-minor tweak was perhaps only a week ago - hence why it came up on their radar in the first place and went Wiki-browsing.)

[voliol]

Though the two approaches I see being useful give different kinds of work to maintain:

* DF202x namespace pages feature SomethingAsSteamGraphics.png alongside SomethingAsVanillaGraphics.png as illustration of every (trivial) feature (entire screenshots might be exemptable?). Or, where the latter is text anyway, like the standard "stockpile and use" montage illustration inthe top corner of a material page, PNG and as-is. This so neither usage-base has to go to too much effort to understand the other format. (May even encourage cross-migration in both directions.)

* Much as there is a "Simple" wikipedia based off the standard one, provide DF202xSteam and DF202xVanilla as information mirrors (a lot of automation is possible, if only minor pandering-to-the-other-group alterations need to be made, and calls to maintainers to check-and-resolve necessary synchronies). With no judgement made as to which is the 'Simple' one, as arguments can be made either way.


I think the former, but it may be too busy in places.

My reasoning is that we don't anticipate much functional difference between both DF202x(Whatever) gameplay variations other than graphics. But although we haven't catered for any particular (or set of) popular 3rd-party tilesets, there is going to be two distinct visual requirements atop the Quick Start Guide, the aforementioned material-appreciation page or a creature guide. Entirely new splits may need to be considered in actual tileset explanations (though maybe symmetric "<this> <equivalent to that> <description>" lines could work where it's not too much one-to-many in vanilla (probably).

It's work any-which-way. But apart from entirely splitting support wikis amongst relative devotees (or letting a Steam Community one organically arise from scratch, with heavy cribbing allowed), which is even less efficient a way to deal with it, I can't see any way to do it without disadvantaging whole swathes.

I did not think of the second option, and while it has its merits I believe it shouldn’t be necessary. In addition to the graphics, the few remaining Premium-exclusive features should only require articles of their own, with mentions on already existing ones. One about steam achievements, steam workshop, trading cards etc..

I imagine a toggle could be used to switch between graphics and ascii modes, akin to what fandom wikias do for character portraits in different adaptations (example).
Knowing next to nothing about them, it would certainly be nice if the toggle could be handled by cookies in some way, or rather if the state could be saved so whoever doesn’t use the default option won’t need to change it every time they open an article.

The tileset explanations can be left mostly as-is (ascii-mode will still be relevant), but the graphic set one be reworked to act as a hub for the Mephday graphics.

(ETA: Final suggestion - actually don't use DF202xWhatever name for namespace. Like Microsoft basically abandoned year-labelling (after Windowses '95, '98, maybe Millenium and definitely 2000; though Office and other suites continue/continued longer). Because some (later) new users arriving to the brand in 2022 or later might be put off by a 2020/2021-named version, for example, whatever the timepoint involved, not yet knowing that the latest non-minor tweak was perhaps only a week ago - hence why it came up on their radar in the first place and went Wiki-browsing.)

DF2020 I think is as easily connectible to the decade of the 2020s as it is to the year, so it could work. If it comes down to DF2021, however, I wholeheartedly agree. What would a suitable name be though? Due to the way Dwarf Fortress versions are named, the ”main version number” (eg. 0.47) might not be the optimal choice. Of course it could be done as it has been before, but the number may change unreliably without any dramatic gameplay change; see 0.43.01.

[Starver]

I don't have in-depth wiki-mode experience, but I had known of TVTropes and its (amongst others) spoiler-show/noshow remembered toggle.

After adding in the site-wide (and every-page switchable) setting memory, perhaps {{someTemplate|vanilla=im1.png|steam=im2.png}} would handle this? Alternate to vanilla= being codepage= for text-not-image versions, somehow so incorporating foreground and background.  Various meta-templates could package up common but complex sets further.  (SMoP!)

Just checking your Anime/Manga example (and looking at the 'source', seeing it's somewhat more complex), less involved than an entire Infobox format (except where it is an Infobox-like container.

But this is detail to be bashed out later, I'm sure. I await other people discussing the original point before going too much more into what you do if/when you do it.

[Salmeuk]

* DF202x namespace pages feature SomethingAsSteamGraphics.png alongside SomethingAsVanillaGraphics.png as illustration of every (trivial) feature (entire screenshots might be exemptable?). Or, where the latter is text anyway, like the standard "stockpile and use" montage illustration inthe top corner of a material page, PNG and as-is. This so neither usage-base has to go to too much effort to understand the other format. (May even encourage cross-migration in both directions.)

I think this is a super-important point. While I am intrigued by the official tileset, I imagine I will still fall back on ASCII. That's just what I know.

Will the tileset be available for free, or is it only included in the paid release? If the latter is the case, the wiki should absolutely cater to both graphical styles, since free players might not understand the tileset without access.

To solve this, I like the idea of a site-wide tileset-to-ASCII toggle, but then that becomes it's own project, and that might delay the wiki's updating even further. Asking article writers to upload two images, tileset and default [square] ASCII, would not be too burdensome except for the most image-heavy articles, and then it could always be updated late on. Of course, that doubles the image hosting needs.

Just my two cents as an avid wiki-user.

[Starver]

Will the tileset be available for free, or is it only included in the paid release? If the latter is the case, the wiki should absolutely cater to both graphical styles, since free players might not understand the tileset without access.

AIUI, the "Mephday" tiles/graphics are a key selling point of the Steam product, but using additional features to support the fancy new graphics processing (e.g. implementing native TextWillBeText-like details) that are also freely usable by any further free graphics-packer to work with, in the traditional modding/graphics community.

Spoiler (click to show/hide)

If you go for Steam/Itch, you're getting a premium product that can be reconfigured to Vanilla (or non-Meph/Mayday) graphics, and if you stick with the Bay12 package there's nothing to stop you getting graphics similar to the other release, once anyone makes it available, though the "Mephday" set itself is © to the premium release.

We need to cater for those who need both, therefore. And if we have side-by-side examples on show (maybe not everywhere) maybe some Hipster Steamers will enjoy getting down-and-dirty with the "looking into the Matrix" look with their premium download, and some of those who start by trying the free version will get to the stage where they'll know they now want to pay something for the fuller (official) experience.

That was why I thought side-by-side might confer additiinal benefits. Though whether that only needs to happen in certain places (switchable in most if the others and not done in a few fringe ones) is a point of discussion. And one I didn't mean to insta-divert this thread towards.

But exact details may vary a little in the run-up to the release, even if I'm currently sufficiently on the mark.

[eternaleye]

One thing that might be a good idea, regarding the screenshots issue, is to use MediaWiki's support for "slideshow" galleries, so that the images for different visual styles (Mephday vs. ASCII) fit into the page layout the same way single images do (for the most part, at least).

The syntax for a "slideshow" gallery would be:

Code: [Select]

<gallery mode="slideshow">
Image:MicroWaterReactor_premium.jpg|Micro Water Reactor (Premium graphics)
Image:MicroWaterReactor_ascii.jpg|Micro Water Reactor (ASCII graphics)
</gallery>

This was added in MediaWiki 1.28, and the DF Wiki is on 1.32, so this should work pretty trivially, and we could even make a template so you could do something more like:

Code: [Select]

{{GraphicsImage|MicroWaterReactor|jpg|Micro Water Reactor}}

and have it expand to the first code snippet.

The relevant "Template:GraphicsImage" page on the wiki would just be:

Code: [Select]

<gallery>
Image:{{{1}}}_premium.{{{2}}}|{{{3}}} (Premium graphics)
Image:{{{1}}}_ascii.{{{2}}}|{{{3}}} (ASCII graphics)
</gallery>

It'd require a little care to upload images with the correct filenames, but it'd make editing the pages much easier, and keep the layout mostly unchanged.

[lethosor]

This feels like something I ought to weigh in on; sorry for being late.

I was one of the people pushing for DF2014 back in 2014, and I agree now that it wasn't a great choice. Back then, the oldest namespaces had only been around for two years (DF2010 and DF2012). DF2012 being the current version in 2013 and half of 2014 was a little weird, but not as weird as DF2014 being the current version in 2020. The reason DF2012 and DF2010 only "locked in" to v0.34 and v0.31 once the next version was released was because renaming namespaces takes a while to propagate throughout the wiki (we have to clear the cached copies of most pages, so it's kind of intensive on the backend). There are also some pages like templates and categories that need to be manually renamed. Granted, a lot of the process for the DF2010/DF2012/DF2014 migrations was automated, but many of the scripts we used are probably lost by now. Either way, a new namespace is not a lot of fun to create, which is part of the reason I've been hesitant to make one.

Regarding save compatibility: part of the reason for keeping old versions of the wiki around was so that players who wanted to play older forts that couldn't be upgraded could get to documentation more easily (for example, Boatmurdered in 23a). People can load a 0.42 or 0.40.03 save in 0.47.04 (at least in theory), so there's less of an incentive to create separate 0.42/0.43/0.44 namespaces for people who could upgrade but haven't (taking the effort involved in creating a new namespace into account as well).

There have been some discussions in various places over the years, like here. I'm thinking one of the better solutions is to name the namespace for the current version "Current", then copy those pages into a namespace for an older version (like "v0.47") when we want to split one off. That also avoids conflicting with people racing to edit pages when a new version comes out - migrations take a while, so in the past, we've had to lock the wiki to get the pages transferred over without people editing them in the meantime. In contrast, a bot would be able to grab the last revision of a page before the new version came out relatively easily. It would also be possible to make this change before a new DF version comes out, which would take allow us to spread out some of the load on the wiki.

Regarding the premium version: I don't think we should create a new namespace solely because of the premium version being released. My understanding is that not everyone will play the premium version, for one thing. However, if the gameplay changes are significant enough (i.e. not just some updates to the graphics/modding pages), I wouldn't be opposed to splitting off a namespace for v0.47 vs the new version. We usually have a good idea if a major DF version has major changes before it's released - we don't necessarily know if it will break save compatibility, but I think a new namespace point would definitely be worth considering.

This was added in MediaWiki 1.28, and the DF Wiki is on 1.32, so this should work pretty trivially, and we could even make a template so you could do something more like:

Out of curiosity, where'd you find that? We've been using <gallery> since at least 2014, when we were running 1.20. (Maybe we had an extension, but I don't remember having to disable one when we upgraded...)

[PatrikLundell]

A few arguments for why the Premium release may be a reasonable point for a new namespace:
- As mentioned, a split is long overdue.
- The UI changes will do a number of the key mappings.
- The UI changes will change the contents of a fair number of menus (assuming it isn't cut due to running out of time).
- The multiple grids will change the "look and feel" a fair bit, regardless of whether character or tile graphics are used.
- More or less every DFHack script or functionality that has a UI component will probably have to be updated to work with the new grids (not sure how much that will be visible on the wiki, though).
- While DF is set to be "truly" backwards incompatible in the very next major DF release after Premium, the development time for that is probably 3-7 years, which is a fairly long time for a name space.

Note that I make a distinction between the Premium release (the next major DF version) as opposed to the Villains (current) and Myth&Magic (next after Premium), and the Premium vs Classic version where the Premium version will be the commercial one from the Premium release onward, and Classic being the free (with optional donations) version. Handing Mephday and character graphics images in a logical way is an issue, but trying to do that in parallel with pre Premium release layouts would probably get rather messy.

[BlueManedHawk]

So wait, will a new namespace create whole new pages to be filled in for that namespace, or will it copy the old pages into the new namespace?

[lethosor]

So wait, will a new namespace create whole new pages to be filled in for that namespace, or will it copy the old pages into the new namespace?

In the past, we have used a bot to copy pages into the new namespace and add/update a template indicating that they may need additional review. I'm unaware if the scripts we used in the past still exist/work, or if we would need to come up with something new.

[delphonso]

Posting to watch and potentially participate.

[Miuramir]

Given the info and examples in the 2021-01-14 dev update, in my opinion at least the case for a new wiki namespace has become much stronger.  It looks like the new version will have a radically different UX / UI even in the ASCII version; with most modal windows going away, a whole slew of new pop-up windows with multiple tabs, major changes on how scrolling works, significantly rearranged key bindings, and so on.  It seems likely at this point that the vast majority of instructions, and many guides and suggestions, will need to be reworked for the new version; preserving the old version instructions (for historical reference, and for those players who do not update for whatever combination of reasons) with an archived namespace is precisely why one would want multiple namespaces.  Arguably, a "player muscle memory and operating instructions" compatibility break is even more disruptive than a savegame compatibility break. 

I like and strongly support the idea that the new namespace be "Current" or some similar take; and that as time and versions roll along, older versions are archived off into a separate namespace (as needed by major game changes) with a name determined at the time of archiving, with the considerable advantage of hindsight. 

As far as presentation of the graphical  vs. ASCII take on things, I am less sure of the optimal approach, but in general I think that templates that are designed to present both appearances on the same page / sidebar would be the best.  I'm a long-standing proponent of the keyboard-driven ASCII take on things... but what we've seen of the Premium version has me seriously considering a change, and I think the level of both refinement and utility it will bring may convert a fair number of us old-timers.  But not all, and if for no other reason than preserving the ability to play on less-than-ideal devices and for universal accessibility (ie, handicap assistive device compatibility), I think preserving the old-school Roguelike roots and ASCII display as a parallel presentation is important. 

One wrinkle not previously discussed is that there are rumors that there will be a fully modern "free" new-style graphical tileset (which is far more than a traditional tileset, given all the interacting and blended layers) available around launch.  Given that it seems like creating these is dramatically more work than a traditional tileset, it is possible that in practice there will effectively be three common looks for some time; paid Premium, the aforementioned work, and new-ASCII; so that may be worth thinking about.  Is it possible to create a template with basically three slots for the visual, where the third one is pulled from some user preference setting?  (I.e., the sidebar for something would show three icons; how-it-looks-in-Premium, how-it-looks-in-stock-ASCII, how-it-looks-in-the-tileset-you-indicated-you-prefer-in-your-user-settings, with some sensible default for the last.) 

[Starver]

Might be easier if (officially) tied in with/mirroring a tileset repository. Or just a selective one, like the forum editing buttons, here, gives eight pastable font-types[1], so maybe a regularly reviewed/updated/augmented top-ten, by whoever(s) has the time to take given art files, shred them into many single-tile images for the wikimedia resource, classify them (by RAW details harvesting or to fit all requirement gaps discovered) and maintain any template-realiasing that needs adjusting.

Composited tile graphics might be the big-trouble (hopefully don't need to shred and then combinatorially recombine into single flat images for every possible/likely/required overlaid combo.

Can't recall(/not checking) if it's been said that an agreement might need to be sought with Mephday over using their "supposed to be for Premium purchase only" graphics. It would also be cursory politeness to check with all authors whose non-paid tilesets are (potentially) featured. But in both cases it might be good for all. For a limited set of known wiki-side requirements (like the layout of behind the servicing of the {{Metal|name=Copper|color=6:4:0 ...}} insertion) willing contributors could find it easier to extract/recomposite the appropriate graphic with intimate knowledge of what is needed. It could be considered a 'selling point', without them having to accept the whims of more casual process from the generally well-meaning wikipedians of this parish. They also have the ultimate heads-up on new revisions and know if anything should/can be updated. Applies especially to Premium Mephday (and associated licencees/licensors, however that is going to work with Wiki-style copyleft/rights-reversed), though.

Sorry if I've repeated something, from me or someone else. I probably should have scrolled up to check, but a brief 'it just (re)occured to me' expanded somewhat in the editing.


[1] For reasons best known to itself, Courier (at least, given its usefulness) doesn't interpret as the monospaced type it should, on my tablet's browsers, sticking to the proportional sans variety of default. (But code-tagged stuff works as it should, and I'm sure I could manually edit my own BBCode parameters to work better for me.) But I digress, save that it illustrates the possible need to serve 'what I want' with the page as much as possible where you can't rely on other