Template talk:Crafting Box

Semanticizing Recipes[edit]

Sometime soon I'd like to start semanticizing stuff on sotawiki.net and will be starting with recipes. I'm gonna do them slightly differently than we are on my current wiki (because we're having a few problems with out current method) so it will require a bit of experimenting.

Normally I'd confine such experimentation to a Sandbox page but semantic stuff like this is tricky since pagenames are important. So to properly work on it I may touch a dozen pages and be messing with templates (although if a template change will break something current I will try to keep the template on a Sandbox).

I'm new to this wiki and I'm a bit uncomfortable jumping in with potentially huge, sweeping changes like this. So please tell me if I'm stepping on your toes or if I seem to be going the wrong direction with this or if you'd like to help. -- [[User:Fenyx4|Fenyx4]] (talk) 14:23, 27 February 2014 (MST)

"We operate like adults around here and would rather you make the change and have the willingness to undo your change if it's rejected by the group. It makes it so we can all be more productive and just get stuff done. Then if we need to change something we just don't take it personal." this is what I responded to his question in IRC... figured I'd throw it in here for historical data-Violation (talk)

My main concern is the fact that the SMW is hard to understand and to edit for new editors; which is the main reason Wikipedia doesn't use it since the majority of the edits on Wikipedia is done by new editors and it should be straightforward to edit a page and new editors shouldn't need to figure out special commands to contribute to the wiki. If the majority of our content will be added by a small group of experienced wiki users, this is not an issue. However, I think we need every little bit of help and new users should not be discouraged by special markups with little or no text after clicking the Edit button. This is not to say that we shouldn't use SMW, it is by far the best way to efficiently update and maintain a wiki. I guess we can find a balance between readability of the page sources and making use of SMW features. Gordias (talk) 13:46, 1 March 2014 (MST)

Agreed. It is all about finding the balance. I think hiding as much of the SMW in templates as we can is a good way to go. We clearly already expect people to be able to use templates. Although I was surprised how quick people just naturally started using semantic properties on the U4E wiki merely because other pages used them. The biggest confusion people had was when cached pages would take a bit to update. -- Fenyx4 (talk) 13:53, 1 March 2014 (MST)

By the way, adding comments before SMW templates is one idea, eg. . Gordias (talk) 13:58, 1 March 2014 (MST)

I like it! I should also put better documentation in the template itself. Going to something like Template:Query_recipe and just seeing a blank page is bad of me. Sorry. -- Fenyx4 (talk) 14:10, 1 March 2014 (MST)

I like the contained listing that the pages on the ultimacodex sota wiki had... and I like the recipes that sotawiki has. here's the diagram I drew out on paper (didn't like it so I did it digitally with screen grabs and photoshop, sorry it took so long). Updated Image: Violation (talk) 12:11, 3 March 2014 (MST)

Violation (talk) 14:25, 1 March 2014 (MST)

Is that trivia about the iron skillet true? I'll be disappointed if it isn't.

I made it up sorry Violation (talk) 18:55, 1 March 2014 (MST)

As the "Contains in" list can grow fairly large I think it should be moved above "References" so the other stuff doesn't get pushed out of sight.

It is already above there and we would use a 3 column layout like we currently do for recipe lists to manage the extra size (see: Carpentry). Violation (talk) 18:55, 1 March 2014 (MST)

Sorry, I meant directly above "References". Or maybe directly above "See also". Important part is that it is below Lore and Trivia. -- Fenyx4 (talk) 20:46, 1 March 2014 (MST)

Is the list preferred for "Contains in" over the table? (As seen on Chunk of Coal) I like how the table has the recipe. Saves me a lot of clicks when looking for things I can craft.

Over what table? The recipe for the item you're looking at is at the table... am I confused on what we're trying to accomplish? I thought we were talking about item pages... so I would be talking about removing all the unwanted recipes (if you search for iron hilt most are not trying to find the recipe for great sword... but if you are interested in seeing how to make the greatsword after you make the hilt you follow the "contained in" link to the great sword). Violation (talk) 18:55, 1 March 2014 (MST)

