Dwarf Fortress Wiki talk:Versions

Bed
	/ Θ
	/ Θ
Construction
Rooms
	Bedroom; Barracks; Dormitory;
Base value
	10☼

Archives

Page 1

Version 0.31.19 starts a new DF generation?

My reading of Toady's comments on the release of 0.31.19 is that it came out basically because he felt it would take too long to get DF all the way to 0.32. With the ore changes, the sitefinder changes, the addition of grazing and several different industries, there's a lot of changes between 31.18 and 31.19. So I'm thinking it might be a good idea to call it the first release of DF2011 - and what we refer to as "DF2010" would then become 0.31.18.

Thoughts? --DeMatt 07:06, 28 February 2011 (UTC)

Revisiting Redirects

I wasn't around when the redirect policy was created, and I'm having trouble understanding the rationale. The example claims that linking Main:Cheese to cv:Cheese maker is problematic...but mainspace only ever redirects to the current version. If the best target in the current version is cheese maker, why not link to it directly? (It's not, at least for Cheese, since DF2012:Cheese exists now.) The explanation seems to be claiming that 40d articles that link to Cheese will follow the Mainspace link--but that hasn't been the case for a long while now. Articles in 40d automatically link against other articles in 40d, so that version remains internally consistent no matter where mainspace links to in the current version. For a current example, what do we gain by linking Main:Mead to cv:Mead and linking DF2012:Mead to DF2012:Alcohol?

If this really is just an outdated procedure, I recommend we drop the mummery and allow mainspace to link to cv:(best target). Double redirects may work (sometimes, but Main:Mead demonstrates a common problem where automatic redirection fails), but if they are unnecessary I think they should be avoided, partly because of problems like Main:Mead and partly because of the effort required to protect double redirects from users who believe they are problematic.--Loci (talk) 20:16, 8 January 2014 (UTC)

I was just thinking that. I'm currently attempting to write a basic extension to eliminate the need for mainspace redirects entirely, although Mediawiki's class structure may make this more difficult than I had hoped (the only method I've found for resolving redirects takes the article text instead of a title, e.g. "#REDIRECT ..."). I do agree that the current situation with redirects isn't ideal, so I'm hoping this will work better (once I get it to work). --Lethosor (talk) 20:42, 8 January 2014 (UTC)

Okay, that wasn't quite as clear as I meant it to be. In general, I think this is a tricky situation. Mediawiki wasn't designed to have five content namespaces, and certainly not chains of redirects between them. The problem that was pointed out in the policy is the fact that with:

Main:Foo -> cv:Bar

pages in the cv: namespace can't use [[foo]], since the namespace links modification causes it to be treated as [[cv:foo]] instead, which doesn't exist. The current suggested solution is this:

Main:Foo -> cv:Foo -> cv:Bar

This fixes the problem of [[foo]] not working on cv pages, but creates issues with double redirects not always working. Another solution, which is more intuitive to new editors, is:

Main:Foo -> cv:Bar
cv:Foo -> cv:Bar

Both require creating two redirects. The first method has the advantage of ensuring that the cv redirect exists (otherwise, main:foo would be a redlink), while the second has the advantage of working more reliably in a couple cases.

What I'm trying to do is make main:Foo "jump" to cv:Foo when cv:foo exists, even if main:foo doesn't exist (basically it would treat all mainspace pages as redirects to cv pages, but only if the cv page exists and not the mainspace page). I had main:Bar jumping to cv:Bar fine, but if cv:Foo redirected to cv:Bar, accessing main:Foo would mysteriously stop at cv:Foo even if I increased the redirect limit. What I'm trying to do now is follow the redirects internally, without relying on Mediawiki to do it automatically - unfortunately, that has proved to be harder than I had hoped (and I sent my web server into an infinite loop while trying). I will try to work on this some more when I get a chance, although I'm not sure when that'll be yet :(. For now, feel free to fix broken double mainspace redirects as necessary, as long as redirects in the DF2012 namespace stay pointing to the right page (and new mainspace redirects get added in the DF2012 namespace too). --Lethosor (talk) 04:21, 9 January 2014 (UTC)

You're treating cv like a namespace--it's not. It is simply shorthand for "fill in the current version here". As I discovered a long time ago on a server not far away, linking from Main:Foo to cv:Foo tends to break redirection chains. If, instead of linking to cv:Foo, you link to DF2012:Foo, it might just work. It would, of course, be better if your patch could evaluate cv itself, but even if you have to hardcode the current version it's a single point of maintenance that requires update very infrequently. (For that matter, we could probably dispense with the cv hack entirely and just have a bot update mainspace links from DF2012 to DF201X when we switch to a new version.)--Loci (talk) 20:05, 9 January 2014 (UTC)

I know cv isn't a namespace - I was just trying to avoid future confusion when the DF2012 namespace changes. It's interesting that changing "cv" to "DF2012" fixes some broken redirects, although I've found that simply making an edit to a broken redirect can usually fix it as well. I've actually had the most problems with double redirects when the second one (in the DF2012 namespace) doesn't use the DF2012 prefix (e.g. main:Foo containing [[cv:Foo]] and DF2012:Foo containing [[Bar]]). I'd rather keep the cv alias even if it isn't necessary for mainspace redirects when I get the patch to work, since it makes it easier to refer to the current version of the page (for example, several MDF articles contain links to a vanilla page for things that don't change in the mod).

Also, using aliases like "cv" is supported by Mediawiki; in fact, several WMF wikis use them (for example, "WP:Redirects" on Wikipedia). It's quite likely that Mediawiki isn't processing double redirects using aliases correctly, though, since that's uncommon on most wikis. --Lethosor (talk) 21:35, 9 January 2014 (UTC)

In light of the lack of support for the current redirect policy, I propose we replace the current redirect section with:

Mainspace article pages should use the cv: alias when redirecting to a versioned page, which will automatically update the link when a new version is released. For example, page "Main:Foo" should redirect to page "cv:Bar" (where "Bar" is the page that best describes the topic Foo in the current version).

Pages in mainspace should only redirect to an older versioned page if that content no longer exists in the current version of the game (e.g. Cave river, Chunk). In these cases the cv: alias cannot be used.

Pages inside a versioned namespace should not use the cv: alias. Instead, they should redirect to the best page within that versioned namespace (e.g. DF2012:Dodging, v0.31:Drink).

Due to limitations of the wiki software, double redirects should be avoided if possible. When fixing double redirects in mainspace, please make sure to use the cv: alias as appropriate.

If no one objects, I will make this change in a few days.--Loci (talk) 20:21, 15 January 2014 (UTC)

Okay with me. It may be worth mentioning that double redirects only really need to be changed when they don't work (since changing a lot of redirects that work isn't necessary), but I think it's clearer and more relevant than the current policy. —Lethosor (talk) 00:26, 16 January 2014 (UTC)

Done.--Loci (talk) 20:55, 22 January 2014 (UTC)

