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.
This makes sense to me. I don't think a
ton of pages refer to specific UI elements, though, but I know there are a good number of keyboard shortcuts in many places. My understanding is that keyboard shortcuts would be retained for the most part, but if there are many new UI elements, adding conditional references to them across pages in the DF2014 namespace would be confusing.
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.
I want to do this too; I would prefer to discuss it somewhere more centrally, though (i.e. not this thread). It also hasn't been a super high priority for me to even start a discussion on the subject. There is technically one on the
wiki, but there's not a lot of activity on wiki-related discussions these days.
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.)
EDIT: Just as I'd said in a previous thread, I don't see there being a problem using the Premium sprites in the wiki.
Thanks for confirming! We do have some existing support for raws (the DFRawFunctions extension) and tilesets (the DFDiagram extension) in templates, so we might be able to make this a fairly non-manual process, although it would require some dev work.
Let me be frank, the wiki is currently in quite a dire situation.
The reason the wiki is in a dire situation is that a significant chunk of the bay12 community does not actually play the game (and hasn't done so for 5+ years), and many DF players do not engage the bay12 community (and stay on the same six or seven websites as do most people on the internet). People are intimidated by the wiki, and don't edit; conversely, lots of information is posted on reddit or the forums without ever making it to the wiki. As a result, the wiki is really, really obsolete - it took several years for the article about bogeymen to be corrected to reflect their new powers.
I don't have any solution for this. I try to edit the best I can but sometimes I don't have time and most importantly I can't reliably test every aspect of the game. That's what the power of the crowd is for, and that's what a wiki is for. But if there is no crowd to sustain it we might as well revert to a good old fashioned manual with a yearly reprint or something.
I will admit that I am one of those who hasn't had a lot of time to dedicate to playing DF or updating the wiki. However, I'd like to push back against the "dire situation" part a bit - I've seen a number of good edits and a decent amount of activity recently. Some pages haven't been updated in a while, but in many cases, they haven't needed to be due to a lack of recent changes. I wouldn't say that some incidents of outdated pages warrant scrapping the wiki altogether.
I would probably encourage continuing this discussion in the
"let's fix the wiki" thread, at any rate, and keeping this one dedicated to the namespace discussion.
[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
We can specify multiple fallback fonts, and most templates do that already. Can you point me to an example of one that doesn't work for you?