About butchering and softcap
Creatures-Category v Creatures-Page-Table
I compared the entries in the creatures-category against the creatures in the creatures-page table and equalized both.
Only leftover item is the Ruby Dragonfly, for which I'm currently not sure how to handle it.
Technically the Ruby Dragonfly don't really exists (at least not as specific active creature) until its caught. (ie: inventory only item (assuming wall decoration also has only one variation?))
One could also say the same about the Emerald Dragonfly.
Which would make the thing that does the actual flying around part just a (none specific specified) Dragonfly.
Probably easier thought of than properly implemented. (pondering about it some more)
--.MvGulik. 08:34, 22 December 2018 (EST)
- Well yeah it's good decision to rename entry into Dragonfly(with link on Emerald?) and as it is now, and leave a note about loot as Emerald and Ruby.
- Also i think Rabbits and Chickens(Mallards and Wood Grouse too), would be better to compare into one entry like other domestic animals?
- P.S. I actually think that their own pages pages should be compared too. Someday.
- --.Kitsuneg . 22 December 2018 (EST)
I took my time to think about this.
The overall idea here is not just specific to how to display certain object in the creature table. But it includes organisational structural changes to enable those changes.
In case of the dragonfly, which is somewhat of a special case on its own, it would mean that there would be a separate "Dragonfly" (or "Any Dragonfly") page.
This main dragonfly page would than take care of the creature part of the dragonfly, and the Ruby- and Emerald-Dragonfly pages would take care of the curiosity parts of each variation.
This way the dragonfly could be used in a (fully or partially) automated creature table. But it would also behave properly in the other data-parts.
(not sure yet about using the "specific" or "required" property in this case ... probably "specific")
Using merged Rabbits, Chickens, or using other grouped entries in the creature table ... I don't know if that's a good idea.
If its, in the long run, relies on manual editing of the creature table, I'm not for it, as it maintains multiple input entries for the same data (which is something I try to limit/remove).
If it can be accomplished with structuralist changes ... maybe. Although, and I was a bit surprised that the domesticated animal groups do not have separate pages for the specific animals in those groups. Doing the same, ie: only a single group page, for Rabbits and Chickens seems counter productive to me.
Note that that don't excludes having a separate Rabbits,..,etc page(s) that deals with the general parts/info of that group (these group pages could, for the time being, replace there related animals in the creature table). But it still includes having separate data pages to contain the specifics for the separate animal-types in that group.
(not having any idea yet on how to setup (date-structural-wise) those domesticated groups while also having there separate animal/creature pages in play)
Note: "Page" could also be seen/read as separate-SMW-set-data-section. With SMW features as #subobject, there is no absolute need to have a specific pages(with object-name) to set particular object data. (as long as the page-v-data separation makes sense)
--.MvGulik. 04:46, 23 December 2018 (EST)
- As a side note about domestic animal pages, when i started working on the wiki the domesticated animal pages (cattle, sheep, and pigs) were each their own page and i had originally intended to create a separate creature page for each version of the domesticated animals (male, female, child). I enjoyed having generic cattle, sheep, pig information be centrally located, but i didn't like having all three animal variations on that page too.
- As far as maintaining both this creature table and creature pages, I originally created the table to help me quickly identify which creatures I had already updated/created creature pages for. (Whenever i would update a creature page i could add that data to the table and mentally mark it compete). In a perfect world this table could just be automatically generated from creature infoboxes, but currently there's more information in the table than you can find on creature pages. For instance, aggro conditions and behavior columns are only found on the table.
Domesticated v Wild
Just a quick data peek.
|Group||Items||Separate Wild version|
|Cattle||(Calf, Cow, Bull)||Yes - Aurochs|
|Pig||(Piglet, Sow, Hog)||Yes - Boar|
|Sheep||(Lamb, Ewe, Ram)||Yes - Mouflon|
|Goat||(Lamb, Nanny, Billy)||Yes - Wildgoat|
|Horse||(Foal, Mare, Stallion)||Yes - Wild Horse|
|(Rabbits)||(Bunny Rabbit, Rabbit Doe, Rabbit Buck)||No - Uses domesticated version|
|(Chickens)||(Chick, Hen, Cock)||No - Uses domesticated version|
There is definitely some structure to it. --.MvGulik. 05:33, 23 December 2018 (EST)
While we're discussing the topic of creatures, now is a good time to discuss animal skeletons.
Jorb has only recently begun adding animal skeletons back into the game, and currently they serve no new function other than a third stage of animal butchering. The quantity of bone harvested from an animal hasn't changed, but the method of harvesting them has.
Do we want to add individual pages for each skeleton? That will basically double the number of animal pages we have, less some of the smaller critters which don't leave skeletons behind.
I'm personally not super into creating skeleton pages. As long as the resources you can gather are listed on the creature's page, I think it's superfluous to have a page for each skeleton.
I don't think this is necessary..
But this gave me an idea, i think i will gather screens for dead animals - killed, skinned, skeleton. Maybe skeletons would fit on bone material page aswell. And ofc a lot of pages should be updated with new info - most fine bones in How to Acquire part says they dropped on the ground - that not true.
One benefit with having separate object pages/data-containment it that it allows for generated tables.
One other benefit is that it allows for consistent data wherever that data is used/displayed.
Not using/maintaining some sort of system that maintains data(displayed) integrity either means:
- that it leads to different versions of the same(subject) data at different location (making RoB's data ambiguous),
- or data should be limited to only the page where its collected and nowhere else (presuming nobody likes to maintain/edit multiple pages to maintain RoB's data integrity).
I think one should look here a bit more at what would be good for RoB as wiki in the long run (data, users/editors, and game wise).
Personally I see no reason for not having individual skeletons pages/data/props. As it don't excludes also having that data on the animal page (by way of query or perhaps even inclusion).
--.MvGulik. 08:39, 24 December 2018 (EST)