Ring of Brodgar talk:Community Portal

From Ring of Brodgar
Jump to navigation Jump to search

Community Portal Pages >

This is the general RoB wiki discussion page.

Legacy naming standard

Thinking about a general standard to be used for naming Legacy stuff.

For the default Legacy subject pages this is taken care of by the Legacy name-space.
But for other page types, like images, properties, etc this is not available. (at least not currently)

Using a leading, but fake, name-space looking "Legacy:*" part is probably not such a good idea.

Next best thing seems to be to use a leading "Legacy_*" name part. which seems ok/best (at this moment).
One potential issue with the leading "Legacy_*" part (compared to using a trailing one) is that mediawiki is only case-insensitive for the first character of a page name.
ie: for real ns "Legacy:Loom" == "legacy:loom", but for a fake ns like with "Property:Legacy:Hurt" == "property:legacy:Hurt", but <> "Property:Legacy:hurt" (as "Legacy:Hurt" in this case is the actual page name)

The trailing variant is not free of potential issues either, as you (probably) can't search for stuff that begin with "Legacy". And no nice grouping of Legacy stuff when viewing alphabetical sorted lists of course.

Any comments? Other ideas? or Pro's or Con's I might have missed?
--.MvGulik. 20:32, 25 November 2017 (EST)


I dont see any problem with "File:Legacy_*" or "File:Legacy-*". You've probably noticed that some files here are named "File:Hafen-*". I personally feel having the main wiki files be named "file:*" is better than "File:Hafen-*". There might be some capitalization issues, but that can be worked around easily.

I'm not certain how, but you may be able to make a "Legacy File" or "LegFile" namespace to hold all necessary legacy images and properties. that may be something worth looking into --Ricky (talk) 00:36, 26 November 2017 (EST)


"Legacy_*" versus "Legacy-*":
I did not think about that one. Using "-" instead of "_" might not be a bad idea. I see one potential/conditional pro. Not sure yet about potential con's.

"Hafen-* versus "Legacy-*":
Yea, there is no real need to use "Hafen-* for the current-game/main subjects or other stuff, presuming Legacy stuff being completely separated. For page-icon related images that is currently a bit of a problem though (including potentially maintaining and splitting there wiki history).

New Namespaces:
Only Mediawiki Bureaucrats (ie: Spiff) can create new namespaces. So separate Legacy namespaces for Files, Properties, etc. are currently out. On top of that, I don't know how long the Legacy game will be kept on-line. But at some point I figure it will be taken down. (actually I'm a bit amazed its still around)

--.MvGulik. 06:04, 26 November 2017 (EST)


Going with '-' separator for both "Legacy-*" and "Hafen-*" (img-only). Adds a bit more work, but its good practice. --.MvGulik. 04:06, 27 December 2017 (EST)
--- Update existing "Legacy_*" to "Legacy-*": Done. --.MvGulik. 06:46, 27 December 2017 (EST)

Page related icon image names (Hafen v Legacy)

(Update: The need for "Hafen-" tagging is/was removed --.MvGulik. 01:57, 29 July 2019 (EDT) )
(Update: Support for "Hafen-" image tagging is/was removed. --.MvGulik. 18:32, 17 August 2019 (EDT)

After giving it some more thought I came up with the following for separating Hafen and Legacy images.

1) Until the separation is complete. Using "Hafen-{PageName}.png" as default for hafen page related icon images.
- After the separation is complete, a global replace could be used to change or ditch the image "Hafen-" part.

2) Moving image pages, with Legacy only images, to "Legacy_{PageName}.png" (without leaving a redirect)
- Will look into some image check in the MetaObject template to switch to available image versions ("{pagename},png", "Hafen-*" or if those fails "Legacy_*")
- Some similar thing for the Legacy-MetaObject template.
- Needs some way to direct the user, on main:pages, to the "Hafen-*" image for image updating.