I was finally able to get my extension to work after being motivated by one too many malfunctioning redirects. It now causes nonexistent pages in the main namespace to behave exactly like redirects to their DF2012 counterparts (when linked to, accessed directly, and transcluded). Double redirects also work (up to 100, in fact, although that was a temporary safety measure that I'll probably change). This means we'll be able to safely get rid of all mainspace redirects (redirects that redirect to something other than "cv" will still function if not deleted). —Lethosor (talk) 01:20, 14 March 2014 (UTC)

What about articles which don't exist in the current version but do exist in older versions? Will those still need mainspace redirects, or will your extension be able to automatically redirect them to v0.31/40d/23a? --Quietust (talk) 01:29, 14 March 2014 (UTC)

It ignores all mainspace pages that actually have content, including redirects, so pages like masons guild won't be affected (unless deleted). —Lethosor (talk) 01:47, 14 March 2014 (UTC)

Done and deployed. Cat is still treated as a redirect, even though I just deleted it (try clicking on the "redirected from" link). Pages that exist are ignored, so Masons guild and History of Dwarf Fortress still function normally (as a redirect to a 23a page and a non-redirect, respectively). —Lethosor (talk) 18:57, 14 April 2014 (UTC)

I'm sending around a bot right now to delete all redirects of the format "foo -> cv:foo" (a surprising number don't fit this format, so I'm leaving them alone for now). —Lethosor (talk) 20:43, 14 April 2014 (UTC)

I'm confused. Do we use double redirects or not? Is there a single place we define our linking policy (including redirects), and is it updated?

I had trouble linking to Consolidated_development in v0.34:Dragon. It kept pointing to v0.34:Consolidated_development, which does not exist. I ended up linking to Main:Consolidated_development to make it work. --Nahno (talk) 10:18, 1 July 2014 (UTC)

That's a separate problem altogether - links in the versioned namespaces (v0.34, v0.31, 40d, 23a) automatically link to pages within their namespace. I may be able to set up a fallback to mainspace once I'm able to deploy again, but for now the "main:" alias is the intended solution. —Lethosor (talk) 11:36, 1 July 2014 (UTC)

Google often directs people to the 0.31 page

I've noticed a couple of times that finding a wiki page from an external search will often drop me onto a page from an older version. Is it possible to mitigate this somehow for new players? I could imagine something like redirecting old:Bar -> cv:Bar unless the user has come from old:Foo; no idea if that would actually work though. PeridexisErrant (talk) 11:48, 4 May 2014 (UTC)

As a temporary solution, I could write a script that displays a banner of some kind if the user came from an external site. I'll ask Briess if he can do anything on the server level to increase the weighting of the current version's pages. (Obviously there are situations where people are looking for old pages, like 23a:dungeon master, so we don't want to disable indexing entirely on old pages.) —Lethosor (talk) 17:03, 4 May 2014 (UTC)

DF2014?

As Toady draws closer to a new release, it might be worthwhile to discuss the addition of a new version to the wiki. The upcoming release covers two years of changes and introduces a number of new plants, foods, drinks, multi-tile trees, climbing, jumping, etc., so it is likely to have significant changes from the current DF2012. To avoid having people start new pages (and lose all the effort spent refining the prior version's page), I think it would be best to have a bot automatically copy over the DF2012 pages as a starting point for DF2014. I would suggest that these copied pages include a noticebox template mentioning that the content may be outdated, so that we can easily track which pages have been reviewed. I think either the {{version check}} or {{old}} template would work. --Loci (talk) 19:43, 5 May 2014 (UTC)

This is what User:QuietBot did after the 0.34 release, so it's certainly possible to use the same script to migrate to DF2014. I would like a way of tagging migrated pages, since inaccuracies in some pages went unnoticed for months after they were migrated. Since {{old}} is already in use, {{version check}} may be a better solution (it can be reworded slightly, or we can make a separate template for DF2014 migration). —Lethosor (talk) 19:23, 1 June 2014 (UTC)

Made Template:DF2014 migrated as an example. Any thoughts? —Lethosor (talk) 19:32, 1 June 2014 (UTC)

Redirects inconsistency

Following a redirect is supposed to be exactly the same as going straight to the page it redirects to, but this actually isn't the case:

Go to Seeds and you get v0.34:Seed (outdated)
Go to http://dwarffortresswiki.org/index.php?title=Seeds&redirect=no and click on the link and you get to DF2014:Seed (current)

So if you search for "seed", the top result is the DF2014 version. But search for "seeds" and you get the redirect, which sends you to the outdated page instead. Hairy Dude (talk) 23:22, 22 February 2015 (UTC)

While I'm talking about redirects, it seems redirects to sections don't work: see DF2014:How do I manage my seeds and crops. I know MediaWiki is capable of this trick because Wikipedia does it. Hairy Dude (talk) 23:32, 22 February 2015 (UTC)

I have absolutely no idea why seeds redirects to a v0.34 page - it could be a Mediawiki bug. The section links issue is due to a known issue in the redirect extension we use, which has yet to be fixed. —Lethosor (talk) 00:01, 23 February 2015 (UTC)

It looks like deleting both Seeds and DF2014:Seeds fixed things (by allowing AutoRedirect to handle the redirects instead). Feel free to tag any others with {{bad redirect}}. —Lethosor (talk) 00:03, 23 February 2015 (UTC)

It gets stranger. Vial redirects explicitly to cv:Flask which displays (when you look at it with &redirect=no) as DF2014:Flask, but still goes to the v0.34 version. It seems redirects interpret the cv: pseudo-namespace (or whatever it's called) in an outdated way. Hairy Dude (talk) 18:08, 23 February 2015 (UTC)

I've added a note to this page about this issue. If it gets resolved, the note should be removed. Hairy Dude (talk) 21:04, 23 February 2015 (UTC)

Reorganizing versions

The internet deals with moved content... poorly. Google is still linking to v0.34 pages more than a year after the switch to "DF2014", and even the wiki software still has cached links pointing to the old version pages.

I propose reorganizing versions on the wiki to avoid moving content whenever possible. Instead of having a temporary "current version" namespace that changes occasionally, all the current information gets promoted to the Main namespace. When the next version split occurs, the Main articles as of a certain revision number can be copied to the newly-created permanent "old version" namespace, while all the current information remains in Main. This not only fixes the link rot issue, but it has a few other benefits as well: fewer administrative tasks, no lockdown (a historical version of the Main pages can be copied at any point, even if the Main articles are already modified for the new version), almost all the article history is maintained in the Main article (instead of being spread unevenly across multiple versions), no "temporary" namespaces are needed, fewer problematic long redirect chains, and hopefully less user confusion (since Main gets priority in search results, etc.).

As an example, today we would not have a DF2014 namespace (which is good because "temporary" namespaces historically disappear anyway). If you ran a search for seed you'd end up at Main:seed, which would have all the current information on seeds. The version box at the top of the page would still link to the older versions of the seed article. When a new version is released, an admin would choose a revision number and copy the Main:seed article as it exists at that revision number to v0.40:seed. That's it. One historical copy that needs little to no new editing, and zero redirections/moves.--Loci (talk) 19:02, 27 July 2015 (UTC)

Makes sense to me. It would involve a lot of work, though (e.g. fixing templates and categories to account for the current version being in mainspace), although that should be doable thanks to {{category}}, {{version switch}}, etc.. A bot could be set up to copy revisions from before a release date as well, which would be more difficult (and maybe slower) than a direct copy, but not severely. —Lethosor (talk) 17:24, 30 July 2015 (UTC)

Actually, there are a few issues with that, namely that there wouldn't be an easy way to distinguish between versioned and non-versioned mainspace pages. There are ways to resolve Google search priority (we can exclude pages from older versions from search engine results if there are newer versions of those pages available, for example). —Lethosor (talk) 19:47, 6 August 2015 (UTC)

There aren't very many non-versioned mainspace pages, and determining if a page is versioned is as simple as looking for the version template and/or categories added by the version template (e.g. copy this category instead of Main:*). The problem with "suggesting" newer pages to Google is that they obviously aren't crawling our wiki regularly (if they were, the fact that the mainspace redirects point to new pages would automatically be picked up). Even if your Google hints worked they wouldn't do anything for all the other broken links out on the 'net.--Loci (talk) 20:35, 6 August 2015 (UTC)

Google actually crawls the wiki constantly - we probably get crawl hits from google for a continuous block of 2-3 hours per day, each and every day. Why they are slow to update is beyond me though. I can't remember why we didn't do this initially, but there was a technical limitation involved if I remember correctly. --Briess (talk) 22:05, 6 August 2015 (UTC)

There are <meta> tags that can be used to hide pages from search results (for search engines that recognize them, that is). Searching for {{av}} or Category:Current might work, although we'd have to make sure all of the DF2014 pages include that (some pages don't, particularly some disambiguation pages, although all of them should). —Lethosor (talk) 22:53, 6 August 2015 (UTC)

Is there a particular reason main and current are separate to begin with?—CLA (talk) 00:17, 7 August 2015 (UTC)

It's mostly intended to distinguish between versioned and non-versioned pages and make version-related templates simpler to work with, since every versioned page has a namespace. I wasn't active here in 2010 when this system was created, so Briess and Emi would know more.

Another issue I just thought of with Loci's suggestion is categories - currently, categories like Category:Animals are used to organize the versioned sub-categories. Sure, we can change {{Category}} to categorize mainspace pages in Category:v0.40:Animals or Category:DF2014:Animals, but that would be less straightforward because there wouldn't be a namespace with that name (until pages are migrated when a newer major version is released). —Lethosor (talk) 13:05, 7 August 2015 (UTC)

Moving current pages to the main namespace sounds like a great idea. -Jecowa (talk) 20:47, 4 January 2018 (UTC)

Another thought: dealing with migrating redirects could be difficult with this proposal - specifically, determining which redirects should be migrated to a versioned namespace. Redirects can't contain {{av}}, at least not before #REDIRECT. I think it would be possible to copy pages in two stages, though - all non-redirects first, then all redirects whose targets were also copied. Thoughts? Anything I'm missing? —Lethosor (talk) 23:41, 27 June 2019 (UTC)

Some subpages (particularly /raw and /Edit notice) also deliberately lack {{av}}, although those shouldn't be too hard to handle. —Lethosor (talk) 00:35, 9 July 2019 (UTC)

Redirect pages (and all other edge cases I've looked at) can be included in categories (like Category:Current) to determine whether or not they should be copied into an archival version. But if the redirects are "properly qualified" then they can all be copied over blindly. Mainspace redirects pointing to versioned information should use a blank namespace (which will be automatically constrained to the archival namespace); mainspace redirects pointing to unversioned information should use an explicit "Main" (which will automatically link back to the unversioned page). Then, when [[Toady]] gets copied to [[v0.4x:Toady]] it will point back to [[Main:Toady One]]. Meanwhile, [[Beer]], copied to [[v0.4x:Beer]], will properly point to [[v0.4x:Alcohol]].--Loci (talk) 20:00, 14 July 2019 (UTC)

I think qualifying redirects is the best solution here - categorizing redirects manually is another possible source of errors, since categories (or a lack thereof) would only be visible on the redirect page itself, and Category:Current is a hidden category. Copying over mainspace redirects into versioned namespaces would also resolve some issues that have come up due to those not reliably existing currently. I should be able to set up a bot script to add "main:" to current mainspace redirects (and it shouldn't break anything, since those redirects go to other mainspace pages anyway). —Lethosor (talk) 21:57, 14 July 2019 (UTC)

(Note: I wrote all of this without noticing the previous discussion above.) I was wondering, when the wiki creates a new namespace for a major release again, if it is possible to not create a namespace for the next current version (e.g. "DF202x") and instead have the mainspace articles (which are currently redirects) become the new cv and move the content there. Therefore, cv:Cat would just be "Cat" (or Main:Cat).

Certain namespace-related templates like Template:Ns/0 would need to be changed, though nothing significant as far as I know. For most cases, any "DF2014" would be replaced with "Main" or even blank. There's also multiple extensions handling the current namespace system and they may need to be modified too, though I'm not sure if or how much. I'm guessing based on the discussions above that it will change stuff up.

My reason is the current namespace is increasingly becoming more anachronistic. "DF2014" could be misinterpreted as "this page is about the 2014 version of the game" or "this page was last updated in 2014", which I've seen a few people in forums mention. Granted that Template:Av is on the top of very article, I still think the namespace is inconsistent with the recentness of the article. But how is this related to what I'm asking for? Let's say we continue the current system: if we happen to do a new namespace change this year and create DF2020, the next major release (after graphics/UI) will be mythgen, which is estimated to take several years to develop (the Big Wait), and so the anachronism will start over again. The proposed way will prevent this from occurring for the next major release and every release thereafter.

I think the confusion with having a namespace that becomes old-fashioned overtime supersedes the confusion with not marking current versioned articles with a namespace. Most users just search "Cat" on the search bar and naturally expect to get information about the latest release of DF. So if users go a page that's just titled "Cat", they won't expect outdated info about cats from a previous release. That's how the current system works anyways. We'll be skipping the two-step process that we have now. It'll make several wiki tasks much simpler as well. Editors can create new articles for current versions without remembering to add a namespace. It'll fix any existing issues with (double) redirects; instead of Main:Kitten redirecting to cv:Kitten, which goes to DF2014:Kitten, which then redirects to DF2014:Cat, Main:Kitten would just redirect to Main:Cat. And the cv: alias will no longer be necessary since "cv:" = "Main:" and will be forever.

There's no need to differentiate the current version and previous versions with a namespace for the current version is what I'm saying. Articles of previous versions will retain their respective namespaces. Users will still type "40d:Cat" to go to the 40d version of the article, but if they want the current version, they'll just type "Cat" (like now). The mainspace containing the "live" version of an article is natural and would create no uncertainty when browsing the wiki. And it would simplify the wiki somewhat and future-proof this anachronism problem. As a bonus, this change will also prevent web search engines from showing previous version pages when typing "DF cat" or something. (This isn't happening right now as DF2014 has been the current namespace for ~6 years, but it'll happen again when everything moves to a new namespace.)

This is the gist of it, and I may have ignored most of the problems with this proposal. I have personally wished for the whole version namespacing be made less complicated and have been seeking for a solution, and I feel like this is the best way to go about in the future. – Doorkeeper 21:27, 14 August 2020 (UTC)

Whoops, looks like Loci already proposed this exact thing long ago. I definitely missed that discussion and should have checked first. My apologies. I'll move my text to that section and remove this one. – Doorkeeper 21:36, 14 August 2020 (UTC) Done. – Doorkeeper 21:40, 14 August 2020 (UTC)

The main issue I have with that is that putting pages about the current version in a namespace also differentiates between those pages and pages not about any version (for example, Toady One does not need a 40d or v0.34 page). Yes, we can use {{av}} to mark versioned pages, but people often forget to add that to new pages. The current system also allows determining whether a page is versioned or not from its title, which makes migrations a lot faster. Relying on {{av}} would require either reading the content of every page (which would slow scripts down significantly) or cross-checking with the list of all pages including the template (feasible, but a bit more complicated, and still susceptible to missing templates). I suppose that manually fixing and migrating pages missing {{av}} later wouldn't be too much work, though.

I am definitely in favor of changing "DF2014" (or a new namespace) to "Current", though. I was in favor of "DF2014" in 2014, but I don't think it makes sense anymore, and "Current" seemed to be a popular alternative in both the DF2012 and DF2014 discussions on the matter. —Lethosor (talk) 04:02, 16 August 2020 (UTC)

Weird redirect behaviour

Pump stack redirects to cv:Screw pump#Pump stack. If you look at the redirect itself it says it redirects to DF2014 namespace, which is correct. But if you actually follow the redirect, it goes to v0.34 namespace. Hairy Dude (talk) 16:10, 20 August 2018 (UTC)

Yeah, that's part of the issue described in the above section (the wiki caching part, not on Google's end.) —Lethosor (talk) 15:00, 21 August 2018 (UTC)

v50 organization

Some wiki admins have had a talk on Discord and decided that the most sustainable path forward is to put content for all future versions of DF in the main namespace. We will be working on a bot to do this in the next few days. Feel free to chime in with suggestions here. —Lethosor (talk) 22:56, 14 December 2022 (UTC)

Is it maybe possible to do backwards-namespacing? Like we have a "Main" namespace, which people are free to update, and whenever there's a new version of DF the "Main" namespace is copied into a namespace for the then old version, much like how you'd branch a stable branch from a development branch when working with a git-project? Therahedwig (talk) 23:13, 14 December 2022 (UTC)

Yeah, we could do that if we decide to. We were talking about doing that for v50, actually, and might still do something similar to preserve edit history if it doesn't end up being too hard to automate. Our hope is that we will not introduce new namespaces for v50 -> v5x, unless there is a serious breaking change (and hopefully there isn't one). But if we change our mind, one advantage of the type of migration you mentioned is that it can be done retroactively - we can copy historical revisions that were current at the time of the release, and would only lose some typo fixes made after the release that apply to earlier versions as well. —Lethosor (talk) 02:11, 15 December 2022 (UTC)

ETA is < 24 hours. Doing some final checks on a migration script. —Lethosor (talk) 07:08, 19 December 2022 (UTC)

We should really have a task list as there are many things that change and need updating. Including but not limited to:

Most templates that used the previous namespace convention broke, including nav templates.
Many game files changed locations and their pages need to be updated.
Raws need to be updated.
Various features added, changed, removed.
UI has been changed -- though I am more inclined to wait for classic release to avoid extra work --Jan (talk) 06:56, 20 December 2022 (UTC)

"Raws need to be updated." Including applying text wraparound where necessary, I suppose - more than a few of them have proven to be that special kind of...difficult to navigate otherwise, shall we say? Silverwing235 (talk) 12:52, 20 December 2022 (UTC)

There is already a task list in the section below that includes templates and raws, with an explanation. —Lethosor (talk) 16:25, 20 December 2022 (UTC)

v50 migration

The initial migration script is done. New content is in the main namespace, e.g. Cat. Old content is still at DF2014:Cat. History was migrated to the new (main namespace) articles.

I know several things are broken still. Please reply if you find any others:

~~Versioned templates haven't been migrated yet (e.g. {{vermin}} on Ant)~~
- Fixed. Most were migrated by a bot.
~~Raws are missing on all pages that use them.~~
- This also affects sidebars, such as on Cat and Microcline.
- Update: The DFRawFunctions extension has been upgraded to include v50 raws, using the "v50:" prefix for filenames instead of "DF2014:". ~~I haven't finished a migration script to create the /raw pages themselves, but they can typically be created manually by copying the DF2014 /raw pages and changing "DF2014" to "v50" everywhere.~~ —Lethosor (talk) 20:20, 1 January 2023 (UTC)
- Update 2: Raws have been added for all pages! They were copied from the "DF2014" pages and had "DF2014" replaced with "v50", which appears to have worked from a spot-check, but let me know if you find any problems. —Lethosor (talk) 05:57, 4 January 2023 (UTC)
Some pages where the DF2014 page was a redirect to a main namespace page that contained content were migrated incorrectly.
- In this case, the main namespace page is usually a redirect to itself. This can be fixed by undoing LethosorBot's edit to the main namespace page, then copying the content to the DF2014 page.
- Update: most seem to have been fixed manually - thanks! —Lethosor (talk) 19:41, 21 December 2022 (UTC)
~~Some main-namespace talk pages redirect to DF2014 talk pages. Some of these redirects work, and some (usually older ones) do not.~~
- Fixed with a bot. Some redirects from talk pages to other deleted talk pages are now broken, e.g. Talk:Above_ground (exists) -> Talk:Tile attributes (redlink). I am leaving them like that because they redirect to where the talk page should be created, but I'm also fine with people deleting them if they really want to. —Lethosor (talk) 19:41, 21 December 2022 (UTC)
{{quality}} for new articles is disabled (see below)
Some links from DF2014 to Main weren't working: e.g. the version selector DF2014:Mason's workshop was linking to DF2014:Main:Mason's workshop instead of Main:Mason's workshop. I'm not sure exactly why, but I fixed it with a change to the NamespaceLinks extension. Let me know if you spot similar broken links. —Lethosor (talk) 23:19, 21 December 2022 (UTC)

—Lethosor (talk) 04:54, 20 December 2022 (UTC)

The quality levels of the 50.03 pages seem to be missing. I'm not sure if that's covered under that first point. Trainzack (talk) 06:47, 20 December 2022 (UTC)

If the the Dwarf Fortress Wiki:Quality feature can be made to work with namespace scheme change, I suggest to automatically assign the lowest quality rating to all pages, alternately add the {{old}} to all pages. Otherwise there will be a lot of pages that will fall through the cracks. --Jan (talk) 09:12, 20 December 2022 (UTC)

I disabled {{quality}} in the main namespace because it would require some rework to make the rating script and the template work properly there. Feel free to take a stab at the template. I will see what can be done on the extension side. —Lethosor (talk) 21:14, 20 December 2022 (UTC)

What needs to be done on the template side? I'm not sure I see too big of an issue leaving pages as "unknown-quality" for now (or just change the default to tattered) until we get the rating script working. Is that script up anywhere, anything that could be helped with? Vallode (talk) 11:10, 2 January 2023 (UTC)

They're already marked as unknown. Really the only issue I know of with the template is that it doesn't show up with some of the newer skins we added, and that can be fixed by getting rid of the absolute positioning. As for the script, it can be found at https://github.com/DF-Wiki/QualityRatings, and the issue is really only with the configuration system not recognizing the main namespace as valid. —Lethosor (talk) 02:29, 3 January 2023 (UTC)

Great, I started having a crack at fixing the template with different themes. Is the preference to get some CSS going and then include it in the global stylesheet (i.e different styles per theme) or to try and get a "one size fits all" fix? —Vallode (talk) 08:14, 3 January 2023 (UTC)

I would rather avoid custom site-wide CSS if we can. —Lethosor (talk) 03:29, 4 January 2023 (UTC)

I appreciate that, I think it's the simplest solution to add a few lines to common.css though. Unless there is a way to attach CSS specifically to a template, I saw a few extensions that allowed that but I'm not sure if any are present in the wiki at the moment. Regardless there already exists a class `div.topicon` that is specifically for the quality ratings, is there an issue with expanding this class to accommodate the themes? The list of themes where the quality rating display is broken/invisible: Citizen, MinervaNeue, MonoBook. —Vallode (talk) 21:48, 4 January 2023 (UTC)

What do you think of moving the template out of the topicon entirely and just placing it in a div? It would take up a (hopefully) small amount of vertical space in the article. User:Lethosor/Sandbox/Quality_test is an example. Unfortunately it isn't possible to prevent other templates from displaying above the quality this way ([1]). So maybe we do need some custom CSS after all if we want that. I'm open to trying out whatever you propose. I'm a bit worried about future-proofing against skins we add later (particularly a mobile skin) but at least MediaWiki supports skin-specific global CSS as well. —Lethosor (talk) 00:33, 5 January 2023 (UTC)

I would rather we avoid taking any more vertical space in the article. The growing block pyramid at the top, starting with version template, is annoying. If you end up placing it inside the article space please use a slim box 100% wide that would include both.--Jan (talk) 01:19, 5 January 2023 (UTC)

Agreed with you Jan, however I see that as two different tasks (ArticleVersion template changes, getting quality back on pages). I made a test adjustment to the quality and it takes up a negligable amount of extra space. See User:Vallode/sandbox#Page_quality for the example, we'd be able to completely remove "topicon" (unless it is used somewhere else?) and then potentially move on to making the ArticleVersion template into a slim version on the left-hand-side instead of a large box? Let me know what you think. --Vallode (talk) 17:35, 5 January 2023 (UTC)

Sorry, I just noticed this, I hope you weren't waiting on me. I haven't looked into how it works. All I can say that it would be nice if it shows on main, it is annoying that it shows on discussion and history. And otherwise I think that those negligible spaces adds up when you have multiple notice, redirection etc templates and would prefer if you can condense all of it somehow. I also had couple of ideas on that front, but as dev designer you probably can come up with something more refined if this is direction you choose. --Jan (talk) 00:50, 10 January 2023 (UTC)

It appears some pages are redirecting recursively and never resolving correctly, like the [table] and tileset repository 07:35, 20 December 2022 (UTC)

Indeed, these can be caught here: Special:DoubleRedirects --Jan (talk) 07:51, 20 December 2022 (UTC)

It might be useful to change the notice title to "release information for editors" --142.59.195.176 10:26, 20 December 2022 (UTC)

Can do. —Lethosor (talk) 16:27, 20 December 2022 (UTC)

New here, hello. Should we set a date where we remove/only show the banner for logged in users. There are (some) pages that have 4 different notices about the upgrade. Engraving is one such page, the top banner states "information for editors", we then have the "this page was migrated" banner, a version selection which warns the article might be inaccurate, and a smaller banner saying the page might need to be updated. Quite a lot of screen space, I think we can start to slowly reduce the amount of warnings this coming month? Vallode (talk) 10:07, 2 January 2023 (UTC)

Unfortunately, only showing info to logged-in users is difficult with how MediaWiki caching works. In terms of reducing warnings, there is a discussion here. —Lethosor (talk) 21:43, 4 January 2023 (UTC)

As for Engraving specifically, the {{old}} banner was actually present on DF2014:Engraving as well and got carried over with the migration. I removed it, and agree that it was redundant. —Lethosor (talk) 21:46, 4 January 2023 (UTC)

Main talkpages seem to redirect to DF2014 talk. Not sure if it is intentional but I like it, though we should pay attention when creating new discussion relating to v50 ending up there.--Jan (talk) 14:18, 20 December 2022 (UTC)

That's unintentional. I specifically wrote the migration script to not move talk pages, but that has the side-effect of leaving any previously-created "Talk -> DF2014 talk" redirects intact. —Lethosor (talk) 16:27, 20 December 2022 (UTC)

Yo Lethosor, are we adding graphic sprites for the pages in some way? Or are we waiting for you to add some sort of new template or something? I'm sure you don't need me to tell you that the current templates don't allow that. Not sure if I'm allowed to change/create any templates either, as I don't want to break things for hundreds of pages. Edit: And IF the icons are allowed, should they be left alone, or 2×-3× sized like how the Minecraft wiki does it? --Zippy (talk) 14:29, 20 December 2022 (UTC)

Depends on which templates you mean. There are copyright concerns with uploading a premium sprite sheet, for instance. —Lethosor (talk) 16:27, 20 December 2022 (UTC)

I'm not talking about uploading an entire sprite sheet. I'm just talking about individual icons for each respective page. One image for cows, one for horses, one for werebeasts, etc. --Zippy (talk) 16:50, 20 December 2022 (UTC)

If we do that for every creature in the sprite sheet, that's not much different (in terms of copyright) from uploading the entire sprite sheet. —Lethosor (talk) 17:09, 20 December 2022 (UTC)

Is there someone we can talk to about that? We finally get this new game with graphics, and then we can't use the very graphics of the game? No matter what the rules are, I'd say that would be the stupidest thing ever. I know I'm infamous here when it comes to copyright and images and stuff, but about 80% of game wikis out there are completely unofficial, and use game file images like no one's business. I can't imagine anyone's door being knocked on if we used the game's sprites, but I won't add any here until we have a go-ahead. --Zippy (talk) 17:14, 20 December 2022 (UTC)

...I've made noise in Mayday's direction on this matter, at least (prob an incorrect maneuver, but).Silverwing235 (talk) 17:55, 20 December 2022 (UTC)

I hope some sort of arrangement can be made so we can use the new sprites with permission/limits, just as we are using the raw files. Otherwise we are all (devs and editors alike) shooting ourselves in the foot here.--Jan (talk) 21:07, 20 December 2022 (UTC)

I just thought of something. We're supposedly not allowed to upload entire sprite sheets, right? What if - for the time being - we just use a few of them for the purpose of testing out new infoboxes? --Zippy (talk) 21:46, 20 December 2022 (UTC)

I don't know. If someone could ask Kitfox and post the response here, that would be great. —Lethosor (talk) 21:47, 20 December 2022 (UTC)

I've reached out to Alexandra, but she hasn't answered yet. Until then I found these old approvals from the previous community manager, Feeona: (link1, link2). Waiting for a newer response until we begin mass uploads is probably the politer option, but like Zippy said, it is also standard for wikis to use game sprites with less approval. I second their idea of trying it out with a few images to test the infoboxes. On the extreme off-chance (and I do think it is) Kitfox protests we can always remove these few. --Voliol (talk) 22:19, 20 December 2022 (UTC)

And here is a third, more official statement: (link3). Perhaps that address of info@kitfoxgames.com is the better channel to ask for a confirmation, rather than Discord DMs, but I will be going to bed, so it is best if someone else does that. --Voliol (talk) 22:29, 20 December 2022 (UTC)

Thanks for tracking this down! Ok, sprites should be fine, but let's avoid uploading the entire premium tileset as a single image, for instance (as the forum thread says, "use common sense"). —Lethosor (talk) 00:21, 21 December 2022 (UTC)

Looks good, permission is always preferable over fairuse, I think it is a win win for all involved. I agree that we shouldn't upload entire sprite sheets (e.g. there is no reason to upload the windmill from every direction or whole construction phase for workshops) and that there are a lot of details that needs to be ironed out through testing. --Jan (talk) 05:07, 21 December 2022 (UTC)

We have a green light on uploading all and any sprites. Their response to me can be seen here. I'm sure someone else confirmed it before me. --Zippy (talk) 19:00, 21 December 2022 (UTC)

Shifting temporarily to a new issue, is the documentation of Template:ArticleVersion outdated? It would seem so to me, since the current version no longer has its own namespace, with the templates needing updating being different ones. --Voliol (talk) 18:30, 20 December 2022 (UTC)

I think it is still accurate enough. We left open the possibility of making another namespace in the future, albeit with a different migration strategy - see above. —Lethosor (talk) 21:52, 20 December 2022 (UTC)

Some Changes to infoboxes might be needed. Too bad User:Doorkeeper isn't around. He did a great work with navbox project--Jan (talk) 20:52, 21 December 2022 (UTC)

I just realized that raw files aren't stored as regular wiki pages but loaded via the DFRawFunctions extension (hence the need to update). Good news it's going to be handled in bulk, consistently and relatively easy to updated. Even better it's Lethosor problem ;) Also I just realized that all the "raw files" (txt files in the new vanilla folder) are released into the public domain. Both are probably not news to the vets but I'll leave it here for those who less up to date like myself. --Jan (talk) 07:35, 22 December 2022 (UTC)

I noticed that some templates aren't working properly in the new namespace, e.g. Basalt entry had its raw updated manually but the infobox fail to show any details. Cursory look suggest {{layerlookup/0}} need a minor tweak. This should do the work

Replace: {{layerlookup/aux|{{{{FULLPAGENAME}}/raw}}|uses={{{uses|}}}|wiki={{{wiki|}}}}}

With___: {{layerlookup/aux|{{:{{FULLPAGENAME}}/raw}}|uses={{{uses|}}}|wiki={{{wiki|}}}}}

Not sure what the plan and ETA with raws update so I didn't touch this high usage template for now. --Jan (talk) 08:11, 24 December 2022 (UTC)

Please do feel free to make this update. I am still working on a script to create the /raw pages themselves. —Lethosor (talk) 03:12, 1 January 2023 (UTC)

Wouldn't it be an idea to add to the Sitenotice to remove the {{migrated article}} tag when an article has been fully updated? I see many articles that seem to be updated still have the tag. And/or advise to make use of the {{verify}} for sections still in need of checking? --Halavus (talk) 10:12, 2 January 2023 (UTC)

Probably a good shout. The "see this page" link does include the detail on removing but we should more explicitly encourage removing the banner once a page has at least been looked over. Vallode (talk) 11:01, 2 January 2023 (UTC)

v50 specific issues

Graphics

Follow up on the use of game sprites and the need to trying it out with a few images to test the infoboxes. First sprite File:Beds v50.png was uploaded and used on Bed entry. Any thoughts? --Jan (talk) 18:06, 21 December 2022 (UTC)

Seems like it should be rearranged to be horizontal. Also, has there been a serious discussion about copyright? Full screenshots are 100% fine, but you start going into a grey area when you upload pieces of a spritesheet. I'm of the opinion that it's all fine as long as it's inconvenient to reconstruct the full sheet from the individual images. Maybe a further restriction could be you shouldn't upload any of the art unless it's used in an infobox (maybe an exception for pieces of the UI). And one more restriction could be you shouldn't show everything, like in your bed example, maybe just the wooden bed is good enough, leave out the stone and metal, especially since those can only be made from strange moods. Brightgalrs (talk) 18:43, 21 December 2022 (UTC)

Actually, your bed image is kinda bad for showing off what a bed looks like because it doesn't show the pillow/blankets. That might point to cropped screenshots being the best path, although less convenient for the uploader, as you don't get details left out. Brightgalrs (talk) 18:46, 21 December 2022 (UTC)

I created a new license template Template:Copyright game, based it on the way the RimWorld wiki does things. Call it a prototype, but it's probably how your bed image should be labelled. Indeed, I added it to it already. Brightgalrs (talk)

I agree that the horizontal arrangement would suit better here and that we should strive to represent how things look in-game. Otherwise, I am not too concerned about people being able to reconstruct anything (lets just say that anyone interested in that can get the real thing from the game files), also it seem we have permission to use the sprits on top of fairuse. --Jan (talk) 19:55, 21 December 2022 (UTC)

Modifying the existing template to allow the inclusion of the new sprites is easy (Something like this?) The big question is the matter of consistency is there any exceptions that will break the format (size wise with variant bloat for example), the sprite naming format, etc --Jan (talk) 20:44, 21 December 2022 (UTC)

If we are going to show a variant for each material type, then maybe these should be added as separate images so we can add a tooltip for each image. --Jan (talk) 20:49, 21 December 2022 (UTC)

I've got another prototype going here and here: User:Brightgalrs/vector.css and User:Brightgalrs/Sandbox. (You'll need to add the css stuff to your own /vector.css). Basically it's a way to recolor images using css classes. No idea if there's a better way. Also, the real implementation would require a change to MediaWiki:Common.css. Brightgalrs (talk) 22:41, 21 December 2022 (UTC)

Should mention, there is a different way, just upload each image 16 times, one for each coloring. But maybe that's not very elegant. Brightgalrs (talk) 22:45, 21 December 2022 (UTC)

It should be noted that soon the classic edition will be released, hence one should plan to have both the Premium and classic alongside in that little space --Jan (talk) 03:14, 22 December 2022 (UTC)

I'm looking into a tab extension to potentially support this in infoboxes. Perhaps Extension:Tabs? I tried Extension:TabberNeue, but it displays a placeholder if JavaScript is disabled, which isn't great. —Lethosor (talk) 04:22, 22 December 2022 (UTC)

The Neue Tabber seem to works pretty much like the old one (which fandom still use) defaulting to showing the first tab only. Quick look suggest that neue work the same, plus the notice that 'Tabber requires Javascript to function' warning? if so, and if it is a bother, then you should be able to edit out the tabberneue-noscript string in code. --Jan (talk) 06:29, 22 December 2022 (UTC)

I much prefer your tabber solution, but if that fails we can also use the gallery slideshow mode. If so, beware it has no way to control image size so the images have to be maliciously uploaded using the exact same size. example:

--Jan (talk) 10:19, 22 December 2022 (UTC)

adding premium set to Infobox

I am unclear where are we going with this?
1) Will (A) tabs be implemented, (B) we be using mediawiki toggle example for premium and classic/blocked, (c) put images side by side, or (d) something else?
2) Also silver and Pig iron use very different image style for example.
3) Anything else you want ? --Jan (talk) 12:32, 30 December 2022 (UTC)

