New Item Reference Page

[Tametomo]

It's funny that you'd suggest something like that, Crush, as I started simple, but the categories grew larger, as I found items that didn't quite fit. However, I like you're divisions a little better, as they can be scripted later. I'll update to that standard as soon as possible.

Also, I didn't think about a template for the item pages, and am currently investigating the best way to do so.

As to the sparsity of some of the sub-pages, I can see your point, but right now I'm trying to think of the best solution that will require the least amount of intervention later. The pages are split by the item labels that are currently used in the items.xml. My goal is that some time in the future, there will be only one autogen script which can just pull those item labels and create the specific pages either from the command line, or by some minor hard code adjustment (which I would prefer not to do). Right now, I think that the basic item reference page is the only one that won't be generated, but it's not too big of a pain to fix.

[Ces]

I made a few suggestions in this revision: Item Reference (diff 9582 9579)

One thing to note, and one question.

I added the Cotton Cloth (no image and not on subpage yet), but wasn’t sure how to add the tanktop(s) so I leaved them be (for now).

I also added the dates when the items were introduced into the svn as comments on the main page. Would this be interesting to have as its own column? (If so, I can do it for the subpages as well.)

[Tametomo]

I also added the dates when the items were introduced into the svn as comments on the main page. Would this be interesting to have as its own column? (If so, I can do it for the subpages as well.)

I don't think that the date the item was added to the svn has too much value. I mainly chose 6 months just because it seemed like the best cutoff. If I did 3 months, hardly anything would be on there, while if I did more than 6 months, then the christmas stuff would also be there, and the page would have been rather large.

Also, I personally hate the full listing links, as it seems like a waste of space and doesn't look as good visually to me than when the headers were linked to their individual pages. Since I didn't make that change, I asked a question on Jaxad0127's talk page rather than to just change it back right away.

Other than that change, I've liked all of the other contributions. Seems like it's starting to evolve into something that will be much better for the future of this project.

EDIT: As an aside, I'm trying to keep it as automatable as possible, and getting the SVN date would make things really complicated. I don't ever see the basic Item Reference page being fully automated, but it shouldn't be that bad once the other pages are automated, as you can just cut and paste from them. Out of all the elements in the pages so far, the hardest bit to automate would be the rarity, but it's still (slightly) possible. I haven't made up my mind on whether to just ignore it for a script, and leave it out altogether, or to just script it and then correct it as necessary (which could easily be done. The problem is knowing what can be bought/quested, and what was available before and what isn't anymore).

[Jaxad0127]

EDIT: As an aside, I'm trying to keep it as automatable as possible, and getting the SVN date would make things really complicated. I don't ever see the basic Item Reference page being fully automated, but it shouldn't be that bad once the other pages are automated, as you can just cut and paste from them. Out of all the elements in the pages so far, the hardest bit to automate would be the rarity, but it's still (slightly) possible. I haven't made up my mind on whether to just ignore it for a script, and leave it out altogether, or to just script it and then correct it as necessary (which could easily be done. The problem is knowing what can be bought/quested, and what was available before and what isn't anymore).

The availability could be kept in a separate file thats maintained separately (due to the amount of processing involved). A separate file for this also helps automate the no longer available option.

As for those extra links I added, go right ahead and remove them if you want to. I didn't realize that the headers were links. Those were removed by Kess.

[Tametomo]

Yeah, I didn't think that it was too obvious, and was trying to find a way to handle it better but still be as convenieny, which is why I really liked Crush's addition to the template, where it linked to them at the top.

[Ces]

So, perhaps, skip the links in the main text alltogether? I’m not really fond of having headers being links, as it looks visually disturbing to me. I think Crush’s template links will be enough. Only aesthetical though.

And sorry for the dates, I somehow forgot about the script... I blame the heat. Consider them gone. But in case they are useful:

Code: Select all

