User talk:MSipher

From Starbounder - Starbound Wiki
Jump to: navigation, search

Miniknog R&D Report

I've already asked Katzeus about this, but got no response - could you move Miniknog R and D Report to Miniknog R&D Report, like the way it's called in-game? - Sligneris (talk) 08:01, 13 July 2017 (BST)

Sorry I didn't get a chance to clean this up - I looked at it this morning and it was done! Good catch, and thanks MSipher Katzeus (talk) 13:06, 13 July 2017 (BST)

Lore navigation boxes

I've been trying to revise lore navigation on UserWiki:Sligneris and UserWiki:Sligneris/Legacy. Though I'm content with most of it, I'm a bit unsure when it comes to codex stacking. Does it look fine? - Sligneris (talk) 14:07, 14 July 2017 (BST)

Article Block Table

Hey, let's have a discussion about the block info table in articles. I'm really not a fan, I think it makes the articles too technical. I'm going to roll those back until we have a plan about them.

Also, bespoke tables like this are really, really unmanagable, this is exactly why we use templates. Please don't do any further changes like this without some discussion.

Katzeus (talk) 12:20, 26 July 2017 (BST)

Okay. I admit I'm not sure what you mean by "too technical", especially given that that specific information is, well, technical information. I suppose the placement/stackable info could be conveyed in paragraph form without being too clunky and awkward, but the other stuff... eeeehn. That's better in quick-look bullet/table form, and I feel it's info that's best put "above the fold" (and certainly above the racial descriptors, which are basically fluff), so it's visible first-screen, without needing to scroll down. Going into the clutter at the bottom to find Tags or if that item you want is even printable via page Categories is really not ideal. Honestly the "printable or not" issue is a bugbear for me on multiple levels (the very idea of scannable-but-unprintable common items chaps mah nips, especially given this game's unfortunate tendency to not relay info terribly well), so anything the wiki can do to ease confusion/annoyance on that, the better. Perhaps adding the Pixel Printer to the "Crafted at" bit? I'm guessing that'd be another "pull direct from game data" thing beyond my capabilities.
I'm loathe to add any new infoboxes to the right under the tooltip. That would create a really unbalanced page with a lot of empty space on the left 3/4ths of the screen if there's already crafting info there. (Part of the issue is the doubled-up banner ads eating up so much vertical space and pushing the entire article down, but I know there's diddley to be done there. Ads are a necessary evil. I'm assuming a vertical banner ad in the empty space to either side is untenable?)
As for table vs template, I have no dog in the fight, so long as the end result makes it easy for people to locate and read the information they're looking for (and just as easy to discover valuable info they weren't looking specifically for). --MSipher (talk) 19:25, 26 July 2017 (BST)
I like object info tables, but I think they should have their own section, below racial descriptions and above change history. Also, if you could turn it into a template, like the Itembox, that'd be great.
Oh, and... is there some way for the table not to show up in the middle? - Sligneris (talk) 21:40, 26 July 2017 (BST)
Oh I absolutely disagree that anything should go under the racial descriptions that's not Version History or Trivia. The descriptors are pure fluff that at least 99% of times convey no meaningful information, and frankly the pages would be fine without them. I'm not saying get rid of them; they don't do any harm on the page... except for when they push more important info down off the first screen, and information that affects Tenants and object placement (aka "actual gameplay") is definitely more important. --MSipher (talk) 21:58, 26 July 2017 (BST)
Is that so? Because for the past few days, racial descriptions have been the first thing I was looking for when opening an object's page, and I think object information should go below them, closer to other technical information, such as History and Data. Alternatively it could go to the right, as part of the Itembox template, but you've already said why that could cause issues.
Well, maybe look at Astro Storage Locker for example. There's plenty empty space under racial descriptions that could be greatly utilized by these object info tables. Here is a preview of how it'd look like. Wouldn't that be alright? - Sligneris (talk) 22:33, 26 July 2017 (BST)
No. I don't know how I can make this any more clear. HOW you present information is important, and that includes order. It's why the sections on the revamped race pages are the way they are... the most important information up top (racial overview, direct player info), with increasingly less critical information as you go down the page.
The racial descriptors are fluff trivia. They convey zero useful information almost universally. Seven versions of "Look! A safe!" on a page about a safe is not useful data. One in a hundred MIGHT have some micro-lore snippet, like how some commemorative plates depict pre-VEP Apex, but that is in no way more important information than the stuff that dictates what Tenant this item will summon or where you can even put the object in question... again, actual gameplay information. As far as informational priority goes, racial descriptors are pretty much dead last. --MSipher (talk) 23:20, 26 July 2017 (BST)
Well, if you say so. I disagreed on the importance of racial descriptions, and I gave you my suggestions... While I agree that information from these tables is fairly important, we have to figure out how and where to display it on the article. - Sligneris (talk) 00:38, 27 July 2017 (BST)
Yeah, I support finding a way to integrate any relevant info into articles - either way the implementation should be through templates so we can universally control the table. If we wanted to reorganize/restyle it's moving one column in a template vs moving 3000 columns on different pages, that's why I rolled those edits back. The details are in the page history if we can reuse them though.
The details in your table that can be queried from the associated data pages are the tags and if it's printable, the rest isn't stored anywhere so it'd need manual entry.
I want to save unnecessary workload on the data-entry side, but just as importantly I want to make sure it's easy to maintain on the maintenance side. Having the same data in two different places for every object isn't a good solution - I'm happy to help bridge the gap to help get the data where it needs to be if we can develop a good design.
I also agree about the importance of page order for data, but think adding a technical table over the racial quotes seems out of place. I wonder if the more appropriate place is in the data footer? Visibility is reduced there, but there's an expandable div just sitting "empty". I appreciate the discussion about this, especially for big multi-page changes it's good to get these things worked out as much as possible before charging in (I know from experience here hahaha) Katzeus (talk) 11:31, 27 July 2017 (BST)
Alright, but here's a question. What's the benefit in putting the racial descriptors over just about anything else? Serious question. Most importantly, what service does this provide the reader? What does 7 variants of "this is a box!" do that's more important than the information that dictates a room's Tenant, an actual gameplay feature that's really obtuse in the game itself?
I can appreciate reluctance to reshuffle something that's stood for a few years, or make a new addition. It's a pain, no argument. But sometimes you need to for your readers' benefit. The other wiki I work on has, over the course of the last year and change, been restructuring several major page types that have stood for like eight years because it was determined that they were presenting information in ways that were hard to read or set a bad "tone" for the reader (coincidentally by emphasizing certain sections over others in placement order)... and yes, that was something that needed to change manually, across hundreds of pages. It was also a good opportunity to re-evaluate the contents in the process and do some editing to get rid of fluff and bad content. But it's been done.
Any rate. Like I said, I think adding the Pixel Printer to the "crafted at" bit under the tooltip where the crafting tables nominally go would be a good way to ensure people can easily see if an item is printable or not at a glance without scrolling (probably depending on their monitor), since I don't think anything is both printable and craftable. Should probably add the printing cost, but that's something that can be data-mined too I'm sure. Placement/stacking-surface info can be done in paragraph form and yeah that's manual but hey. That's why we have editors in the first place. Plus some objects are more complicated than normal (Vine Wall Light, Gun Chest) and need that extra human work. --MSipher (talk) 19:45, 27 July 2017 (BST)
I 100% agree racial descriptions are the least 'important' information about most objects. They're at the bottom of page order - the only thing they're above is the footer navboxes/data section. There are tables of information (ingredient for, loot tables, effects, etc) which all sit above the racial descriptions. Those tables are a little different though, they're basically 'lists', not technical tables of data. I think the information is important, but strongly don't think it fits inside the 'article' section of the page where you'd placed them. There are a lot more solutions we could look at, including working it into the infoboxes somehow - I'm not fighting for the status quo here.
This also doesn't have anything to do with the work involved to update the pages, or an attachment to 'the way things have always been' - It's purely from a page design/data structure standpoint. There's no need to get defensive about the importance of the data, we just need to discuss the right way to present it and the way you'd implemented those tables isn't it.
For the pixel printer thing...I like that idea. Maybe just a box with the printer if it's printable with a price or something. I mean the info printable/nonprintable and price info is there already, we can easily display it conditionally if there's a solid design. Did you have a design in mind? If not I could put something together to discuss. Katzeus (talk) 12:38, 28 July 2017 (BST)


