User talk:ABSOLON: Difference between revisions

From Elanthipedia
Jump to navigation Jump to search
Line 67: Line 67:
::::::The other thing is that the database as you have it on Olwydds wouldn't be able to exist in the same form here. On-demand filtered lists like that are not a wiki's strength. I.e. even if we were to include all of your information from there it wouldn't be as easy to access for users here. That said, I do like having elanthipedia being as complete as possible. I think the best solution would be to (eventually, as per above) have all of the foraged items as an entry in our database with the most commonly found or easiest to access locations in each province and then include a link to olwydd's for more detailed information.--[[User:ABSOLON|ABSOLON]] ([[User talk:ABSOLON|talk]]) 18:06, 20 October 2014 (CDT)
::::::The other thing is that the database as you have it on Olwydds wouldn't be able to exist in the same form here. On-demand filtered lists like that are not a wiki's strength. I.e. even if we were to include all of your information from there it wouldn't be as easy to access for users here. That said, I do like having elanthipedia being as complete as possible. I think the best solution would be to (eventually, as per above) have all of the foraged items as an entry in our database with the most commonly found or easiest to access locations in each province and then include a link to olwydd's for more detailed information.--[[User:ABSOLON|ABSOLON]] ([[User talk:ABSOLON|talk]]) 18:06, 20 October 2014 (CDT)
:::::::While we obviously could just filter out for just the healing herbs, there are still a TON of entries for those in there. I also think that it would great to have everything in a single location but unless we could set up some sort of DB that can be accessed similarly by the wiki so it could be sorted down by the user to a manageable list on each use, just having tables of that information on each page will get unmanageable fast. Maybe it is something to keep in mind for future projects though, I imagine a number of things would make use of a database format vs. long tables (looking at you, crafted item pages...heh). --[[Kythryn]] 15:10, 21 October 2014 (CDT)
:::::::While we obviously could just filter out for just the healing herbs, there are still a TON of entries for those in there. I also think that it would great to have everything in a single location but unless we could set up some sort of DB that can be accessed similarly by the wiki so it could be sorted down by the user to a manageable list on each use, just having tables of that information on each page will get unmanageable fast. Maybe it is something to keep in mind for future projects though, I imagine a number of things would make use of a database format vs. long tables (looking at you, crafted item pages...heh). --[[Kythryn]] 15:10, 21 October 2014 (CDT)

== Help with Picked Flora project ==

