Roblox Wiki:General discussion/2013

< Roblox Wiki:General discussion

Asset Documentation[edit]

I know this has been brought up before, but I think we should document hats, gears, faces, packages, and heads. It would boost interest in the wiki and help people learn that their favorite hat is a TF2 reference, or maybe their favorite sword can be played like a guitar and they never knew. It would also be pretty fun to document. Not to mention, assets are a huge part of roblox and we are the roblox wiki. »ArceusInator 20:30, 8 December 2012 (CST)

Nothing has changed between now and the first time you brought it up. There are simply too many assets, it would be tedious to keep everything updated, and any useful information is already available on the main website. Documenting individual user-created items is beyond the scope of this wiki. --Anaminus 23:48, 8 December 2012 (CST)
I totally agree Anaminus. This will help interest, and give us more to do. There's really not whole bunch to do at this point. itunes89 - (October 22, 2017)
I'm not talking about user-created items; of course that wouldn't even be possible. I mean actual hats, gears, faces, heads, and packages, uploaded by roblox. »ArceusInator 11:40, 9 December 2012 (CST)
All assets are user-created, because they all share the same properties, such as being small, numerous, and are uploaded and managed by a user account. --Anaminus 17:10, 9 December 2012 (CST)
Looking at the catalog page, just under hats alone I see 2,584 results. I think at this point it would not be practical for us to document these, as our resources could be put to better use in other endeavors, such as merging our scripting tutorials. Thanks though. --Gordonrox24 | Talk 12:15, 9 December 2012 (CST)
Hire a monkey for two bananas an hour and he'll do it for us. But seriously though, what if we would only do the iconic hats? The hats that you would find in the history books, things like the 'Oh Noes' sign, or the teapot. -- xzbobzx 13:20, 9 December 2012 (CST)
This was already attempted. It ended up being to difficult to maintain. If you really think you have the time and patience, you can always make your own website. In fact, give it a shot. It's dead simple to setup a wiki on your computer. Start documenting assets there, and if you actually get anywhere, set it up as an actual website. --Anaminus 17:10, 9 December 2012 (CST)
Ah okay, and no thanks. Makes me think we should have a list of things that didn't work out so newbies like me won't suggest it again. -- xzbobzx 09:10, 10 December 2012 (CST)

Error on the Players Page[edit]

Hey! I'm new to the Wiki, so sorry if this in the wrong place. I was looking around the Wiki a bit, and I noticed an error on the Players page. However, I have no idea how to fix it. The error is the method SetAbuseReport replaces SetAbuseReportUrl. But SetAbuseReportUrl should be there, not SetAbuseReport. How would I fix this? And where should I post things like this?

Nelson 18:18, 4 January 2013 (CST)

The way the object pages work is very complex, And took me about two hours to figure out. You would change this at Object:Players/methods. I've now fixed it. -VisualCSharp(Talk) 01:13, 5 January 2013 (UTC)
Oh, and the correct place to put this would be the Player object's talk page. -VisualCSharp(Talk) 01:15, 5 January 2013 (UTC)

Approved Plugins page.[edit]

