Template talk:Artifact

From GodWiki
Jump to: navigation, search

This is the talk page for discussing improvements to the Template:Artifact page.

  • Be polite
  • Assume good faith
  • No personal attacks
  • Do not bite the newcomers
  • Respond in a mature manner
  • Be welcoming
  • Maintain civility at all times

This page has an /Archive

Old and/or inactive discussions have been moved to the archive subpage.

Hmm. Default "Type"?

I just noticed that the documentation for |type= conflicts with the code.

The docs say it's optional and defaults to "Normal", but very clearly (from the rendered all-defaults template) it's actually required and defaults to Unknown.

What I can't decide is whether it should default to Unknown, and force everyone to explicitly type "Normal" every time they document a normal artifact, or if "Normal" should just be the default unless set to something else. Thoughts? -- FeRDNYC (talk) 20:48, 30 December 2018 (UTC)

Hmm. I kinda think we should leave it as Unknown if unspecified. Because it occurs to me that defaulting to Normal will create needless inaccuracies, and Unknown is a good prompt to editors to actually check. Sure, far more artifacts are normal than not, but non-normal artifacts are more interesting and more likely to have new artifacts created (I suspect), so Normal isn't that suitable as a default. -- Djonni (talk) 21:30, 30 December 2018 (UTC)
*nod* Reluctant concurrence. -- FeRDNYC (talk) 21:32, 30 December 2018 (UTC)

Portable photon generator — weird layout on mobile

Sooo, I'm not sure why, but after adding {{artifact}} to the Portable photon generator it's messed up on mobile.

It looks fine in the preview, but when I hit save this is what I see as a result. I checked if I added any unnecessary whitespace or something like that, but I can't see anything I might have done wrong. --Terezka (talk) 22:17, 12 January 2019 (UTC)