heya ABSOLON! I was hoping if you had some time I could get you to help me with getting the wiki-code to do what I want with the next project Linett & I are going to tackle, the picked flowers and foods. I'm starting off with the roses ([[Rose]]), since there are so many different variations and other things that need to be sorted OUT of the picked flower list. I'm using as my "test picked rose" the [[Hodierna's Blush rose]]. What we're currently thinking about doing is for each individual flower/food page, assign it the itype "picked flora", and then have a table or search populate on the common name page for that flower. If you'll notice on the [[Rose]] page there are various sub-headings now for each rose "type", and under the "Flowers" section there is a table query to look for those.
:Where I am stuck though is how, on the next section (Store & Festival Purchases) to exclude the roses that have the itype "picked flora".
:Also, I would welcome any ideas on how to make these pages more streamlined and wiki-friendly. I know from the TALK on the [[healing herbs]] page, you mentioned some server caching issues with tables. If there is a more efficient way for doing a search (ie. with the MSearch, ISearch, etc.) I know we aren't tied to any particular way of presenting the information. Obviously, we'll have a few picked items already in the database we'll need to to back and update, however we have a TON of new ones to add, so if there is a better way to do things now is the time to make the conceptual change...heh.
::Thanks in advance! --[[Kythryn]] 06:37, 22 November 2014 (CST)

Revision as of 06:37, 22 November 2014

Automatic Item Tagging

This is going to sound like a strange question, but would you have any interest in the weapon, shield, armor, and item page templates automatically generate material, color, and symbol tags? This is by far the most time-consuming part of adding item pages. (I wrote a script that does everything else. It attempts to create tags as well, but it requires a lot of cleaning up and error checking.) Tags are literally the reason that I have text files of hundreds of Elanthipedia item forms that I have not yet posted.

For example, this item from Tildi's Flowers has this mind-boggling array of tags:

|name=fragile wirework crown displaying shimmering chaos chalcedony lantana flowers
|noun=crown
|look=Thin palladium wires form an elaborate knotwork of interlocking loops.  Twists of the silvery-white metal curl out and upwards from the headband, creating the base for each flowering cluster comprised of tiny gemstone florets.  Dramatically varying in coloration, the naturally formed combination of hawk's and tiger's eye displays a wide range of colors from pale to dark blue, streaked with chaotic swirls of rusty red, gold and rich brown hues, ensuring each flower is unique in appearance.
|MTag=palladium, chaos chalcedony, chalcedony, hawk's eye, tiger's eye
|CTag=rust red, rust, red, rich brown, brown, gold, yellow, dark blue, blue, silvery-white, silver, white
|STag=lantana flower, knotwork


Manual of Style's standards for item tags: As you can see, we currently tag both the more specific version and the more general version (e.g., "chaos chalcedony" gets tagged "chaos chalcedony, chalcedony"). The same goes for colors. This makes the item search feature work for both general and specific queries. It also creates extra work.

Let me know if you're interested; I don't have the wiki-fu to undertake something like this myself. I have lists of commonly seen materials, colors, symbols, etc. My AIM is IsharonDR. --ISHARON (talk) 18:35, 21 June 2014 (CDT)

I have to wrap my head around how best to go about this. It should be able to be done, but I'm not sure my wiki-fu is entirely up to the task either. I think similar to how Item Properties work, a separate template ItemTags would be included in each of the Item, Weapon, Armor and Shield templates that matches the description and item name for a list of descriptors should do the trick... but I'd have to think how that would interact or interfere with the ability to manually add or edit tags.--ABSOLON (talk) 22:07, 21 June 2014 (CDT)
It could be done. It actually wouldn't be all that complicated, just time consuming. You'd basically use the #pos parser function to check the name and look for each item for every item you want cataloged. Problem is a) you'd have to add in everything you wanted it to catch, and b) I have no idea how resource intensive it would be. I suspect it would be pretty bad, compounded by the fact we have a LOT of item pages. -CARAAMON (talk) 00:29, 22 June 2014 (CDT)
Actually, I just had an idea. Would a form you could cut and paste the name and look into, run it, then cut and paste the output from into the item form be useful? That would cut down needing to run it in the background every time an item is edited or refreshed. -CARAAMON (talk) 00:31, 22 June 2014 (CDT)
I was thinking that myself actually. Basically the same thing as the script Isharon is already using, but a part of elanthipedia so that anyone could make use of it without needing a separate tool.--ABSOLON (talk) 00:35, 22 June 2014 (CDT)
P.S. it would also need the READ in addition to the LOOK and TAP.--ABSOLON (talk) 00:43, 22 June 2014 (CDT)
The form idea could work. I'm happy to share what my Elanthipedia Items script already looks for. However, because there are so many "false positives," I'm actually thinking about editing my script to create fewer automated tags. (For example, currently, if the script sees the word "ebony", there is no way for the script to know whether ebony is a material or just a color. Right now, the script fills out ebony for both the material and the color, requiring me to go and remove any inappropriate tags. This can add up to a lot of work.) Basically, what I am thinking is to produce a list that would check for only unambiguous terms, requiring less intensive error-checking. The downside is that it would increase work on the other end (requiring me to manually add more missing tags). Sometimes I wonder if we should simplify our tagging standards. --ISHARON (talk) 19:53, 26 June 2014 (CDT)

Re: ambiguous tags. It could still check for these, but automatically mark them as ambiguous. E.g. MTag, CTag, STag, and ATag. Manually editing them would be easier that way at least, since you wouldn't have to compare the tag lists to find duplicates manually. The ATag could even simply exist in the item entry without needing to display it on the page, except perhaps flagging the item as an 'Item with Ambiguous Tags.' Then you could still post your items without having to worry about backlog and just go through and move ambiguous tags to the appropriate tags at your or someone else's leisure.--ABSOLON (talk) 03:59, 27 June 2014 (CDT)

Thanks for the idea. I think I'll try something like that. --ISHARON (talk) 23:10, 28 June 2014 (CDT)
Let me know what you do with your script and I can get the template to work with your new output in the meantime. E.g. if you decide to just do an ATag, I can make the template flag the item so it's easier to track it down later.--ABSOLON (talk) 09:03, 29 June 2014 (CDT)
Sorry to jump in on this thread, but I saw it when I was on your TALK page for the herb stuff. Historically, when fests come around, I seem to be one of the folks adding a lot of the game prizes to the wiki. Unfortunately, I don't always get them added how the moderators want them and someone ends up having to make little tweaks to 100 things I added the night before. If there was a script to add things that could make life easier on you guys, I'd be more than happy to use that instead of the FORM pages. With the HE coming up, I imagine there will be a few new batches of items I'll be adding, plus I still have a couple bags of prizes on an alt from the Mega-Safari I need to clear out. --Kythryn 15:18, 21 October 2014 (CDT)
If you use Genie there's two scripts for this.:
1. Elanthipedia_Shops_(script) - This script outputs shop info in template form, although there is still a bit of editing necessary.
2. Elanthipedia_Items_(script) - This script outputs item info in template form, although there is a fair amount of editing necessary, especially surrounding tags.
I am not aware of any non-Genie options, unfortunately. Regardless, no script is going to perfectly create an item template every time, so there probably wouldn't be a lot of difference in how many minor things need editing just from using a script. One suggestion I have when you have a lot of items to enter would be to enter a handful of items and then wait to see what someone fixes on them, and then enter the rest with the fix in place now that you know what it is. (The most common example is not setting 'sourcetype' to '-' when there's no non-automatically populated sources, for example.) The downside to that is it might be a while before someone gets around to checking for fixes.--ABSOLON (talk) 16:25, 21 October 2014 (CDT)

So....

How'd you like to be a moderator? You seem to have a pretty good understanding of everything we need, and we can always use more hands. Gimmie an IM if you're interested. -CARAAMON (talk) 23:39, 18 June 2014 (CDT)

Welcome aboard, don't screw it up. ;P -CARAAMON (talk) 00:32, 22 June 2014 (CDT)
Thanks! Glad to be aboard.--ABSOLON (talk) 00:37, 22 June 2014 (CDT)
Congrats! --TEVESHSZAT (talk) 11:22, 22 June 2014 (CDT)
Congratulations! --BLADEDBUTTERFLY (talk)

Warrior Mage 3.1 graphical spell tree

Just a heads up that I noticed the graphical spell tree has Arc Light listed as costing 3 spell slots, but the Shard Guildmistress as well as DISCERN say it's 2. Thanks for all your hard work! JACOBS77 (talk) 02:22, 4 August 2014 (CDT)

Fixed.--ABSOLON (talk) 14:49, 4 August 2014 (CDT)

Cleric 3.1 graphical spell tree

Hey again. Hand of Tenemlor is 2 spell slots. I'm willing to correct it, but don't want to step on any toes. --JACOBS77 (talk) 12:57, 11 August 2014 (CDT)

Oops, totally missed seeing this message until just now. Will fix it later tonight. Thanks for the heads up.--ABSOLON (talk) 18:46, 1 October 2014 (CDT)
Fixed. You may need to refresh the page to see the change.--ABSOLON (talk) 02:33, 2 October 2014 (CDT)

Help with minor Khri project

I merged what I thought was still relevant information over to the category page, and formatted it. I'm new to wikis so I'm not comfortable enough to mess with the tree images, so if you want to update the one on the category page then feel free to. --NINEVAH1 (talk) 11:46, 4 September 2014 (CDT)

Thanks! I can finish it up from there. I just didn't know what information was still correct or not.--ABSOLON (talk) 01:56, 5 September 2014 (CDT)


Herb Foraging

You commented on the forums that you were hoping someone would take on the task of working on a foraging compendium of sorts. I have quite a bit of data and I regularly gather more. I have a sortable spreadsheet which would allow one to either find a location and discover what herbs are there or to find every place on could find, say, Yelith Root. The problem I have is how to translate that into a functional format for Elanthipedia (which I have yet to figure out). I suppose I could just create a sortable table but I imagine there is a more user friendly way. Do you have any suggestions or guidance? Ithrios (talk) 15:46, 1 October 2014 (CDT)

Gimme a few days to put a template together for individual herb pages. I'll probably have time to get to it on Saturday. Then you can fill out the template data from your database with things like what each heals, locations, special properties, etc on each herb's page. From that we can pull information together for tables like with the spell category pages or possibly queries like with the bestiary search. Unless you have a better suggestion? Out of curiosity, how detailed is your information on location? General, such as 'in boar clan' or 'on the NTR' or is it more along the lines of room no.'s 1, 14, and 26? --ABSOLON (talk) 18:50, 1 October 2014 (CDT)
It is detailed down to a specific room. Quite often two rooms in the same area have different herbs available and, in general, I try and find a room in an area with the most variety. When I have tried to read between the lines from what the GMs have said it seems that they have specific settings for rooms that allow a group of herbs to be foraged in the same room (for example, nuloe and aevaes are almost always found together and qun is only found in deserts). I have tried to guess what these settings are with the goal of being able to classify a room as "boreal forest type 3" or "coastal grassland type 1" but have had only limited success up to this point.Ithrios (talk) 08:34, 2 October 2014 (CDT)
I just figured you would need the categories of information I have for each herb to create the template. Currently each has: area healed (body location and internal/external), preparation type (crush or dry), wether it is forageable during the day, night or both (currently all herbs are forageable during the day, some cannot be found at night), what seasons it is forageable in (some herbs cannot be foraged in the winter) and the general terrain types it is found in. This is in addition to the specific locations, of course. Would it be easiest to track specific locations on their own page where I could fill in what herbs can be found and use the queries to fill in a table on the yelith root page? This would make the location equivalent to a spell and the herb equivalent to a spell list. This would require adding each room as its' own page, unfortunately. The upside is we could link those to specific locations on the maps.Ithrios (talk) 09:59, 2 October 2014 (CDT)
Yeah, each room having its own page is a bit much. I think specific locations are best stored on each herb's own page. The at a glance table could easily provide general biome details which would be enough to give a good idea, and if someone wants specifics they can follow a link. As for the rest, I'm working on getting a more official set of biome and terrain settings, but no guarantees there. At the very least I'll set up what you have indicated above, so regardless of what gets created, you should be able to just enter the appropriate details where needed.
Could you shoot me an AIM so I have it? XyngleburtDR.--ABSOLON (talk) 10:32, 2 October 2014 (CDT)
This should mostly be done except for the data entry and some tweaking as people provide suggestion for improvement. It is set up to work for both healing herbs and plain old foraged items, but since there's not much call for information on general foraged items we're going to just leave it at herbs for now until some issues with Item pages get worked out.--ABSOLON (talk) 03:56, 18 October 2014 (CDT)
With Absolon's update of the wiki pages, it got me thinking about the information over on Olwydd's foragaing database (http://www.olwydd.com/herbs/forage.php). From the sounds of it, a lot of that information mirrors the information that Ithrios is also compiling. I still add to that DB because there wasn't really anything else around, but it is a PIA. I have a spreadsheet and a key for all the cities, herbs, etc. Then, when I get some new items to add, I email Olwydd a copy of that SS and he uploads it when he gets time. Obviously, he doesn't really play anymore, so it's kind of neat he keeps that site running and helps with updates, but it is still a more involved process than just "hey, I found qun pollen here, cool...let me put that in the DB quick". That all being said, would you like me to email him and see if he has any problem with us migrating that stuff over here? Looking at the master SS, as of July 2014 there are 12796 separate listings, which includes herbs, woods and misc. foraged items. We'd need to tag in terrain types and drop some site-specific stuff, but IMO it would be nice to just have a single DB/table/whatever going for this stuff. --Kythryn 12:32, 20 October 2014 (CDT)
The eventual plan is to include all foraged items and to have them be actual Item:Item_name pages. Due to issues with properties in the Item namespace right now, this isn't currently feasible unfortunately. I talked it over with Caraamon and we decided that limiting our data to herbs right now is best, because most people aren't going to need to find information about the various random non-herb foraged items and it saves us from having to convert 100+ pages once the Item namespace issues are resolved. As for woods, those don't currently have much of a meaningful purpose and lumberjacking is coming soon so we're holding off until it is released. That system will likely be much more like mining anyway and not be tied into the foraging system at all.
The other thing is that the database as you have it on Olwydds wouldn't be able to exist in the same form here. On-demand filtered lists like that are not a wiki's strength. I.e. even if we were to include all of your information from there it wouldn't be as easy to access for users here. That said, I do like having elanthipedia being as complete as possible. I think the best solution would be to (eventually, as per above) have all of the foraged items as an entry in our database with the most commonly found or easiest to access locations in each province and then include a link to olwydd's for more detailed information.--ABSOLON (talk) 18:06, 20 October 2014 (CDT)
While we obviously could just filter out for just the healing herbs, there are still a TON of entries for those in there. I also think that it would great to have everything in a single location but unless we could set up some sort of DB that can be accessed similarly by the wiki so it could be sorted down by the user to a manageable list on each use, just having tables of that information on each page will get unmanageable fast. Maybe it is something to keep in mind for future projects though, I imagine a number of things would make use of a database format vs. long tables (looking at you, crafted item pages...heh). --Kythryn 15:10, 21 October 2014 (CDT)

Help with Picked Flora project

heya ABSOLON! I was hoping if you had some time I could get you to help me with getting the wiki-code to do what I want with the next project Linett & I are going to tackle, the picked flowers and foods. I'm starting off with the roses (Rose), since there are so many different variations and other things that need to be sorted OUT of the picked flower list. I'm using as my "test picked rose" the Hodierna's Blush rose. What we're currently thinking about doing is for each individual flower/food page, assign it the itype "picked flora", and then have a table or search populate on the common name page for that flower. If you'll notice on the Rose page there are various sub-headings now for each rose "type", and under the "Flowers" section there is a table query to look for those.

Where I am stuck though is how, on the next section (Store & Festival Purchases) to exclude the roses that have the itype "picked flora".
Also, I would welcome any ideas on how to make these pages more streamlined and wiki-friendly. I know from the TALK on the healing herbs page, you mentioned some server caching issues with tables. If there is a more efficient way for doing a search (ie. with the MSearch, ISearch, etc.) I know we aren't tied to any particular way of presenting the information. Obviously, we'll have a few picked items already in the database we'll need to to back and update, however we have a TON of new ones to add, so if there is a better way to do things now is the time to make the conceptual change...heh.
Thanks in advance! --Kythryn 06:37, 22 November 2014 (CST)