3) Image pages with mixed Legacy and Hafen images. ... Leave as is for now.
- (I need to experiment a bit with history splitting first)
- Other: Will look if its possible to creating a temporary "Legacy_*" image directly from RoB wiki, ie: without download+re-upload.
- PS: Ricky. I think its best if I'm going to be the only one doing this history manipulation on active RoB wiki pages for the time being. When I build up some experience and got a good overview on it, I could write some documentation if needed.

--.MvGulik. 14:48, 27 November 2017 (EST)


Sounds good, boss. Just holler if you need anything. --Ricky (talk) 16:37, 27 November 2017 (EST)

Localized Resources

I think its about time we rebuild the Localized Resources page. Each of the localized resources and their materials should have their own page.

  • each resource should have a picture of what the resource looks like when active/depleted (in full light)
  • each resource needs # of materials each node holds, as well as average respawning time
  • each resource needs its skillcap (i think we already have this)
  • each resource needs its terrrain/location (I believe some are universal, such as heartwood, but ice spires, guano, etc. need this info)
  • each resource should display its experience event

Basically everything the Localized Resources page displays should be on each individual page


Are you thinking "Localized Resource" template ? (as that popped-up in my mind)

Just in case. CSV dump of "localized resource" table data. 

"-- NODE --","-- NODE --",,,"-- Resource --","-- Resource --",,,
"IMAGE1 (File:***.jpg)",Text,Biomes,XP,"IMAGE2 - Icon (File:***.png)",Text,"Quality Cap",Decays?,Use
Abyssal_Chasm,"Abyssal Chasm","[[Mountain]], [[Cave]]",400,Hafen-Foul_Smoke,"[[Foul Smoke]]",Stealth,<?>,"Curio Q10:(LP = 10000, weight = 20, expdrain = 60, studytime = ?)"
Ancient_Windthrow,"Ancient Windthrow",Forest,400,Hafen-Ancient_Root,"[[Ancient Root]]",Survival,Yes,"Heals HHP equal to its quality, evenly spread over all wounds."
Clay_Pit,"Clay Pit",<empty>,400,Pit_Clay,"[[Clay|Pit Clay]]",Masonry,No,"[[Paving#Pavement Styles|Blue brick paving]], possibly porcelain."
Geyser,[[Geyser]],"Mountain (snow), Grassland, Dryflat, Mountain (red), [[Cave]]",400,Hafen-Brimstone,[[Brimstone]],Survival,Yes,"Can be used to make [[Catapult]] and [[Matches]]"
Cave_Organ,"Great Cave Organ",[[Cave]],400,Notes_of_a_Foul_Symphony,"[[Notes of a Foul Symphony]]",Stealth,<?>,"Curio Q10:(LP = 3000, weight = 12, expdrain = 30, studytime = ?)"
Guano_Pile,"Guano Pile",[[Cave]],400,Hafen-Bat_Guano,"[[Bat Guano]]",Farming,<?>,"Can be used to fill [[Treeplanter's Pot]], replacing [[Soil]]. Guano is generally of a higher quality than soil."
Headwaters,Headwaters,[[Mountain]],400,Hafen-Water,"[[Spring Water]]",Survival,No,"Similar to water, can get better results if used for tree planting (needs testing) (+10 sta -18 e, 0.05 L/sip at q20)."
Heart_of_the_Woods,"Heart of the Woods",Forest,400,Hafen-Heartwood_Leaves,"[[Heartwood Leaves]]",Survival,No,"Restores [[Travel Weariness]]. Can be [[Equipment Gilding|gilded]]."
Ice_Spire,"Ice Spire","[[Mountain]] (snow-covered part)",400,Hafen-Ageless_Ice,"[[Ageless Ice]]",<empty>,<?>,"Instantly finish all curios in study."
Jotun_Mussel,"Jotun Mussel",Lake,400,Hafen-Mother_of_Pearl,"[[Mother of Pearl]]",Exploration,<?>,"Curio (LP = 8000, weight = 15, expdrain = 10, studytime = ~75m), ..."
Crystal_Rock,"Rock Crystal","[[Mountain]], [[Cave]]",500,Hafen-Rock_Crystal,"[[Rock Crystal]]",Smithing,No,"Curio (LP = 2500, weight = 4, expdrain = 40, studytime = ?), ingredient in [[Charter Stone]]s and [[Realm]]s. Can be [[Equipment Gilding|gilded]]. Stone axe or pickaxe required to collect"
Salt_basin,"Salt Basin",<empty>,400,Hafen-Salt_Crystal,"[[Salt Crystal]]",Cooking,No,"Decrease hunger level by 20% at q10."

