Wikia

Memory Beta, non-canon Star Trek Wiki

Captainmike

Admin
136,800 Edits since joining this wiki
April 26, 2005
  • My occupation is artist
user talk:captainmike/archive 2007
user talk:captainmike/archive 2008
user talk:captainmike/archive 2009
user talk:captainmike/archive 2010
user talk:captainmike/archive 2011
user talk:captainmike/archive 2012
user talk:captainmike/archive 2013
user talk:captainmike/archive 2014
user talk:captainmike/archive 2015
user talk:captainmike/archive 2016

How is Star Trek Online a part of the Star Trek Expanded Universe? Edit

Hello Captain Mike,

How does Star Trek Online fit into the Expanded Universe timeline? I have been playing the latest module for it: Agents of Yesterday which feature a couple of missions that take place on Original Series worlds and settings. If we add those would they require to have their own headline?

I am asking as Star Trek Online's 24/25th century are differently depicted than in Pocket Books (the Borg still being around for example). The distinction between the two timelines were more clear, but the AoY missions are just set after the Original Series television series.

One mission for example involves Murasaki 312, how would I add that?--The Dutch Ghost (talk) 22:02, July 10, 2016 (UTC)

The STO game nominally takes place in the future of the 'standard' Star Trek timeline, but is only a 'possible future' (which is why the STO novel differs from other timelines)... in particular, there seems to be changes of premise that occur between the latest Pocket novels and the earliest STO sources -- but since the 'standard' timeline hasnt gotten there yet, we generally don't want to waste time speculating on why those changes occurred, or how.
The new module I'm unfamiliar with, but if it involves traveling back in time from the 25th century, then it can be described as those from a 'possible future' traveling back into the 'standard timeline' and possibly (but not necessarily) causing an 'altered timeline'. I really can't say because i'm not aware of the premise.
But simplicity is key, so i'd say they're probably in the 'regular' 23rd century and you're just going to lists this as a regular reference to Murasaki 312 just like any other source. Not 100% sure if that's what you're asking, but I hope this helps. -- Captain MKB 22:09, July 10, 2016 (UTC)

Yes, that was basically my question: how to treat the new content of this module. Should it be put in the main timeline or I should I put a clear indication that this content is part of the Star Trek Online timeline. The new module starts out in the 23th century (the player can create a new character in this era) and is set some time after the end of third season of the Original Series. There is some time travel in it but from that period back into Season 2. The time traveling Na'kuhl also make an appearances (hope that does not spoil it for you) during the story campaign of Agents of Yesterday.--The Dutch Ghost (talk) 07:30, July 11, 2016 (UTC)

I don't think there's a clear point of divergence that would allow us to call it an alternate reality. Sounds like the content of the story could lead to that outcome, but you should be putting everything in as regular references. -- Captain MKB 11:54, July 11, 2016 (UTC)

Okay, I will put in all the Agents of Yesterday under the general timeline articles of the mentioned subjects. So far there does not seem to be a breach with the established storylines, the missions involving time travel back into the Original Series seasons are more like 'hidden perspectives', elements that were not told during the episodes such as there being Na'kuhl on the Enterprise during "Journey to Babel" who also provided the Orions with the technology for their fast attack ship, or giving the Klingons cloaking technology (well it seems to be implied during that mission in STO).--The Dutch Ghost (talk) 12:39, July 11, 2016 (UTC)

SpoilersEdit

Did not think i put that many spoilers into it. I just tried to keep it like it was on Memory Alpha. Plus, i forgot about spoiler template. Thanks for warning, will try to remember that for next movie or show.CC-1990 (talk) 23:21, July 22, 2016 (UTC)

Question about stubsEdit

I've noticed that you've frequently added stub templates to very short articles. I am not entirely certain that this is correct, as it is my understanding that, sometimes, the articles are short not because they are stubs, but because that's all the details given about the subject in the source materials. Doug86 (talk) 03:35, July 31, 2016 (UTC)

I've been adding the stub template to articles that need completion. I assure you there is additional context to be added for all these articles. -- Captain MKB 09:46, July 31, 2016 (UTC)

USS Excelsior Edit

This user, 184.1.16.134, vandalized the USS Excelsior (NCC-2000) page by replacing words with some nonsense words. Not only did I revert his edit, but I even gave that user a warning about what would happen if he did it again. Please block this user as soon as possible. AdamDeanHall (talk) 19:45, August 1, 2016 (UTC)