The usage of "Table" seems to have caused confusion. Let me clarify; your example of "Contains in" uses a bulleted list. When I made it I used a table. You can look at Chunk of Coal where I am demoing as a table on this wiki. It doesn't have all the recipes Chunk of Coal is in yet because SMW isn't fully implemented yet. You can see more complete examples on the old wiki. Like here and here. I like it this way because, if we followed the example you gave, you wouldn't have to click through to "Great Sword" to see what ingredients it needs. -- Fenyx4 (talk) 20:46, 1 March 2014 (MST)

As long as we are talking about presentation how do people feel about adding a non-icon image to the Item Infobox? See http://wiki.ultimacodex.com/sota/Axe_of_Prosperity or http://wiki.ultimacodex.com/sota/Iron_Helm. It would be possible to change that into a slideshow gallery ala http://wiki.ultimacodex.com/sota/Denis_Loubet... But... I dunno about that. I do think it would be nice to have one in game image near the top of the page though. -- Fenyx4 (talk) 15:38, 1 March 2014 (MST)

The goal is to have the exact game rendered image at the top... we haven't ripped all the files yet but Darkstarr gave me the okay as long as I'm not running any advertisements on the site. The screenshots would be a gallery at the bottom and would be tagged somehow to be updated in... if you want to make that rotating that's fine by me, it gives more shots to a small space... the red box would be where the space was "planned" for screenshots. Violation (talk) 18:55, 1 March 2014 (MST)

I understand and agree that the exact icon should be at the top of the infobox. I'm just suggested that we may also want an in-game screenshot at the bottom of the infobox so people don't have to scroll down to see how it looks. -- Fenyx4 (talk) 20:46, 1 March 2014 (MST)

Yeah I could care less either way... I see the benefit of having in-game shots up there but there is a lot of information that will be added to that infobox (item information... damage types for weapons, def types for armor, can be used as a wall/floor decoration, etc). I'd imagine so we might want to keep the in-game screenshots limited in their size.Violation (talk) 07:39, 3 March 2014 (MST)

p.s. can we start a new line yet? :p running out of space here... Violation (talk) 18:55, 1 March 2014 (MST)

Sure. ;) -- Fenyx4 (talk) 20:46, 1 March 2014 (MST)

Yeah I think screenshots inside the item-info good as long as it's hidden when they're not there (ie not an amazon.com ad for you to upload your screenshot). Violation (talk) 07:27, 2 March 2014 (MST)

I still think I'd like to see the recipes for other items on their respective pages and then the master recipe list for skills on those skill pages like GW2 did in option two that you posted. I understand the extra click you're talking about but I also see that extra click as a good thing... it keeps things sorted nicely. When you query the wiki for a stick you want to find a stick you don't want 27 pages that all mention stick because they're part of that recipe. Also, when people see an issue they would try to edit that page to fix the issue and it wouldn't work because it's a query and they'd see the commented out so now they have had to click 5 times (search, edit, back, click item link, edit) to get to where they wanted. I think organizing things nicer from the start and standards would be polite to all involved (just my thoughts but I could be way off base). Violation (talk) 07:27, 2 March 2014 (MST)

The GW2 example wasn't meant as two options but both parts of a larger standard that lends itself well towards usability.

I disagree that adding the extra click makes it sorted nicely. If I'm already looking at a list dealing with recipes I'd like to just see the recipe. Don't make the user dig for the information.

Not sorted, easier to edit and control from an end user... it sorts exactly the same either way.Violation (talk) 07:39, 3 March 2014 (MST)

'Sorted' was the term you used so I was sticking with it. I interpreted it as 'organized'. -- Fenyx4 (talk) 10:07, 3 March 2014 (MST)

When you query the wiki it already separates out page titles matches from page text matches. Avoiding talking about sticks because it might clog up search results is self defeating. I'd WANT to see all those pages in the search because they do relate to sticks.

Great point!Violation (talk) 07:39, 3 March 2014 (MST)

You haven't given the full example for your editor;

With a Query: He's on Iron Bar and sees a problem with a recipe for Coil of Iron Wire in the recipe list. Click edit, sees comment and clicks back, click item link, click edit, edits page.