Did some try, it seems, the first headlight (aka == text == ) always somehow hide under the infobox. Need someone more competent than me to look at it! Seems to be a mobile issue only. -- WardPhoenix (talk) 23:33, 12 January 2019 (UTC)
That's probably going to depend on the mobile device. On mine it actually looks fine in both portrait and landscape. (screenshots) But I know the issue you're talking about. -- FeRDNYC (talk) 04:38, 13 January 2019 (UTC)
There used to be CSS in the old mobile skin (Minerva) that managed the placement of images correctly for different-sized devices, and the infoboxes used to take advantage of that CSS for their own placement as well. But that CSS went away when the Minerva skin was disabled (an unexpected change by the devs that I've still never seen any explanation for).
As I told S624, unfortunately the devs have shown an unwillingness to even address CSS bugs, never mind add new features, and without access to modify the site CSS there isn't really anything that can be done about that. Fixes that make things look better on some devices will look worse on other devices. The correct solution is to have responsive CSS defined with media queries so that things lay out differently on different-sized devices. But that requires that the person working on these issues have access to alter the wiki CSS. Nobody has been granted that access.
The only thing I can do is return the left margin on the infoboxes to their previous excessive levels. Maybe that will be enough to push the body content out from alongside them, on the devices where they're currently overlapping. But I'm very worried that will just cause some other issue for other devices. There is no way to correctly solve this issue without stylesheet modifications, and those are not available to us. -- FeRDNYC (talk) 04:58, 13 January 2019 (UTC)
I just tripled the left margin on all the infoboxes to 1.5rem, see how that looks. Not much change on my own devices (which is good), except that in landscape the flashlight image no longer fits alongside the infobox. But that's fine. -- FeRDNYC (talk) 05:05, 13 January 2019 (UTC)
Just pining GodTerezka  and/or GodWardPhoenix  on whether the infobox margin changes made any difference on this? -- FeRDNYC (talk) 09:02, 14 January 2019 (UTC)
Nope, same issue. WardPhoenix (talk) 11:28, 14 January 2019 (UTC)
Sorry, I've been very busy with exams the last couple of days... The issue is still there for me as well. When I tried looking for other examples, it looks like articles with too short first paragraph have this template problem, but others are fine.
It's a shame devs don't want to address the CSS bugs. I'm gonna submit it anyway, maybe if enough people annoy them with it they do something. --Terezka (talk) 10:22, 15 January 2019 (UTC)
Yeah, I wouldn't have expected much to change, especially after I sussed out the issue with the disappearing headings and got a better handle on what's going on here. Please do report the problem, like you said the more complaints they get... my biggest worry, though, is that it's not an easy thing to fix "just like that", meaning without working with us to come up with the right solutions, and coordinating changes on both ends to implement them. Still, anything they can come up with that moves things in the right direction would be good.
In the meantime, I've got some ideas for new templates that can help us work around the current problems, even though these kind of band-aid fixes make me nervous. (And could potentially complicate the proper fixes down the road.) -- FeRDNYC (talk) 08:36, 16 January 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── See the proposed fix at Talk:Main Page#Fixes for mobile content layout. -- FeRDNYC (talk) 14:42, 17 January 2019 (UTC)

Activation cost parameter

Noticing that Subplot thickener listed the activation cost of the artifact in the article body ("COST 50% Godpower"), it struck me how that's the sort of data that should have a place in the {{Artifact}} infobox. So I'm thinking I'll add a {|cost= parameter. The question is, how should it work?

I guess the first question is, what are the possible inputs for the activation cost? Is it just "no godpower" or "50% godpower"? (Ignoring temporary effects that might alter that 50% figure, for a time.) It feels like there must be more than just those two choices, but I certainly can't think of any others.

If it really is just those two, I'm tempted to have |cost= take either the number 0 (and maybe some equivalents like none, free, or the number 50. The displayed value could be formatted accordingly:

|cost=0 → "Requires no godpower to activate"
|cost=50 → "Requires 50% of Godpower to activate"

That would lend itself to easily adding categorization, maybe Category:Activatable Artifacts requiring no godpower vs. Category:Activatable Artifacts requiring 50% godpower or whatever. Sky's the limit. Thoughts? -- FeRDNYC (talk) 20:32, 25 January 2019 (UTC)

I was editing so many artifact articles and didnt even thought of having the cost in the infobox <facepalming>. Good idea and thanks for your job as always. WardPhoenix (talk) 00:49, 26 January 2019 (UTC)
Rescuing your self-deleted commentary because I think it's a good point... ;-)

I may be wrong but isn't the in-game message "0% godpower needed" for those wont don't require any? Need to check but I think it would be better to keep consistent with the way it is written in game?

You know, I hadn't checked, but I did now and the actual in-game text (for my sample size of 2) is:
  • Bag of trophies
    • Desktop browser: There could be something valuable inside or some rubbish (does not require godpower)
    • Android app: There could be something valuable inside or some rubbish (does not require godpower)
  • Box with a question mark
    • Desktop browser: This item can affect the hero in a good or bad way (requires 50% of godpower)
    • Android app: This item can affect the hero in a good or bad way (need 50% of godpower to activate this item)
Interestingly, it's not completely consistent even between game interfaces (in weird, minor ways that don't actually affect anything). So it feels like a fair question to ask, how exactly we should format the corresponding infobox messages. ...Or, OTOH, maybe those small inconsistencies mean it doesn't matter at all. -- FeRDNYC (talk) 17:57, 26 January 2019 (UTC)
Tick.png Done |cost= is now implemented, as above. I ended up going with just "No godpower" or "50% of godpower" for the messages displayed in the infobox, because I wanted them to be short enough to fit on one line without wrapping. -- FeRDNYC (talk) 22:55, 26 January 2019 (UTC)
Edited an artifact entry to add cost and add a sudden realization and question : should we put the effect of those artifact in the infobox under he description parameter, under another parameter or into the body text ? WardPhoenix (talk) 01:30, 27 January 2019 (UTC)
That's also a good question — I guess first we need to work out how much variety there is in activatables' effects, and whether that information can be concisely presented in the infobox.
I know for one such class, the so-called "black box" artifacts, Djonni set up {{Navbox black boxes}} to collect them all, and the {{Blackboxendmatter}} content that's been transcluded at the bottom of all of them. So, that's already a lot of information on each of those pages, and since it's presented directly there instead of in an article there's really no place for the infobox to link to... IOW, it would be sort of redundant to also have that information in the infobox. (Then again, the activation cost is shown there as well, so even that becomes sort of redundant.)
But that's also only one type of activatable artifact. I believe there are others, so the question becomes do we set them up in a similar fashion, use the infobox, etc? I don't really have a strong feel for the best way to organize all that, but I'm certainly open to ideas. -- FeRDNYC (talk) 23:47, 27 January 2019 (UTC)
We have a lot of different effects so I guess the best option if we choose to put it in the infobox, is a description-like category where we can write freely the effect. Unless you want to make a shortcut for every effect (kinda like how boss type is made) but well, I think there is too much different effect for that. We can also stay on the body article for that information of course.
Effect i can remember : Teleport to randomtown/arena/Godville ; Contain X artifact for 0 or 50% GP; melting gold or object ; Tries to use 3000gold or kill monster ; Healing ; Add a charge to accumulator ; Restore 50% GP ; Summon a boss ; Search for underground boss ; hammer of realignment unique one ; launch a mini quest ; add a friend invite ; add a randol god to friend ; ........... That's a lot and I may missing some (like events one). WardPhoenix (talk) 00:28, 28 January 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Hmm, that's quite a few. Still, it wouldn't be too hard to come up with a shorthand, maybe something like...