--.MvGulik. 14:14, 19 December 2017 (EST)


Sounds great, make an example with any resource - even with missing information, and i will try to finish others.

Also current table should be exist, updated to category ofc and hold all this information in one place.

--Kitsuneg (talk) 15:12, 19 December 2017 (EST)


Okay, I filled in Abyssal Chasm with all the information i think is important for each page. if there's anything i'm missing, just add it.

Wasn't sure about making a new template for ~15 objects, so I just make a "template" to be manually filled in.
I didnt want to bother making a new template interact with the infobox, so I think this will suffice.
Kitsune, if you want to change the wording or anything about the template I made, feel free to do so.
Its better to do any fixes now to the first page before you copy it to the rest of the pages. I've been there and done that, it sucks ass

if you have any questions, just holler --Ricky (talk) 17:15, 22 December 2017 (EST)

Category:Containers

Added properties Xinv, Yinv, and Vinv to define storage containers. works exactly like Xsize and Ysize.
using Xinv will automatically add that page to Category:Containers, so we dont have to do that manually any more.
should look like this in the infobox: 

|xinv = 5
|yinv = 5

I updated all the pages currently in the Containers category, but i think there's a bunch more stuff that's been missed, like the Saddlebags, Wagon, etc..
hopefully someone will add it in eventually.

--Ricky (talk) 16:45, 22 December 2017 (EST)

"Specific" property

Implemented the "Specific" property as "Infobox metaobj‎‎" template parameter.
Updated "Salad Greens‎‎" and "Any Mushroom" related pages. (as test and example cases)
All seems to work ok. If you see anything odd in relation to this update, report it at the Specific property talk page.
--.MvGulik. 16:46, 13 March 2018 (EDT)


Looking at the Cloth page, and seeing the kinda large 'Required By' objects list, there is one thought that keeps nagging me: "Can all those items be made with 'any' of the specified Cloth-types". The key word here is 'any'. If for example some of those 'Required By' objects can only be made by 3 or 4 of those 6 Cloth-types ... I'm not sure if they should be in that list. (probably a potential can of worms, but still something I kinda wonder about)
Currently is just a nagging though, on which 'I' have not done any further pondered or investigating (which will have to wait in my case, until I'm done with the Legacy related stuff that's on my todo-list).
--.MvGulik. 13:46, 14 May 2018 (EDT)


They can be made with any cloth, i did not check all that list, but mostly items where should be specific cloth - required it right.
Also goal for you future todo-list - we need "Specific" property - that can list 2 or more types, mohair yarn\cloth for exaple works as wool equivalent in recipes.
--.KitsuneG. 14 May 2018 (EDT)


Those req pages can get bulky, but there are few, if any, exceptions like what you're mentioning. Generally all of an item category (any cloth) or one specific type are used in a recipe. The closest example i can think of any mushroom vs edible mushroom. but even in these circumstances the devs prefer to make a new item category instead of specifying X, Y, or ,Z crafting item
--Ricky (talk) 15:04, 14 May 2018 (EDT)


Roger. --.MvGulik. 01:33, 16 May 2018 (EDT)
>we need "Specific" property - that can list 2 or more types
Added. Give it a try I would say. (ditched the category part for the moment). --.MvGulik. 23:12, 18 May 2018 (EDT)
What format/syntax should we be using? In the case of Red Deer Antlers, they should be both finebone and bone material. I tried a few formats, but none of them seem to be working for me.
--Ricky (talk) 00:17, 19 May 2018 (EDT)
Try infobox parameter. ie: "| specific = finebone, bone material, etc". --.MvGulik. 05:05, 19 May 2018 (EDT)