Personally, I would love tabs to be implemented, but I think that side by side might be best for most. --Jan (talk) 12:32, 30 December 2022 (UTC)

Here is rough layout we can use. It should fit most buildings given the default sprite size. There is also a different floor plan for both (inspired by reddit)

5×5

toggle

Hotkey: bog

		o
	░	░	░	\
/
o	░	░	░
			~

Layout

3×3

toggle

Hotkey: bog

	"	=
░
░	]	░

Layout

1×1

Hotkey: bog

╧

X

1×3

Hotkey: bog

32px

═

X

Any thoughts on the direction and or any and all of its elements? --Jan (talk) 10:16, 31 December 2022 (UTC)

I kind of like side-by-side, if it fits. If anyone wants to implement a toggle button or tabs, I would ask that that be implemented in a template for now, so that e.g. we could change a toggle button to tabs in a single place if we decide to install an extension to support that. —Lethosor (talk) 03:14, 1 January 2023 (UTC)

I noticed a comment saying that impassable tile are no longer used in v50, is that true for all constructions? If so, floor plans are no longer needed, making things much easier as we can fit everything in except the 5v5 constructions like trade depot (and even these can be placed one above the other if so desired). If not, any thought on the alternative floor plan design? --Jan (talk) 07:46, 1 January 2023 (UTC)