|effect= argument Artifact effect
town Teleport to randomtown/arena/Godville
surprise Contain X artifact for 0 or 50% GP
melt melting gold or object
gold, kill Tries to use 3000gold or kill monster
heal, full Healing (These are the ones that fully heal, right?)
charge Add a charge to accumulator
gp, godpower Restore 50% GP
summon, boss-fight, above Summon a boss
dig, search, underground, ug Search for underground boss
align, alignment hammer of realignment unique one
mini, quest launch a mini quest
invite add a friend invite
friend add a randol god to friend
blackbox, good-or-bad, "good or bad" "This item can affect your hero in a good or bad way"

(Where I list more than one, they'd be synonyms. More synonyms could be added besides those, too. There's no hard limit to how many forms could be accepted for each, though past 4 or 5 it tends to make things more confusing instead of more flexible. Additions / corrections / concerns certainly welcome.)

Another option, if we wanted to make it even more flexible and future-proof, would be to have |effect= accept both shorthand arguments from the list above, and free-form text. In other words, if the template is passed one of the words in the left-hand column, it'll display the corresponding standard long description for that effect. But if it's passed anything other than a recognized word from the table, it'll just pass the text straight through.

So any articles passing |effect=align, |effect=heal, |effect=gold, etc. to the template will show the standard expanded descriptions. But if the one of the seasonal activatables had {{artifact|effect=Summons a Snowman for the hero to fight}} on it, the infobox would display that text verbatim despite it not being one of the known arguments. -- FeRDNYC (talk) 23:30, 28 January 2019 (UTC)

One problem with argument is that you're gonna make a lot of them while a lot of effects concern one or two artifacts only (realignment, arenalin, invites to Godville, etc.). Imo, it would be a lot of work for almost no use (well it's not me who gonna do that but still). I think the free-form is the more reasonable thing to do, it won't take much more time by artifact and can be easily fixed if any changes happens. But if you also want to make formatted argument, feel free to do it of course xD. WardPhoenix (talk) 00:25, 29 January 2019 (UTC)
Oh, TBH I'm not really worried about that. Once the basic framework for the code is there, extending it actually pretty trivial, so better to err on the side of excess. The list of artifacts matching any given effect can really only grow over time. So while some of these may not be used much today — heck, most of them won't be used at all simply because most artifacts don't have articles about them, and most of the ones that do don't use {{artifact}} yet — having the code in place means they can be used in the future.
That entire table doesn't have to be part of the code, either. But even if it was, it'd look like this:
|town=Teleport to random town
|arena=Teleport to arena
|godville=Teleport to Godville
|surprise=Surprise contents
|melt=Make a gold brick
|gold|kill=Tries to use 3000gold or kill monster
|heal|full=Fully heal the hero or heroine
|charge=Add a godpower accumulator charge
|gp|godpower=Restore 50% godpower
|summon|boss-fight|above=Above-ground boss fight (solo)
|dig|search|underground|ug=Underground boss fight (party)
|align|alignment=New alignment
|mini|quest=Start a mini-quest
|invite=Add a friend invite
|friend=Find a new friend
|blackbox|good-or-bad|good or bad=Good or bad effect
And at this point it's already 90% finished, though not 100%:
  • The output texts need a bit more polish.
  • Some are pretty long for an infobox entry and I'd love to shorten them more, if I could think of how.
  • There are wikilinks that should be added, where appropriate. (The different boss types, for example.)
  • My assumptions need to be double-checked, for a few. (Are "summon" boss fights always solo?)