PS: It might not be a bad thing to look at potential naming-styles for those general(specifics) pages. --.MvGulik. 07:16, 19 May 2018 (EDT)

File/Image naming

Changed the names of some files for the sake of image-naming clarity. For Barrels and Cheese Trays the scheme should be self explanatory. The (on wall) scheme should probably not trigger any problems either, ... the (wearing) scheme however (one case, as it needed to be moved out of the way) seems a bit troublesome. As characters are wearing more than one item at a time (ie: images are/can be used by different pages), and wearing a cigar or wearing a wielding sword sound not right to me. So on that part, character specific screenshot naming, some additional thinking is probably not a bad idea. --.MvGulik. 07:34, 22 April 2018 (EDT)


Moved/renamed the majority of '(single)object on wall' type images to "<related object-page-name> - (on wall).<ext>" (including updating the pages that used these images of course). --.MvGulik. 05:10, 28 April 2018 (EDT)
Changed/renamed any and all image/file extension's with caps to full lower-case extension. --.MvGulik. 13:15, 2 May 2018 (EDT)

Automated Game-Update processing

Recently I switch to an other code editor, which allows (ie: makes it easier) for more structured programming than the old one I was using.
To get accustomed to this new editor I focused on extending the automated RoB-page updating related to new game patch+hat updates.
If all works as intended (hidden bugs notwithstanding) the following things get done after a new patch is spotted. (manually initiated btw)

  • Uploading of new hat resource/icon image(s). (if not already exist)
  • Creation of initial new hat page(s) (if not already exist). (using the New store hat page template for this)
  • Updating the Store hat list with new (patch) hat(s), including updating dropped hat(s).
  • Updating the Game Updates page with a new patch/update row.

I hope the RoB users that usually took care of some of those parts don't feel bypassed by this automation.
--.MvGulik. 20:24, 12 June 2018 (EDT)


Just in case. For when additional H&H data (outside RoB-wiki or H&H-forum) is required, or in this case Store-page historical data. One can try:
1) Store-page at Wayback-Machine (best archive source in this case)
2) www.havenandhearth.com at Wayback-Machine (significant less history available. But just in case)
--.MvGulik. 13:27, 11 October 2018 (EDT)

