Roblox Wiki:General discussion

Welcome! This is a general board for ROBLOX Wiki related discussion.
An archive of past discussion is available for the years 2012, 2013 and 2014 (see these links for the archives). Note to archivers: Do not archive discussions only for being old or inactive. Only discussions that are no longer relevant should be archived.
Please put newer discussions at the end of the page, not at the start.

Unfortunately, if you are not a wiki writer or editor, you can not contribute. This is due to the fact this page is for the discussion and organization of the ROBLOX wiki staff. However, you can discuss any such items on the official ROBLOX wiki group wall! Access[edit]

Hio. If you are an active contributor to this wiki, and you do not have forum access, please post your ROBLOX username here and I will email you an invite (make sure the email address on your account is current plox). A lot of partial documentation for upcoming features is being posted there, and there is also a healthy discussion about the future of the wiki. Telamon 23:43, 21 November 2013 (UTC)

My username is 'Quorum'. Thank you? -- Quorum 06:22, 22 November 2013 (UTC)
My username is woot3, and the email to send it off to is [Removed Content], thanks -- woot3 15:56, 22 November 2013 (GMT)

Ok, cool. Check your email, should be from RBXDev. The main wiki discussion seems to be centered around this thread Telamon 18:58, 22 November 2013 (UTC)

My username is MemoryAddress. Thanks? -- Memory Address 23:55, 9 December 2013 (UTC)
My username is Articulating, if you are still providing access. Thanks, Articulating 15:03, 22 January 2014 (UTC)

Merging Data Persistence Tutorials[edit]

We have FIVE data persistence related articles (this, this, this, this, and this). We really need to merge these all together to create a unified experience. I think we should merge everything into a new page called Data Persistence. If I had editor powers then I'd probably do it myself but for the meantime someone else needs to do it. Tenal 15:06, 11 November 2012 (CST)

I completely agree. Here's my breakdown of it:

How To Efficiently Use Data Persistence
Can probably be collapsed down to one small paragraph on how it's stored internally. No need to explain XML here. Perhaps some of it should be moved to DataComplexity
Data persistence
Use this page to house the final content. At present, the only thing wrong with this page is its shortness
Data persistence tutorial
Some useful code examples and explanations. Including all the member boxes is overkill - a simple list is sufficient
Data Persistence Complete Guide
This seems to be an exercise in copy and paste. There are essentially only two sections here, each of which is duplicated 4 times
ROBLOX Scripting How To: Data Persistence
Might also be valuable. I'm getting fed up of skimming them by this point.
21:35, 11 November 2012 (UTC)
Jeditkacheff created the last article. Last time I read over it, it seemed to be a pretty decent one. However the point still stands and we can (and need to) merge them all into one article. I'll work on that once I have time. Tenal 13:30, 12 November 2012 (CST)
My suggestion. Data Persistence seems like the obvious best choice for the main page name. We should slowly begin to condense and merge the useful info from all of the other DP tutorials into the central Data Persistence page. We can then leave the pages with high traffic as redirects to the newly created tutorial. This is not an overnight process, merging pages takes a lot of time. I appreciate all of your enthusiasm and hard work.--Gordonrox24 | Talk 19:17, 12 November 2012 (CST)
Not to be too picky, but the title should be Data persistence not Data Persistence
08:13, 13 November 2012 (UTC)
Why? Data Persistence is much more eye-friendly. Anyways, I'm not going to be picky but until I get a good reason why, I'm going to personally use the Data Persistence title. Tenal 20:35, 13 November 2012 (CST)
Primarily, to be compliant with
07:51, 14 November 2012 (UTC)
I also support Data Persistence as the title, as it is the proper name of the API feature - not a common noun. Similar to how the poem "marie rose" is never capitalized. MrNicNac - Senior Wiki Editor
We should create a lot more redirects too, like, if someone wants to be able to save stuff in thier game, they'll probably search "Save game" or "save data" or "save leaderboard" or something. - Quenty (talk • November 15)
Is this still needed? I've got some free time on my hands. Xzerizon 18:09, 13 February 2013 (CST)
Yes it is. We just need to decided on a name. WP:NCCAPS, which NXTBoy suggested is only really a Wikipedia guideline, not a naming policy. I personally like the name Data Persistence, so I' like to go with that. Of course, in the future it would be quite easy to move the page.--Gordonrox24 | Talk 13:32, 15 February 2013 (CST)
Do we still need both Data_persistence_tutorial and ROBLOX_Scripting_How_To:_Data_Persistence? I see how they are different, but can they be combined at all? As a user coming to find reference and instruction, fewer similar articles is better. Don't let the fact that one was written by a dev stop you from combining if it makes sense. --Reesemcblox 23:21, 16 October 2013 (UTC)
If they're not combined by the weekend, I'll put in my time to combine the tutorials into one page. I'd do it sooner but I am super busy with homework for an entrepreneurial class.
- AdarkTheCoder - 10:18, 17 October 2013 (UTC)