Charlie Pike deletion discussion Edit

Can you explain to me what I did wrong and tell me what I should've done instead of just saying it was an "inappropriate discussion"? I thought I was following the policy as you explained it to me in Forum:Characters with contradictory names. NetSpiker (talk) 00:48, August 3, 2016 (UTC)

Suggesting a merge or discussing altering the format of the article can take place on any article's talk page.
A deletion discussion presupposes that there is actual reason to DELETE the article -- and there is no such problem with Charlie Pike. it is a responsibly written article from a valid source. A deletion discussion could be very threatening to the author of an article, who as far as I can see contributed in good faith. There's no reason either Charlie Pike or Josh Pike should be deleted. -- Captain MKB 00:55, August 3, 2016 (UTC)

I didn't mean to offend anyone. Since Memory Beta (unlike Memory Alpha) doesn't have a "Pages to be merged" section, I mistakenly assumed that the "Pages for deletion" section would be the right place for a merge request. I will restart the discussion on the Charlie Pike talk page. NetSpiker (talk) 03:22, August 3, 2016 (UTC)

OK, but for the record, i am of the opinion that the articles should not be merged. they are two different characters. i'm sorry it doesnt appeal to you that there are discontinuities. -- Captain MKB 12:56, August 4, 2016 (UTC)

I have no problem with different stories contradicting each other. I just suggested that they should be merged because you once told me "I definitely would not suggest or support there being two articles for one character. these should redirect to a common page". How is the Charlie Pike/Josh Pike situation different from the Ra-ghoratreii/Eteon tar-Chereos situation? NetSpiker (talk) 13:23, August 4, 2016 (UTC)

EDIT: I just read what you posted on the Charlie Pike talk page. So there's no policy that alternate names are not supposed to have separate pages. You judge each example on a case by case basis and decide whether or not it's different enough to be considered a separate character. I guess that's okay. NetSpiker (talk) 13:32, August 4, 2016 (UTC)

Its different because both Ra-ghoratreii and Eteon tar-Chereos are the same person holding the same position, but with a different name. There would be no difference between two separate articles about them because they both have identical life-timelines and actions. Even in cases like this where novelists have written different endgames (perhaps there are even two separate obituaries), they are still the same person just with a branched endpoint.
Charlie Pike and Josh Pike, despite both purportedly being Pike's father, have both led sharply different lives and hold different places in the Trek universe -- Josh Pike is Starfleet's elite, a retired admiral if i am not mistaken -- while Charlie Pike is an NCO who has had a soap opera of history with remarriages and his son being adopted away from him and then reuniting
It would be a disservice to templatize Charlies history into Josh's article and it would be a disservice to change Josh's history to reflect what was written about Charlie. They're two different people. -- Captain MKB 13:39, August 4, 2016 (UTC)

Portable infoboxes Edit

Heya :) sulfur and I have been working to make the infoboxes on MA portable, and he thought it would be cool if I swung by here to offer my services, as well.

Changing over to portable infoboxes will help more people on more devices see your content. It'll also put you in a better position for the future, as the infobox morphs from something which simply shows data into something that leverages data.

I've therefore whipped up an example for you at User:CzechOut/Starship. As you should be able to readily see, {{Starship/Draft}} works just like {{Starship}}. All the same variables are employed. And the re-coloring of titles happens just as it does now: depending on the value of {{{type}}}.

Since you're an artist, I thought you might enjoy looking at a very slight variation to your current design. As you can tell, I've taken the padding along the outside edges of the infobox away to give a sleeker look. If you'd like that restored, it's super easy, but I just thought we might look at this as an opportunity to freshen things up slightly.

Please do take a look and let me know if you'd like me to change any of this. Since all your infoboxes use this basic design, once we get this first box settled, it'll be easy to pump out the rest of them.

And just to emphasise: you don't have to do any work on any of this. I'll build 'em all based on your approval of this first design. — CzechOut @Wikia 22:59, August 7, 2016 (UTC)