None of the constructions have blocking tiles any more from my experience playing. I haven't tested siege weaponry with that stuff, but none of the workshops have it, nor does any furniture. (walls and fortifications will of course obstruct movement AndrielChaoti (talk) 18:47, 1 January 2023 (UTC)

Ok, I have removed them from v50. --Jan (talk) 23:48, 1 January 2023 (UTC)

I have added a basic side by side variant to Template:V50 workshop and Template:Building for testing, let us know if there any issues. Few notes:

The default image naming scheme of workshop-name.png will likely conflict with existing images here or on commons, maybe another naming scheme should be used like v50 workshop-name.png as it is with ascii pictures.
There is inconsistency in image size. If you want to use large zoomed images then toggle is best, otherwise they need to be all in native size (96px for 3x3).
In the current version the code roughly centers the images and if there is a big image like with Siege workshop it drops to a new line --Jan (talk) 23:48, 1 January 2023 (UTC)

How about combining shortcut keys and the new menu icons:

b

o

l

--Jan (talk) 02:24, 3 January 2023 (UTC)

I worry that this is difficult to read (I read it as "boil" at first). I would rather use something like {{k}} with a known background. What about something like this?

l

or, alternatively, using flexbox without any overlap:

l —Lethosor (talk) 02:37, 3 January 2023 (UTC)

