All imbuable items should also have a parameter to denote if they have one, two or three slots. This should be displayed as a column in the tables on this page. -- Bennie (talk ~ fellows) 10:22, November 19, 2016 (UTC)
Should imbuements have their own pages? If we have a page for each imbuement, we could have pages such as:
- Helmet Imbuements (etc) which lists (1) slotted helmets and (2) a list of imbuements that apply for this slot
- Powerful Imbuements (etc) which lists each imbuement of the "Powerful" tier and how to imbue, etc.
Or some categories:
- Category:Powerful Imbuements (etc)
- Category:Helmet Imbuements (etc)
- Category:Skill Boost Imbuements (etc)
Sixorish, thanks for creating the template. I made some edits, but left something for you which I don't know what you intended to do with. But before we start making all pages I want to make sure everything is designed good. Some questions:
astralsourcesnow takes "25x Fiery Heart". Shouldn't we separate the quantity from the item, e.g. Fiery Heart:25. I don't have a use in mind right now, but I can imagine a need will rise in the future to automatically determine the amount per needed item. With a standard delimiter this is easier to extract.
Re: astralsources - my concern with the "item: count" idea is that string functions have terrible performance and should be avoided at all cost. There are a few ways to represent lists of data, but all of them have significant weaknesses. I do agree that this needs to change, but the "item: count" route is probably not a good one.
- Freeform - this is good for text that is not structured, does not need to be formatted strictly and does not need to have its data inspected by other pages. I think this is the best option for this scenario because we have no need to use the information externally.
- Freeform using a list template - this is good for text that is structured as a list of items. There's an implied strictness of formatting because it uses a template. This is a fine option if there's no need to inspect the data externally;
- Multiple parameters - this is good if the maximum number of reagents is fixed and few in number. For example if we made the assumption that there were at most 3 reagents, we could have parameters astralsource1..3; this allows us to easily inspect the data, at the cost of making it a little bit more complex to write templates that get around this.
- One really long string with special characters to change the state of the parser. Good if the data needs to be inspected. It's slow and requires the user to understand the syntax.
(PS: when I say 'inspect the data (externally)' I mean use the data outside of its primary use of displaying that piece of information; e.g. determining whether Basic Scorch requires "25 Green Dragon Tails" would be an inspection unless it was done by the template(s) responsible for displaying that piece of information)
Re: imbue groups - I considered this, but wasn't sure how it's actually implemented in the game. I think conceptually, CipSoft wanted something that is consistent for the convenience of the users. But it's just a convenience. Now here are the many problems with having 1 page in place of 3 imbuements of the same family:
- They can violate their own standards if they want. If they do, our system breaks down because we made assumptions about the game that were not valid.
- We cannot create useful DPL lists, because we're grouping information that is not related (as per the game mechanics).
- We cannot, as far as I can see, calculate the effect % values knowing only the name (Scorch) and the tier (Basic) unless we hard-code all the values inside the template. General rule: if you need to hard-code values, you're doing something wrong. This means that we wouldn't be generalizing imbuements, we'd just be grouping the responsibility which is exactly what we want to avoid in this case.
However, I won't object to having a page (e.g. Scorch (Imbuement) which acts as a generalized page and lists the 3 relevant imbuement pages - that seems fair, though probably a bit excessive.
And good idea, please don't start editing pages until we all can agree on how it's implemented. the Basic Scorch page was created as a proof of concept. -- Sixorish (talk) 12:34, December 23, 2016 (UTC)
I've implemented the following:
- Slots are now comma-delimited instead of requiring a template call. This uses string functions, but shouldn't be too inefficient on this scale.
- Astral sources are now comma-delimited, with an optional quantity field specified by ":". As an example, see Powerful Reap.
As for combining imbuement types, I don't think there's any way to make this possible without creating issues down the track. There's no way to calculate an imbuement's effect knowing only its type and level. If it were, it would still be problematic because DPL is on a per-page basis and you'd need some nasty tricks to get it to list all three imbuements.
How about the following idea?
- Lists all imbuement types, and then all imbuements.
- Scorch (Imbuement), etc
- These pages describe the imbuement type, and list the three imbuements of that type. They could use their own template, Template:Infobox Imbuement Type.
- Basic Scorch, Intricate Scorch, Powerful Scorch
- These pages describe the actual imbuements and use Template:Infobox Imbuement; they link back to the imbuement type.
I've gone ahead and made the pages. Here are some changes I made:
- Added a type parameter, which will be Scorch in 'Basic Scorch'.
- Created templates for shared strings: Special:PrefixIndex/Template:Imbuement Effect/. These are used on all pages to share common strings with differing values (compare e.g. Basic Scorch and Intricate Scorch.)
- The slot shields is now supported.
- Slots are now case insensitive: "Shields" == "shields".
100% gold fee
Does it cost 10,000 gold total to have a 100% basic imbuement, or 5,000 + 10,000 gold?
That is, does the "gold to raise to 100% chance" include the gold for the imbuement itself?
Timer countdown inside PZ
I think it should be more clear about imbue time ticking down just for having the battle status. It also ticks down for having the battle status and then going to PZ (even thought it looks like you no longer have the status)
There's no real excuse for an encyclopedia (such as TibiaWiki) to exclude such information. Our users want to know all the details, so we should provide everything we can. If the system is complex, we can work around it by e.g. using examples, moving the intricacies in another section/paragraph, etc.. Don't omit information just because most people won't use it, because we target all players. -- Sixorish (talk) 11:31, April 9, 2018 (UTC)