There are a lot of good Roblox Studio plugins out there(Here's a lot of good ones.). We should create a official page where people can download these plugins. We will approve them here, so people know they aren't download virus and such. I would like to take the lead, I will approve, remove, add, take request and everything. What do you say? itunes89 - ( 07:28, 6 January 2013 (UTC) )

This wiki was created to help people with building and scripting. On the other hand, plugins do enhance your building and scripting experience so I support this idea. As long as this page doesn't get overflown with useless plugins.
11:30, 6 January 2013 (UTC)
I don't think this is well suited to a wiki. Personally, I'd be tempted to set up an organization on github, and host all the "approved" plugins there, and simply link to them from the wiki. That way they can actually be improved by the community, and there's an issue tracker.
13:33, 6 January 2013 (UTC)
I think this is something that would be interesting to try on the wiki, however I would much rather have our current focus elsewhere. Maybe once we've started organizing our scripting tutorials, which really is next on my agenda, we can look at the practicality of doing something like this.--Gordonrox24 | Talk 18:59, 6 January 2013 (CST)
I also agree on this being a good idea, but not a priority. Doesn't mean we can't throw a few people off to work on it though. MrNicNac - Senior Wiki Editor
Okay cool. Is there anything anyone needs me to work on? I've been scanning around, haven't found anything. itunes89 - ( 14:02, 7 January 2013 (UTC) )

Can I begin now. I've now seen this asked for a few times in the forums. I think having an official place to post these plugins would avoid people downloading viruses. I will start this page on the 20th, so if you would still not like me to, just post here. itunes89 - ( 16:53, 18 April 2013 (UTC) )

I maintain that we'd do better to host these somewhere offsite specifically designed for storing software, and simply claim said collection is official on a wiki page.
18:51, 18 April 2013 (UTC)
Yea, for now I will use just MediaFire. I PMed Roblox, hopefully, they can give us a subsite for hosting these zip files. I could even use my own webserver. itunes89 - ( 19:45, 18 April 2013 (UTC) )

Studio 2.0[edit]

Alright folks, we've got a pretty big task in front of us. Over the next couple of weeks we will need to begin updating the wiki pages about ROBLOX studio. We are going to be updating them to reflect the changes that are coming in ROBLOX Studio 2.0. This includes pages such as Studio and Toolbox. We are going to need to be updating pages and images to fit with the new version of studio. I'm going to be actively helping with this process, so if we have any questions feel free to ask. Thanks!--Gordonrox24 | Talk 16:39, 8 January 2013 (CST)

Okay great. Are we creating a new page Roblox Studio 2.0 or are we just updating Roblox studio and alike? itunes89 - ( 00:18, 9 January 2013 (UTC) )
We will just be updating existing pages.--Gordonrox24 | Talk 19:46, 8 January 2013 (CST)
This could take a while... (those are for {{Studio}})
21:06, 9 January 2013 (UTC)
Very aware. It's a massive project. I've already started updating some of the more obvious images, but there are a ton of them. There is also some imagemap work to be done, which could be interesting.--Gordonrox24 | Talk 15:15, 9 January 2013 (CST)
There is absolutely no reason to use JPG for icons. I'll try snooping around for the raw images. As for the menus, it would be better to use some HTML+CSS magic, instead of trying to maintain hundreds of images. I've experimented with it already, so I could put up a solution, eventually. --Anaminus 18:28, 12 January 2013 (CST)
The template would also be a good thing to update. Honestly, I wish Studio 2.0 used tabs instead of an updated .Net framework, but I can't really complain... Anyway... - Quenty (talk • January 13)
We used JPG originally, so I was planning on just carrying on with that. Agreed, it isn't the most time effective solution. If we could find the raw images, that would be ideal.--Gordonrox24 | Talk 20:19, 12 January 2013 (CST)
Found them. I can upload them with a generic name format (i.e. studio2-icon-[index].png), and then we can redirect to those. Unless there's a specific way you'd like it to be done? --Anaminus 20:59, 12 January 2013 (CST)
Are you suggesting uploading to numeric indices, like File:Studio2-icon-0.png, or named ones such as File:Studio2-icon-leftarrow.png?
12:08, 13 January 2013 (UTC)
I've gone through and renamed all the ones that are used. So they would appear as Studio2-icon-SmoothSurface.png. Does that seem fine? If these are to be put into their own category, what should it be called? Category:Studio2 Icons? --Anaminus 18:04, 13 January 2013 (CST)
Sounds good to me. Like the category name as well. --Gordonrox24 | Talk 10:10, 14 January 2013 (CST)
All done. The exact category name is Category:Studio2 icons, which is slightly more consistent with the names of the images themselves. --Anaminus 20:17, 14 January 2013 (CST)
Also, which OS do we want these screenshots to be taken on?
21:50, 13 January 2013 (UTC)
As far as I know, 2.0 for both Mac and Windows are the same, so it shouldn't matter which OS you take photos with. I could be wrong on that, can anybody confirm?--Gordonrox24 | Talk 10:10, 14 January 2013 (CST)
Toolbars will render differently on every OS (as they should - programs should match the UI paradigm of their OS). Windows 7 draws things shiny, windows 8 draws things flat, etc. Dictating an OS now (for screenshots) results in consistent images. If we build things in CSS, then the point is moot.
23:25, 14 January 2013 (UTC)
If you don't mind my input, esp. since most pages have been updated already... I propose users with Windows 8 do it. Whether anyone likes W8 or not, the fact is it's coming from the most popular OS manufacturer and it is the most recent, and recommended, OS. It'll eventually grasp a bigger market share than W7 and it's a much more modern OS. With most of the users on Roblox probably planning on buying a new computer if theirs isn't relatively new, most of the targeted market should be running W8 eventually.
Trappingnoobs   (Writer, Editor, Reviewer)    Like something I did? Dislike something I did? Tell me on my talk page17:28, 11 July 2013 (UTC)

Archiving this page[edit]

What are the options for archiving this page? It's getting long, and though some topics are still pending, many are done. It would be nice if we could archive some of them off. I have a lot of new projects to put on here and I don't want them to get lost, or new readers to have trouble finding the recent topics/replies. Thanks. --Reesemcblox 23:57, 11 September 2013 (UTC)

On Talk:Roblox, we've been putting "[RESOLVED]" next to any topic that's been resolved. Doing something similar here would be helpful for determining what not to archive. --Anaminus 01:03, 12 September 2013 (UTC)
I like this idea, but it doesn't apply to all discussions. I suggest we apply it to discussions to which it applies and, for discussions to which it doesn't apply, just archive the discussion when it's been inactive for a while and isn't relevant anymore. -- Mark Otaris 01:22, 12 September 2013 (UTC)
Done. I have archived all the discussions that were no longer relevant, disregarding whether discussions were old or inactive. -- Mark Otaris 01:22, 12 September 2013 (UTC)
Thanks! Now that we have archives, this topic can be archived. :) --Reesemcblox 20:32, 12 September 2013 (UTC)