Without a Query: He's on Iron Bar and sees a problem with a recipe for Coil of Iron Wire in the recipe list. Click edit, edits page. But wait if the recipe was wrong on Iron Bar was it wrong on Coil of Iron Wire? Click item link, click edit, edits page. Wait... Are there lists elsewhere that need changing? Clicks what links here and starts going through hoping to find everything. And hopefully he does find everything because otherwise we now have inconsistent data across the wiki. Like you have said elsewhere SotA is gonna have lots of recipes. The more we automate the better.

I feel like our editors are more capable than you give them credit for. And even if they aren't able to handle it then we shouldn't be favoring them over the readers. -- Fenyx4 (talk) 06:41, 3 March 2014 (MST)

Actually I did... I just didn't use your example for mine... I used yours for your editor and my layout for mine... you have applied your layout to my editor... he would never have found the issue with the recipe until he was on the coil page from clicking the link in my example... and at that point clicking edit would be correct because he was on the correct page. I agree that there are capable people but I also have done about 50 recipes FOR people under the current system because they're confused... I know for sure that I will have a LOT more to do FOR people under this new proposed system.Violation (talk) 07:39, 3 March 2014 (MST)

I think the desired result you're looking for in not clicking through 100 pages to get 100 recipes can be done with a master recipe list and doesn't need to be both... recipe list and all these extra queries on each item page. In the end I'm opposing because I'm trying to make the jump from viewer to editor easier... I am not taking credit from editors abilities. We have gone through lengths to do so up to this point and it has worked marvelously. I think I'd like to start a forum conversation because this is a really slow chat between Fenyx4 and Violation currently and we aren't getting much feedback out of others. Are you okay with that?Violation (talk) 07:39, 3 March 2014 (MST)

I don't think moving it onto the forums would increase my response time. We could discuss the merits of different communication medium but the last thing we need is another discussion on this page. :)

I feel like we're arguing all over the field here, you've switched from a bulleted list of recipes containing the item on the item's page, to a list of recipes containing the item on a separate page (GW2 second example) and now (if I understand correctly) no list of recipes containing the item and they can make do with looking through other lists. And that is just one point we're discussing so, for sanity's sake, I'm going to break it into talking points below. -- Fenyx4 (talk) 10:07, 3 March 2014 (MST)

Should it be on the Item's page[edit]

Should we include a list of recipes which contain the item on the item's page?

I think that a list of recipes containing the item on the item's page would be very useful for the viewer. I know I found it useful during R3. -- Fenyx4 (talk) 10:07, 3 March 2014 (MST)

If we do have a list on the item's page should it be auto-generated with Semantic Wiki[edit]

Should Semantic Wiki queries be used to generate the list?

This is a definite yes for me. This makes it easier on editors and avoids the risk on inconsistent data. It makes it easier on editors because it decreases the number of edits they need to make and because it can help automate complex things they couldn't handle themselves. The information is entered once, in a logical place for that information to be entered and then it is pulled to be shown elsewhere. The queries themselves can be put in templates for easy use and modification.

As Baron has said before SotA is going to be huge with lots of content. The more we can automate the less likely we'll be overwhelmed.

It may cause a bit of confusion for new editors but I don't think it would be that confusing and the benefits far outweigh the problems. -- Fenyx4 (talk) 10:07, 3 March 2014 (MST)

If we do have a list on the item's page how should it be formatted[edit]

How should it be formatted?

Tabular with all the relevant information. Including the list of all ingredients. -- Fenyx4 (talk) 10:07, 3 March 2014 (MST)

Recipe Master Lists[edit]

I like how the table has the recipe. Saves me a lot of clicks when looking for things I can craft. -User:Fenyx4

Okay so this got me thinking... I have been making these stupid spreadsheets to show people what recipes are and aren't known by the wiki... I think I understand my confusion here... you're trying to make a master recipe list that has every recipe in it for xyz? Can we NOT have that on base resources (the raw elements would be massive lists I'd imagine... things like iron bars and bolt of cloth and strips of leather... yeah... they'd be massive but missing a lot still) and instead do it by skill? Makes a LOT more sense by skill and would kill two birds with one stone (people trying to fill a crafting book top to bottom could use that list). Violation (talk) 18:58, 1 March 2014 (MST)

Examples from existing wikis and how they handled large lists of recipes successfully...