Troubleshooting and Instructions

  • Symptom: Changes in one section of the wiki not showing up in another section of the wiki.
  1. Hit Refresh at the top of each wiki page affected
  2. Edit/Save each wiki page affected. (You dont need to actually edit anything, just open/save the page
  3. Perform a Super Refresh of your browser by pressing: Windows:CTRL+F5, Mac/Apple:Apple+R, Linux:F5.

First: Well as my mate notice - if we follow that instructions, the page will dissapear from every related pages. Isn't just a Refresh button enough?

Second: We should somehow aware new editors about that, that information hard to find, i myself was needed Ricky instructions personally before i get it. Well we can mannualy write each new active editor about that, but its super annoying..

  • one suggestion - to put a reminder note here, but.. who actually would read this =(

Third: Maybe Ricky? should start new Wiki official thread on forum? with updating info on first page, instructions , etc..

--Kitsuneg (talk) 21 June 2018 (EDT)


>"Isn't just a Refresh button enough?"
In some cases it might (not tested yet). The [refresh] button will issue a page-purge, ie: telling MediaWiki to ditch, and rebuild, the cached version of that page.
But in other case, related to page/data-linking, a null-edit is required (for direct debugging).
Without a null-edit, the related change on other pages will normally happen on its own, but mediawiki decides when that is (could be seconds to hours depending on the case)
(if a page turns up with missing data after a Null-edit, hitting the Refresh button after a few seconds should show that MW is rebuilding the related link/data-table.)
--.MvGulik. 20:59, 1 July 2018 (EDT)

"requires" property usage outside infobox

Never spotted this before, but it seems [[requires::...]] has been used outside the confines of the infobox on RoB for some time now.
Can someone explain the benefits or target reason for doing so ? (personally I think this is a bad idea)
--.MvGulik. 14:53, 1 July 2018 (EDT)


I've personally never done it, and to be honest I didn't realize it was possible. I also don't see any reason to place it outside the infobox.
--Ricky (talk) 15:12, 1 July 2018 (EDT)


There mainly/(only?) used on softcap related data in the quality sections. But after checking how that particular data is processed by RoB, there is not even a potential benefit possible in my view.
- Properties are just like category assignments, they can be put anywhere. But to keep things organized for easier page-updating/problem-solving, limiting there used locations is a (very) good practice.
Leaving this open for a day, while looking into the clean-up job.
--.MvGulik. 15:59, 1 July 2018 (EDT)


Just checking and making sure this is the case, and there are no known exceptions ... or objections.
It stands to reason that if a particular object is softcaped by a given ability ... that that ability is a required skill (ie: "skillreq").
I got at least 34 cases where a softcaping ability is not used in the skillreq part ... so better to check-up on this before adding those to skillreq I think.
--.MvGulik. 16:55, 2 July 2018 (EDT)


Done, well the last part that is (removal of "requires" parts). Skipped the first part as something is still bugging me on that.

Data dump of effected pages+parts. For later perhaps, and/or for someone else.

Chef's Pin 	 	- Softcap: Carpentry
Twig of Spruce		- Softcap: Carpentry

Liver & Onions		- Softcap: Cooking

Glass Beads		- Softcap: Masonry
Polished Porphyry Beads	- Softcap: Masonry

Bear Fur Trimmings 	- Softcap: Sewing
Boarhide Lining	 	- Softcap: Sewing
Extra Stitches		- Softcap: Sewing
Feather Stuffing	- Softcap: Sewing
Felt Hat		- Softcap: Sewing
Felt Inlay		- Softcap: Sewing
Fisherman's Hat		- Softcap: Sewing
Greased Joints		- Softcap: Sewing
Hemp Fibre Finery	- Softcap: Sewing
Hide Layer		- Softcap: Sewing
Leather Patch		- Softcap: Sewing
Mohair Monogram		- Softcap: Sewing
Moose Antler Buttons	- Softcap: Sewing
Patterned Embroidery	- Softcap: Sewing
Quilted Wadding		- Softcap: Sewing
Reinforced Hem		- Softcap: Sewing
Rough Guard Patch	- Softcap: Sewing
Silken Ribbon		- Softcap: Sewing
Silkspun Seam		- Softcap: Sewing
Snakeskin Stripes	- Softcap: Sewing
Spun Gluethread		- Softcap: Sewing
Wool Cloth Collar	- Softcap: Sewing
Wool Stuffing		- Softcap: Sewing

Cornbraid		- Softcap: Farming and Sewing
Fine Feather Brooch	- Softcap: Lore and Sewing

Bark Reinforcement 	- Softcap: Survival
Bear Tooth	 	- Softcap: Survival
Forager's Brooch	- Softcap: Survival
Lynx Claws		- Softcap: Survival
Taproot Lacing		- Softcap: Survival

Heartwood Leaves	- Hardcap: Survival

Bone Pins	 	- Softcap: Stealth

Scent Gland		- quality depends on Survival and sharp tool
Wax-Impregnated Lining	- Softcap: Exploration

Foul Smoke		- Hardcap: [[requires::???]]

Dead Chicken		- Softcap: highest Farming or Survival.

-- Untouched (for now):
Fruitroast		- .?.
Rock Crystal		- .?.

--.MvGulik. 20:40, 3 July 2018 (EDT)

RoB wiki update

RoB wiki was update to MW 1.31.0. (among others. see Special:Version for current setup)
SMW support for the Legacy-namespace was also enabled. This last part might result in some Legacy data bleeding into the main/hafen wiki part. If you spot something like that, please report it here.

And that pesty "Legacy:Honey Bun" case is gone.

--.MvGulik. 23:32, 14 July 2018 (EDT)


"And that pesty "Legacy:Honey Bun" case is gone."

That's great news.

- looks as if the curiosity Table has a lot of non curiosity items now, however (fixed)

- looks like the gild% properties have been broken due to having a % symbol in a number property (see Hard Metal Rivets and Straw Hat as examples) (fixed)

- looks like all formulas have been broken. Looks to be related to the <math> function (fixed)

--Ricky (talk) 23:58, 14 July 2018 (EDT)


Roger ...
> "curiosity Table"
Seems fixed after applying a Null-Edit to the page. Rows without data are now gone.
> "gild%"
Seems SMW is not supporting the "%" character in property names any more. Skipping digging into the details, and going for globally changing the "%" character with "pct" to resolve this without delay. (effected: gild% and egild%)
> "formulas"
I'm not seeing the problem. Need more data. 1) Example page, 2) What you expected to see, and 3) What is displayed (your interpretation/view).
--.MvGulik. 09:26, 15 July 2018 (EDT)


Re:formulas.

Looks as if it resolved itself. I'm no longer experiencing the issues i saw last night.

- seeds such as Willow Catkin which had previously used the 'seed of::' property have broken.

--Ricky (talk) 14:02, 15 July 2018 (EDT)


Actually its not really the "seed of" property that is broken, but the double property assignment that is failing.
So stuff like this, [[requires::seed of::Willow Tree]] is not working anymore. (41 pages)
Mmm ... I can split those double assignments up into two separate assignments, like [[requires::Willow Tree]] [[seed of::Willow Tree| ]]. But that "seed of" case seems not right/correct for the "producedby" setting. (... implementing it anyway, to at least get rid of the error cases)
Will have to think about what to do with those additional "seed of" assignments. (low priority at this moment at my end)
Suggestion in the mean time are welcome.
--.MvGulik. 15:47, 15 July 2018 (EDT)


Re: seed property

Honestly, I've never seen this property as a great boon. 'requires::' accomplishes the same task, so it seems a little redundant to me.

Searchbar

The searchbar no longer displays items until after the search function is executed. Not sure what that's about (I'm on mobile aswell). In the same vein. Would we be able to disable case sensitivity for the search bar with the new version of SMW? Previously searching "Red apple" would not automatically take you to "Red Apple" (which is why we had a lot of case sensitive redirects)


Re: Search-bar.
The "Go to" part in the search pop-up is still there, but it seems its only activated for SMW related pages(changed). (type in "s" to see it in action)
Search seem case insensitive to me. Type in "red apple" and pressing the Go button (after getting rid of the overlaying search pop-up) will put you on the "Red_Apple" page. (Just in case. Don't forget that external links (ie: H&H forum, etc) that point to a case-related redirect will break if that redirect is removed. Just a thought)
--.MvGulik. 15:51, 16 July 2018 (EDT)
Search bar popups seem to work fine for web browsers, but seems to not be working for mobile devices.
I feel the search bar's case insensitivity for finding searched items is new. I may be wrong, but i vaguely remember the search bar trying to find case sensitive pages, and then displaying "there is no x. are you looking for X?". regardless, glad thats not a problem.
The search bar's pop-up is still case sensitive however. would there be a way to fix that? I would prefer if searching "red apple" in the searchbar would display "Red Apple" in the popup. I know the first letter of the first word is case insensitive, but further words need to be typed correctly to find the item.
No mobile-internet usage on this end. Not looking into mobile issues unless its some real RoB-wiki showstopper.
For mediawiki case insensitive search autocompletion ... its possible => [1]
--.MvGulik. 19:52, 16 July 2018 (EDT)

Lags and formulas broke

Seems after the last update, or the last crash in july - wiki start to work slower, sometimes pages need to download for 5 min. Happen to me - but a lot of people start complain in discord too. And yesterday this start to happen https://prnt.sc/ksm2pw
--Kitsuneg (talk) 10 September 2018 (EDT)

Yea, RoB is lagging a lot more recently. One thing that might be related to it is that the hosting provider seems to be in some kind of general big updating process (namecheap.com/status-updates). The math parsing error was a new one, which I also encountered. But its easily fixed, if it persists on a given page, by applying a null-edit to the effected page. --.MvGulik. 02:38, 11 September 2018 (EDT)

Implemented RoB color template usage.

All combat related {{Font_color|...}} cases where switched to using {{RoB_color|...}}.
Colour adjustments to a particulate colour-scheme can/should now be done in the RoB_color template, which changes the used colour wiki wide for the stuff that uses that colour-scheme.
(it took a bit more work/edits on some pages than expected/needed, bloating the history a bit ... bad preparation on my end)
--.MvGulik. 04:10, 14 September 2018 (EDT)

RequiredBy2 Template

The new RequiredBy2 template takes care of listing the 'Required By' items for the given page/object, and the 'Required By' items for the specified specific types on the given page/object.
Although it seems to work flawless (so far of course), its currently implemented in a preview/debug state.
To take a sneak preview (metaobj infobox pages only) add the parameter/line "|rb2_preview=foo" to the infobox-metaobj call.
... Remember: Preview!, ie: Don't save!

  • Will implement it for real in about 24 hours if nothing major pops-up.
  • Known issue: Will not show changed/edited property stuff in Preview mode.

--.MvGulik. 14:31, 19 September 2018 (EDT)

Fully implemented/activated RequiredBy2. --.MvGulik. 03:25, 21 September 2018 (EDT)

"My feelings abut this" Great work! Finally fixed this issue! So many work to do now ^_^

P.S.[2] i guess this was not planned, happens on every item that has no recipes. --Kitsuneg (talk) 21 September 2018

:)
"Required By" section is currently unconditional (ie: will show up on all metaobj pages). Will be changed back to conditionally in a few days.
--.MvGulik. 10:10, 21 September 2018 (EDT)
"Required By" now conditional again. (v2 btw ... seems I'm still having issues with SMW queries :-/ ) --.MvGulik. 13:08, 25 September 2018 (EDT)

Variable Food

A long time ago i speak with Ricky about googlesheet with variable foods and how to implement that on wiki(instead of using wikitables that need to be updated manually and pretty annoying) - that sheet was pretty bad, we have no idea how to do that and so we decide not to do anything about that.

After that Not a cat create this https://certainly-not-a-cat.github.io/cookbook/ and i helped him to fill it with info - still not completed(spices add a lot of work) but as you see it's has 8055 variations for now.

So MvGulik maybe you have an idea how to show this on related pages? and delete current wikitables instead?

--Kitsuneg (talk) 10 November 2018


Wow. Nice data collection, put in a nice display and search jacked to boot. :)
I'm currently not sure if and how such data could be used in a manageable way on RoB (display wise and storage/property wise).
Display:
The total count of 8000+ on its own might not be a problem, when it would roughly distribute equally among the foods.
But seeing that "Autumn Steak" alone racks up a count of 2601 permutations, that would be a really big ask-table if put on the "Autumn Steak" page itself.
Storage: (no idea's yet)
On a other thought:
With such a large data collection, it might be possible to isolate the particular rules/values per ingredient (if applicable, which I don't know). Which would be a lot less data to manage than all possible permutations.
--.MvGulik. 10:23, 10 November 2018 (EST)

Oh, just realized, can you add it on main page External Resources? Or Guides? i have no rights.

--Kitsuneg (talk) 14 November 2018


Good Idea. I added links to the cookbook in a few places where it'll probably be found most often.

--Ricky (talk) 23:33, 14 November 2018 (EST)

Big tables separation

I think it would be better to separate big/global tables into the own separate pages, placed under a general "Tables" or "Big Tables" folder.
Ergo: Crafted Curiosities table would than reside in "(wiki/)Big Tables/Crafted Curiosities" (or "../Curiosities Crafted").
The "Big Tables" pages itself could serve as an index page with additional information on the contained table pages under it.
One reason for not having more than one big table on a given page is that it seems to serve no real use. If, for example, you like to view or compare two big tables it make more sense to just open the separate table pages in separate browser-tabs, instead of opening the same page multiple times.
(not sure how this works on mobile ... but scrolling up and down again and again to view/compare data in different big tables in the same page seems, even on a mobile, the least optimal way.)
--.MvGulik. 18:31, 1 July 2019 (EDT)

Wip ...
  • Using "Tables" as initial base name for the moment. (simple/bare parts naming)
  • ... Currently having a bit of a brain/idea/solution lock on how to merge/(string together) the different parts in a general good way ... .
--.MvGulik. 07:15, 5 July 2019 (EDT)

Searching and main-space redirects

It seems searching on RoB has become case-insensitive. That kinda opens up the question whether to keep main-space redirects, which where mainly created as response to the prior case-sensitive MW search behaviour. They could still have some case-sensitive external hot-linking purpose and potential limit the need to be case-specific for internal links (although only for existing redirects, as its not something that was structural implemented across RoB). A down side to this would be that the search page will list those redirects too.
Although I'm currently kinda indifferent to those redirects. I do generally lean towards ditching them as its not something that is structural implemented across RoB (which should then also be maintained), and not having them feels just plain cleaner to me.
I'm currently not having any plans on doing anything with/to them. But eventually I might (based on additional input on the subject, or the lack of it).
--.MvGulik. 09:01, 8 December 2020 (UTC)

Page for Securing Your Home

I would like a page to summarize the current siege mechanics. Let me know if this already exists, I couldn't find it. Important things to have on the page:

  • how do the siege weapons interact with each other / with hearthlings / with normal buildings / with claim objects?
  • how do the different types of claims interact with each other?
  • common security mistakes to watch out for
  • locks / keys / gate / visitor gates rules
  • drying times of all relevant siege weaponry
  • vulnerability windows for claim objects and siege weapons

A lot of this info already exists on separate pages, I just think there should be a summary page linking to all the relevant security pages. Phaen (talk) 19:28, 24 December 2020 (UTC)

There is no summarize page for current siege mechanics. Feel free to start one. --.MvGulik. 02:50, 25 December 2020 (UTC)

Variable_Item_FEPs

Using a separate discussion page for this. => Variable_Item_FEPs
--.MvGulik. 17:52, 22 January 2021 (UTC)

Object/Hitbox size support

Currently RoB is using xsize & ysize as general size info, used for both objects(hitbox) and items(inventory). (inherited from Legacy)
Things have significantly change over time in relation to object sizes (stuff with hitbox/bounding-box).
What would be a useful alternative for objects hitbox data ? (if any)
I figure hitbox size data can be potentially pulled from the res files. (which I have not explored in depth yet)
These would be floats values. (Although precise, floats are generally also low user-friendly data, although one can adjust there output)
Although the game now support none rectangular hitboxes, RoB would be limited to using just two values (rectangular approximation).
Hm. A rectangular approximation on none rectangular figures gives potentially 3 options. Figure the default-max(none rotated outer boundaries) makes the most sense here.
(HnH currently supports a minimal rotation of 11.25(90÷8) degree's (for most objects)). --.MvGulik. 09:52, 2 February 2021 (UTC)

Added Empty Blank Lines

(For potentially adding additional related data/info/ideas)
(Related to Visual_Editor_Note @ Community_Portal)


First case spotted at 26 September 2022. ref
Which is within a day after the Mediawiki TemplateData extension was enabled & disabled).
... Guess it left some sand grains behind in the machine. --.MvGulik. 10:06, 7 October 2022 (UTC)

Update: Might be fixed when RoB is updated to an upcoming newer LTS-MW version. Probably somewhere next month. --.MvGulik. 08:17, 10 October 2022 (UTC)
Retrieved from "https://ringofbrodgar.com/index.php?title=Ring_of_Brodgar_talk:Community_Portal&oldid=113980"