Oh there's also a comparison of the Character infoboxes to look at. — CzechOut @Wikia 23:55, August 7, 2016 (UTC)
Heh, actually ... once I started working with {{Characterbox}} a bit more, I just went ahead and added all your original padding back in. The alt pictures at the bottom collided with the image of rank insignia, so the original negative space was pretty useful. You may have to do a browser cache clear, but you should find that the old and new boxes are pretty much twins now. — CzechOut @Wikia 00:36, August 8, 2016 (UTC)
Hi, I took a look and the look seems pretty legit. my main concern would be the way the code is written -- as Wikis go, we are advised to stay away from HTML and keep the data entry simple -- i have a hard time convincing users not to put HTML overrides and workaround coding in tables and infoboxes, so hopefully anytime that happens wont break the efforts. i'd like to be assured that the code does not violate any of that rule of simplicity, furthermore.
i'm not in a great place to comment further, because in coding the padding and color changes ten years ago i did a lot of awkward workarounds myself. but i'd just hope it is something we can apply without any outages or violations of any rules. -- Captain MKB 23:18, August 8, 2016 (UTC)
Well, the portable infobox code was designed specifically with simplicity in mind.
Data entry is absolutely the same as with the current, wikitext infoboxes. Not a single variable has been harmed in the making of your portable infoboxes. Whatever you did before to call your infoboxes on a page is exactly what you'll do with the portable versions.
Meanwhile, most communities have found that it is much easier to build a portable infobox from scratch than it is to attempt one of the old-school wikitext models. This is because a lot of the parser functionality is built into the code.
For instance, if you wanted to make sure that a variable in, say, {{starship}} didn't appear if there was no value for the variable, you'd have to write an #if: statement, like this:
{{#if: {{{class|}}} |
{{1}}-
! align="left" {{1}} Class:
{{1}} align="right" {{1}} {{{class}}}
}}
By contrast, portable infobox code simply assumes that you don't want the {{{class}}} line to show up if there's no value for it:
<data source="class"><label>Class:</label></data>
That's it! There's no counting of the number of curly braces to make sure they show up. There's no need to worry about using {{1}}. It's simply naming the variable and offering the label.
And by tucking away the styling into CSS pages like MediaWiki:Infoboxes.css and MediaWiki:Themes.css, we're further protecting your infoboxes from accidental damage. You have to be an admin (or staff or one of our official helper groups, like Vanguard) to affect the template styling.
As for introducing HTML, don't worry. Though it looks similar, this isn't HTML but XML. It's hard for users to "break" without immediately seeing that they've done something wrong. Warnings immediately pop up when you try to publish something the parser rejects as bad code. And when something is broken, you get a very clear sign on pages that call the template that the infobox is refusing to parse. So in the case of someone other than you passing rejected elements to the template, you would simply return to the template and undo their edits to the last known good version.
This is better than the wikitext infoboxes, because users could introduce errors without any sort of alarm. They could remove a single curly brace, and the box would still function -- except in one harder-to-spot area. They could change the background color of a single line in the box, and you might not notice for weeks. If the infobox were particularly obscure, those errors might stick around even for years.
Such damage is much less likely with the portable infobox code. Understand, though, that I'm not saying PI code is completely foolproof.
Users could introduce undesired changes that weren't coding errors. For instance, they could remove an entire <data source> line, the infobox would still parse correctly, and you'd be none the wiser unless you happened to spot the absence. And they could vandalise the spelling on labels and titles. But they could do that with wikitext infoboxes. And portable infoboxes can't be genuinely broken without an error message and publishing alarm being tripped.
If you wanted additional assurances, you could always just protect the templates. Since the number of active admin is relatively small, it would be relatively unlikely that someone other than you would break them.
Does that allay your concerns? If you have further concerns, please feel free to ask them below. Or, if you have no further issues, lemme know if it's okay for me to actually push the "approve" button -- yes, there's an actual button! -- on these new designs, or if you'd like to do it yourself. Thanks! — CzechOut @Wikia 17:56, August 9, 2016 (UTC)
I think we're in a good place to use these. make it so, engage, etc -- Captain MKB 13:18, August 11, 2016 (UTC)
Engage I did, and now your infoboxes are all converted to portable. Please lemme know if you run into any problems! — CzechOut @Wikia 03:58, August 12, 2016 (UTC)

Hyphenation in portable infoboxes Edit

Okay, I killed the hyphenation in the data labels and data values. I think you might have been seeing it here with greater frequency than is typical because your infoboxes are a bit on the narrow side. — CzechOut @Wikia 16:56, August 12, 2016 (UTC)

A lot has changed in display standards since 2005 when we launched - widening them might be the next step. Having the code simplified makes that easier! Thanks again -- Captain MKB 01:18, August 13, 2016 (UTC)

Image handling Edit

