Interesting and useful pages:
Need a template? check out this page.
Hey, re: Symbel being deleted, can we get the table that used to be there re-added to the top of Category:The_Symbel perhaps? I used that all the time and it being gone is pretty annoying. Ideally this would be automatic, but we do already do it in some other places (see Category:Baked_Goods and others). Way more handy than opening up dozens of tabs.
Those tree pages not redundant.- As jummy told they are used for redirect pages. But i think, every ingame item must have their own page. All links to tables must be added to item page, same for tables. --Rootconsoler (talk) 12:23, 1 March 2017 (EST)
Why do we have separate pages for different trees, when all the information is neatly organized on Tree? It seems redundant, and I think we should just do away with independent tree pages.
Yeah, I understand that it feels redundant, but I wanted each tree to have its separate page in order to be able to link specific trees in articles. before I gave each tree its own page, most trees were dead links. While it would be reasonable to have each tree redirect to the tree page, I wanted users to be able to type a tree name into the search bar and actually pull up that tree, instead of a list of ~45 trees. On top of that, certain special trees already had their own page, such as the mulberry tree and apple tree so I felt it would be reasonable to give each trees its own page and its own metabox to add info to it. I should have at least filled in the metabox info for each tree, but that is quite a bit of work. Ideally, each tree page would have a description of block and board textures as well, without having to visit the Block of Wood and Board page
I did however change the metabox to link to the tree page in the first sentence of each tree page, so that should at least help users find useful info on the (unfortunately) empty pages
I think those special trees only had pages during legacy. There's no special information conveyed on the Apple or Mulberry tree pages that isn't already sufficiently described in Tree, Apple Pie, or Silk Cloth.
By That logic, we should also remove every food item and curiosity and simply use the tables.
Within the next week, I'll go through and actually add information to the individual tree pages, and create a table similar to the FEP/curio tables that can pull info from each tree page which will appear on the infobox table on the main Tree page.
Hello! For attacks and restorations on Combat moves what order should the columns go in? Restoration I was thinking Name-Cost-Reduces-opens-cooldown-notes-wieght-learned from For Attacks I was thinking Name-Cost-opens-attack type-damage-grievous damage-weight-cooldown-notes learned from. Is this ok?--Pinkie-Pie (talk) 16:50, 16 August 2017 (EDT)
Hey Pinkie-Pie, Thanks for going through and revamping the combat moves! I would do it myself, but I dont know anything about haven combat. I agree the tables should be rearranged into a more coherent order, and if you're up for that challenge, that sounds great. It'll be a bit of work, but I think you can manage. I went ahead and arranged some "sample" templates in what I think is probably the best way you can arrange the info. I added some formatting to help the tables look clean as well. I felt having all the info that overlaps (cooldown, IP, weight, openings) next to each other would add some coherency Along with rearranging these pages, a glossary of sorts needs to be added defining terms like initiative(IP), cooldowns, attack weight, and the Mu/μ symbol. Cheers and good luck with your project. if you need any pictures of specific moves added I might be able to get a hold of them. Either leave a list of moves here or leave an unuploaded file on the combat page such as [[File:MoveYouNeed.png]] And i'll upload them
Related to pages:
Why not just Move(rename) a image page if its not using the right page-name ?
Deleting and re-uploading it is 1) more work, and 2), from a history point of view, your kinda erasing the work history a other user (which, if done in general, could/might effect the motivation of some users to contribute to RoB wiki).
--.MvGulik. 13:51, 30 November 2017 (EST)
Yeah, I should have just moved it, didn't really think about it. I was on a mobile browser at the time, which is pretty difficult to navigate. In the future I'll keep that in mind. --Ricky (talk) 17:38, 30 November 2017 (EST)
Aha, Mobile. Roger that one. --.MvGulik. 23:12, 30 November 2017 (EST)
Why did you change the Abyssal_Chasm image file from jpg to png ?
In-game images are general intended to be jpg's because those are generally smaller in size versus png files, while png is generally for the icon files (quality over size). Just converting a jpg to a png will only generate a bigger file with the same image quality. --.MvGulik. 03:32, 23 December 2017 (EST)
When I made the Abyssal Chasm page it asked for hafen-Abyssal Chasm.png, so instead of just slapping an |image= field in the infobox I just reuploaded the file as a .png. It's mostly a matter of preference on my part, I just dont like jpgs that much and find it more fitting to (re)upload images according to what the infobox wants rather than forcing a |image= field into the infobox.
--Ricky (talk) 05:59, 23 December 2017 (EST)
But that is what the |image field is for!
Also I don't think its a good idea to have all Localized Resource related (or other) in-game images being converted from JPG to PNG. Besides its kinda breaking the general rule to use JPG and not PNG for in-game, or larger than general icon sized, images. ... Please undo/reconsider this particular change.
PS: Some additional things to take in consideration when it comes to image file sizes.
- In the past image size might still have mattered for the speed a page was fully loaded/displayed at the users side, now a days (with general fast internet all around) that seems kinda questionable. But the same can't be said for bandwidth use. User on mobiles can have certain total bandwidth restrictions, although I'm not sure that is a real issue as I have no personal experiences in that area. However the total bandwidth the RoB site generates itself can be of some concern here. The bigger the image file sizes are, the more bandwidth it consumes. For one image that might not matter, but if extended to all images that will add up. Now I don't know what kind of account Spiff uses to host RoB with, but trying to not use unnecessary large image-sizes seems to be the smart and considerate path here.
PS2: Redirects on file-pages can also be used (as long as they don't contain an image them-self or other text. I think)
--.MvGulik. 11:11, 23 December 2017 (EST)
- I decided to make the changes I suggested for the Abyssal_Chasm image (due to the, to me, apparent stalling of the discussion). --.MvGulik. 16:03, 17 January 2018 (EST)
Apologies for my evasive behavior. I'll admit that was shitty, but I just didn't want to bother with it.
Roger. --.MvGulik. 03:07, 18 January 2018 (EST)
Ricky. Can you PM me, at H&H forum, Spiff's email (or contact him for me). Using the separate bot account (mvg_bot) I have with normal rights will not really work, its just to limited in rights. I could use my regular/admin account, but I really don't like to do that. --.MvGulik. 20:26, 4 December 2017 (EST)
Seems like you have PMs disabled on the HH forums. I have his email, but I hesitate to post it here for various reason. if you could re-enable your pm priveleges on the forums i'll PM the name to you.
Oops, I did not check that. Forum PM enabled again. Also send you my personal e-mail. Just in case. --.MvGulik. 09:43, 5 December 2017 (EST)
Thanks Ricky. E-mailed Spiff. --.MvGulik. 23:59, 5 December 2017 (EST)
Hey, with that new dungeon stuff, I guess we should start new category.. And what u think, maybe loot should be another category too? Not sure how name this, just loot not correct - because technically butchering animals is loot too.
Yeah, We'll have to make some new categories for dungeons and such. I'm not sure how I want to approach it yet, however. i'm waiting until more info crops up about the dungeons first before I make anything in depth. a few more dungeons to help set standards on what to expect wouldn't hurt either.
Just from what i've seen so far I was thinking about having a dungeon category, an 'all dungeon' category for items you can get for any dungeon, and then any other items should go under a 'dungeon x' category
"Ring of Brodgar" namespace
- > Trying to mov away from the RoB namespace
- Why ... What's your reasoning for moving all the pages in the "Ring of Brodgar" namespace to the Main namespace ?
- --.MvGulik. 22:02, 8 April 2018 (EDT)
I believe there's too few articles to justify having a namespace for them, and i don't think they're easily accessible (i.e. users wouldn't know to type 'Ring of Brodgar:') to whichever users might wish to see those articles
- That particular namespace is one of the default namespaces that comes with a MediaWiki installation. As such (technically) its not a deletable namespace. That leaves 'to use or not to use'.
- From https://en.wikipedia.org/wiki/Wikipedia:Namespace:
- >"Namespaces allow for the organization and separation of content pages from administration pages"
- >"Namespaces separate data into core sets, those intended for public viewing, and those intended for the editing community.
- Which is why Namespace 4(Ring of Brodgar) is there. In this case for potentially separating none haven game related stuff (ie: wiki/RoB admin/doc, editing community, etc) from game related content/data.
- As such the number of articles in such a namespace plays a not so significant role in my view.
- >"not easily accessible"
- Based on the above, we got two wiki-user types in play now. Those Namespace 4(Ring of Brodgar) pages are not really intended for the general RoB/wiki readers, just the editors (for which I think one may assuming a bit more wiki skills/knowledge). Besides, if the/those pages on a wiki-site are properly organized (good page-linking implied). "not easily accessible" would be a none issue too.
- General personal view: ... Its might seem easier to merged all kinds of stuff in 'one fits all' box (wiki-pages, program-code, or clothes). It also tends to results in an unorganized mess over time, and if one needs/likes to separate and reorganise it again its usually more than double the work. (ie: easy sort turn gain, while passing one the potential workload to clean/reorganize things up to others in the future. ... which seems a familiar sounding Human theme. :-( )
- --.MvGulik. 13:35, 9 April 2018 (EDT)
Page deleting note
Seems there is some wm database issue that restricts restoring revisions that are older than July 2013, as such deleting of pages with revisions older than 31-July/1-aug 2013 should be put on hold. --.MvGulik. 13:45, 29 July 2018 (EDT)