Undelete request[edit]

Looking through Special:WantedPages, Gear is one of the most linked pages. Looking back, MrDoomBringer deleted it without giving a reason. Could someone with undelete rights restore the page?
NXTBoy (talk • contribs)
13:23, 23 December 2013 (UTC)
Done. --Gordonrox24 | Talk 20:51, 23 December 2013 (UTC)


Lua extension matures[edit]

Read about it here. This would be invaluable for giving the documentation system an overhaul. Please can we install it?
NXTBoy (talk • contribs)
22:17, 15 March 2013 (UTC)
I agree --JJRcop 17:44, 15 March 2013 (CDT)
Ha! And you said it was too far away. I think, as a condition to getting it installed, we should have modules written and ready to go beforehand. --Anaminus 18:34, 15 March 2013 (CDT)
I'd say the opposite - we want it installed early so we can try out a bunch of different strategies, rather than committing to a final design before fully understanding what the Lia can do.
10:18, 16 March 2013 (UTC)
That seems cool. itunes89 - ( 17:39, 16 March 2013 (UTC) )
What I want to avoid is the wiki turning into a lua playground. Anyone who knows a sliver of lua is going to want to try it out, but it should be made clear that this place is not a sandbox. There's no reason we can't setup our own servers, or use existing sandboxes, to explore ideas. Having a system ready to go is an excellent incentive for getting the extension installed quickly. --Anaminus 13:14, 16 March 2013 (CDT)
Very interested. I'd love to get this installed on our sandbox wiki, test it out there for a bit, and if all goes well bring it right here. Thanks for that link. I found this presentation, as well as this tutorial good places to start to understand this, for those interested.--Gordonrox24 | Talk 15:46, 18 March 2013 (CDT)

Broken user-rights page[edit]

One thing I noticed is Special:ListGroupRights is a mess with a bunch of stuff like (<span class="mw-listgrouprights-right-name">noratelimit</span>) on it. As to the youtube plugin, it appears to work properly. Legend26 (talk | contribs) 20:05, 7 December 2013 (UTC)

I noticed that too. Also on the Special Pages - Version page. I am not sure what to do about it, is it breaking anything important? --Reesemcblox 21:49, 9 December 2013 (UTC)
Not that I can tell, it's just a pain to look at. Legend26 (talk | contribs) 01:07, 10 December 2013 (UTC)
It breaks almost every page written before december 2011. That's how old this problem is.
11:58, 23 December 2013 (UTC)
This is due to the SyntaxHighlight GeSHi extension. Good thing we picked up on this two years ago
11:56, 23 December 2013 (UTC)


Sandbox wiki[edit]

We have a sandbox for the wiki where the version of mediawiki has been upgraded. Please check it out and make sure things are still working as expected. Only older accounts will be able to log in there, as the copy of the wiki data the devs grabbed was many months ago. Sandbox Wiki --Reesemcblox 19:26, 4 December 2013 (UTC)

