- v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
- Use this page to report any issues related to the migration.
Difference between revisions of "User talk:Quietust"
Line 33: | Line 33: | ||
::::::::Fair enough. That aside, which of the above should I use? Lookup both the object ID and raw file from the creature name hardcoded into the page, or lookup just the raw file from the object ID hardcoded into the page (dropping "Creature id lookup" and rewriting "Creature file lookup")? Should that code go directly in the /raw pages, or should we put it into {{tl|creature raw}} instead (which has now gone unused)? Also, feel free to mess around with the <nowiki><noinclude>'d</nowiki> formatting on [[DF2010:Beetle/raw]] (possibly put it inside another template or two - 'begin' and 'end', perhaps - in case we want to change it in the future) - given the number of /raw pages this will create (just short of 700), I'd prefer to get them right the first time. I've already got the bot script itself written, and it'll just be a matter of changing the line where it assembles the page contents. --[[User:Quietust|Quietust]] 12:55, 6 May 2010 (UTC) | ::::::::Fair enough. That aside, which of the above should I use? Lookup both the object ID and raw file from the creature name hardcoded into the page, or lookup just the raw file from the object ID hardcoded into the page (dropping "Creature id lookup" and rewriting "Creature file lookup")? Should that code go directly in the /raw pages, or should we put it into {{tl|creature raw}} instead (which has now gone unused)? Also, feel free to mess around with the <nowiki><noinclude>'d</nowiki> formatting on [[DF2010:Beetle/raw]] (possibly put it inside another template or two - 'begin' and 'end', perhaps - in case we want to change it in the future) - given the number of /raw pages this will create (just short of 700), I'd prefer to get them right the first time. I've already got the bot script itself written, and it'll just be a matter of changing the line where it assembles the page contents. --[[User:Quietust|Quietust]] 12:55, 6 May 2010 (UTC) | ||
:::::::I think we should stick as little on the page as possible. If each page is just a template or two with simple parameters, switching things out later will be easy. I'm imagining something like this: | :::::::I think we should stick as little on the page as possible. If each page is just a template or two with simple parameters, switching things out later will be easy. I'm imagining something like this: | ||
− | < | + | <nowiki>{{creaturesomething|creature}}<noinclude>{{creaturerawcat|creature}}</noinclude></nowiki> |
:::::::where ''creature'' is either the name or the id. I think id is better since that reduces the total amount of plumbing we need to have, and the it's less likely to be changed in the future since objects in DF refer to each other by id. Then on template:creaturesomething we can stick all the formatting and a call to {{t|creature raw}}, which we can make a straightforward raw-delivery function (which is useful elsewhere; eg: {{t|creatureInfo}}). Template:creaturerawcat can contain <nowiki>{{category|raw pages}}</nowiki> for now, but maybe later we'll want to rename the category or put a more complex hierarchy there. [[User:VengefulDonut|VengefulDonut]] 13:48, 6 May 2010 (UTC) | :::::::where ''creature'' is either the name or the id. I think id is better since that reduces the total amount of plumbing we need to have, and the it's less likely to be changed in the future since objects in DF refer to each other by id. Then on template:creaturesomething we can stick all the formatting and a call to {{t|creature raw}}, which we can make a straightforward raw-delivery function (which is useful elsewhere; eg: {{t|creatureInfo}}). Template:creaturerawcat can contain <nowiki>{{category|raw pages}}</nowiki> for now, but maybe later we'll want to rename the category or put a more complex hierarchy there. [[User:VengefulDonut|VengefulDonut]] 13:48, 6 May 2010 (UTC) | ||
+ | ::::::::If we include any formatting in template:creaturesomething itself, then that formatting will just appear as plain text in the "Raws" box at the bottom of the creature page, and we don't want that, hence putting it inside templates and transcluding it inside <nowiki><noinclude></noinclude></nowiki> tags before and after the actual data. --[[User:Quietust|Quietust]] 13:57, 6 May 2010 (UTC) | ||
===Good idea=== | ===Good idea=== |
Revision as of 13:57, 6 May 2010
Instructions for a Pleasant Talk Experience |
---|
In the interest of keeping discussions in one place:
|
Comments
- Please place new comments at the top of this section. If you are replying to a message I placed on your user talk page, please place the reply on your talk page and place your signature in the "Reply Notification" section above. To add a comment, simply edit this section and add a new subsection (with three equals signs around the title).
Gamedata
You. rock. Holy. crap. --Briess 19:33, 4 May 2010 (UTC)
- The tiny column of raws is unusable. I think we're better off not having it in the same place as the creature box. VengefulDonut 12:29, 5 May 2010 (UTC)
- Here's an idea:
- Let's stick the raw lookup template for the individual creatures and such on their /raw page and pull that using the gamedata template on the main page. Thoughts? VengefulDonut 14:45, 5 May 2010 (UTC)
- An interesting idea, and one that would probably be easy enough to automate. It would also make the name->ID and name->raw_file.txt lookup tables unnecessary, since the /raw pages could just be made to contain something like {{raw2:DF2010:creature_standard.txt|CREATURE|DWARF}}. However, it'll also result in a ton of tiny pages to maintain, especially those that use DF2010:creature_standard.txt which had been split into 3 parts to stop it from crashing PCRE. --Quietust 14:55, 5 May 2010 (UTC)
- Then it will probably be easier to deal with if you keep the lookup template active. That way if a file needs to be split again then only the lookup changes. You think you could make your bot stick the appropriate things on the raw pages? Also, maybe lump them into a raw file category. VengefulDonut 15:47, 5 May 2010 (UTC)
- Clearly, the "file" lookup should be kept; however, I figure the "id" lookup could probably be dropped since there's no reason they would ever need to change (and the only reason I added them was because I was looking up the raws based on the page name). See DF2010:Beetle/raw for a sample data page using both templates - dropping down to just the one lookup will change it as follows and necessitate changing the "file lookup" template to translate from raw ID to filename rather than general name to filename. --Quietust 17:41, 5 May 2010 (UTC)
- Then it will probably be easier to deal with if you keep the lookup template active. That way if a file needs to be split again then only the lookup changes. You think you could make your bot stick the appropriate things on the raw pages? Also, maybe lump them into a raw file category. VengefulDonut 15:47, 5 May 2010 (UTC)
- {{#ifexist:{{DF2010:Creature file lookup|beetle}}|{{#tag:nowiki|{{raw2|{{DF2010:Creature file lookup|beetle}}|CREATURE|{{DF2010:Creature id lookup|beetle}}}}}}|Unable to locate raws!}}
- {{#ifexist:{{DF2010:Creature file lookup|BEETLE}}|{{#tag:nowiki|{{raw2|{{DF2010:Creature file lookup|BEETLE}}|CREATURE|BEETLE}}}}|Unable to locate raws!}}
- Also, I'd prefer to get some sort of consensus before continuing that we really want to create all of these /raw subpages. --Quietust 21:55, 5 May 2010 (UTC)
- The process of creating these /raw subpages started quite a while back, and has continued in a haphazard way since. The only difference is yours automatically updates itself. VengefulDonut 03:05, 6 May 2010 (UTC)
- My concern is that the templates I've written effectively make the /raw pages completely unnecessary, hence my wanting to make sure we still want to go in the direction of using the /raw pages at all. --Quietust 04:27, 6 May 2010 (UTC)
- Your templates make it easy to put a raw in the box, but for the really wide raw entries that cause scrolling, seeing it on a page is easier to use. So a slight adaptation of what you have enables both. VengefulDonut 05:29, 6 May 2010 (UTC)
- Fair enough. That aside, which of the above should I use? Lookup both the object ID and raw file from the creature name hardcoded into the page, or lookup just the raw file from the object ID hardcoded into the page (dropping "Creature id lookup" and rewriting "Creature file lookup")? Should that code go directly in the /raw pages, or should we put it into {{creature raw}} instead (which has now gone unused)? Also, feel free to mess around with the <noinclude>'d formatting on DF2010:Beetle/raw (possibly put it inside another template or two - 'begin' and 'end', perhaps - in case we want to change it in the future) - given the number of /raw pages this will create (just short of 700), I'd prefer to get them right the first time. I've already got the bot script itself written, and it'll just be a matter of changing the line where it assembles the page contents. --Quietust 12:55, 6 May 2010 (UTC)
- I think we should stick as little on the page as possible. If each page is just a template or two with simple parameters, switching things out later will be easy. I'm imagining something like this:
- Your templates make it easy to put a raw in the box, but for the really wide raw entries that cause scrolling, seeing it on a page is easier to use. So a slight adaptation of what you have enables both. VengefulDonut 05:29, 6 May 2010 (UTC)
- My concern is that the templates I've written effectively make the /raw pages completely unnecessary, hence my wanting to make sure we still want to go in the direction of using the /raw pages at all. --Quietust 04:27, 6 May 2010 (UTC)
- The process of creating these /raw subpages started quite a while back, and has continued in a haphazard way since. The only difference is yours automatically updates itself. VengefulDonut 03:05, 6 May 2010 (UTC)
- Also, I'd prefer to get some sort of consensus before continuing that we really want to create all of these /raw subpages. --Quietust 21:55, 5 May 2010 (UTC)
{{creaturesomething|creature}}<noinclude>{{creaturerawcat|creature}}</noinclude>
- where creature is either the name or the id. I think id is better since that reduces the total amount of plumbing we need to have, and the it's less likely to be changed in the future since objects in DF refer to each other by id. Then on template:creaturesomething we can stick all the formatting and a call to {{creature raw}}, which we can make a straightforward raw-delivery function (which is useful elsewhere; eg: {{creatureInfo}}). Template:creaturerawcat can contain {{category|raw pages}} for now, but maybe later we'll want to rename the category or put a more complex hierarchy there. VengefulDonut 13:48, 6 May 2010 (UTC)
- If we include any formatting in template:creaturesomething itself, then that formatting will just appear as plain text in the "Raws" box at the bottom of the creature page, and we don't want that, hence putting it inside templates and transcluding it inside <noinclude></noinclude> tags before and after the actual data. --Quietust 13:57, 6 May 2010 (UTC)
- where creature is either the name or the id. I think id is better since that reduces the total amount of plumbing we need to have, and the it's less likely to be changed in the future since objects in DF refer to each other by id. Then on template:creaturesomething we can stick all the formatting and a call to {{creature raw}}, which we can make a straightforward raw-delivery function (which is useful elsewhere; eg: {{creatureInfo}}). Template:creaturerawcat can contain {{category|raw pages}} for now, but maybe later we'll want to rename the category or put a more complex hierarchy there. VengefulDonut 13:48, 6 May 2010 (UTC)
Good idea
VengefulDonut 02:19, 30 April 2010 (UTC)
- Also, dealing with metals should be feasible now :) VengefulDonut 02:23, 30 April 2010 (UTC)
- Well, maybe not.. the way the alloy templates are set up will make it nasty. Do you think anyone will mind if they're scrapped? VengefulDonut 02:29, 30 April 2010 (UTC)
Bituminous coal
Oops. Not sure how that came about Oo VengefulDonut 21:34, 26 April 2010 (UTC)
Raws
I set the query for random page to prevent finding pages with /raw in the title ( NOT LIKE '%/raw') for now, and once we have the handy dandy fancy raw extractor stuff, we'll use that. --Briess 12:59, 23 April 2010 (UTC)
- P.S. thanks for letting me know about that potential problem ;) --Briess 13:00, 23 April 2010 (UTC)
Template:23a Metal
I was just curious about this new template. Is there a particular reason that a new template was necessary? I had thought that the regular Template:Metal was fully version-independent, but I could be wrong. I'm just interested in helping make templates as reusable as possible. --Soy(T-C) 15:29, 21 April 2010 (UTC)
- Metals in 0.23.130.23a don't necessarily use the same foreground color for bars and for background-colored furniture - for example, copper bars are brown and produce brown furniture, but copper barrels are red with a brown background, while bronze is yellow and a bronze barrel is yellow with a brown background. I was also trying to replicate the original infobox template used on the old wiki, since it depicted the source materials as ores rather than metal bars (and in the 2D version, you could only make alloys from ores, never bars). There's also the fact that the newer templates unconditionally include Construction as an option, and constructions did not exist back in 23a. The {{23a Ore}} template was made for a similar reason - the current one doesn't handle the unmined tile and the mined stone being different colors (even in current versions, only a few stones actually behave that way, and none of them are ores), and there was no such thing as an economic stone back then (so it was completely impossible to use ores for masonry or stonecrafting). --Quietust 15:50, 21 April 2010 (UTC)
- Thanks for the response. I guess it just irritates me on some fundamental level that all of the templates can't be re-used across all of the version namespaces, but it does not seem like it would be worth the time investment in this case to make the changes. It must be the latent programmer coming out in me. At least it seems like the majority of the templates will work OK between the new version and 40d. One tiny suggention I would make though, you may want to add {{Category|Metals}} and {{Category|Ore}} respectively to those two templates, so the pages get filed appropriately. :) --Soy(T-C) 18:14, 21 April 2010 (UTC)
- It's one thing to have forward compatibility, but given the huge amount of changes between the 2D and 3D versions it's not surprising that some of the current templates don't work with the old stuff. Also, by "those two templates", should I assume that you meant {{Metal}} and {{Ore}} as well as {{23a Metal}} and {{23a Ore}}? --Quietust 18:24, 21 April 2010 (UTC)
- Ugh, my apologies, apparently I was assuming that the Metal and Ore templates already had category tags in them. Instead I just looked and it seems like the category tags were manually placed on each individual page. Sorry about that. Having the tags added by the template saves a lot of editing in my opinion, but it's up to you how you want to handle it. I'll work on prying my foot out of my mouth. --Soy(T-C) 18:44, 21 April 2010 (UTC)
- There's also the minor annoyance that including the {{Category}} tag in the template itself also causes the template to be categorized if it transcludes itself as an example, which isn't what we want. If we know that the {{Category}} template will never be used to categorize templates, it would be easy enough to just place a check inside the template itself to check if the namespace is "Template" and simply omit the category tag entirely. --Quietust 18:48, 21 April 2010 (UTC)
- That funcionality is already built into Template:Category, with room for expansion should you want to use it to categorize other types of pages. Just a simple #switch on the page namespace. --Soy(T-C) 19:24, 21 April 2010 (UTC)
- Actually, no it isn't - while the template can change which category gets included, it does not prevent a category tag from being added at all. This would be easy enough to fix - just wrap the outer Category tag with {{#ifeq:{{NAMESPACE}}:Template||...}}. --Quietust 19:27, 21 April 2010 (UTC)
- Sorry, I misunderstood what you were saying. If I understand correctly, isn't this the same issue you encounter when inlcuding a normal category tag in a template? Like you said, it shouldn't be a big issue to correct, although I have noticed that Mediawiki doesn't always resolve the markup language in the order that I expect it to. I suppose it could also be fixed on each template that transcludes it, but that defeats the purpose. --Soy(T-C) 19:49, 21 April 2010 (UTC)
- Actually, no it isn't - while the template can change which category gets included, it does not prevent a category tag from being added at all. This would be easy enough to fix - just wrap the outer Category tag with {{#ifeq:{{NAMESPACE}}:Template||...}}. --Quietust 19:27, 21 April 2010 (UTC)
- That funcionality is already built into Template:Category, with room for expansion should you want to use it to categorize other types of pages. Just a simple #switch on the page namespace. --Soy(T-C) 19:24, 21 April 2010 (UTC)
- There's also the minor annoyance that including the {{Category}} tag in the template itself also causes the template to be categorized if it transcludes itself as an example, which isn't what we want. If we know that the {{Category}} template will never be used to categorize templates, it would be easy enough to just place a check inside the template itself to check if the namespace is "Template" and simply omit the category tag entirely. --Quietust 18:48, 21 April 2010 (UTC)
- Ugh, my apologies, apparently I was assuming that the Metal and Ore templates already had category tags in them. Instead I just looked and it seems like the category tags were manually placed on each individual page. Sorry about that. Having the tags added by the template saves a lot of editing in my opinion, but it's up to you how you want to handle it. I'll work on prying my foot out of my mouth. --Soy(T-C) 18:44, 21 April 2010 (UTC)
- It's one thing to have forward compatibility, but given the huge amount of changes between the 2D and 3D versions it's not surprising that some of the current templates don't work with the old stuff. Also, by "those two templates", should I assume that you meant {{Metal}} and {{Ore}} as well as {{23a Metal}} and {{23a Ore}}? --Quietust 18:24, 21 April 2010 (UTC)
- Thanks for the response. I guess it just irritates me on some fundamental level that all of the templates can't be re-used across all of the version namespaces, but it does not seem like it would be worth the time investment in this case to make the changes. It must be the latent programmer coming out in me. At least it seems like the majority of the templates will work OK between the new version and 40d. One tiny suggention I would make though, you may want to add {{Category|Metals}} and {{Category|Ore}} respectively to those two templates, so the pages get filed appropriately. :) --Soy(T-C) 18:14, 21 April 2010 (UTC)
bar vs bars
It doesn't matter that they're called "bars" in game, since the style guide dictates singular forms
Yes, as the correct game term it does matter, and no, the style guide doesn't "dictate" that. It specifically says "Exceptions are proper nouns and terms that are always plural" - and there is no metal "bar" in the game. And now is the time to change it - just because it was wrong before, doesn't mean it should stay wrong. It is the same as "plate armor" was in 40d - one term referring to more than one item. However, I don't want to get into an edit war, and will leave it. I disagree, tho' - both "bar" and "bars" are metal, and anything else is either, specifically, "vertical bars" or "floor bars".--Albedo 04:33, 20 April 2010 (UTC)
40d:obsidian
I'm pretty sure you meant to be looking at the DF2010 version of this article
<facepalm> Clearly, time to have a beer and get afk for a while. Thnx!--Albedo 04:44, 20 April 2010 (UTC)
speciality
is british english, specialty american english. IIRC, both can be used on the wiki unless it's explicitly a game term. ;)
Non-Newtonian Fluids
To further expound on my edit comments:
For a fluid to be non-Newtonian, one of three things must be true:
1. The shear stress of the fluid is non-linear when graphed against shear rate. (i.e. the fluid gets thicker/thinner depending on how quickly force is applied)
OR
2. The shear stress of the fluid is non-linear when graphed against time at a constant shear rate. (i.e. the fluid gets thicker/thinner depending on how long a constant force is applied)
OR
3. The fluid has non-zero shear stress when the shear rate is zero. (i.e. you have to exert force on the liquid to get it to start flowing, though it may continue flowing normally thereafter)
Magma definitely qualifies, because it's technically a suspension (i.e. a mixture of solids and liquid), rather than a pure liquid. And suspensions are always non-Newtonian.
All the best.
Gamedata
How would you feel about a version of template:gamedata that pulled information from raw files? VengefulDonut 03:58, 15 April 2010 (UTC)
- Would certainly be interesting, though I can't help but be concerned that this might put a lot of additional load on the wiki. Then again, it seems to be handling the stuff for stones just fine. --Quietust 17:56, 15 April 2010 (UTC)
- Apparently it's negligible. I was worried about that possibility too but have been reassured otherwise. Supporting previous versions shouldn't be difficult from the place we're at now. It may even just be a matter of passing the right things to the templates. VengefulDonut 02:44, 16 April 2010 (UTC)
Namespace Searches
It was set to work properly for new users about a month ago; however, user settings take precedence over system level settings. You might want to check them; if you think it's a problem, though, I can go through and modify everyone's settings globally with a script (but this overwrites all search settings) --Briess 21:56, 14 April 2010 (UTC)
- Oh yeah, forgot about that. They were indeed set to exclude those namespaces, but no longer. --Quietust 21:58, 14 April 2010 (UTC)
Alluvial is not soil
Blaugh, my bad. Read it elsewhere a while back and assumed it was accurate. --Retro 18:39, 13 April 2010 (UTC)
Slade / Demonic fortresses
A note on your removal of the 'digging into demonic fortress from underneath' bit - going from this quote on the Slade page ("Slade walls cannot be dug into. However, slade floors can.") it's presumably possible to do this by digging a down-stair into the bottom floor of the fortress. As I haven't found one myself nor did I add the original info I can't confirm, but it made sense to me when I first read it. --Retro 14:05, 8 April 2010 (UTC)
- However, the bottom floor of the demonic fortress tends to have solid slade walls beneath it, so there'd be nothing to dig into. It's possible that it could have empty space underneath it, given sufficient randomness, though the fact that it's possible to channel through slade floors (but NOT through the walls underneath them) is probably a bug in and of itself. --Quietust 14:36, 8 April 2010 (UTC)
- Good stuff, didn't know about the full walls underneath. Glad I ran it by you before just trying to pop it back in or something. --Retro 18:38, 8 April 2010 (UTC)
Code stuff
Not necessarily. I haven't really had a chance to look at the code yet (I've been busy all week until now), so I'm going to take a look and see how and if we should integrate that into our codebase. My primary concern is ease of continuing upgrades for mediawiki, but if it's simple enough, it shouldn't be a problem. --Briess 18:09, 1 April 2010 (UTC)
Fun -> #REDIRECT cv:Fun
Seems this is going back and forth - see Talk:Fun--Albedo 22:39, 28 March 2010 (UTC)
- Fair enough - I'll leave it alone. --Quietust 02:30, 29 March 2010 (UTC)
Bot Programming
What language is your bot using? Because if it's a language I know (which it probably is, because I know a lot of languages) I could definitely help you write code for changing all the links properly. Even though it might be more short term work, I think it's a better overall outcome than having modded files. Modded files make upgrading the software harder, etc... aside from the issue I mentioned about people assuming the links work one way from prior experience. Also, I just stole Wikipedia's Talkback template, Template:talkback something I think you'll like. Emi 18:29, 25 March 2010 (UTC)
- Just noticed the links up top, and thus why a bot to redo all the links might be tricky. I'll just go ahead and write a python bot to do it. Emi 18:32, 25 March 2010 (UTC)
Magma temp
Sorry, it was from a forum post. I realise my mistake now, but I'm too embarrassed to undo it. Could you please fix it? --Eagle0600 03:52, 30 January 2010 (UTC)
Archive
I do not have a db dump from that time. Do you still want the namespace, though? --Briess 00:55, 15 March 2010 (UTC)
- Sure - it'll just require some manual re-entry (which will be slightly annoying due to the fact that anonymous edits were disabled, so archive.org didn't manage to archive the "Edit" pages which would've contained the source markup). --Quietust 01:46, 15 March 2010 (UTC)
Tilesets
Oops. Sorry about that. I think I accidentally edited an old revision. VengefulDonut 18:50, 13 December 2009 (UTC)
Workshop Pictures
Heh, I was hoping I could bait you into creating the rest of the picture templates. :) Sorry about the +'s-- I forgot I had built those on smoothed tiles. --HebaruSan 04:49, 9 November 2009 (UTC)
chevron/caret
chevron is << or >>; ^ is a caret
This is minor, but wanted to bounce it off you. A "caret" is, specifically and solely, an editor's mark - it refers to a specific shorthand usage (inserting an edit) and not a shape, and I doubt if the majority of readers would be at all familiar with that term anyway. A "chevron" is either "^" or "v" - a sergeant's stripes are "chevrons". (Not sure where you get your horizontal form from.) I think "chevron" is a more generally recognizable, and thus more useful term, neh?--Albedo 22:21, 4 November 2009 (UTC)
- I'm just going by Wikipedia's definitions of caret and chevron. In particular, chevrons most often point down rather than up. --Quietust 22:42, 4 November 2009 (UTC)
- I would never use a Wiki as an authoritative dictionary, unless I wanted something more vernacular/modern, and then I'd go to urban dictionary.com. It's a function of that (amateur) editor that emphasizes one definition (or orientation) over another. Soldiers' stripes are "chevrons", and they can point up or down (country/era dependent), and the majority of heraldic uses are "up".
merriam-webster online dictinary: "chevron"
http://en.wikipedia.org/wiki/Chevron_%28insignia%29
http://www.merriam-webster.com/dictionary/caret (read again - "caret" is context specific. Also, how many DF uses would know the technical ASCII name?)
I'm going to change that one word back.--Albedo 01:42, 5 November 2009 (UTC)
- I would never use a Wiki as an authoritative dictionary, unless I wanted something more vernacular/modern, and then I'd go to urban dictionary.com. It's a function of that (amateur) editor that emphasizes one definition (or orientation) over another. Soldiers' stripes are "chevrons", and they can point up or down (country/era dependent), and the majority of heraldic uses are "up".
Decorations
Care to explain how I made this?
No, I don't use any mods. --LaVacaMorada 13:43, 23 October 2009 (UTC)
- I guess I stand corrected, then. It would seem that bone and shell decorations can go on anything. --Quietust 14:48, 23 October 2009 (UTC)
Defense Design
Thank you for cleaning up the defense design diagrams. They're so much more readable now! Especially the ballista battery. --HebaruSan 00:55, 20 October 2009 (UTC)
Formatting
Thanks for the help with the page format. I couldn't get that link to display properly with one set of brackets because of the | I was using between the link and name, thanks to you I don't have to choose between one unmatched bracket or an undesired pair now.--The Architect 16:59, 8 October 2009 (UTC)
booze hauling
Hm, is anon editing working? Anyway, I can't log in at work. Need to confirm booze hauling behavior, as I don't think it's automatic. Drinking may be a bit strange. One time I dumped a barrel right as a dwarf was running over to it to take a drink. The dumper beat him to it, and hauled the barrel off to the garbage dump. Urist McThirsty followed him all the way to the dump and chugged out of the barrel as soon as it was dropped (even though the barrel was auto-forbidden), then went on his merry way, leaving the barrel there. It's possible the forbidden status canceled an auto-haul. It's also possible that hauling is assigned to the nearest idle dwarf, and a guy that just finished drinking is momentarily "idle" and also closest. They do tend to flash "idle" for a moment before and after breaks, eating, and drinking. -24.154.179.50 14:58, 7 October 2009 (UTC)
- The bit about booze being automatically hauled to a stockpile was based on the observation of soldiers, guards, and nobles carrying a booze barrel while performing the job "Store Item in Stockpile", something they would normally never do. --Quietust 15:05, 7 October 2009 (UTC)
- (that was me) Ah, works for me then. -Arrkhal 20:19, 7 October 2009 (UTC)
statues
Why would it only be more efficient with copper, silver, gold, platinum, and aluminum ? --Birthright 19:54, 29 September 2009 (UTC)
- Most of the other metal are alloy I presume, so impossible to use the raw stone. --Karl 20:20, 29 September 2009 (UTC)
- No, that would be "possible", not "more efficient". Q is thinking that it's because the value is the same, for both ore/alloy and metal. He's not exactly right, because copper can be made into several alloys that would improve it, and other metal ores rely on becoming alloys - if you're not going to make nickel silver, then garnierite falls into that category too. But for the other 4, there is no possible value advantage to smelting into bars first, and then using three bars to make statues that are worth exactly the same as the one from 1 ore. (Unless your Blacksmith is considerably more skilled than your Mason, which is a stretch to begin with.) Probably should change that to something a bit less absolute.--Albedo 21:46, 29 September 2009 (UTC)
- Yeah, that's what I meant - there's no point in ever making a statue out of copper/silver/gold/platinum/aluminum bars when you can make it out of the native stone instead (which, in those cases, has the same value). Most metal ores are worth less than the metals themselves, though for the really cheap ones (like copper, nickel, tin, lead, and zinc) you'd be better off making the statue out of flux. --Quietust 22:08, 29 September 2009 (UTC)
- No, that would be "possible", not "more efficient". Q is thinking that it's because the value is the same, for both ore/alloy and metal. He's not exactly right, because copper can be made into several alloys that would improve it, and other metal ores rely on becoming alloys - if you're not going to make nickel silver, then garnierite falls into that category too. But for the other 4, there is no possible value advantage to smelting into bars first, and then using three bars to make statues that are worth exactly the same as the one from 1 ore. (Unless your Blacksmith is considerably more skilled than your Mason, which is a stretch to begin with.) Probably should change that to something a bit less absolute.--Albedo 21:46, 29 September 2009 (UTC)
salt water
the above paragraph already explains how to verify whether or not it is drinkable)
Yes, but it doesn't emphasize the need to not assume you did it correctly. That line was not a redundant "how to", but "make sure you do". The whole issue of a well that was non-drinkable (which worries me as well, re your recent edit) was that the player did not pay close attention.--Albedo 22:03, 23 September 2009 (UTC)
- I've readded a statement to basically advise double-checking, though my own testing revealed that a built well works fine for thirsty dwarves, whether from a murky pool or right at the shore itself. It's possible that it's the Z-level of the well that determines whether or not it works - placing a well in an underground cistern might not work as well as one placed on the surface... --Quietust 23:03, 23 September 2009 (UTC)
Alluvial vs soil
Good find. VengefulDonut 01:36, 11 September 2009 (UTC)
crop table
I didn't redesign the table. I brought back a previous design since the recent one was too obscure. VengefulDonut 12:04, 5 September 2009 (UTC)
no soap?
Soap needs an alchemist's lab, which needs 3 glass flasks - Are those ever available from caravans? I thought "No, so no sand = no flasks = no lab = no soap" - no? Never spec needed glass flasks from caravans, so dunno.--Albedo 21:51, 4 September 2009 (UTC)
- It's fairly well known that you cannot request glass or sand from caravans, so yep - no sand == no soap. --Quietust 22:35, 4 September 2009 (UTC)
Aluminum
Holy crap! That aluminum=platinum is huge! I had been playing all this time just assuming that aluminum was cheap (since it is in the real world.) Is there any way we can make this bigger? Noobs need to know about this. --3lB33 13:39, 24 August 2009
Purple Materials
Wonderful, *now* I found out there's a second purple stone after having already made a giant rose gold tomb... I guess I should of looked closer first, man was that a waste of gold. Shardok 01:07, 9 August 2009 (UTC)
- To be fair, you can usually find gold nuggets in much larger quantities than bismuthinite (since the latter only occurs in small clusters)... --Quietust 04:03, 9 August 2009 (UTC)
- Yeah, but I had such better uses for it, like making coins. Yes, we definitely needed more coins. But I know I had found far more bismuthinite on that map than I had gold, then again, I was turning the bismuthinite into bismuth bronze, so I wasn't going to give that up any time soon either. Honestly I should of just not made a giant purple tomb. Shardok 04:43, 9 August 2009 (UTC)
Actual character
Quietust (Talk | contribs) (actual character)
Actually, there is no single "actual character" for a bottomless pit - there are two "default" sets of icons for vanilla DF, the ascii and the included tile set. The character I get is like a very thick capital O, but a little boxy. It's certainly not a "o". --Albedo 21:50, 31 July 2009 (UTC)
Bot Requests
- If you would like to have a large number of page edits performed by QuietBot, then add a note here.
Fixing Cv: alias redirects
How easy with your bot is it to make sure all mainspace pages that redirect to a cv: page redirect to the same page as their name? Ex: if page Cheese redirected to cv:Cheese Maker, having the bot change it to cv:Cheese. My python bot seems to have trouble processing redirect pages on this wiki. Emi 06:10, 26 March 2010 (UTC)
- That should be fairly straightforward (for each page, open "pagename" for editing, check for string "#REDIRECT" and abort if absent, check for string "[[cv:" and abort if absent, check for string "[[cv:pagename]]" and abort if present, then replace page contents with "#REDIRECT [[cv:pagename]]" and save). However, doing that will introduce a whole ton of double redirects which might cause other problems. If that's what we really want to do, then it shouldn't take me long to assemble a script and run it. --Quietust 12:41, 26 March 2010 (UTC)
- That's what we want to do. It'll break some redirects (because not every page exists like it should), but broken redirects are a lot easier than red links. And yes, it will introduce double redirects, that's the point. Double redirects work just fine on this wiki (Briess changed the wgMaxRedirect variable) and will save us a ton of trouble. Emi 18:19, 26 March 2010 (UTC)
- I think I should also be figuring out why my bot doesn't like certain redirects. Because we also need to go through redirect chains and make sure that the talk pages follow the same chain as their respective normal pages. Emi 19:15, 26 March 2010 (UTC)
- That's what we want to do. It'll break some redirects (because not every page exists like it should), but broken redirects are a lot easier than red links. And yes, it will introduce double redirects, that's the point. Double redirects work just fine on this wiki (Briess changed the wgMaxRedirect variable) and will save us a ton of trouble. Emi 18:19, 26 March 2010 (UTC)
Mainspace 40d redirects
Could you have the bot take all the mainspace 40d redirects and change them to cv: instead of 40d:. Effectively the redirects will remain the same, but this way we're prepared for when the new version's namespace takes over as the current version. Thanks. Emi 19:52, 20 March 2010 (UTC)
- It is done. Only redirects within the main article namespace have been updated (e.g. ones within 40d itself continue to point to 40d), and talk page redirects have been omitted. --Quietust 23:32, 20 March 2010 (UTC)
Broken Redirects
Request: could you go through the pages on Special:BrokenRedirects and for each page, blank the page, then restore it? That will fix the linking engine (it's trying to link to the pages in the main namespace instead of the appropriate namespace, breaking and re-adding the link forces the parser to reevaluate) --Briess 19:41, 10 March 2010 (UTC)
- It's in progress and about halfway done. For now, I'm only having it handle redirects that point to the 40d namespace - I'll handle the rest of them in a second pass. --Quietust 20:55, 10 March 2010 (UTC)
- All done - the Broken Redirects count is now down to 79, all of which are real broken redirects. However, the double redirects page has now grown to 1666 entries, and fixing those won't be quite as easy - it might be feasible to have a script just follow the redirects manually until it finds a real page. --Quietust 21:16, 10 March 2010 (UTC)
Misc
- Please do so. All of my script utilities and several attempts at dropping to the SQL layer have failed to move all the pages, so I've been manually moving the broken talk page to the correct page, then deleting the broken version. --Briess 18:32, 8 March 2010 (UTC)
- List of still broken pages: http://pastebin.com/raw.php?i=x8msEevZ --Briess 18:32, 8 March 2010 (UTC)
Q - help me out. 40d Talk:Armor piece - where is that page now? And if it doesn't belong under the "new" page, then where? Archived under T:AP? I understand the premise of this migration, but not the mechanics. --Albedo 21:49, 8 March 2010 (UTC)
- I moved it back to its "broken" title so it can be fixed by hand afterwards. --Quietust 21:51, 8 March 2010 (UTC)