Old food tables: Finish, or replace?

I meant to post this last week, but I must have clicked the wrong button:

Before we start implementing the item name, price, stat for each spirit table, we should decide weather to use just a table, or a data/style transclusion list similar to Monster_Defensive_Stats.

The recommended item table sounds like something that would cause a lot of edit wars. If there was an objective best item, we would have had a table like this years ago(this is not the first time something like this was suggested). Since spirit satisfaction increase is capped at 1 lvl per feed, the fastest way would be to go for the max stat gain every time, which is usually unreasonable because it's expensive; since stat growth is scaled logarithmicaly with price, the most cost/growth efficient way would be to go for the cheapest item that gives exp, which is unreasonable because you're not going to get anywhere raising the stat 1 point per feed.

I second Sozen's idea of using data templates to reduce mess.

And where does it get the data from?

Are you asking what the Template:Data___ are or who/how to fill that in? I'm picturing something along the lines of: {{Egofeeding|10 Sign|Str||Int|etc}} using your current design if we go by that format. Other than filling in the Str/Int/etc, all you'd need to do is build a column template and use the preexisting data templates for the price, name, and link parameter, like we do with the Weapon Lists page but on a smaller scale. Also, it would probably be helpful we made parameters in the data template, like, FemaleBowStat=Str, and allow toggle view of that on the Weapons template, if we want that transcluded as well. Of course, filling out the stat increase will take work like you have been doing unless there's another source of that data somewhere I am not aware of.

If you guys want to make the large data addition for every single item, be my guest. It looks like more trouble than it's worth, though.

Also, wouldn't that make filling in the entries a huge pain? They'd be scattered everywhere instead of on one page...

Where it would get the data from: We could either add parameters for each spirit type to the current item data templates, or make separate data templates for the spirit food stats. A separate template might be easier on the server since all the item's other data would not be getting passed to the table that doesn't use it, and it would be easier to add data to it since there'd be less scrolling/searching, but we'd be making a lot of new pages for these templates, and there would be a redundant price parameter(both the regular item data template and the food stats template would include the item's price). If there are any items where the differently priced versions give different stats, (afaik there are none, but I'd like to be prepared for anything) the separate template method may be cleaner; if we just append the current data templates, then we may still have to add a separate template for the special version of that item with just the food parameters(with the same parameter names so it can use the same style template in the table). Also, the parameter names would probably be shorter(in a template just for feeding stats, we can just name the parameters as weapon category plus M or F (example: bowM, bowF, bluntM, bluntF...) but if we put food data with the regular data, we may have to add something to the names to avoid confusion (example: egofoodBowM, egofoodBowF, egofoodBluntM, egofoodBluntF...).

I should probably have done this when I proposed the data/style method, but I was tired: Pros (of using data/style)

1. easier for editors to add data(with named parameters, the contributor doesn't have to keep track of the order the columns are in and count the pipes in the row)
2. it may be easier to change the format of the table when we need to (just edit the row style template and maybe the header, instead of changing each row individually)
3. we can more easily add conditional formatting (for visual efficiency), ie. make the text color vary depending on the stat, or make the cell background color represent the efficiency rank of that stat for that spirit.
4. we could use the info in more than one place without having to copy/paste each detail manually. For example, we could also add tables that only display info for one spirit coming from the same data templates, and we could add individual item tables (similar to what's at the bottom of Littlesnow's userpage) to the item's page.

I think I had more, but these were the main ones.

As for cons, nothing significant comes to mind so far. If anyone is worried that the coding may be complicated, don't be; I will probably take care of most if not all of the style code unless someone faster or with more free time beats me to it, and code for data will be fairly simple, and more user(data editor) friendly than a plain table would be.

Cons:

• Less experienced editors (the ones who filled in at lot of the old tables) will likely have a hard time filling in missing stats, and give up.
• ~1000 new pages (or whatever we decide on) for each item/price pair

If we already knew what stats were given for each item, this wouldn't be so much of an issue to me.

• I'm pretty sure the data/style method would make it easier for the less experienced editors(see pro 1). If we do this, we'll flesh out all the needed pages with blank parameters(or maybe question marks to show exactly where the data should go) for the unknown values, so all the editor will have to do is find the page for the item they just fed to their spirit and find their spirit type on that page. I'm fairly certain new users would find this less intimidating than navigating the pipe maze(sea of '|' characters) in a 12 column direct table. The formatting(style template) would be a lot more complicated, but that will be done by me and/or other experienced users who can handle code like this; the data editors (especially the inexperienced users) will not have to read, or edit any of that.
• As for the flood of new pages, we may or may not actually add a page for each item (we might just append this to the already existing data templates). Even if we do decide to put the feeding data on a separate page from the main data, the new pages aren't that big a deal; we already have individual pages for every monster and item, this won't be that different.

so all the editor will have to do is find the page

Do you not realize how confusing it is to find template pages without a magical edit link provided?

Ah, thanks for reminding me. We should discuss weather the "magical edit link" should be another column in the table, or a parenthetical in the item name column.

By the way, I just noticed you had already started compiling the plain table before I retyped my transclusion recommendation. I apologize for the inconvenience.

The plain table will make a good intermediate step regardless of whether it's the final version, so no worries.

Lets put what you have so far at the bottom of Spirit Weapon Item List.

I see you've been listing the ducat price in the price column for fomor weapons. Have checked to confirm that ducats are equivalent to gold? (ie. put the ducat value into the calculator and feed the item to your ego to see if the numbers match. Could also check by dropping the item and timing how long it stays on the ground before disappearing, and then doing the same thing on an item with a gold price close to the ducat price)

Yes, for the fomor weapons that I recorded, the price in ducats transferred directly to gold value. The Traveler's Outfits that are sold do not transfer 1 to 1, instead increasing from 2500 ducats to 18500 gold.

Separately, I've also confirmed the conversion formula between NPC value (selling the item) and "actual" value (buying the item). For the record, it's broken into 4 piecewise sections (starting with the actual value):

• 100 gold or less: x = y / 2
• 100 - 1000 gold: x = y / (2 + (y - 100) * 2 / 900)
  • Effectively, the multiplier adjusts linearly from 2 to 4.
• 1000 - 10000 gold: x = y / (4 + (y - 1000) * 6 / 9000)
  • Effectively, the multiplier adjusts linearly from 4 to 10.
• 10000 gold or more: x = y / 10

Where x is the NPC value and y is the "actual" value.

Based on this formula, my next (and last) step before the table's ready is to match all the values on the table against the NPC value listed for the item. The data from the item's page will be taken as correct.

FYI