Everything there seems to work fine as far as the interface goes; MediaWiki releases don't usually introduce changes that could cause problems on existing MediaWiki installations that upgrade, and when they do, these problems are described in the release notes. --Mark Otaris 04:17, 5 December 2013 (UTC)
Thanks Mark. --Reesemcblox 20:38, 5 December 2013 (UTC)

Embedded videos[edit]

On to Stage 2 - please test the new video widget and the new permission that should allow Writers to make edits without revision. The video widget does not auto-play, and supports playlists. Sandbox link is in the first post of this section. --Reesemcblox 20:38, 5 December 2013 (UTC)

Wouldn't it be better to keep the videos separate from the wiki and just list them on YouTube and refer to there? All the power of wikis lies in the fact that they can be contributed to collaboratively, that it is possible to see all the changes made to a document and that any change can be modified or undone. It is practically impossible to do any of those things with videos, and considering they are hosted on YouTube, it is in fact simply impossible (practically or not). The most we can do with this widget is create catalogues of videos, but I suppose this can already be done on YouTube, so I don't think putting videos on the wiki offers any advantage over simply having them on YouTube. Furthermore, if these videos aren't released under the GNU Free Documentation License, which is the license used for content on this wiki, and none of the videos about ROBLOX I have ever seen is released under any particular license, then they cannot be included on the wiki as that would contradict the license information on Roblox Wiki:Copyrights. I think all of that is quite a lot of trouble for not much benefit. Perhaps it would be better to allow uploading of ogv and ogg files (video files), as is done on Wikimedia projects such as Wikipedia, and inclusion of these files into articles. That would make it possible for any wiki writer to modify the video (even if it's still difficult to do, at least, they can be improved), and it would solve the license and history problems. It wouldn't be ideal, but I think it would sure be better than simply including the YouTube video player in articles, which is basically just as useful as giving a link to the YouTube page of the video. It would also be better because it wouldn't require a YouTube account and because it would work in the same way as normal files, thus not requiring current writers to learn to use YouTube's interface (but, more importantly, it would be possible for them to improve existing videos, versus having to ask the owner of it on YouTube to update it). --Mark Otaris 20:12, 8 December 2013 (UTC)
The group rights page on the sandbox wiki does not indicate that writers are able to edit page without requiring revision. I noticed the problem mentioned below by Legend26 as well. I have some concerns over using the Widgets extension along with a YouTube widget to include videos, as that doesn't seem like a very good solution. If we really want to embed videos from other providers in articles like this, I think we should use the YouTube extension or a similar extension instead. That would be a cleaner solution, but it would be even better to just allow uploading of video files and inclusion of them in articles. --Mark Otaris 20:25, 8 December 2013 (UTC)
I'd also like to note that we don't need any of this because we already have the ability, on this very wiki, to include video files (although not to upload them, but that can be changed easily by changing a setting in LocalSettings.php), and to include video files from YouTube. Example:
<HTML5video type="youtube" width="400" height="300" autoplay="false">4ttoJHWkq6c</HTML5video> --Mark Otaris 20:25, 8 December 2013 (UTC)
The extension that currently allows us to do this allows us to change the width and height, to specify any video in the ogv, webm or mp4 format uploaded on the wiki or to embed one from YouTube. It allows us to choose whether a video should play automatically or not, and it seems to work perfectly (although I might be missing something). We could just use this and simply change the LocalSettings.php file to allow ogv, webm and mp4 files. --Mark Otaris 20:28, 8 December 2013 (UTC)
The HTML5video extension videos do not work in the embedded Studio documentation we are trying to release, because it's the wrong type of video player. We need it to be iframed instead of flash or other player. HTML5video also auto-plays even though you have that setting to false. We have to move away from HTML5video for those reasons. I'll concede that we could host the videos on this wiki as files but we are not going to do that in the near future. The goal right now is to get the Studio documentation feature out. --Reesemcblox 21:49, 9 December 2013 (UTC)

Wiki updates[edit]

Wiki update should come out on production tonight. --Reesemcblox 21:49, 9 December 2013 (UTC)

Moved to Wednesday night. --Reesemcblox 17:30, 10 December 2013 (UTC)

