Stonehearth Wiki Rebirth

General Discussion
1

So Stonehearth Wiki has been outdated for some time and needs some major TLC. I’ve decided to step up and try to lead a team for keeping the Wiki updated the best we can. I’ll start by saying this will be no simple or small task but I think we can do it if we start from scratch with the Alpha 18 update. Alpha 18 will be our baseline for all information that will be put into the wiki and will try to maintain that information as updates are pushed out.

Our main focus will be creating and editing pages for every item, class, mob(generic names will be used due to randomly generated mob names), and critters. Example of the Generic names will be such as “Goblin Leader”, “Goblin”, and “Necromancer”(boss mob from the Crypt).

I’ve made a discord server so people can talk about what sections needs to be updated with current information, what pages need to be created and other information. Stonehearth Wiki Discord. Right now the discord is very basic and freshly created but I will flesh it out later.

If you would like to help please take the time to make a post here stating what kind of contribution you would like to focus on whether it be structuring the wiki to make it look nice, adding entries for items, or whatever else. If you decide to join the discord please specify your discord name and ID (the # beside your name at the bottom of discord) so I can keep track of who you are~

EDIT: If you would like to know what progress or new pages have been added check out the discord server as well; We have a channel for Updates such as new pages and a channel for what a specific person is currently working on.

I myself am currently working on Tools/Job Talismans. 3/15 done so far. Will try to get at least 7 done today.

3 Likes
2

@TheDerpySupport, so glad that you are taking the lead on updating the wiki. The last major update was completed in October/November of 2015 - with a small review in February, and things have certainly changed since then. A couple of notes as you work on this:

  • In addition to moderating here on the Discourse, I am a Wiki Guardian (essentially a moderator) on the Stonehearth Wiki as well. As such, I have a few more privileges and access to tools that the average user doesn’t. If anyone working on this needs assistance with something (for example, editing a protected page, or doing mass updates/deletions in bulk), feel free to let me know so I can assist.
  • The software running the wiki (Mediawiki, developed by the Wikipedia team) is very expandable. Many pages will use the same basic format. Creating templates (a few are already created) is a good idea to reduce typing the same thing over and over, and keeping pages consistent.
  • I previously created a spreadsheet for tracking updates to the wiki. I’ll need to check if it is up to date, but I have linked it below and given sharing access to anyone with the link. Please use it as you go through reviewing pages so we don’t all end up reviewing the same pages many times.
  • When I have more time, I’ll write up some notes on what the existing templates are, as well as common markup for things like tables.

Thanks @TheDerpySupport again for taking the lead on this. I wish you the best of luck!

5 Likes
4

As an example of one of the new pages(which will probably get changed as people modify it to look better Kappa) here is the page for “Farmer’s Hoe” which previously did not exist. Farmer’s Hoe

4 Likes
5

Currently Finished Pages:
http://stonehearth.gamepedia.com/Farmer’s_Hoe
http://stonehearth.gamepedia.com/Carpenter’s_Saw
http://stonehearth.gamepedia.com/Herbalist_Staff
http://stonehearth.gamepedia.com/Mason’s_Chisel
http://stonehearth.gamepedia.com/Weaver’s_Spindle
http://stonehearth.gamepedia.com/Blacksmith’s_Hammer
http://stonehearth.gamepedia.com/Wooden_Practice_Sword

Red Text on any of those pages are pages currently not created and will be created as we go forward with the updating of the wiki. If anyone has any questions or comments about the finished pages so far please speak up so I can hit them before I move on from Tools/Class Talismans

2 Likes
6

Note: it MAY not be feasible for stonehearth.
This is just possible suggestions depending on the current state of things.

I used to be active on a couple of mediawiki-based wikis, and specialized in embedding data into wiki pages which are accessed via templates by other pages to create a dynamically-consistent set of pages (instead of having the value manually entered into individual pages that has to be all updated manually, I just update the ‘source’ data and all dependent pages will show things correctly).

Now, this was before the “boom” of semantic web and stuff, and though I have not been keeping in touch, there are probably much easier ways to do things that are similar to those which I had to conjure a lot of voodoo template coding to accomplish.

The main problem I see here, is that the data format, and data content of stonehearth is likely to be volatile. So I had this notion:

  • embed the raw JSON file content of stonehearth.smod into respective pages as “data”. (if possible, the exact JSON file. as a fallback, run a script that automatically formats the raw JSON into a form suitable for wiki)
  • create support templates that extracts information (properties) from these raw data.
  • Then create the templates that actually make use of the support templates above to compose the “human-readable” pages.

What this means is that, the same template can be used to generate the human-readable pages for all the entities without requiring human to manually edit all the content. Adding a new entity is simply creating a new data page (dump the json/data from game into it), creating a new content page that calls a template referencing the data page above (one line), and we have the final page.

To still allow “manual additions”, we can mix the auto-generated part from parts which allow human to edit.

An example:
Note that this is done a long long time ago, using very basic template stuff which is probably outdated by today’s standards.

This is a page for a sword in the game The Sims Medieval for human to read.

This is what the source (click on the source tab) of the page actually looks like. Notice that the info box etc from the page view above are template generated from the embedded data instead of manually edited. Part of the page however, retains the manual wiki editing style so even those people who don’t know the templates can add content there.

The properties of the “sword”, which are declared as data on the page, are actually accessible from other pages as well by referencing. (so changing the values on this page will “automatically update” all other pages that uses it).

Example of another page that uses data from many other pages.
Note that everything in the table on the page, including the icons, values, etc are all pulled from the data from the individual pages for the items. Changing the values on the item page will automatically update this page’s table.
If you look at the source of the page, you can see how the values are pulled, which is quite intuitive to read.

EDIT: lol I even forgot some niceties that were placed in. In the above page with the list, pages for items which are not created are shown in redlink. but some of them have a small “(create)” link behind. Clicking that will load a default template and instructions on how to create a page for a new item from scratch that integrates into the template system, even for people who do not know how the templates work.
Those with “(objectify)” are “legacy” pages which do not contain object data detected by the templates, so providing easy prompts for the contributors who knows how to do the template to “update” them.

For those who are more familiar with mediawiki templates
basically, the above is achieved by using a generator template (e.g. one for Sword) to generate an item specific template on the item’s page (e.g. Crude Sword page above is actually a generated template). This allows the item page to be used as firstly a human readable page, and secondly, as a template that can return properties of that item. Reminder that this is “old tech”.

Just thinking that if we had something similar to that, every time after an update for stonehearth, we can just

  1. if there are no document structure changes, paste in the new json data directly into the respective entity pages and everything else will update.
  2. if there are document structure changes, change the support templates on how process it, without breaking the other pages that uses the support templates to “extract data” from it.

iow, I just don’t feel like updating 101 things manually after each new game release… lol…

1 Like
7

Here’s my concern: all items pull their info from more than one json file, and beyond there’s still a bit of inconsistency. For example - all files use localization strings, so we would need to parse en.json in addition to the item’s json file to get things like name, description, and flavor. If done right, this could be huge as it would simply localizing the wiki, but it would likely be very complicated for mediawiki templates. Further, some items mixin data. Take doors - they get their health from a mixin, except for the iron door which has health hardcoded in the file.

Anyway, it sounds like a great idea and I’d love to see it work, but I worry about how well it will work in reality. If we could get a script outside of mediawiki to transfer the localized text back into the json files, we might be able to do this - but it won’t be easy.

2 Likes
8

yeah. I was hoping that new technology would hopefully make that easier. I could just be over-optimistic. It woundn’t be feasible if it takes too much efforts to to implement vs the expected period of usefulness, or too much efforts to maintain.

If going by old way, since wiki templates do not go well with structured data, I would probably choose one of the following approaches:

  • subpages (downside: a lot of smaller pages, upside: allow each sub-structure in a hierarchical data to be accessed in one chunk)

  • flattened properties - i.e.convert all properties in tree into top level property whose name is concatenation of the “entire path”. (downside: substructure cannot be accessed as one collection, upside: everything can go onto one page).

No matter which approach, it will require a preprocessing stage (say use a script to convert raw json data, which can handle mix-ins, multilingual text references at the same time into one of the two forms above. The one that includes subpages may need to use wiki API directly to mass upload the pages too if it is too troublesome).

Regarding multi-language, yes. It won’t tie in with the UI locale naturally (though it can made to be. I am not so sure though as I always think of App locale vs data locale as 2 independent things that does not always have to match). Going old-school, if I don’t “bake” the strings into the data itself, I would pre-process each language file into a template, and make the data refers to the strings via a template. that way, the data remains language-agnostic. But it won’t be nice to the server’s computing resources (evaluating large/nested template).

So if going “old-school”, I prob won’t recommend it, unless as a small experiment. Was hoping more like some new plugins for wiki engines can take in json structure directly and have a template that can extract data directly from it which will greatly reduce the complexity required (yeah lazy me, lol)

Different issue: suggestions

Anyway, to start a slightly different issue on the topic: how to motivate/promote contribution and suggestions on a sustainable process.

Again, these are just simple ideas that I just throw out from my experience, not organized or quoted from any better sources.

Basically, I would classify wiki contributors into roughly the following roles (note that a person can have more than one role at a time)

  • Planners (aka redlink makers) - these people plan out what needs to be added, often using means like navboxes (highly recommended as it acts as nav tool), lists, or at least some high level page that marks out all the topics of interest in wikitext.

  • Writers (aka page makers) - these people are the ones adding the actual content. Can roughly be categorized into advanced writers who knows how best to put content into the wiki, and basic writers who just provide content, but may not know best way of organizing them. The latter group can simply create content in whatever format that they can manage and add a tag/category to trigger post-processing by the last group.

  • Maintainers (aka house keepers) - these people refactor existing contents to introduce standardization, organizations and relations. They can also provide common tools(templates) such as common info-boxes to show similar content summaries in standard fashion, navboxes to help jump around related topics quickly etc.

As much as possible, some guidelines should be given to each group (e.g. maintained on a “working page” specialized for the group) to help move things in a more directed fashion. Also, interactions (among contributors) and confidence (knowing what you do to the wiki is ok) promotes motivation.

Example of a guideline (JUST example).

  • Always start with a list/navbox of related topic, and make it a child of some fixed parent so that it is always accessible (won’t get “lost”).

  • Planners comes in with a subject category and create a list/navbox of redlinks. More items can be added/edited by other contributors easily once the thing actually exists. This thing should be embedded into all pages of the items it references.

    e.g. Say I create a navbox for tools, and put in redlinks for all the tools I know of atm. Anybody who looks at the navbox can either add in a new item that is not there yet, or click on a redlink itself to create a page for the item. He/she should embed the navbox on the page created so that all pages of the items listed have easy access to each other. It will help people when they want to “imitate” the style/structure of existing pages.

  • When creating/editing a page, if the writer is not sure of the organization or conformance to the current standards, just use predetermined tags to mark the page. That way, even if not experienced, they can concentrate on contents instead of having to divide their attention for other concerns like conformance to guidelines.

  • Maintainers should monitor some dynamic pages which lists all pages that has special tags included, that should indicate what housekeeping needs to be done on the page. This should be more efficient than randomly searching for such pages or looking at change history all the time.

anyway, no rocket science here. just basic stuff that any slightly experienced wiki contributor can list down. But it may help for those new to wiki content creation.

1 Like
9

If there’s a template,for all of 1 category of items to follow, then it would be a lot easier adding new ones.

Aka if you have a template for tools, there’s only like… 8 tools in the game? Changing the ingredients, and the icon of what it needs are relatively simple. Especially if in the ingredients slot it’s just a icon+name that when clicked would lead you to that ingredient’s page. Going through all the items in the game files would take someone dedicated maybe 4-6hrs.

When it comes to enemies and all that it might take a little longer.

1 Like
10

We already use template for the tools pages and currently there are 15. Like I said the rebirth project wont be simple and it wont be easy. Pretty much the whole wiki entries will be redone to have a better structure. The idea is to list every item, mob, or information obtainable via playing the game like a true wiki should

1 Like
11

Ahem, what about the level requirement?
The Farmer’s Hoe is crafted by a Carpenter level 2, this is not mentioned on the page.

I have this dream of collecting the lore from the flavor texts of the recipes, we could make a list of all the NPC names that appear on them. But that’s when everything is already updated, more of a long term idea.

Totally agreed.

1 Like
12

Right now I was more interested in getting the information up and I have slowly been correcting any missing information; Just last night I went back through those pages and added the damage info for the tools

As for the “flavor texts” not all the tools have them that I remember seeing and any “description” listed on those pages is taken from the tool’s hover text when viewing a hearthling’s character sheet.

1 Like
13

I meant more for other recipes, like doors / windows / furniture, but there are still lots missing the flavor text so I only suggested it for the long term, when all the recipes have it.

It’s not the same the description on the tooltip than the flavor text (this one only appears in italic when you’re viewing the recipe on the workbench) but it contributes to the lore so I’d like to see them at some point in the wiki, not sure in which section, though.

1 Like
14

If it appears on the workbenches then I would suggest it be placed on the item pages rather than the workbench pages; Like I said in the post above “The idea is to list every item, mob, or information obtainable via playing the game like a true wiki should” so this would include lore or flavor text

1 Like
15

ok… just for fun… i did a little… refresher course on mediawiki. Still using old tech, but I’ve “ported” the current en string table to a template that can be used by other pages. Just for testing, I ported another language (Turkish, because it is the first one I found that I can recognize a download link that seems to be for a18, since I cannot read most of the threads).

What I did:

  • wrote a quickie node js script take takes in a language json, flatten it, then exported it to a wiki template format.
  • create/edit a page corresponding to a locale in the wiki, copy paste the content from earlier into it and save.
  • create a “handler” template that only needs to be done once (no need to do anything when adding another language).

This is the page that shows how to use the template. Note that the template name is long now because I am using a sandbox page. If defined in template namespace, the syntax can be shortened to something like {{i18n|text_id|lang_code}}

http://stonehearth.gamepedia.com/UserProfile:Sphrs/Sandbox/Test1

This is the kind of idea I meant by being laz… ahem… I mean ‘efficient’ by incorporating (semi) automation when possible. Contributers’ attention should not be wasted on copying stuff from game data. It should be annotating/commenting/describing stuff which are not.

EDIT: though this is just for the language data, the same process can be done to any json. The only issue here is references and mixins, which has to be recognized and baked into the data before exports. Otherwise, the output will only have the properties defined by the specific entity json file itself.

16

@sphr Honestly While it would probably be nice to have some automation but I dont know any wiki that actually automates information based on what you’ve shown…Even as big as the Starbound wiki is over at Starbounder it’s all updated by the community manually… It just seems like there could be problems with relying on automation for the wiki

17

The use is specific.

Generally, wiki contribution stuff cannot be “automated”.
What can be is only when we refer to some fixed set of data, e.g. game data files. The “automation” here is also very weak, it is just in the process of preparing that data into a form suitable to put into the wiki, with a method that allows wiki users to use in their own pages, as an alternative to having humans do it manually (e.g. everybody key in “same” stuff in different ways and different formats)

In terms of the wiki itself, there isn’t really much “automation” to talk about. (once the process outputs the content)

And most of the above is just for “fun” and poc. I’ve mentioned in my first post that it may not be feasible.

The positive point, though, is that say, users requiring the text (or any other properties if object data gets exported) for “pine log” can just use the template call in place, and whenever the name/description of pine log changes in the source data, their page display will always reflect the change without requiring manual editing.

I think a more practical approach could be a mix:
each page will contain non-structured content that writers are free to edit in whatever method he/she wants. But where applicable, little info-boxescan be inserted (can be added by another person when he sees the need). These info-boxes will be “synchronized” from a central source, which will “auto-update” whenever the source changes, without requiring attention of the person writing other content on the page.

Of course, it could be done by human too :wink:

18

Personally the information i’ve been finding for tool/class talisman descriptions has been different because they havent updated it in the game files because on at least 3 different tools the hover over text on a character sheet doesnt display the same description like the others; I believe this was because they wanted to give each item it’s own custom description but then later decided to centralize it and keep custom description as flavor text on the workbench description for crafting the item

19

Precisely why I think data from game and information we put into wiki should not be mixed up. But would be best if both are available :slight_smile:

On one hand, it would be good that we show the data that is currently in-game (Because that is what we see). On the other hand, like the reasons you mention, we need information not from game data as well. As a potentially beneficial side effect, it may make it easier for both dev and players to spot inconsistent/outdated stuff in game data.

20

Well as I said in one of my previous posts “The idea is to list every item, mob, or information obtainable via playing the game” this limits it to only information seen ingame not hidden information in the game files

21

don’t misunderstand me. I am not talking about listing everything in game data.
I am talking about attaching game data where applicable to the current contents. I don’t know for sure for other people, but I personally would be interested in reading what is the in-game data in addition to the user contributed content.

an example:
http://dwarffortresswiki.org/index.php/DF2014:Dragon
note that for above, that the data here may not may not be auto-extracted. but it doesn’t matter, even if it is manually prepared, as long as readers (like me) gets the info we are interested in :wink:

Hmm… when I looked at DFwiki, I am reminded of one more possible use of wiki : modder reference. E.g. it WOULD be nice if there is some info that immediately tell a potential modder where and what he/she should be looking at if there is intent to mod that subject.