Template talk:Infobox metaobj

User_talk:Rook - Currently best documentation source.

Old messages

There is no Hurt for now. Can some one delete this propereti from template? --Rootconsoler (talk) 15:23, 29 June 2016 (EDT) I'd rather leave it until dev says theyre not going to reimplement hurt. if you get confirmation i'll remove it --Ricky (talk) 00:28, 30 January 2017 (EST) Great timing with the jorb stream coming up 3 hours from now! :) Digzol (talk) 13:15, 1 February 2017 (EST) The hunger/energy info on food is a link to a number. Grapes for example, looks like this: Energy/Hunger: 125 How do we make that number not a link? --GauHelldragon (talk) 23:51, 8 October 2016 (EDT) I actually dug through the infobox page and found a fix for those linked numbers. shouldnt happen now. --Ricky (talk) 00:28, 30 January 2017 (EST)

ToDo's

(minor stuff to include in next major edit)

• Revision: 72045
  • Ditch "<empty>" input case for ccrafted. Blocks potential template-call display style where all/(well most) parameters are displayed without any data in templated call.(Done)
  • Category:Foods is set two times by hunger parameter (one can go, last)(Done)
  • Category:Structures, Infobox/equipmentStat, lift:
    Infobox/equipmentStat can't be used with bools (only checks for any data)
    Move cat into Lift data-case check.(Skipped. Lift also functions as a general structure flag (ie: extended bool. (True/False/None)). The general structure flag might not be to clear, due to it being used on seemingly none structures (to be checked))

• Move vsize & vinv declarations up (additional vertical spacing fixup)
• ...

(to be looked at)

• Other bools, like lift, template parameter-data normalization. lift evolved to using "Yes/No", while ccrafted evolved into using "yes")
• Ditch or keep single-value property collection. Technicality those are just single-data lists (ergo: category type data), while properties are multi-data (links) type data. There not hurting, but not really necessary either (if same data category is available/used). ... Exception seems to be, for quickly adding such a property into an #ask table to view/find misfit cases.
  • Current single-data properties: ccrafted(not actively used), ...
• Category:Structure: check used parameter combinations (lift, repwith, sthp, soak)
• Gild Objects v Gemstones:
  • Currently the gemstones category assignment is done on the page itself. (currently its acts as Gemstones identifier)
  • if the gemstones category assignment is to be moved to template level there needs to be some other way to distinguish between Object v Gemstone. (currently there seems to be no other available way to do so)
  • ...
• ...

(temp notes/reminders)

• Category:Structure: when is something a structure. At least stuff that uses a build-sign-post. + repwith seems logical to.
  • Category:Structure is set on: lift, repwith, sthp, soak.

Gilding Attributes

I'd been working on adding links to a special search page for related gilding attributes; a discussion was just started on my talk page that maybe it isn't useful there (although I'm not in agreement, I'm fine to defer). However, the standard tends to be that folks wind up mixing Attribute impacts with Gilding Attribute classes; they don't really have anything to do with each other hence the point of the chances I've been making. That said, would be good to have a way to auto-matically cross link to other related gilding attributes, especially if possible more easily discovering which Gildings (property gildatt) match to which Equipment's Gilding Attributes (property Egildatt). The "special page" search link looks like this: `Special:SearchByProperty/:Egildatt/` -- it would be useful in my humble opinion to integrate that, or its companion `Special:SearchByProperty/:gildatt/` into the infobox template as decoration on the gilding attribute list entries. ProgrammerDan (talk) 16:39, 18 January 2019 (EST)

If the main data target is other equipment's with the same gilding attributes, would an #ask/#show query result not be more appropriate instead of SearchByProperty links?

... Although. A lot of gild related items have 2 or 3 gilding attributes. Which also would mean 2 to 3 list. List of, at this point, unclear size (probably not to long ... to be checked).

--.MvGulik. 22:29, 18 January 2019 (EST)

You're now way past me in media / semantic wiki knowledge :). Let me know how I can help, and I will be glad to! I don't mind repetitive, boring updates. Definitely if this wiki format would make it easier to pair Gildings with Gildables, that would be a huge step forward, because it's not straightforward at present. ProgrammerDan (talk) 22:39, 18 January 2019 (EST)

I don't know everything, and have my own blind spots.

Note that for repetitive boring stuff ... there is a RoB global replace feature (Regexp fuelled) that can do a lot of potential boring stuff (relative simple edits, but applied on lots of pages with a single click). But it need to be requested, as its an admin only feature.

--.MvGulik. 12:08, 19 January 2019 (EST)

Changes (done/potential):

• (done) Swapped "Attributes" link on "Gilding Attributes" text to "Unique value list" link (until something better comes along)
• (.?.) (potential temp solution) change link on Gilding Attributes input's with value specific SearchByProperty link. (... not sure if this is actual possible from infobox template)
• (.?.) Generate #ask useable property with active used Gilding Attributes (subset of character attributes and skills)(seems needed for next step)
• (.?.) See about pulling subjects, based on Gilding Attribute. (to be used, if possible, on Gilding Attributes input's) (can return up to 15+ subjects)

Zero Expdrain

Currently a Expdrain with a zero value results in a -999 output on other calculated properties that use it as divisor. (ie: division by zero error case)
General issue being here that -999, when used as such as final output on a page, is not that informative.
Changing the error value is not really an option. As the related properties are of type number, and any other number would just be as uninformative or even worst.
Only option so far, to change that -999 to something like "N/A" for SMW generated tables, seems to be to pass the SMW Ask results trough a secondary template, AND use the MW-table "data-sort-value" feature (to ensure numeric sorting versus text sorting) on related entries.
On hold for the moment. Potential "Post-expand include size" hiccup's being one reason (as the main target table is kinda big). Optimal the called template should also be usable too for other SMW calls that pull same effected properties (need to look at that ... later. ie: reason 2).
last minute NTS thought ... A blank or no property-entry instead of -999 might open up some alternative options (later)
--.MvGulik. 16:28, 30 December 2019 (EST) (mmm, not really the right talk page. move later)

Slots

• Clothing/equipment slot input can contain one or more slot id's
• In case of more than one sloth (current max-used is 2)
  • 1) A single item will use both slots at the same time. Current used format: "<id1> and <id2>"
  • 2) Each slot can independently contain that item. So a character can use two of the same item. Current used format: "<id1>; <id2>"

"OR" makes no sense for case 1. But "AND" makes kinda sense for both case 1 and 2.

The main difference here is whether both slots are linked/(grouped as one)(1), or independently usable(2). (related to the item in question ofc)... Hmm, that's not helping.

With the used format this "<id1>;<id2> AND <id3>;<id4>" makes no real sense, at least not game-wise. "(1or2)and(3or4)"

This makes some sense "<id1> AND <id2>; <id3> AND <id4>". (Either uses slots 1+2, or slots 3+4. Exclude cases: (1+4),(2+3).

... (something for later.)

--.MvGulik. 21:44, 28 November 2024 (UTC)