I'll take a look. Sorry for the inconvenience. I hadn't expected that prose-only people would be represented by symbols. I just thought they wouldn't have a picture. — CzechOut @Wikia 02:55, August 13, 2016 (UTC)

Is this practice widespread, or is it just something that happens with Characterbox? To find a solution, it's going to be important to know which templates, specifically, are affected. — CzechOut @Wikia 03:01, August 13, 2016 (UTC)
Okay, I think I've fixed it for you. Please take a look at Agbadudu and let me know if that's what you were hoping for. Thanks! — CzechOut @Wikia 03:21, August 13, 2016 (UTC)
That's a lot better. I've been trying to think of a better arrangement of those forever, but they are very widespread. i've thought of making icons a separate line in the table from the image, but it would kind of mean going through every template someday to change the parameter. we might want to do that someday, but for right now this is what i am used to. - Captain MKB 04:31, August 13, 2016 (UTC)
It doesnt look great on mobile either, so it' something we'll probably have to fix eventually -- Captain MKB 14:53, August 13, 2016 (UTC)
Well, I wouldn't call it horrible. It still gives recognizable icons-at-a-glance on a single line, like on desktop. But if you want anything different, you are going to have to consider a major overhaul.
As I see it, there are two options, both requiring a bot (which I can provide). You can:
* put each image into a variable of its own, and then let the infobox code handle each image naturally or through {{sidebar image portable}}
* actually remove the images -- or change the image variable name -- so that you have no image
In any case, for the short term, it would be helpful to know the names of the templates where this dual-icon approach can happen. For instance, he reason {{planetInfobox}} is exhibiting the undesired behavior is because I didn't know to apply the {{characterbox}} fix there. — CzechOut @Wikia 16:32, August 13, 2016 (UTC)

Adapted box Edit

hey i just noticed that {{adapted}} didnt really get a new treatment -- its a hybrid for episodes that are also comics and novels - the episode style you picked up is deprecated, by the way -- we were trying to transition that to be ore like the other infoboxes (as the "adapted" one reflects) -- Captain MKB 14:53, August 13, 2016 (UTC)
Yeah, {{adapted}} wasn't classified as an infobox -- instead it showed up as "unknown" template type -- so it wasn't on the Special:Insights/nonportableinfobox list of infoboxes to do. It's done now, though. And it appears to function better than the previous version, in that it actually displays images and a ton of variables (particularly in the "publication information" section) that had been specified, but weren't displaying.
This incident makes me believe I'm going to have to crawl through all the templates at Special:Templates to find any mis-categorised infoboxes. If you know of any that do not currently appear at this list of converted infoboxes, please let me know. — CzechOut @Wikia 16:32, August 13, 2016 (UTC)
Adapted is the newest one, its designed to work as a couple of infoboxes its a merge of novelization, comic adaptation, film, and can replace film parameters with episode parameters -- it could be merged with episode in the future, but right now it is used for episode-with-comic-adaptation (omitting the novelization parameters), novel-with-comic-adaptation (omitting the episode and film parameters), and films-with-comic-and-novel-adaptations (as well as ones with novels but not comics)

Other styling matters Edit

Are you saying that you'd like all infoboxes to be styled in exactly the same way, and that {{characterinfobox}} and {{starship}} and {{adapted}} are exhibiting that style? (FWIW, I think that would be a great and highly sensible move.)

If that's true, can I get a ruling on where you want your section headers? Some infoboxes have them left-justified. Others have them centered. You can see the confusion by going to The Counter-Clock Incident, where the code obeys the conditions set for {{Characterbox}}. However, {{Characterbox}} has the added advantage of colored headers, so the headers stand out more there than in other infoboxes.

I think I'd recommend all of your headers to be centered. What do you think? — CzechOut @Wikia 16:32, August 13, 2016 (UTC)

Seems legit. Yeah, i hadnt realized there were such different styles at play. Characters, planets, ships and facilities benefit from coloration in headers, while episodes and other media do not need that attribute -- but the goal is definitely to have the font, alignment and cells styled the same for all of the above.
Headers now all centered. — CzechOut @Wikia 00:01, August 14, 2016 (UTC)

Other Wikia sites Edit

Oh, hmmm. Interesting. I'd never thought of the template naming as indicating whether the wiki was on the Wikia network or not.

I was going off the actual language of the templates, which was saying that the site was a "wikia". That's language to which none of the sites I've encountered so far would actually agree. DC and Marvel are resolutely Databases; Tardis is definitely a wiki or "the data core".