Feb 13, 2008	Crusade Helmet, Infantry Helmet, Knight’s Helmet, Warlord Helmet
Feb 23, 2008	Iron Ore
Mar 17, 2008	Black Cowboy Hat, Jeans Chaps, Snake Skin, White Cowboy Hat
Mar 20, 2008	Bunny Ears, Easter Egg (Blue, Green, Pink, Red, Teal, Yellow)
Apr  3, 2008	Golden Platemail
Apr  4, 2008	Crown, Developers hat
Apr 26, 2008	Cap, Fur Boots
Apr 30, 2008	Serf Hat
May 28, 2008	Golden Warlord Plate, Orange, Warlord Plate
Jun  5, 2008	Cotton Cloth, Tanktops

[Quiche_on_a_leash]

If it's any help, I recently wrote a dyeing script in php for manabay so items that are dyed look like in they should in game.
So if you want the correctly dyed images, rather than the grey scale versions, you can find them here: http://tmwc.110mb.com/manabay/cachelist.php

[Crush]

I see my tank tops in there. Does that mean someone already threw them around ingame and people are trading them?

[Quiche_on_a_leash]

Nah, manabay uses the latest items.xml etc, I just block what can be sold with a list.

[Tametomo]

So, perhaps, skip the links in the main text alltogether? I’m not really fond of having headers being links, as it looks visually disturbing to me. I think Crush’s template links will be enough. Only aesthetical though.

I think the links in the headers are useful, as you don't have to go to the top if you're interested in looking at more of that type of item. However, I don't think that there's a need to go out of the way to take up more space to do so. At the same time, I didn't think that it was very obvious to begin with, and felt like there was a need to double up on links, which is why I like Crush's navigation links. Also, it makes it so that you don't need to scroll down to it if you don't want to.

If it's any help, I recently wrote a dyeing script in php for manabay so items that are dyed look like in they should in game.
So if you want the correctly dyed images, rather than the grey scale versions, you can find them here: http://tmwc.110mb.com/manabay/cachelist.php

Haven't quite decided on what I'm going to do for dyed items. Doesn't look like I can ignore them, but I don't think that they should have their own individual item listings also. I could just show all individual colorings on one item, or just do one for the noncolored variant. So far that works, but I'm not entirely sure if there will be a generic tank top like there is for sweaters.

If I go about showing the individual colorings (which will be the more likely outcome), I might add a link to the template. Personally, I prefer to have all images located on the wiki, rather than offsite, as you never know when something will be pulled or changed on another site (even though I realize that I can trust you to not change them).

[Bjørn]

If I go about showing the individual colorings (which will be the more likely outcome), I might add a link to the template. Personally, I prefer to have all images located on the wiki, rather than offsite, as you never know when something will be pulled or changed on another site (even though I realize that I can trust you to not change them).

Since we have all the images in Subversion in the tmwdata module, I don't actually see much of a point in duplicating them on the wiki. As for the item reference, I would much prefer a PHP script based directly on items.xml and the images in tmwdata, which we could host on Platinum. Same for the monster reference.

[Crush]

Maybe we could just format the contents of items.xml using XSLT. This wouldn't require any server-sided scripting because all modern web browsers can display XML files with XSLT rendering instructions.

[Bjørn]

Maybe we could just format the contents of items.xml using XSLT. This wouldn't require any server-sided scripting because all modern web browsers can display XML files with XSLT displaying instructions.

Hmm, nice idea. That won't do cutting out and dyeing of the images though, but of course the generated html could refer to a server-side script that does this...

[Tametomo]

Maybe we could just format the contents of items.xml using XSLT. This wouldn't require any server-sided scripting because all modern web browsers can display XML files with XSLT rendering instructions.

Bagh! I really should have thought of that. It's by far much easier to do than the current scripts and wouldn't require too much work, although it would require a separate items.xml for each page, which would then reference their own stylesheet in the header (easy to have autogenerated). The stylesheets would then be written for each page, where it would have to be changed in a couple of spots, but would be generally the same.

However, would this need to be held outside of the wiki? I don't know how mediawiki would handle this (I know it can have HTML inside of it, but would the browser be able to recognize the contents as XML instead of just text?)

[Crush]

What's the point of putting completely auto-generated pages which aren't supposed to be edited by humans on a wiki? Why not put the item reference on a separate page of the homepage?