Alright then. I'll simply list here the information, bit by bit but in no particular order, that I feel should be in a "placement" style infobox or table or whatever somewhere. Other more situational stuff can work as normal text; illumination, for example, since every light source has a different light color and intensity and field and etc.

  • Placement - Floor, Wall, Ceiling or Background. Where the object can be placed.
  • Block Count - How many blocks total, for Tenant Tag purposes.
  • Dimensions - Maximum width & height. However, many objects do not have simple rectangular block-silhouettes. Many have gaps or sticky-outty-bits that need accounting for somehow.
  • Platform - If the object acts as a platform to stand on/place objects on. Like Dimensions, this is not as simple as "yes/no" for many objects thanks to aforementioned sticky-outty-bits.

Now, a grid-silhouette graphic can present most of this information REALLY quickly and with minimal template-coding arglebargle (Block Count absolutely should be presented as a simple number), but that WOULD involve a fair amount of front-end work. However, it wouldn't require an individual graphic for everything, since most objects do fall under some basic standards. Pretty much every "chest" is either a 2x2 or 2x3 no-stack, most bookshelfs/cabinets fall under the same dimensions w/ stack, etc. And doing them as simple blocks-on-grids would make cranking them out super-fast to boot. I can throw together some samples later, for "generics" and more situational pieces (non-rectangular silhouettes, changing dimensions based on placement, excessively huge pieces, etc). --MSipher (talk) 19:56, 28 July 2017 (BST) a-like so. --MSipher (talk) 04:22, 29 July 2017 (BST)