A few of them can probably still be cut. (As you say, Hammer of realignment is unique, so maybe it doesn't need an |effect= shorthand of its own...) But as I said, better to have it and not use it than vice versa, if there's any likelihood of multiple-artifact use. If people are filling in free-form text simply because there's no matching shorthand, cleaning that up is a lot more work.
(They're going to do that anyway, but at least those cases can immediately be replaced with the shorthand when they're found. The reason |boss-type= doesn't take free-form text is for exactly that reason: We know that list is fixed and every possibility has a shorthand, so forcing their use means we don't have to clean up a bunch of free-form entries that overlap with the supported values, but use slightly different wording, capitalization, etc.)
Basically, though, that's the code right there. Just a matter of creating the rest of the structure required to display it in the infobox, then dropping it in. (And documenting it, but that's mostly a matter of cutting-and-pasting the table version into Template:Artifact/Documentation.) -- FeRDNYC (talk) 09:49, 29 January 2019 (UTC)
I see your point and seems you have already made that, as much use it. The above ground boss is always solo while underground are in team I think (unless you use it in town and guard kill the boss and give you gold). -- WardPhoenix (talk) 11:46, 29 January 2019 (UTC)
Excellent, thanks! I was pretty sure about that, but...
Anyway, with the event ending this week, I'll probably let this sit for a few days, to think about it and see if anyone else has any input. Then next week or whenever I can get the coding in place to add this (or whatever we all end up deciding it should look like) into the infobox. Thanks for all your help & ideas! -- FeRDNYC (talk) 22:39, 29 January 2019 (UTC)
Thinked about something else so posting before i forgot. Shouldn't be better to have in order in the infobox, type/effect/cost and then description. Because at the moment type and cost are divided by the description. (Sorry if you had already planned to do it xD). ---- WardPhoenix (talk) 00:32, 1 February 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Hm, that's a fair question. The order the list will go right now, if all the parameters are defined, is:

  • Type • Description • Value • Activation Cost • Associated Monster • Wanted On

That's partly because fields just tend to get tacked on in the order they're created, but also because typically the required fields are always shown first. (We know every {{Artifact}} navbox will display Type and Description, even if one/both is set to "Unknown", so listing them first ensures that they don't end up moving around depending on what other fields are or aren't set.)

Artifacts of Godville
Type Activatable
Description Unknown
Value 10
Associated Monster Terror Bull
Wanted On 2140 g.e.
Effect Something good or bad
Cost 50% of Godpower

Personally I think there's some value in that, so my inclination is to leave it alone. However, prioritizing the activatables' effects over meaningless fluff like Value is also important. So my instinct, when adding Effect, would be to make it:

  • Type • Description • Activation Effect • Activation Cost • Value • Associated Monster • Wanted On

though I could also easily be talked into

  • Type • Description • Value • Activation Effect • Activation Cost • Associated Monster • Wanted On

On the grounds that the Activation fields are specific to one type of artifact, whereas the any artifact can have a Value. (That makes this somewhat analogous to the |pet=yes or |boss=yes fields in {{Monster}}, which have their own dedicated subsections with different coloring, and always come after all of the general fields.)

In fact, something similar could even be done for activation, to make it stand out more — i.e. something like what you see here (but with much better colors, of course. -- FeRDNYC (talk) 18:07, 1 February 2019 (UTC)

Heh, and ignore the all the occurrences of |wanted= in the discussion/example above, as that's an error — the parameter wasn't supposed to be in the template, I had previously removed it, and I only just discovered that it snuck back in with the {{Infobox}} upgrade. So, now I'll be removing it again, and hopefully it'll stick this time. -- FeRDNYC (talk) 18:17, 1 February 2019 (UTC)
That exemple looks actually good ! Nice job on that again! Being shaped like boss monster or pet the information is really steading out, so good idea you had there. (As for the colour well... taste and colours eh...) -- WardPhoenix (talk) 00:35, 2 February 2019 (UTC)