Same, but that is the best I came up with. We can use the key or maybe someone can help improve the design. Also 'l' is hard to read even with {{key}}.--Jan (talk) 03:05, 3 January 2023 (UTC)

I added a {{Menu icon}} to start things so others can have a go with it. Also any thoughts on the icon naming convention (their shortcut sequence), is there easier/better way? --Jan (talk) 09:36, 3 January 2023 (UTC)

User:BarelyCreative updated the template:

b

o

l

y. I think it looks good, thoughts? --Jan (talk) 18:40, 3 January 2023 (UTC)

I like that, yeah. —Lethosor (talk) 03:29, 4 January 2023 (UTC)

There were some places where it didn't make sense so display every icon all the time (like step-by-step guides), so I changed it slightly to allow display of fewer icons using "num" and counting from the end: {{Menu icon|b|o|l|y|sep=-;|num=2}}

l-

y BarelyCreative (talk) 09:05, 4 January 2023 (UTC)

Bizarre palette-swapping idea/prototype

No idea if this is a good idea, since it takes a bit of time to set up, and there might be some performance issues... and maybe display issues?

But take a look at this:

It's way to swap palettes on an image, although the image itself is a table, with each cell representing a pixel. The template itself looks like this: {{User:Brightgalrs/Sandbox/PaletteSwitch|templatename=User:Brightgalrs/Sandbox/Rock|palette-name=saffron}} Input the pattern and desired palette name.