I think I've only moved three or four, none of which have a "better" version off-Wikia, and I've kept redirects for all, so that longer-term editors won't be confused. I think I've already passed by {{stowiki}} and {{stowikia}} in my template reclassifications -- without renaming them. As a sometimes STO player, I got the distinction you were going for in those titles. — CzechOut @Wikia 03:29, August 14, 2016 (UTC)

Reclassification results Edit

After reclassifying several hundred templates from "unknown" to something meaningful, it looks like a majority of your infoboxes weren't classified as "infoboxes". I'm not quite sure why. Of all the wikis I've worked on, the initial bot classification here seems to have been the most profoundly incorrect.

This, of course, means I'm not as close to being finished converting your infoboxes as I thought a couple of days ago. But now that we've said they're all going to have the same format, it should be something I can finish this weekend. — CzechOut @Wikia 03:52, August 14, 2016 (UTC)

Image fixEdit

I've discovered today that the image fix that I came up with yesterday has a serious downside. It allows users to specify a certain imagewidth. But, I hear you say, "That's what it was supposed to do, so that we could get those really small icons to work."

Yes. But the problem is that it will totally break the infoboxes if the widths are specified too high (>220px)

image width too wide (300px)
image width too narrow (150px)

As you can see, this is problematical on two levels. First, it makes {{{image}}} and {{{altimage}}} have different widths. As there's no need to apply the fix to altimage, it's handled entirely by PI code, and therefore is scaled appropriately to the width of the infobox. Second, it means that, even when images technically "fit" the infobox, they won't have the same surrounding whitespace. Everything I've seen about your infoboxes tells me that's not what your design ethos is. I think you intend uniformity.

Essentially, this fix is allowing those infoboxes that don't have real images of the subject control how infobox images work. And that's not a great idea. Infoboxes that actually have images of their subjects should be the standard case, and those that don't should be very much of an exception.

I therefore propose this solution:

  1. Remove the current "fix", thereby allowing infoboxes with images of their subjects to be considered the norm in the code.
  2. Use my bot to go through the pages and find the instances where two images are in the value of {{{image}}}. Change the name of these variables to {{{icon1}}}. Since {{{icon1}}} does not exist in any infobox template, this will have the immediate effect of simply removing the "double icons" from all infoboxes.
  3. If you're fine with not having images of things that don't actually have images, we can stop right there.
  4. If you want to retain the icons, then we would do another bot run that separates the first icon from the second. We'd make the second icon the value for {{{icon2}}}.
  5. Then, we'd do one of two things:
    1. Apply a variation of the original fix, using {{{icon1}}} and {{{icon2}}}
    2. Apply {{sidebar image portable}}, but in a way that would get bigger icons that would look better on phones. See First Battle of Berengaria for an example of how this would work.

I should say the bot work is very easy, and I intend to run it manually, so that I have to approve every change. The chance of screwing anything up is practically zero. (And don't forget sulfur taught me most of what I know about bots, so this is very much an "all-in-the-family" kinda job.)

What do you think? Does the proposal -- and the need for it -- make sense to you? — CzechOut @Wikia 19:39, August 14, 2016 (UTC)

We've had trouble for years getting people to adhere to image sizes -- i'd actually welcome automating the 220px requirement so we didnt have to teach people to use it.
I'd be in support of restoring the full size image code with the proviso that icons go somewhere else - if there's no actual image, it can be blanked. this will be a benefit to mobile use judging how the last fix rendered.
The reasoning behind the small icons is so they don't balloon the height of the info table, so it might be a bit of a stretch to have a table with both an icon row and the top and alt images - but that's the only detractions from the plan - and it wont even be hideous, just a little taller. -- Captain MKB 20:36, August 14, 2016 (UTC)

Are fanfiction allowedEdit

Just wondering are fan fiction series allowed? (Dragonboy546 (talk) 05:10, August 16, 2016 (UTC)Dragonboy 546)

No. Use the Star Trek Expanded wiki for those. -- sulfur (talk) 16:34, August 16, 2016 (UTC)
I didn't mean like fan series but novel format and I've been blocked till next year (Dragonboy546 (talk) 20:43, August 20, 2016 (UTC)Dragonboy546)

Infoboxes Edit

Hey! Sorry for the delay. I hadn't realised you had posted here, on your own page. I'll be working on those issues this weekend. -- CzechOut @Wikia 22:31, August 26, 2016 (UTC)

Around Wikia's network

Random Wiki