Talk:Community Portal

From Ring of Brodgar
Jump to: navigation, search

Use this page for discussion of current and future RoB Projects

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)

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)


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 Saddlebag, Wagon, etc..
hopefully someone will add it in eventually.

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


Related to this:
As it currently stands both active RoB admin's (Ricky and me) are not actively playing the game. And for actively patrolling RoB edits (as in flagging edits as patrolled) it kinda makes sense one would play the game, or at least could access the game.
A potential alternative here could be if RoB admin's could give patrolling rights to RoB editors. (some, not all of course)
But it makes sense to first see if there is any interest in this, before suggesting this to Spiff (RoB's Bureaucrat and Owner/Hoster).
One nagging problem here is. Default wiki-users don't see the patrol related MediaWiki features, and as such are probably not really aware of this feature. And problem two, RoB-wiki is not like Wikipedia, and has generally a low active editors count. Still ... I think it could be an attractive RoB feature.
--.MvGulik. 03:29, 27 December 2017 (EST)

For now im already doing that: checking recent changes and fix mistakes if there are, and we also has verify\articlestub tools.
Ofc if someone want to patrol all the changes and check it - it would be wonderfull. But not so important, for my opinion.
--Kitsuneg (talk) 27 December 2017 (EST)

Yeah, given the small volume of edits on this wiki, i'm able to check recent changes daily
and pseudo-patrol any edits. of course like you mentioned, I'm not able to verify 100% if
new information is correct, but I still have pretty good knowledge of the game.

If you think its absolutely necessary, I think making kitsune an admin would be an acceptable course of action.
--Ricky (talk) 16:40, 27 December 2017 (EST)

I don't think its "absolutely necessary', or even just necessary. I just think it could/maybe be potentially beneficial in the long run.
From above linked page:
"This allows people (with permission to do so) to coordinate their patrolling activity, such that edits get checked over once, with less wasted effort (different people checking the same edit)."
IE: It could allow for more (regular) RoB users/editors to also engage in a bit of organized RoB change checking, versus multiple users doing blind/invisible checking of the same edit(s).
Making users admin for access to the patrolling features is kinda overkill.
--.MvGulik. 20:28, 27 December 2017 (EST)

RoB CSS - "code" background-color

Changed the general(common) background-color for <code> sections (#f9f9f9 to #eee). I'm using "MonoBook", but I'm not sure (yet) if this is playing havoc with the other skins.
Feel free to object to the change. (there are more roads that lead to Rome in this case)
--.MvGulik. 13:20, 17 January 2018 (EST)