I've got a larger showcase here: User:Brightgalrs/Sandbox/PaletteSwapShowcase. Only did a rock pattern so far, but all palettes are implemented. The major use for this would be on each stone, metal, wood, etc. type's page. The palette could be read directly from the raws. Brightgalrs (talk) 03:22, 24 December 2022 (UTC)

From a technical perspective, my primary concern is indeed performance. Both on the server side and client side, a large number of tables that large (in terms of markup and cell count, that is) tend to be resource-intensive to generate and render. I saw your image-filtering experiments on User:Brightgalrs/vector.css, and while that strikes me as a newer and less-backwards-compatible approach, it would probably be more resource-friendly.

Is this color adjustment something the game is doing natively? i.e. does this accurately match what the game displays? I bet we could slap together an image-filtering extension (or find an existing one?) that can do this if needed. —Lethosor (talk) 03:49, 24 December 2022 (UTC)

Yeah that's what I suspected. The images the template creates are spot on, checked it against a screenshot I took of some mica rocks in-game. The css stuff is unfortunately totally incorrect, was cool to learn about it though, so not a complete waste of my time :p. The premium, in-game graphics are true sprites, basically patterns of indexed colors. Each of the in-game colors (which are significantly expanded over the 16 ascii colors, there's 116/117) there is a palette defined in "\Dwarf Fortress\data\vanilla\vanilla_descriptors_graphics\graphics\images\palettes.png". Each indexed color of the sprite is swapped for the corresponding color in the palette. Because of that, the css stuff doesn't work since it's doing the hue/saturation/brightness changes to the entire sprite.

I've looked into an existing mediawiki extension, couldn't find anything. One thing I did't really look at is some type of lua script/module that would basically emulate what the game is doing. So some function that takes in the base image as well as the desired palette, and based on that finds and replaces each color. No idea what mediawiki's capabilities are on that front. Brightgalrs (talk) 05:31, 24 December 2022 (UTC)

We do have Scribunto installed now, so it's totally possible to do something in Lua too - forgot about that. I can add you to the group that grants access to edit the Module namespace if you want to give that a shot. If we use an extension, we'd probably need a custom one, similar to DFDiagram (or perhaps DFDiagram could be extended - it's in dire need of a rewrite anyway). —Lethosor (talk) 05:43, 24 December 2022 (UTC)

I asked around on the mediawiki irc, I think scribunto/lua is a deadend, at least for taking an uploaded image and doing stuff to it with a lua script. However I did come up with this even more bizarre solution, using block elements. User:Brightgalrs/Sandbox/PaletteSwapShowcase2, maybe less resource intensive? Definitely displays a lot worse though, probably unusable.

██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████
██████████████████████

I dunno, maybe none of this is worth it and we should just write some external program to put all the images together offline, and then just mass upload. It wouldn't be that many... Brightgalrs (talk) 06:37, 24 December 2022 (UTC)

Is there an easy way to just paste images from the clipboard?

I use KDE spectacle to take screenshots straight to the clipboard (after cropping) -- is there an easy way to just paste (and auto-upload) an image into an article? It would make it a lot easier to contribute images. Kelvie (talk) 23:35, 1 January 2023 (UTC)

Unfortunately there is not. I would be open to a MediaWiki extension to support this if someone finds one. —Lethosor (talk) 00:32, 2 January 2023 (UTC)

Looks like this could do it, but I haven't used it before: https://www.mediawiki.org/wiki/Extension:SimpleBatchUpload Kelvie (talk) 19:41, 2 January 2023 (UTC)

It won't solve paste-from-clipboard, but this would be great for making uploading sprites much easier (auto-cutup spritesheet, rename, bulk upload). Could you add this, Lethosor? OddballJoe (talk) 21:47, 6 January 2023 (UTC)

Standards for adding graphical version screenshots and images

Hello, new user looking into adding imagery from the new version. Is there a standard for quality of new screenshots or images? I noticed that at a certain zoom level (2 zooms in from the furthest zoomed-out view), the graphics appear crisp and 1:1 pixel scaled, and I would propose that all images be taken at this scale whenever possible. If they need to be displayed larger, they should be nearest neighbor scaled in a photo editing program at 100% increments (Microsoft Paint will do this if you first select the image rather than directly scaling the whole canvas). I would also propose that images should be cropped to conform to the 32x32 pixel grid when possible, though this could be problematic with so many new graphical elements exceeding the bounds of their tiles. I would say the best practice for capturing artwork for items, furniture etc. ought to be done in a 3x3 open area to avoid shadows from nearby walls, or else extracted from the raw files (if this doesn't run afoul of being able to re-create the graphical version using those assets).

I know that perfect is the enemy of good, and any documentation is better than none, but just thought I'd ask about this, and see if/where something like this ought to be posted. Unclesporky (talk) 13:58, 3 January 2023 (UTC)

It has been stated in Template:V50 workshop that screenshots should be at the "native" resolution but someone could edit the Screenshot page for best practice for the steam version. Or post some examples in Talk:Screenshot to find out what is best? --Halavus (talk) 14:21, 3 January 2023 (UTC)

How would I/should I go about putting creature sprites on their pages?

Howdy. New player and wiki user here. I wanted to try and help update the wiki to the Steam release of DF, so I figured I'd chip in by putting each creature's sprites on their respective page, since I'll often look up a creature I have yet to see in game only to be met by a blue J, or whatever. I found all of the game's creature sprites in C:\Program Files (x86)\Steam\steamapps\common\Dwarf Fortress\data\vanilla\vanilla_creatures_graphics\graphics\images, so I figured I could just chop those up in Photoshop and stick them on here no problem, but the programming syntax/whatever it is on this site is incredibly confusing, I don't know how I'd actually go about doing it. I figured I'd just find the spot on the page where the little letter is and replace that with the image code, but it seems the pages are built using heavily nested templates that I can't even begin to understand. Any help?--Treese (talk) 03:07, 5 January 2023 (UTC)

Based on Zippy's work at {{Creaturelookup_b}}, I added an "image" parameter to {{creaturelookup/0}}, which is what creature pages should all be using. See Dwarf and Cow for examples. —Lethosor (talk) 05:37, 5 January 2023 (UTC)

Hotkeys/Menu navigation

Most key bindings and menus have changed. Should the article reflect a) only the old version, b) only the GUI version or c) both? For example, bridges used to be built via b -> g, but now it's in Place strucutures b -> Constructions n -> Bridge b. What should be written in the article? Currently, it's b -> g. I think it should be only b), but I am not sure if there will be differences regarding hotkeys or menus between the premium version and the free version and then, c) would be the most appropriate option. --Prometherus (talk) 10:16, 22 December 2022 (UTC)

Not sure. I wish the classic release soon --Jan (talk) 16:45, 22 December 2022 (UTC)

Are you Toady's herald? Looks like it was just released! Brightgalrs (talk) 18:18, 22 December 2022 (UTC)

And our questions are answered, the old hotkeys seem to have been thrown out. Part of me is disappointed (useless muscle memory) but also relieved (unified UI for both versions is good in general and for the wiki). Brightgalrs (talk) 18:25, 22 December 2022 (UTC)

According to info, in a sort of 'demo version' at that. I'll wait a little while longer, for myself.Silverwing235 (talk) 18:22, 22 December 2022 (UTC)

It's unlikely that keybindings in it will change significantly. My vote is that we should include information for both premium and classic, everywhere. Hopefully the keybindings are not different between versions. —Lethosor (talk) 18:26, 22 December 2022 (UTC)

Shouldn't it be based on the 50 or what verion the article is written for? Dominick ^(TALK) 18:42, 22 December 2022 (UTC)