* UOGuide.com (http://www.uoguide.com/Tailoring -> http://www.uoguide.com/Wide-Brim_Hat) - List how I think it looks nice

* UO Stratics (http://uo.stratics.com/content/skills/tailoring.php) - List how most people likely would like it for burning crafting books

* Minecraft (http://minecraft.gamepedia.com/Diamond) - List how I understand you explaining it

There are a few guides we can use to see other peoples ideas and maybe make something similar somehow. I think it's worthy to note that none of the games I've played plan to have as much player made content as SotA... it's like Minecraft on steroids when it comes to their player content ideas... so we need to expect massive libraries of recipes with however it's planned. Violation (talk) 19:08, 1 March 2014 (MST)

First off the nice thing with Semantics is that all of these different types of lists you mention are fairly easy to make. At least in comparison to typing them all out manually. So we don't have to be too worried if we try something and don't like it. Once we set the Semantic properties up right it is like querying a database.

Things definitely can get too long. Chunk of Coal is already getting up there. But I think we can easily do a case by case basis when it comes to the really long ones. Here is an example of the sort of list I am thinking of. And here is one from the same site where they deemed the list had gotten too long and so they have links to other pages that contain the list. We should be able to come up with a rule of thumb for what length is acceptable. -- Fenyx4 (talk) 20:46, 1 March 2014 (MST)

I really like the second option and think the first option can be scrapped completely as it would duplicate the second option if it's used as a standard. I like the idea of standards (something done the same way everywhere) and I like the standard to be that when people click "edit" on a page to contribute they can... I don't want people changing the master list of recipes (holy grief buckets on potential there) so that would be one that we put a tag that lets people know to go to the item page to edit the recipe. Violation (talk) 07:09, 2 March 2014 (MST)

Visual diagrams / misunderstood[edit]

I have a visual of exactly what I recommended... I haven't seen another one just links to other wikis. I'm still recommending what's on that image above and nothing different content wise... I would be happy to move the order around (like Fenyx4 recommended, ie: contained in above or below lore doesn't matter to me) and I would like to point out that the diagram has one row of what I explained the planned 3 rows... so it would be in-line with other wikis and the pages I linked prior.

This talk page is out of control with misunderstood information and back and forth... not arguing on my end. I've not suggested some of the things you thought I meant Fenyx4 and would like to get you in a Google hangout so we can talk about this instead of typing back and forth once every 12 hours... it's slowing the productivity of the wiki down as now we have no one actually working on this until it's decided. This is the least productive the wiki has been since it's inception and I need a faster more efficient way for "another" form of communication on this topic. I take full responsibility for my visual and verbal diagrams not being communicated in a manner that people can understand... but something has to progress here or it's going to hurt the entire project. We only have 3 weeks to get this ready for the next major update and I've spent more time typing out responses on this one page -- and trying to retype them so they're "polite sounding" (which is my intent) -- then getting viable wiki edits and updates done. I'll await your reply, my Google profile if you have time: https://plus.google.com/u/1/111406733192630801538/posts Violation (talk) 10:25, 3 March 2014 (MST)

I dunno where our conversation got derailed. Sorry if it was on my end. I'm currently at work so can't do a hangout. If it helps I can put together visual representation of the suggestions I had for your visual representation. -- Fenyx4 (talk) 11:56, 3 March 2014 (MST)

It's probably my end... I'm explaining things how they make sense to me not others and in the conversational responsibility ideas should be presented correctly and misunderstood ideas are usually the fault of the person conveying the message not reading it. I am working on an update to mine that will be available in the next hour. Hopefully that helps a bit :) Violation (talk) 12:03, 3 March 2014 (MST)

Implementation of SMW properties[edit]

I'm afraid this is jumping right into the deepend of properties. Normally they don't get this complicated. If you aren't already familiar with them you might want to read this. I'm pretty happy with how the ingredients are now implemented. You can see for Iron Hilt that has a series of Property:Has_ingredient. Property:Has ingredient has a datatype of Record which allows both the ingredient and its quantity to be relatable to eachother.

All these properties are getting assigned by the Crafting Box template so our normal user never has to be concerned with 'em. They fill out the recipe here and the rest happens by magic.

There is one problem I see with how this is implemented. There are items that have multiple recipes. See Iron Bar and Iron Bar (alternate) (I couldn't find the alternate recipe on this wiki or I woulda linked there).

I feel like the proper way to display this would be two Crafting Box templates on the same page. But that would put all the ingredients in the same list so when we query it later it would look like one big recipe and not two separate recipes. We could solve this like it is on the old wiki by giving them their own pages. (and maybe that is what we should do for the short term.) But I think a better way would be using Subobjects which should allow us to split the recipes up.

If we do end up switching subobjects we shouldn't have to change how people use Crafting Box. It would all be under covers.

Thoughts? -- Fenyx4 (talk) 08:05, 2 March 2014 (MST)

While changing the template over I did come across the items that have multiple recipes. We are putting them on the same item page (which is how I like it) and like I said above it isn't playing well with the ingredients. (See Special:Browse/Iron_Warhammer where it lumps both recipes into one list).

So we will need to stick things into Subobjects sometime soon. -- Fenyx4 (talk) 10:26, 6 March 2014 (MST)

All the items with multiple recipes for future reference;

Carpentry Hammer[edit]

I can't get the Carpentry Hammer to show up with the larger size. (See Bed) The rest of the tools work properly as far as I can tell. Could another set of eyes give the template code a look? -- Fenyx4 (talk) 13:13, 6 March 2014 (MST)

Fixed it. Turned out it was a problem with how I was using arraymap. -- Fenyx4 (talk) 15:10, 27 March 2014 (UTC)

Separate 'Ingredients' into 'Tools' and 'Materials'[edit]

Alianin and I spoke in IRC and think it would be useful to distinguish between tools (things that aren't consumed) and materials (resources/ingredients gathered or refined and which are consumed during the crafting process). This would be done by separating the 'ingredients' parameter into 'tools' and 'materials'. We wouldn't necessarily have to make any changes to the display but we would be collecting the data at least so we would have the option later. -- Fenyx4 (talk) 15:10, 27 March 2014 (UTC)

I think this is a good idea. I'm afraid the way the Properity items will be used will be substituting them for the common tools, which is going to make recipe maintenance a nightmare. Being able to sub out just the tool tag will make it a lot easier. --Browncoat Jayson (talk) 15:28, 27 March 2014 (UTC)

Yeah, prosperity items will take some special consideration. I don't want to put two identical, huge crafting boxes with just the tool swapped out on every page. There are better ways to convey that information. -- Fenyx4 (talk) 15:36, 27 March 2014 (UTC)

Exactly. I was thinking an "alternative tool" tag on the prosperity items, and a table below them that did the search on the alternative tool, but substituted the prosperity item in its place. Should be possible, but I hanv't looked into it. Need to wait until they actually implement the prosperity items as usable items... --Browncoat Jayson (talk) 15:46, 27 March 2014 (UTC)

Separate 'Fuels'?[edit]

All of the crafts have consumable fuels (Chunk of Coal for Blacksmithing, Wax for Carpentry, etc.), which gets used up regardless of success or failure. Since these have a unique functionality, would it make sense to list them separately on the template?

Also, it would be nice if we could default the tool based on the selected skill (i.e., if Tailoring, default to "1 Tailoring Scissors"). Then, we only need to override it if there is a secondary tool that needs to be used.

Thoughts? --Browncoat Jayson (talk) 16:03, 10 August 2016 (UTC)

New "results" section in the crafting box[edit]

Goal: to show and document the exact items produced when crafting.

Here's an idea I had for a new results box that I talked with Fenyx4 about a while back and Gordias a couple weeks ago. Gordias said it wouldn't be too hard to get done but I haven't seen any traction so I wanted to get everyone's feedback and maybe some collaboration to get it moving forward. Please keep in mind the light template is still under construction. The reason why this is so important comes with pages like Maple Board that show two different recipes producing the exact same thing... when that simply isn't the case! Violation (talk) 22:31, 10 August 2014 (UTC)

Backend of this is already in Template:Crafting_Box_test. I've been busy with the maps so if anyone else wants to do the frontend please feel free! -- Fenyx4 (talk) 22:35, 10 August 2014 (UTC)