How soon is too soon to document a new feature?[edit]

Hey, just a quick question regarding the documentation of upcoming features. Whilst I do realise it's probably an incredibly menial question to be asking, I'm just wondering.

How soon, is too soon, to document a new feature that's coming soon? Whilst ideally it would be better to release the documentation after the feature has been fully released, wouldn't it be better to release documentation for that feature before that time (obviously with some sort of note stating it's not released) so that players can get the most up to date information ahead of time, so that they can fully utilise it when it's "dropped"? -- Quorum 23:59, 22 November 2013 (UTC)

Please do start writing documentation before the feature comes out. A good message to put at the top is something like "This feature is not yet released and does not have a specific release date. This documentation may change as the feature develops." --Reesemcblox 19:23, 4 December 2013 (UTC)

Tutorial prerequisites[edit]

A lot of tutorials share some low level introductions to events etc. Would it seem reasonable to remove these explanation in favor of a list of prerequisites, such as "basic scripting", "events", "anonymous functions", "tables", "string functions", "string patterns"...
NXTBoy (talk • contribs)
11:43, 23 December 2013 (UTC)

New Wiki sandbox[edit]

Hi all. I wanted to let you know that the sandbox for the new wiki is up and running. Please keep in mind this is a test site and a work in progress, so several things are bound to be wonky. Also note that all the articles are just placeholders and are not indicative of what will be live on production when we move it over. Account creation on the sandbox will open very soon so you can play around.

Will everyone be able to edit it or just current wiki writer/editors? itunes89 - ( 03:24, 20 March 2014 (UTC) )
I personally think it looks nice, though I'm sure some will be displeased with the "rapid change" in the overall change in style of the Wiki. The main thing, that people will likely complain about when this is released, is how white it is. -- Quorum (Talk) 05:12, 20 March 2014 (UTC)
Are articles being transferred across, or are we starting afresh? Looks really nice, although it would be nice to have the current "tools" sidebar links visible somewhere in the new design (the footer might not be too bad a place?). Also, the version page doesn't seem to be listing extensions - is this intentional (and if so, why?)
08:35, 21 March 2014 (UTC)
Also this is a really quite scary way to parse XML, although I like the idea of getting lua to format xml data.
08:40, 21 March 2014 (UTC)
I don't disagree with you; I'm certainly open to a better way of parsing the XML, or an alternate approach altogether. As for the sidebar, we're trying to keep the interface as minimal as possible. Which tools do you find most useful? Lsparks (talk) 22:48, 2 April 2014 (UTC)
I'd probably go for finding a lua XML parser online, and just including that. Pages that are useful are [[Special:WhatLinksHere/{currentpage}]], [[Special:RecentChangesLinked/{currentpage}]], Special:SpecialPages,[[Special:Contributions/{currentuser}]]. Really, you should just show all of them, because they're context sensitive. They could be under a dropdown or something though, if you don't want to use up space with them.
10:34, 8 April 2014 (UTC)
Okay, I have four problems with the main page after I looked at it some more.
  • One sample article (or at least a filler) is showing its title as "LUA 101", can this be changed to "Lua 101" if it's going to be there when this is released?
  • On the "Advanced Lesson" section the first letter of every word is capitalised for all of the titles, apart from "Advanced GUI making" this should be changed in my opinion.
  • The hyperlinked text under "Build Places Like a Pro" is impossible to read with the given background image. The default colour for it should perhaps be changed.
  • The description for "LUA 101" doesn't seem to make sense - "All the basics you need to learn, speak and understand the language of ROBLOX!"
Those are my only issues with the main page of the new Wiki design. -- Quorum (Talk) 11:02, 22 March 2014 (UTC)
Expect all of those to change. Those articles are simply placeholders that were from a website mockup that a fellow on our webteam made a while ago. Lsparks (talk) 22:48, 2 April 2014 (UTC)

Top level heading too small for xblock wiki style[edit]

The page title heading shows up smaller than the following h2s! This can be a little confusing. This effect is due to this piece of CSS:

#firstHeading {
    font-size: 1.6em;

Overriding this:

h1, .h1 {
    font-size: 39px;
Can I suggest the xblock style is modified to allow the 39px style to be applied?
NXTBoy (talk • contribs)
10:30, 3 June 2014 (UTC)

This page is no longer accessible from any links[edit]

Could a link to this page be added to the header or footer? I'm not sure if it makes sense to put it in the tools menu, but that would be better than having to search for it each time.
NXTBoy (talk • contribs)
12:37, 3 June 2014 (UTC)
I have asked the same question on the wiki’s wall, without having seen this message. I use the Vector skin, so this isn’t a problem for me, but this page (and the entire navigation menu, actually, which is there for a reason) should be accessible easily with the new skin. --Mark Otaris (talk) 01:38, 16 July 2014 (UTC)

Documenting similar properties in different classes[edit]

What should be done about:

We'd probably want a little more description for the ConstrainedValue objects (re behaviour of event when setting outside range), but other than that I see no reason that these pages won't all be essentially identical. Is there any way to prevent manual duplication (which falls apart if any one page is edited in future) here?

Something to consider is whether Module:API is able to extract member descriptions if there's a layer of indirection

NXTBoy (talk • contribs)
12:46, 3 June 2014 (UTC)
Looking at those pages currently, they all say "The below example, assuming all referenced objects existed". Is that sensible, or should we actually create the objects in the code so they work as standalone examples?
12:49, 3 June 2014 (UTC)
I don't believe we should, personally. The Wiki, in my eyes, is simply meant to be a reference showing the functionality of each member(/how to use it). It's not going to hurt someone if they have to insert a basic object such as a BoolValue. -- Quorum (Talk) 15:29, 3 June 2014 (UTC)
The issue is that these examples are weak. They should be unique examples that work specifically with the given value type. e.g. The Color3Value example should answer the question, "When would I ever want to use a Color3Value?"
Also, if you have to state that "this assumes that all references exist", then you should just create them in the example instead. It's an unnecessary detail that only causes distraction. --Anaminus 19:51, 3 June 2014 (UTC)
Agree with the doing things in code rather than explaining why you haven't done them thing.
Shouldn't the answer to "When would I ever want to use a Color3Value" go on API:Class/Color3Value rather than API:Class/Color3Value/Changed?
20:49, 3 June 2014 (UTC)
That was an example. An equally valid question would be "When would I ever want to use a Color3Value.Changed?". The idea is to make the examples diverse and interesting. --Anaminus 21:02, 3 June 2014 (UTC)

Should property pages have examples if they just duplicate the example for the instance?[edit]

What examples should go on these three pages?

It seems silly to give an incomplete example on the property pages when the two members make the most sense to use together.

Should there be a standard way of referring back to the main class page to see the example? (And should this appear automatically in the absence of a specific example?)

NXTBoy (talk • contribs)
14:26, 3 June 2014 (UTC)
Preload can be used without checking RequestQueueSize if, say, you don't need to wait for assets to load. Likewise, RequestQueueSize can be used, for example, after setting Sound.SoundId to wait for the sound to load. When a property has a practical alternative use, that makes just as good example material as the property's "intended" use. --Anaminus 19:29, 3 June 2014 (UTC)
Those are both good points for why those pages should have examples. However, you still have the question of whether to show the intended application on the individual property pages. If you do, then you're repeating yourself, and if you don't, then the reader might conclude the alternative usage _is_ the intended usage.
20:09, 3 June 2014 (UTC)
I think that, as long as the intended usage is in close proximity (property page -> class page), then it's fine. If the property was already used in an example on the class page, showing it's intended use, then an example showing an alternative use on the property's page is acceptable. --Anaminus 21:03, 3 June 2014 (UTC)

Break out page actions into a second navbar[edit]

It's annoying having to navigate a dropdown menu to get to an edit or talk link. Can we break out the page actions from the tools menu like this?

This was done by duplicating the primary navbar, moving the relevant li tags from the dropdown to the top level ul, replacing the "selected" class with the "active" class, and applying this small amount of CSS:

.secondary-nav .navbar-nav li a {
    height: 30px;
    line-height: 30px;
    font-size: 0.75em;
.secondary-nav {
    margin-top:  -22px;
    background:  #f8f8f8;
NXTBoy (talk • contribs)
16:09, 3 June 2014 (UTC)

Issue tracker[edit]

I've just added the IssueTracker plugin to the Wiki (with a few small modifications). I intend for this to be a global todo list for all things Wiki. The intention is have a very direct way of requesting features and reporting bugs regarding the wiki so that I can handle it on the backend, as well as tasks you feel other writers can handle and you want to distribute the work. I'm currently leaving it fairly open in terms of adding and resolving tasks to keep it easy to use. One general rule though, you are not allowed to close your own task. When a task is done, resolve it and another writer/editor will check to see if it is resolved. If it is not resolved, reopen the issue and make sure to put notes in the description as to what needs improvement. — Preceding unsigned comment added by Lsparks (talkcontribs)

Well, I have to say that the issue tracker isn’t too great. I don’t think it is usable in its current state. There are major problems:
  • Wikimarkup isn’t supported (that by itself should almost be a reason not to use it).
  • Issues cannot be described (what’s the point of a issue tracker where you can’t describe issues?), except in a very short non-multiline summary field and in a title, which is insufficient.
  • It is impossible to comment on issues (this should be a sufficient reason to not use it; it is essential, if we want to fix the issues, to be able to track the progress we do, to give more information, and to comment on the issues).
  • There is no way to leave edit summaries for changes made to issues, or when submitting an issue (change histories are incredibly useful and I am truly annoyed every time I must make a change on a wiki and cannot provide an edit summary, but we could regardless do without them, so this problem isn’t as important as the others).
  • There is no history or log of the changes done to issues (this is almost as important as the inability to comment—if we can’t have a history or a log of the changes, or at least of issue creation, that means that we cannot see the creation of new issues on the recent changes page, that we cannot have edit histories, that we cannot revert changes, that we cannot see the edits done to issues, that we cannot… well, histories are just so useful that we can’t really do much without them at all).

In truth, I don’t think we should use this issue tracker. This page (Roblox Wiki:General discussion) allows us to comment on issues, to use wikimarkup (meaning links to both, which are essential, and to wiki pages, which are also essential) in both replies and original descriptions (descriptions, not summaries!), to have descriptions of any length (versus a very small summary field with the issue tracker with no wikimarkup support, that collapses multiple paragraphs into huge chunks of text and with no way at all to comment on issues), to have an history of the changes done to the page and to see on the recent changes page when someone has added a thread or replied to one.

Talk pages aren’t ideal for discussion or tracking issues, but they’re largely superior to this very limited issue tracker. If we need to make talk pages easier to use, we should use LiquidThreads, or the more recent Flow. These give us all the flexibility of talk pages while making them easier to use. I don’t think they’re really needed, but I think they would be significantly better than this issue tracker, which by the way has been unmaintained for six years (the original SVN repository is dead, so I wonder where you even got the code from, unless it’s from that GitHub fork someone created).

This issue tracker could be useful for tracking todo entries for individual articles, but I don’t think it’s worth keeping the extension only for that when a simple bulleted list can suffice (and allows replies, which can be useful even on simple todo lists). Sorry for the very negative feedback: I just don’t think using this issue tracker is a good idea. --Mark Otaris (talk) 02:27, 16 July 2014 (UTC)

Additionally, is there any reason we shouldn’t just use Special:IssueTracker instead of creating a dedicated page for it? --Mark Otaris (talk) 02:33, 16 July 2014 (UTC)
In regards to the bullets you listed:
  • I agree, we should be able to put Wikitext in the title and description, I can look at modifying the extension.
  • I'm not sure how a text field doesn't give you sufficient space to describe an issue. If you are writing enough where you need more space, why not just work on the bug or feature yourself?
  • Might be nice to add separate field for resolution notes, in the meantime they could just be added to the description.
  • I'm not so certain that an issue history is very important here. A bug report is not a living document like a wiki page is. If a bug needs to change dramatically or if new action is needed, adding a new ticket is preferable. Adding a history would I think just complicate the matter.

A big reason I do not want to have such a list on this page is that quite frankly this page is difficult to parse. There is a reason bug trackers are not in a text document (even a document where you can see a changelog). I actually did not know the extension added Special:IssueTracker though, that would probably be a better page to use (will add a redirect in a bit). Lsparks (talk) 16:33, 16 July 2014 (UTC)

WARNING: Deleting old api pages.[edit]

I'm feeling confident with the new API pages and I plan on deleting the old pages to tidy up the wiki. The searches are currently flooded with results (both the in-wiki search and google) and it really needs to be cleaner. I am running one more test to see if redirects will help, but I am not optimistic.

I understand the concern about deleting pages is that some external sites that link to the wiki could get broken links. I will go over the wiki's analytics to see if I see any pages in particular that we may want to avoid deleting, but in general I don't think this case is significant enough to concern ourselves with. If you feel otherwise please speak up here (particularly if you have alternate solutions). I'll probably start in a few days but I wanted to give you time to chime in. Lsparks (talk) 19:23, 29 September 2014 (UTC)

Scribuntu is out of date[edit]

mw.logObject and friends are missing from the API, due to having the old version. Could it be updated?
NXTBoy (talk • contribs)
11:14, 18 April 2015 (UTC)

MediaWiki and Scribunto upgrade[edit]

With the release of MediaWiki 1.23 in June 2014, MediaWiki 1.21, which this wiki still uses, has reached the end of its support lifetime. Vulnerabilities have started to creep in (see the cool XSS flaw I found), and the wiki is behind as far as features are concerned. In particular, the old Scribunto version that this wiki uses does not have the mw.html library, which is the successor to the now-obsolete HtmlBuilder module and a proper way to create HTML elements, handle their CSS properties and give them attributes and classes. This library is less error-prone than manually generating the HTML and allows code to be cleaner (for an example of its use, see the table of contents module I created for my book in February 2014). It's much cleaner than handling the HTML manually, since it works with objects: you can create an object for a div element and add CSS to it with methods without ever worrying about spacing, when to close tags, etc. It makes code easier to follow, which is very important because the current API modules are hard to maintain (at least, I have a lot of difficulty finding my way around the code; I'd be very glad if someone could write a page to describe where each thing is done in the current system).

There are also many other improvements in Scribunto. The tools for debugging modules are much better (take for example the mw.logObject method which NXTBoy mentioned just above, which produces a human-readable representation of an object).

I think a MediaWiki and Scribunto upgrade is well past overdue. — Mark Otaris (talk) 04:18, 1 June 2015 (UTC)

Being able to kill Module:mw-patch/text would be nice too
06:19, 1 June 2015 (UTC)
Re "I'd be very glad if someone could write a page to describe where each thing is done in the current system" - I'm working on breaking the system up into more elementary modules - currently we have Module:roblox types and Module:template parser
06:22, 1 June 2015 (UTC)

The vector skin[edit]

This went from working to totally broken a few months ago. Why?
NXTBoy (talk • contribs)
07:27, 22 December 2015 (UTC)
It broke due to the MediaWiki upgrade about a month ago. XBlock was broken as well for a bit, but got fixed - seems Vector hasn't been fixed. Memory Address (talk) 18:04, 23 December 2015 (UTC)

Special pages are broken[edit]

See Special:SpecialPages for a PHP error. This is extremely bad, and makes a bunch of wiki tools a lot harder to use.
NXTBoy (talk • contribs)
21:10, 26 December 2015 (UTC)

Math equations?[edit]

Sorry if this is the wrong place to ask this, but I wasn't entirely sure where to put this otherwise.

I was wondering if it's possible to integrate something like MathJax into the wiki. Whenever I create or edit articles I have to type up all the equations in word and take pictures of them. This is an annoyance in itself, but the real problem is that sometimes I need to take pictures of text too because often the math is embedded mid sentence. For example, implying a value is a vector as opposed to a scalar via the arrow above. This makes it very difficult to go back and edit those parts of the article because they're images, not text.

I think this would greatly help when writing some of the more mathematical based articles for both the person who initially wrote it and also anyone editing it in the future.

EgoMoose (talk) 15:46, 11 April 2016 (UTC) is what you actually want. This is pretty common mediawiki functionality.
16:37, 11 April 2016 (UTC)
Did this not work for you?
16:39, 11 April 2016 (UTC)
I was asked by MemoryAddress to not use latex equations that are hosted elsewhere because if the website providing them went down the equations would not load. That makes total sense to me. I stopped using them in new articles and have been slowly trying to replace latex equations in articles I previously wrote.
As long as you set the alt text to be the latex code, the meaning behind the image is still sort of readable if the site goes down. A template {{math}} that inserted this image with the right alt text would probably be sensible. Since when did wikis allow inclusion of external images though? Do we have an extension for that?
18:01, 11 April 2016 (UTC)

What's the policy on user page content linked around the wiki?[edit]

I have a fair amount of content on my user page that I put there because I find the extra hoops I have to jump through for normal articles a waste of time. My main question is am I allowed to link them as further reading on other pages? I'm very aware this defeats the purpose of having articles checked by editors and images uploaded to the wiki. However, I would argue that we already do this in some sense when we link offsite for things like github, etc. Thoughts and or statements?

EgoMoose (talk) 21:23, 12 January 2017 (UTC)