The keybindings seem to be consistent between versions, (haven't checked exhausitvely, but since the menu layout is the same I think it is a good assumption). Should also keep in mind/consider that not all actions have keybindings. An option would be write 'Click on the <Example Text> icon or press E' Koos (talk) 23:14, 23 December 2022 (UTC)

Removed features & concepts

Since they're removed concepts, I've set Room to be a redirect for DF2014:Room and created Template:Activity zones for the nav bar bedrooms, etc, and made the necessary changes to Bedroom for it. Is this the correct approach, before I go on much further? (also a note, if it is, then Template:v50_rooms probably needs to be deleted) I also imagine that considering the number of changes in the interface, that things like Adventure mode and related pages might best be truncated to "not in 50.03" and when it does make it across, being more deliberately brought over in pieces? HawkOwl (talk) 06:23, 23 December 2022 (UTC)

Usually it is marked with Template:Removed_feature. For example: Dipscript or Party. --Jan (talk) 07:45, 23 December 2022 (UTC)

Ah, that's fair. Should that be mentioned in Dwarf_Fortress_Wiki:Versions#Redirects? HawkOwl (talk) 10:03, 23 December 2022 (UTC)

I think the redirect policy mostly had in mind things that were removed a long time ago, like Tax collector and Economy (and the latter actually has a stub page as well). I guess we could clarify. —Lethosor (talk) 19:34, 23 December 2022 (UTC)

The "current" redirects also cause the version box to incorrectly show that the current version has a page - e.g. 23a:Cave_river shows a v50.04 version, but it's just a redirect back to that version. Similarly, what should happen to redirects like Clothes maker, where a concept has evolved? It currently goes to 23a:Clothes maker - that's correct if the user is trying to look up a very old concept, but if a new user is looking for "how to make clothes", they should be directed to Clothier. --Danny252 (talk) 12:16, 26 December 2022 (UTC)

One should be careful with cv redirects. Most that were recently adjusted were unused plural forms (that should probably be deleted) but few like Crown needed that for backward compatibility. Removing the cv part means the the link on v0.31:Tilesets is now broken. --Jan (talk) 22:30, 26 December 2022 (UTC)

If v0.31:Tilesets is about v0.31, it should not be using "main:" in its links - all of those links are going to pages about v50, not v0.31, regardless of whether the target is a redirect or not. —Lethosor (talk) 23:37, 26 December 2022 (UTC)

You right, I removed it. --Jan (talk) 17:55, 27 December 2022 (UTC)

Crown cv redir issue is now fixed, I believe. As goes with such cases where one can simply revert the troublesome edit, unless I've mistepped, myself? Silverwing235 (talk) 23:52, 26 December 2022 (UTC)

Both [2] and [3] should not have had any effect, because "cv" is an alias to the main namespace now, just like "main". Proof: Crown, cv:Crown, main:Crown. It's possible caching is coming into play here, although I purged the redirect cache after making that alias change earlier this month... —Lethosor (talk) 00:02, 27 December 2022 (UTC)

I think there have been some changes not captured, but as a newb, I'm afraid to edit the page(s). A good example is Strawberry. I'm playing the Steam version right now and Strawberry plants are "not relevant to brewing" in Labor > kitchen > veg / fruit / leaves. Unless I'm mistaken and need to process them? Another example is the trade caravan = it seems the 3 square pathing no longer happens; it's just yak(s). 12:31, 28 December 2022 (UTC) 12:29, 28 December 2022 (UTC)

Strawberries should be brewable according to the Raws.

Trade wagons has been modified in v50. The first wagons will arrive at the same time your fort is becoming a barony. Until then, it's only pack animals and stairs are indeed fine. The Trading page needs a huge rework anyway... I'll try to do that next week. --Halavus (talk) 13:40, 2 January 2023 (UTC)

As far as I can tell, none of the workshop buildings in v50 have blocking tiles any more. There's a comment to the like in data/vanilla/vanilla_buildings/objects/building_custom.txt that says this "[BLOCK:1:0:0:0] workbenches no longer block". Hesitant to update that template as I'm not sure if it's referenced for all of the old versions too. AndrielChaoti (talk) 05:54, 29 December 2022 (UTC)

A new template has been created: {{V50 workshop}} --Halavus (talk) 13:40, 2 January 2023 (UTC)

Thanks! In general, I would like to delegate the switching responsibility to the template (like how {{creaturelookup/0}} works), but in cases where the parameters diverge significantly like with workshops, it could make sense to make an entirely new template. —Lethosor (talk) 02:40, 3 January 2023 (UTC)

creature infobox prototype (moved)

Check it out, I made a temporary template and added it to the cows page. Now it shows the sprites (but not the zombified versions yet). I wanted to show everyone a prototype of what v50 creature infoboxes should look like. Or at least something similar to it. --Zippy (talk) 19:11, 27 December 2022 (UTC)

Hi, I'm new to editing wikis but I have done a bit of work with sprite sheets and I've been going through the DF data files to find the different graphics hoping to help with the animal pages. I've thrown together a template with grass and a few nature sprites (plants, a tree, and a rock) for size reference but I'm unsure how large the 'display' tiles in the middle of the template should be to suit all animals. I can see in the sprite sheets that some land animals have an adult and child sprite, so two tiles. Others have a male, female, and child, but after seeing you include the zombie cows I'm unsure if I should make it twice the size to add them too. Alternatively, I could grab some tiles from the haunted biomes for the zombie animals and make a separate template for a side-by-side comparison. Either way, let me know if this helps. I'd like to help with other graphics too as we add the premium tilesets but the animals seemed the easiest to tackle with me being new to wiki editing. ~~UristTheSeventh (talk)

@Zippy, I am a bit perplexed about the purple cows. Why do we need a zombified version of creatures on every page?

@UristTheSeventh, we can use all the help. Maybe post an example, so that we can have something to compare and contrast.--Jan (talk) 11:49, 3 January 2023 (UTC)

@Jan Here are the examples:

It'll need to be wider or arranged differently for different creatures with more that two sprites or for multi-tile creatures. I can also do an aquatic and air themed template for swimming and flying creatures. ~~UristTheSeventh (talk)

Looks nice, like the metal template. There are several people working on updating the graphics you should talk more among yourselves. Best I can offer is that I width wise I am hoping to go up to 200px for infoboxes.--Jan (talk) 01:13, 5 January 2023 (UTC)

We don't exactly need a zombie sprite on each page. I added it because it was... there. I was also hoping to get some opinions on it anyway since that infobox is a visual prototype, and not a final choice. --Zippy (talk) 03:28, 6 January 2023 (UTC)

Furniture Infobox

!!UNKNOWN!! · xTATTEREDx · +FINE+ · *SUPERIOR* · ≡EXCEPTIONAL≡ · ☼MASTERWORK☼

I made a v50 furniture template prototype. I tested this on Firefox, Chrome and Microsoft Edge/Internet Explorer and it looks fine on all of them. I hope this is good enough to be the official thing, unless I'm missing something. --Zippy (talk) 03:28, 6 January 2023 (UTC)

When do we remove the migration note on specific pages?

At what point can we remove the "this page was auto migrated from v47" warning? There are a bunch of small pages that are more or less accurate, if I've reviewed them, can I go ahead and remove the warning? Kelvie (talk) 23:33, 1 January 2023 (UTC)

Yes, feel free to remove it if you think all content is accurate. —Lethosor (talk) 00:31, 2 January 2023 (UTC)

Any info on fixing "creature description not found?"

I see this issue on most creature pages, it seems to be due to a lookup that's not currently functioning? Cows interestingly doesn't have this issue but I couldn't figure out how to recreate whatever fix it's editor did. --Yallendallis (talk) 00:22, 3 January 2023 (UTC)

That is the missing raws issue described above. Cow was fixed by the addition of cow/raw. —Lethosor (talk) 02:28, 3 January 2023 (UTC)

Ah makes sense, not fully used to the language of wikis yet so I read over it while looking. To put this bit of questioning to rest for any future readers, is it correct that it's fine to update any raws manually, though it will be done automatically at some point? --Yallendallis (talk) 07:48, 3 January 2023 (UTC)

Yes. I'm circling back to work on a script right now, so not much point in doing it if you're reading this. —Lethosor (talk) 04:57, 4 January 2023 (UTC)

This should be fixed now. If you continue to see pages with problems, you can try purging the cache. —Lethosor (talk) 05:59, 4 January 2023 (UTC)

Adventurer Mode related sections

The topic has already been discussed above, but I don't see a clear line on what to do with article sections that mention Adventurer Mode. Like for example in Butcher.

a) Truncate or b) leave in place with a mention that the mode is not yet present IG but will be added in a future update?

Personally I think option b) is better, because I think it's silly to undo some work just to reintroduce it a few weeks later, with the necessary corrections. Even if a copy/paste of a previous version takes ~15 seconds, considering the number of articles that need to be corrected, it would be a bit of a waste of time.--Halavus (talk) 14:22, 3 January 2023 (UTC)

Toggleable image

Any objections/comments to using this template for now for toggling between classic and premium images? I'd probably rename it to "Template:Premium-classic thumb image". I'm sure someone can come up with a better UI eventually, but should be easy to migrate at that point. I also think we should use the same customtoggle class for this and for the infobox. NiftyManiac (talk) 23:12, 1 January 2023 (UTC)

Toggle ASCII

Toggle ASCII
My caption

This looks nice to me! —Lethosor (talk) 00:30, 2 January 2023 (UTC)

Good initiative. From the top of my head:

I suggest using a shorthand, no one wants to type 'Premium-classic thumb image'.
If we end up using toggle for infoboxes (not sure where we headed there), then I agree definitely same custom toggle class should be used for all, thus allowing to switch premium-classic view on the whole page at a click.
The button part on a separate row isn't pretty, creating a lot of dead space that can be used by the text. Are we set on the label 'toggle ascii'? Classic isn't Ascii per se, maybe we can use a 'toggle' with a tooltip for example, or maybe we can get rid of the text and have a smaller icon button (two examples).

I hope that helps. --Jan (talk) 11:21, 2 January 2023 (UTC)

I added Template:Dual image with some of your suggestions. Agree that it's not super pretty, feel free to try something different.

I put the toggle in the caption mostly because I gave up on trying to make a more sophisticated replacement for the default thumb image behavior, I'm sure someone with better wiki-fu could put together something more intelligent.
I cut the text down to just "Toggle"; I think the best solution would be a small graphic showing the old and new dwarf icons with arrows between them. NiftyManiac (talk) 19:21, 2 January 2023 (UTC)

ToggleA 5x5 room with a 3x3 farm plot

I updated the layout, now it should look just like a regular image thumb. I didn't had time to test it, if it doesn't work for you or you don't like it just revert the last change. cheers. --Jan (talk) 21:46, 2 January 2023 (UTC)

I don't know which part of this talk page to put this, but I added the ability to add icons to the v50 workshops template. Leaving the icon part blank will not break the template in any way. --Zippy (talk) 09:47, 3 January 2023 (UTC)

Creature List Now Supports Graphics!

I wasn't easy, but I made new templates so the Creatures page now supports both graphics sprites and ASCII tiles. Allow me to show you:

Tile	Name	Playable	Hostile	Food Source	Adult Body Size	Pet Value (×)	Biome	Features
☺	[[Dwarf]]	Fort, Adv	No	No	60,000	Not tameable	Mountain halls, dwarf fortresses, hillocks	Trading race
e	[[Elf]]	Adv	Variable¹	No	60,000	Not tameable	Forest retreats	Trading race
U	[[Human]]	Adv	Variable¹	No	70,000	Not tameable	Towns and cities	Trading race
g	[[Goblin]]	Adv	Usually¹	No	60,000	Not tameable	Dark fortresses and dark pits	Snatchers²
k	[[Kobold]]	Adv	Usually¹	No	20,000	Not tameable	Caves	Skulking race

Oh wait, there's a bonus. You can also modify the background color of the box the sprites go in. I added that to make possibly-hard-to-see-otherwise sprites more easy to see - depending on the colors it has. Allow me to demonstrate.

Tile	Name	Playable	Hostile	Food Source	Adult Body Size	Pet Value (×)	Biome	Features
☺	[[Dwarf]]	Fort, Adv	No	No	60,000	Not tameable	Mountain halls, dwarf fortresses, hillocks	Trading race
e	[[Elf]]	Adv	Variable¹	No	60,000	Not tameable	Forest retreats	Trading race
U	[[Human]]	Adv	Variable¹	No	70,000	Not tameable	Towns and cities	Trading race
g	[[Goblin]]	Adv	Usually¹	No	60,000	Not tameable	Dark fortresses and dark pits	Snatchers²
k	[[Kobold]]	Adv	Usually¹	No	20,000	Not tameable	Caves	Skulking race

To change the background color, add |bgcolor=COLOR segment after the |graphic part. You can use color names or HTML hex color codes. I added this to the v50 creatures page, but at this time, I only added the first five creatures I just displayed. It's gonna take a while to find ALL of those creature sprites. I hope a lot of people help out on that one. --Zippy (talk) 05:29, 5 January 2023 (UTC)

Thanks, looks nice! —Lethosor (talk) 05:44, 5 January 2023 (UTC)

Nice stuff, took the quick liberty to change the padding-left -> text-align to make all the sprites center aligned relative to each other :) Sweet work --Vallode (talk) 17:41, 5 January 2023 (UTC)

Good work indeed. One minor issue, is that all the sprites have different sizes, which sometimes create slight variation in table row height. Consider using capping the image size vertically for example [[File:dwarf_sprite.png|x32px]]--Jan (talk) 18:15, 5 January 2023 (UTC)

Also often in such tables people want to click on the image to go for the specific entry, and often will try to click on the very first thing they see in line the thumb image, but currently that will take them to the file page. Consider adding link parameter for example: [[File:dwarf_sprite.png|x32px|link=dwarf]]

or no link at all [[File:dwarf_sprite.png|x32px|link=]]

--Jan (talk) 18:24, 5 January 2023 (UTC)

I mean... Yeah, I could do that. I think that lessens the quality of the sprite a bit because it makes edges blurry, but either way is fine. I could have sworn I added a link for all those images the first time. --Zippy (talk) 03:23, 6 January 2023 (UTC)

Since we are adding pixel art sprites to the website it might be convincing to add a global class like .sprite or .pixel-image that uses the CSS attribute `image-rendering: pixelated;` in order to prevent blurryness when scaling the image up/down. Just a thought --Vallode (talk) 09:40, 6 January 2023 (UTC)

Are we able to attach classes directly to images? If so, we can probably attach inline styles directly as well. —Lethosor (talk) 16:52, 6 January 2023 (UTC)

Looks like (without an extension) MediaWiki only supports classes on images:

and not styles:

it just treats it as alt text it looks like? Wrapping it in a div works and demonstrates the difference:

. Speaking from experience, however, image-rendering needs a browser specific prefix in certain browsers (safari, for example) in order to work properly. I'm not entirely sure what the best "MediaWiki" practice is for adding something like this but I would assume it's a simple class in common.css for now. --Vallode (talk) 17:17, 6 January 2023 (UTC)

Ah, yeah, you are correct, I should have checked https://www.mediawiki.org/wiki/Help:Images. I'd be fine adding a class like that to common.css. —Lethosor (talk) 17:27, 6 January 2023 (UTC)

Great, in that case if no one is opposed we can add `.game-sprite` or something like that? See below for the CSS, the order of the attributes is relevant. --Vallode (talk) 18:23, 6 January 2023 (UTC)

/* Used for pixel-art images from the game so they can be resized and maintain crisp pixel edges. */
.game-sprite {
	image-rendering: -webkit-optimize-contrast;
	image-rendering: crisp-edges;
	image-rendering: pixelated;
}

So... you guys think each creature page should show the main sprite(s) alone, or should it show the baby versions alongside them? --Zippy (talk) 08:37, 8 January 2023 (UTC)

I think adult + baby is sensible, the adult + baby + zombie was not, in retrospect. So yeah adult + baby (if there is one) from now on would be my vote. --Vallode (talk) 23:27, 8 January 2023 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Well then, there's a TON of creatures to go - and I mean both the creatures page and the individual creature pages. I really hope everyone can pull their weight on that those images. The spritesheets are easy to find, and if you know how to read the .txt files near them, finding sprites on certain rows and columns should be a breeze. --Zippy (talk) 00:47, 9 January 2023 (UTC)

Zippy, are you doing all of this by hand? That seems quite tedious. Cutting up the spritesheets can be done automatically. Renaming and updating the table could be done with a script and/or chatgpt. We'd need Lethosor to add the batch upload extension though. Maybe some manual work in updating names to match article names rather than raws. OddballJoe (talk) 06:55, 9 January 2023 (UTC)

So did the graphic people gained insights and reached some sort of consensus? are we using big up scaled images + toggle? multiple images to(adult + baby)? anything else? --Jan (talk) 00:32, 10 January 2023 (UTC)

I noticed that someone blew up the size of the previews in infoboxes. Was that you Jan that did that? Whoever did that enlarged the DFtext tile as well. Don't know if that was intentional or not. I'd prefer if the sprites were either left alone or at double-sized max (or however they look in-game at 1:1 - not zoomed in or out), though that's just me. It looks like maybe they're triple-sized or something.

@OddballJoe - It's not all by hand, I have some Photoshop scripts that cut my work time in half, or even by a third. Lethosor said something about us not uploading entire spritesheets. If we did it the entire spritesheet way, one update to the sheet could misalign everything and screw up many pages. For example, let's say Kitfox slipped in an extra couple rows of creatures in an image file, that means the other rows under it would be misaligned and pages would show the wrong creatures. Know what I mean? I'd still prefer if other people jumped in and added sprites, though. --Zippy (talk) 00:51, 10 January 2023 (UTC)

Graphics in Skill Infoboxes

**Skill: Miner**
Sprite(s)

Association
Profession	Miner
Job Title	Miner
Labor	Mining
Tasks
Dig
Workshop
None
Attributes
Strength Toughness Endurance Willpower Spatial Sense Kinesthetic Sense

I've made yet another visual prototype for skills. In other words, we can put sprites of matching dwarves (and possibly humans, elves, goblins, etc.) at the top of infoboxes. If multiple images are put up there, that can mess up the alignment, but don't worry, Zippy thought of that. |graphicmargin can added, and a percentage or a "px" number can be placed in that parameter to fix it. If you leave said parameter out, the alignment will default to about 42% from the left. --Zippy (talk) 06:06, 7 January 2023 (UTC)

{{v50_skill
| color      = 7:0
| graphic    = [[File:miner_sprite_icon.png]]
| graphicmargin = (OPTIONAL)
| skill      = Miner
| profession = Miner
| job name   = [[Mining]]
| tasks      =
* [[Dig]]
| attributes =
* Strength 
* Toughness 
* Endurance
* Willpower
* Spatial Sense
* Kinesthetic Sense}}

Not sure I understand the alignment issue, can you not put text-align: center on the parent table element instead of messing with explicit margins? As another sidenote, should we continue to be naming all of these templates v50_x, I find that a bit confusing. Why not just edit the main templates with the additional information. Loving all the new templates though nice work Zippy :) --Vallode (talk) 11:43, 7 January 2023 (UTC)

No, text-align doesn't work with images and divs. That just works for text. When it comes to images, you got to put a little "finesse" on the CSS with those. As for editing the classic templates with the new info, it doesn't always work that way with every template. Lethosor I think did update the creature infobox template in the way you mentioned. --Zippy (talk) 08:37, 8 January 2023 (UTC)

You can use something like this to automatically handle that--Jan (talk) 08:56, 8 January 2023 (UTC)

Hah I am very familar with the CSS finese :P Can you show me an example of a multi-sprite job infobox? I said what I said because I tested my proposed solution and it worked fine :)

Dwarf Fortress Wiki talk:Versions

Contents

Version 0.31.19 starts a new DF generation?

Revisiting Redirects

Google often directs people to the 0.31 page

DF2014?

Redirects inconsistency

Reorganizing versions

Weird redirect behaviour

v50 organization

v50 migration

v50 specific issues

Graphics

adding premium set to Infobox

Bizarre palette-swapping idea/prototype

Is there an easy way to just paste images from the clipboard?

Standards for adding graphical version screenshots and images

How would I/should I go about putting creature sprites on their pages?

Hotkeys/Menu navigation

Removed features & concepts

creature infobox prototype (moved)

Furniture Infobox

When do we remove the migration note on specific pages?

Any info on fixing "creature description not found?"

Adventurer Mode related sections

Toggleable image

Creature List Now Supports Graphics!

Graphics in Skill Infoboxes

Navigation menu

Search