Wiki will be down for maintenance tonight. Around 8 or 9 Pacific time. After it comes back up it should be on the new version. --Reesemcblox 22:48, 12 December 2013 (UTC)

Unfortunately a catastrophic event has occurred on the new wiki server so we are rolling back to the old servers immediately. Any data changes on the Wiki since 10PM PT last night have been lost. We will re-migrate/re-upgrade the Wiki servers on Monday night next week. --Reesemcblox 21:53, 13 December 2013 (UTC)

That's not too good. :/ Also, kind of sad that we STILL aren't updating the most current version (MediaWiki 1.22.0). Also, there's some extensions we'd like to have, Mark would have a list... - Quenty (talk • December 13)
The wiki WAS on the latest version, then whatever error occurred so now we're back to this. Legend26 (talk | contribs) 01:19, 14 December 2013 (UTC)

Hi folks. We are going to be moving forward with our update again tonight at 8pm PST. We do expect the wiki to be down during this upgrade. Thanks!--Gordonrox24 | Talk 00:23, 17 December 2013 (UTC)

The wiki has been upgraded again. It should be stable now but it might be best to keep your edits in a txt file for the next couple days so it's easy to re-post if we have to roll back. --Reesemcblox (talk) 20:11, 17 December 2013 (UTC)

Except you did exactly the mistake Quenty told you to avoid (see some messages above); it's not at the latest stable version of MediaWiki. The latest stable version is MediaWiki 1.22, and the wiki is currently on MediaWiki 1.21.3. That's a difference of one major version, and version 1.22 was particularly big (because of all the extension development that happened at the same time), so it could very well be considered as two major versions by itself. Also, now that the wiki is updated, could we get Scribunto (and, at the same time, all the other extensions we've wanted since forever)?
  • Scribunto (to create a decent documentation system)
  • Cite (because creating footnotes is basically impossible otherwise and footnotes are very useful in articles)
  • Math (which could be useful to quite a couple of pages about vectors, matrices, quaternions, physics and others)
  • ParserFunctions (because it's impossible to make any sort of decent template system without it; it has many capabilities that Scribunto doesn't have, such as checking whether a page exists and others, and we also most certainly don't want to create hundreds of Scribunto modules for simple things that can be done with this)
  • SyntaxHighlight GeSHi (because it was considered as mega-high super-priority two years ago; see User talk:Mr Doom Bringer, and also see the other priority stuff there and all the requests that haven't been answered since then, since most of them still apply)
--Mark Otaris (talk) 21:30, 17 December 2013 (UTC)
Perhaps I should mention MrDoomBringer said the following about Syntaxhighlight GeSHi two years ago:
Yes yes yes, I've got a queue lined up for a dev about this. Also, I don't read my PMs. Email me if you need to. ---User:Mr Doom Bringer (Talk) 14:08, 17 January 2012 (EST)
Now that I think about it, perhaps we should move all of MrDoomBringer's user talk page here. Much of it is still very relevant. --Mark Otaris (talk) 21:35, 17 December 2013 (UTC)
  • Note that SyntaxHighlight GeSHi should be replacing GeSHiCodeTag (that is, remove GeSHiCodeTag completely). It's also worth noting that a few of these extensions are bundled with MediaWiki (depending on the version), so enabling them should be fairly trivial. --Anaminus 21:58, 17 December 2013 (UTC)
  • I sent the devs to the source to get the latest version. I don't know why it's not the one that was installed. However, we can only get so many changes in at a time given our limited dev availability. The server that the wiki is hosted on also holds other ROBLOX sub sites, so any upgrades or changes have to be prioritized and considered with those other sites. The above requested extensions that you've wanted forever and are mega-high super-priority critical have been noted. Hopefully we can get some more dev time early next year. --Reesemcblox (talk) 22:40, 17 December 2013 (UTC)

The ROBLOX wiki should be a super high priority to ROBLOX. What is ROBLOX's game plan exactly? Oh. Right. It's been shifted to game developers (Yay!). What is the main (if only) source of ROBLOX information and the most obviously accessibly and used resource to learn how to make games, or content on ROBLOX? Oh right. This wiki. What exactly is ROBLOX? Oh right, a sandbox game, where you have to know information to make stuff. As Shedletsky noted, it takes over a year to even learn how to use Studio. Part of this reason is the wiki -- and lack of quality thereof. The wiki is, honestly, at this point, a pet peeve of mine. It's the biggest chance we have to help ROBLOX users, new and old, to learn. It can't be edited easily, and it's quality is about the same as about 6 months ago.

Come on ROBLOX. I'm glad you guys are here, listening, don't doubt that, but the wiki should be a priority. This is hackweek, no? We'd all love you if you would let us seriously reform the wiki. Several points of reformation is.

  • Update the system. (You're already doing this, ++ for you)
  • Update the plugins (Seriously ROBLOX, plugins are important, and we are behind.) We want Scribunto, which will allow us to efficiently document all of ROBLOX's API (which, currently, the best documentation is ah, made by a ROBLOX user known as Anaminus, who wrote about 100 words and some code to generate it. That's right, the best documentation that ROBLOX has of it's API is an automatically generated document that has about 0 descriptions.. The wiki can do better, if only we have the resources to document things thoroughly, to make ROBLOX better.
  • Open up the wiki to users. Any user. What, you might say? Well, the ROBLOX wiki is, well, not really wiki, because, well, no one can edit it. You may be scared to open it up, I would be too. That's why wikis include configuration to basically lock out users until they're tested. Otherwise, why do we have a review system for wiki edits, when THE ONLY PEOPLE WHO CAN EDIT ARE HANDPICKED BY ROBLOX?. Seriously, excuse my language, but WTF? Most wikis don't even have a review system, let alone a HANDPICKED staff of writers and editors who are the ONLY ONES who can edit the ONLY main resource for a sandbox game with 3.3 MILLION PLAYERS. Wikis can lock almost every single right of a new users, force registration and IP detection, and, page creation, changes, uploads, almost anything, and if the ROBLOX Wikia can handle it (because we are, Mark and I are admins of the Wikia, which we are also reforming, incase the current wiki just doesn't get updated), then I'm sure the wiki, with BETTER (custom, mind you) configuration, and the ability to also ban users ON ROBLOX, WHICH IS A SERIOUS THREAT TO YOUR AVERAGE 12 YEAR OLD can do the same.
  • Open up the wiki to bots. Mark_Otaris on the ROBLOX Wikia (Who is the owner now), has been running a bot on that website with 70,000+ edits, I think? It's fixed a lot of problems. Why can't the ROBLOX Wiki do the same? Oh, right, because this right here is the first contact we've had with admins for about 1 year+. Oh, and these bots can help manage these 12 year olds who will hopefully be helping the wiki along!
  • Seriously, open up the wiki for petes sake. Promote your fleet of rather inactive editors and writers into higher positions which are "trusted" to be able to, you know, manage 'dem 12 year olds. Maybe we could actually utilize that 3.3 million players that ROBLOX has.
  • Fix the theme. I've switched to Vector theme because it's easier to use, and clean. I'd suggest (but not exactly think it's a priority) for you to switch too. This can help with load time, and make it look more professional.
  • Seriously! Open up the wiki! The ROBLOX wiki is so out of date, so bad, because it's not doing what a wiki was designed for!, collaborate EDITING. Come on! The ROBLOX wiki is like a dead fish flopping around in an empty barrel. All you need is those millions of ROBLOX players to just jump in and give it some much needed water.
  • Pay more attention to the wiki! The ROBLOX Wikia staff gets back to us faster than you guys have. That is, 1 day vs. 3 years. ...

/end 50th rant about wiki's problems Thanks... - Quenty (talk • December 17)

Vector theme doesn't work for me, and gives super tiny text - is that MediaWiki:Common.css interfering?
11:48, 23 December 2013 (UTC)
Yes, it is a problem caused by MediaWiki:Common.css's first 5 lines, which should definitely be removed. I have created a fix that makes the Vector theme work perfectly; it basically consists of switching to the Vector skin, blocking MediaWiki:Common.css and creating a user stylesheet that contains everything except its first 5 lines. It's not a very elegant way to do it, but there is no way to do it better without being able to modify MediaWiki:Common.css and it works perfectly.
I strongly recommend we remove those problematic rules from MediaWiki:Common.css and change $wgDefaultSkin to vector in LocalSettings.php. Running this code would also be necessary to ensure all users switch to the new default theme: php userOptions.php skin --old "monobook" --new "vector". Note that userOptions.php is a maintenance script and this command should be run in the maintenance folder of the MediaWiki installation.
The wiki will look immensely better and more professional (see screenshot). The Vector skin is the default MediaWiki skin and has been for a while, and it's used on all the Wikimedia projects. It is a lot more accessible, usable and pretty than the other skins and it is the only skin on which MediaWiki upgrades and extensions are tested. Monobook is ugly and hard to use and there is no reason to not switch. --Mark Otaris (talk) 03:25, 26 December 2013 (UTC)

Permissions[edit]

Am I meant to be able to do this..? http://i.imgur.com/LYmDN3C.png
Trappingnoobs   (Writer, Editor, Reviewer)    Like something I did? Dislike something I did? Tell me on my talk page17:24, 11 July 2013 (UTC)
Talking about the bottom-right of the image btw
Trappingnoobs   (Writer, Editor, Reviewer)    Like something I did? Dislike something I did? Tell me on my talk page17:24, 11 July 2013 (UTC)
Yes, you are able too. (See my rights log for a previous test of mine.) User:Tomtomn00/Signature

Enum Documentation[edit]

We have a whole section of the site devoted to classes, but enums are a big part of the API as well. How should I go about documenting the enums in Roblox?
Posted by blocco (talk) on Jul 10, 2013 (Wednesday) at 12:42 (UTC) [Discuss format]
Well, we've got a list of enums at Category:Enums, so maybe we can compile them into some sort of table on the Enumeration page giving a short description. Do you think it would be worth while to create a reference page solely for enums? --Gordonrox24 | Talk 21:28, 27 July 2013 (UTC)
I believe that it would be very worthwhile to create a reference page just for enums, since many properties and methods rely on them.
Posted by blocco (talk) on Jul 27, 2013 (Saturday) at 22:25 (UTC) [Discuss format]

Object wiki pages will be embedded in Studio (Fall 2013)[edit]

The Lua Objects Library on the wiki is great. It's good documentation of all the objects, properties, methods etc in ROBLOX Lua. The Studio devs are getting ready to publish Studio with the Lua reference library built in. What Studio does is show each object's wiki page in a pane when you click the object. The pane is close-able for those who don't want to see it. Example: when someone clicks on Backpack in the Basic objects, it will show the content on the RBX.lua.Backpack_(Object) page. Additionally, when you click on its properties in the Property pane it will show the page for that property from the wiki. There will be many more readers of the Wiki content than before, so we should make sure it's up to date and as useful as possible. Here's what we need to do:

  • Make sure each Object in the library has a description on the Info tab explaining what the object is for and its common uses. The Part page is an excellent example of what we're looking for, though short descriptions are also ok.
  • Add examples to each object, property or method. Each one should have a brief code-use example such as on Anchored_(Property), and studio image example if applicable.
  • We have a fair number of tutorials about objects (like How_to_use_a_SelectionBox) but there aren't links from the Object to the Tutorial (no link from SelectionBox). If a tutorial exists about the Object we should link to it from that Object info page.
  • Hold on embedding videos for now, as we may be changing video plugins. You can link to video tutorials explaining how to use specific objects.

That's it for now. I will be adding more guidelines as this project goes along. --Reesemcblox 21:46, 12 September 2013 (UTC)

What is the current structure of our templates?[edit]

A lot of the API-related articles are very template very. Are these being auto-generated from API.txt? I'm not super familiar with how wiki templates work and an overview of how things have been structured here would be helpful. For instance, how do I add a new article to document the upcoming HttpService? Telamon 19:00, 22 November 2013 (UTC)

The current state is, well, bad. There's a few pages you need to know about, API:Instance, which is the page name format we want to eventually switch to, though for now most are under the name RBX.lua.Instance (Object). The members on this page are automatically listed according to what's on the Object:Instance subpages. Specifically Object:Instance/properties, Object:Instance/events, Object:Instance/methods, and Object:Instance/superclass. When you edit those pages you'll see that we also use a template for each member except for the superclass page. So, to document a new class, a writer has to create about 5 pages manually (nothing currently automates documenting stuff) and then one for each of the class's unique members. The members under the new format (provided we actually go with it) would be at API:Instance/MemberName where currently we currently use something like MemberName (Method/Event/Property). The end result is, to me at least, is a mess and incredibly slow.
So that's the basic rundown of what I understand of the system. Legend26 (talk | contribs) 19:19, 22 November 2013 (UTC)