v50 Steam/Premium information for editors
  • 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.
This notice may be cached—the current version can be found here.

Dwarf Fortress Wiki talk:Diagram

From Dwarf Fortress Wiki
Jump to navigation Jump to search

Replacing {{diagram}}

I like what you're doing here

I agree that {{diagram}} needs a replacement, and I'm happy to see the work you've done on this. VengefulDonut (talk) 12:13, 24 July 2014 (UTC)

Improvements

The tiles display more evenly, the color system is cleaner, tileset support is really cool, getting away from regex is great, and character codes save needing to use a character table. I really like what I see here. VengefulDonut (talk) 12:13, 24 July 2014 (UTC)

Problems

Since the syntax is not backwards compatible (in particular, [#f00] does something different now), the wholesale replacement of {{diagram}} is difficult. If it is not replaced entirely then diagrams will continue to be created using the previous template (since people tend to copy what they see on a page). VengefulDonut (talk) 12:13, 24 July 2014 (UTC)

I've been planning to add an option to support the old color-code system (once I rewrite the parser so it's not a pain to do this :) ), which will allow {{diagram}} to use <diagram> internally. (Performance is a little slower with <diagram>, from what I've noticed, so I'd also like to hold off on changing everything until I can improve that.) —Lethosor (talk) 02:46, 27 July 2014 (UTC)

It is too complicated. The purpose of {{diagram}} is to have a diagramming system that's so easy anyone can use it without having to read documentation. Proper use should be clear from just seeing it used. The z-levels and variables are neat features, but they compromise this purpose. VengefulDonut (talk) 12:13, 24 July 2014 (UTC)

Z-levels and variables are optional - I find them helpful to avoid extra typing (with repeated rows, for example), but the old "one character per tile" method should still work. —Lethosor (talk) 02:46, 27 July 2014 (UTC)
Other editors need to be able to easily understand and edit what was written. We have a lot of opaque things on this wiki that make it difficult for people to contribute (admittedly, some of that is my fault), but they are partitioned off (to an extent). What worries me is that the extra features will become a vector for these "barriers of complexity" to get mixed in with ordinary pages. Diagrams get into all sorts of places (and with these better looking diagrams, likely more so). I think that new editing primitives need to be really important to justify their existence. The lack of variables can be worked around by unpacking them; the unpacked version will be easier for strangers to read and edit. I suggest using regexr or a similar tool to replace the variables automatically if you're working on something large. VengefulDonut (talk) 03:47, 27 July 2014 (UTC)

It has hotkeys. The only people that are going learn the hotkeys are people who read the documentation. The end product is something that looks like an image, so most visitors will interact with it as if it was an image. So multiple z-level diagrams effectively become systems for tricking editors into thinking they've delivered more information than they actually have. VengefulDonut (talk) 12:13, 24 July 2014 (UTC)

True. I'll look into adding more controls to make it more obvious. (Keyboard controls are also problematic in mobile browsers, so an alternative method would be nice.) —Lethosor (talk) 02:46, 27 July 2014 (UTC)

Since this is no longer a template, Special:WhatLinksHere can no longer be used to inspect (and possibly correct) the usage. Since the complexity has increased there is a greater need to be able to do this. VengefulDonut (talk) 12:13, 24 July 2014 (UTC)

If you're looking for a list of all pages using diagrams, automatically categorizing them should be fairly easy (possibly using a hidden category to avoid clutter). —Lethosor (talk) 02:46, 27 July 2014 (UTC)

{{RT}} still exists, and its use is still being encouraged. Nobody should have to go through that. ): VengefulDonut (talk) 12:13, 24 July 2014 (UTC)

I'm assuming you're referring to DF:Community portal - I think it works well for single-tile diagrams, but feel free to change that part if you feel it's inaccurate. —Lethosor (talk) 02:46, 27 July 2014 (UTC)
I thought I saw a message that suggests using RT or <diagram> show up during editing, but now I can't remember what triggered it. VengefulDonut (talk) 03:47, 27 July 2014 (UTC)

It seems your extension runs before the template substitution code. This prevents the use of <diagram> for infobox pictures. (ex: a

{{{1|a}}}

) VengefulDonut (talk) 19:36, 26 July 2014 (UTC)

This is how all parser extension tags work - you can work around this with {{#tag:diagram| {{{1|a}}} }}. —Lethosor (talk) 02:46, 27 July 2014 (UTC)
In that case, we can replace {{diagram}} with {{#tag:diagram|{{{1}}}}} as soon as the syntax is compatible. If this is what's going to happen, I think we should keep the template call as the suggested way to access it. VengefulDonut (talk) 03:47, 27 July 2014 (UTC)

A (slightly ambitious) feature wishlist

  • It should enable the full-scale replacement of {{diagram}}.
  • It should render as a single image. This makes it possible for people to download it and use it outside the wiki.
(It seems it's possible to enable saving a canvas element as a png (example). This one looks like low hanging fruit VengefulDonut (talk) 23:09, 25 July 2014 (UTC) )
Oh! It's possible to save them as pngs already, but some sort of text is capturing the right click and preventing it. VengefulDonut (talk) 19:39, 26 July 2014 (UTC)
Thoughts: currently, the image is being drawn on a canvas, which is javascript reliant. How difficult would it be to instead generate the image in php? Then it won't matter if people have javascript enables or not. VengefulDonut (talk) 03:57, 27 July 2014 (UTC)
  • The image should be indistinguishable from a DF screenshot (it looks like you've already got a handle on this part).
  • By default, the person viewing the diagram should have control over the tileset used to render it. There should be a tool by the diagram to allow people to change it.
  • It should be possible to override this default in order to deliberately display differences between particular tilesets.
  • It should be possible to make the choice of tileset persist across the wiki as an account setting, a user script, a cookie, or something else.
  • This setting should also be transferable through URL variables, so that it is possible to link to a specific page displayed with a specific tileset.
  • It should be possible for a tileset maker to upload their own tileset to the wiki and configure all diagrams to display in their tileset (by default) without editing any other pages.
  • It should be possible to override the color scheme to match modded in-game color schemes by uploading a colors.txt file.
  • With the same customizability and scope as tilesets.
  • Graphics set support.
  • [!CREATURE_TOKEN[:TEXTURE_TOKEN]] (or some other syntax) should inspect the active graphics set to look for a graphic, and fall back on inspecting NS:CREATURENAME/raw to see what the correct character and color are. The {{CreatureInfo vxxx}} boxes (and all other diagrams) should be able to show people the same image they see in the game using their own configuration.
  • With the same customizability and scope as tilesets.

What do you think? VengefulDonut (talk) 12:13, 24 July 2014 (UTC), VengefulDonut (talk) 15:01, 24 July 2014 (UTC)

Basic tileset support

Has this arrived? The only call to Tileset.Font.loadFromURL seems to be here, using ../extensions/DFDiagram/resources/8x12.png. VengefulDonut (talk) 22:53, 25 July 2014 (UTC)

Retrieved from "https://dwarffortresswiki.org/index.php?title=Dwarf_Fortress_Wiki_talk:Diagram&oldid=208254"