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)

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.

--.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)

"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.

--.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)

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)

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)

Retrieved from "https://ringofbrodgar.com/index.php?title=Ring_of_Brodgar_talk:Community_Portal&oldid=118256"