This looks really cool - I absolutely would love to start building in this info - we just need to pre-plan the design so it looks good and iron out details like where in the page it'd go, etc...
I'm going to get caught up on this and take it to the forums to discuss - we'll prob get more feedback there from other people (hopefully). Katzeus (talk) 15:13, 30 July 2017 (BST)
Sure, but... I wouldn't hold my breath. Editor engagement seems... low. --MSipher (talk) 19:54, 31 July 2017 (BST)

Ssssssoooo... Any suggestions? I have an idea for a "uniform size" for the grid proper and ways to account for extreme outliers (like the super-tall Hylotl bookshelves), but can't do a mockup til I get home. I can throw a full idea mockup up then, with ideas as to where the info would go. I'd really like to get back to (ideally) one-shotting the body updates on object pages rather than going into Block Size and then later going into adding graphics to the bodies or whatever.
Which reminds me... some objects change their Block Size depending on how they're placed. I experimented with the Vine Wall Light, and yeah, it can count for either 4 or 2 blocks depending on placement. But the "Block Size:" entry will only accept a single number. I can't put in "2 / 4" (my preferred way of handling this) or "2*" where a * would have the descriptor at the bottom of the table saying "block size can change depending on placement" or somesuch.
IDEALLY I'd like to update the main images for relevant objects as GIFs that cycle between their orientations, but that's not something needed to be done now. --MSipher (talk) 19:39, 2 August 2017 (BST)

I haven't had a chance to experiment with this yet - sorry. I'd be interested to see what you've got in mind though. The design elements are most important, but figuring out a good way to display situations like that block variance are important too to save us the time reworking tables and iron out a plan now. Post your mock-up link here or on the forums and I'll take a look.
I'm not sure about the idea of making gifs for orientation. I think it may confuse readers who'd think the objects are animated in game. It's also a pretty significant increase on server resources -- I don't think the trade off/benefit is worth it. If you want to discuss further we can make a new topic/thread - that's just my initial reaction to this. Katzeus (talk) 12:45, 3 August 2017 (BST) --MSipher (talk) 06:36, 4 August 2017 (BST)

Adding 'The' to each page

Hey, I noticed you've been adding 'The' to every object page text -why? I'm open to discussing changes to the structure of page descriptions, but again, if you're going to make changes to every page on the wiki you need to have a quick discussion before charging in.

In my opinion beginning every article with 'The' is both unnecessary and not an improvement. Can we come to an agreement before you continue adding that? Katzeus (talk) 12:51, 28 July 2017 (BST)

Because of simple sentence structure and flow, so it doesn't read like Tarzan-speak. Seemed a very minor thing. --MSipher (talk) 18:31, 28 July 2017 (BST)
Oh yeah, it's super minor, I'm bringing it up because every other page doesn't use that format already, and keeping things consistent is nice. If we're going to make that change we should use it going forward for every other page. Personally, I think it sounds more clunky with using 'The' -
  • Wooden Chair is a furniture object ....
  • The Wooden Chair is a furniture object ...
In a number of cases it's unclear if the name has an adjective written like this I think, having just the PAGENAME then the description makes it clear that it's a proper name. I don't have STRONG feelings, but obv for consistency it'd be nice to have an agreed on standard.Katzeus (talk) 15:10, 30 July 2017 (BST)

Lorenav Templates and Greenfinger's Notes

I've been recently working on overhauls to Template:Lorenavigation and Template:Lorenav on UserWiki:Sligneris and UserWiki:Sligneris/Legacy respectively. I'd say they're essentially finished, would you mind porting them over?

Also, some codexes from "Greenfinger's Notes:" series are missing the colon, or the prefix entirely. I've already brought up that matter on the forums, but didn't get much of a response.

These codexes are:

Could you move each of these to their respective names? - Sligneris (talk) 22:19, 31 July 2017 (BST)

That's wiki-guts-y enough to where I'd feel better throwing it at Katzeus. --MSipher (talk) 01:33, 1 August 2017 (BST)
Oh hey, sorry I didn't see that message on the forums Sligneris! I must have missed the notification, I apologize. Seems fine, let me look after that this afternoon! Katzeus (talk) 11:34, 1 August 2017 (BST)