Forum:Unreleased content spoilers

From the RuneScape Wiki, the wiki for all things RuneScape
Jump to: navigation, search
Forums: Yew Grove > Unreleased content spoilers

Hola. I am back with another juicy thread and this time it's about 🌟 spoilers 🌟. The game update today was a particularly interesting one in that Jagex decided to include content for future weeks of a time-gated event in the game cache, which includes NPC models and more that are spoilers for upcoming content, and spoilers for the future of the Elder Gods storyline. As with all future content that we find in the game cache, we create wiki pages and upload images for what we find. Sometimes, Jagex might ask us not to do this if there's good reason - for example, we were asked not to shout about the Davendale update as they were A/B testing the tutorial - but most of the time they don't and we just cover whatever we happen to stumble across.

Our spoiler policy is clear: spoilers are permitted on the RuneScape Wiki. We've come to the conclusion based on numerous threads that spoilers for released content, including quests and storylines that a player reading the wiki may not have played yet, do not need to be tagged or hidden separately on the wiki. However, this policy does not take into account our ability in recent years to see future content in the game cache and cover it appropriately on the wiki.

The argument is that we should cover the datamined stuff, but we should also be careful not to do it in a way that’ll spoil it for people who actually care about the story
— Me, today

What I hope to achieve with this thread is two things:

  1. Establish a better spoiler policy for unreleased content, which our future content policy does not cover
  2. Establish a way of distinguishing spoilers on the wiki

1. Spoiler policy[edit source]

I think that when covering future content on the wiki (AKA content that exists in the game cache) which may be related to upcoming quests or storylines, we should warn the reader that they're stumbling onto spoilers. This will be important especially if there's content related to upcoming quests that may spoil the story or outcome of said quests. For example, a new "dead" model of an NPC in the cache with no way to currently see that model in-game is probably indicative of that NPC dying at some point in an upcoming storyline or quest.

To be clear, this is an addition to the current policy we have. We're still not going to care about spoilers for content that is in-game, otherwise the entire wiki would be a spoiler. I'm also not interested in marking upcoming content that is not a story spoiler. For example, if we find a new item in the cache that is clearly unrelated to any quest or storyline, then we don't need to do anything other than adding {{Cache}} to the top of the page like we currently do.

I would like to update the spoiler policy to the following (suggestions welcome):

Due to the encyclopaedic nature of the RuneScape Wiki, it contains information that spoils storylines in the game. Above all else, the wiki strives to provide the most accurate, comprehensive and relevant information that it can about RuneScape. We do not censor details or provide warnings for quests or content that has been released in-game.

For content that has not yet been released in-game, such as content that is only available in the game cache, which may spoil upcoming quests or storylines, we should mark them appropriately and warn readers beforehand [using whatever templates and such we decide below].

For previous discussions about the presence of spoilers, see Forum:Spoiler Policy, Forum:When and where should we use spoilers, Forum:Spoilers, Forum:Return of the Spoilers, and Forum:Unreleased content spoilers.

We can add another sentence or two stating what templates to use for marking future content spoilers based on the outcome of #2 in this thread.

Discussion[edit source]

Support - It's my proposal jayden 20:49, 24 May 2021 (UTC)

Support - We need clarification and direction on these sort of things, even if they're not commonplace. --Legaia2Pla · ʟ · 21:10, 24 May 2021 (UTC)

Comment - What is the benefit of covering this kind of information at all? In relation to the specific spoilers that prompted this thread, they are primarily from something that the wiki has never previously comprehensively documented in the first place, let alone pre-release. Were it just items or NPCs I don't think I'd mind so much. But this just feels like being a dick for no real reason, both to the developers and members of the community who'd rather not see it. Adventurer's log Wahisietel (Talk) Quest map icon.png 21:59, 24 May 2021 (UTC)

Support - Meeeeerds msg 23:15, 24 May 2021 (UTC)

Support - Yes please, I want to actually enjoy this game Superiosity the WikianQuick chat button.png : Yo 23:22, 24 May 2021 (UTC)

Support - I might want to at least add something more directly touching on future spoilers personally but I'm fine with this for now. Achievements Coelacanth0794 Talk Contribs 23:42, 24 May 2021 (UTC)

Support - I know I'm in the minority when it comes to not caring about lore, especially among wiki people, but I feel like this is extremely important for those that do care. Badassiel 02:24, 25 May 2021 (UTC)

Comment - It's unclear to me why there's a burning desire to immediately upload unreleased content mined from the cache prior to release. While the relationship with RS3 devs is not as close as OSRS, there are multiple times that we've been given early access to data and been asked not to publish it until release or just before the release to avoid spoilers. As the cache mining tools are currently restricted to a small set of users, why follow the example on OSRS and store the media and content ahead of time, uploading it when the content is released?

It strikes me that we have RS:NOT#CRYSTAL for covering unreleased content and the proposed policy changes partially conflict with it. While RS:NOT#CRYSTAL is aimed at preventing speculation and wild theories, until the content is turned on in the game, what has been found in the cache here is technically unreleased and potentially subject to change. cqm talk 06:16, 25 May 2021 (UTC)

There is also RS:FUTURE which I had forgotten about and also contradicts the proposed changed. While consensus overrides existing policies, it seems that the issue at hand is already covered by the existing unreleased-related templates. Ultimately, the cache cannot be sourced and thus is not considered a viable source of future updates. cqm talk 06:33, 25 May 2021 (UTC)
I've mentioned RS:FUTURE briefly in the OP, but this policy change doesn't contradict the existing policy. RS:FUTURE says:
All articles or sections about unreleased content should be marked as such. In most cases, articles will be entirely about future content, in which case {{Future}} should be added to the top of the article. Sometimes, only certain parts of the article are about unreleased content, in which case tagging a section rather than the whole article may be appropriate. Whatever the case, this information should be cited.
But the issue I'm raising in this thread is not about unreleased content in general - such as upcoming Treasure Hunter items, or new skill items, or something like that. I'm concerned with how we handle, specifically, quest and story-based spoilers that arise out of upcoming content. It appears to me that a lot of people care about being spoiled for an upcoming storyline, such as Battle of the Monolith (miniquest), and that's why I've proposed what I think is a range of viable solutions to try and allow us to continue covering this content on the wiki, while also making it harder for people to accidentally spoil themselves. jayden 11:34, 25 May 2021 (UTC)
While the sources may need updating to include the cache based on what was being taken from it until this week, I would argue that the uploads that triggered this discussion are materially different to the information allowed per the future updates policy. Items from a reliable source (the cache) sure - it's hard to draw many conclusions from an item name. Cutscenes and dialogue are not even close to those. cqm talk 11:55, 25 May 2021 (UTC)
I would argue that the cache is an integral part of the game; although unreleased, we should also document what is/was in the cache (if possible). Nayfaan (talk) 09:05, 31 May 2021 (UTC)

Comment - On a related, but separate note, it's also clear that RS:NOT#CRYSTAL and RS:FUTURE needs to be updated in general for all types of future content, as we've been using the game cache (rather than the sources listed on those policies, like the official website) for creating future content articles, and there's definitely been a few times that we've speculated on what something will be used for based off of its cache information, like an item that is part of a quest. jayden 11:37, 25 May 2021 (UTC)

Speculating based on cache content would seem to fly in the face of not having speculation in articles per the policies you linked, no? It seems like because admins are pulling this data out if the cache, we hold it to lesser standards. cqm talk 11:55, 25 May 2021 (UTC)

Support - I'm not one for lore myself, but I agree that this is a Runescape encyclopedia and so should contain as much accurate information as possible, even if spoilers are included. Lava hawk.png BlackHawk (Talk)    16:29, 28 May 2021 (UTC)

Support - I agree anything and everything about the game should have its place on this encyclopedic wiki. Even though, from the above discussion, some of us might not find that important / as needed information, but I would argue that this point of view can be true for any other piece of information on this wiki. someone being not interested in said content does not mean no one will be interested in it. Even if no one is, I believe a wiki should serve its purpose of documenting said information (e.g. I for one am interested in the data-mined spoilers and opted to read through it on the wiki). But I also understand that people dont want to get spoiled; I agree that spoilers should be marked clearly. I suggest that we include in the guideline that such spoilers should be provided in a way that it 1. is not visible upon entering related pages, but must require user interaction (e.g. a click) to make said content visible. 2. displays a spoiler warning in a clearly visible position that informs the user that accessing said content through above action will spoil the story and is at their own discern. Also, we might need to draw a line between this kind of spoiler and other kinds of spoilers? Nayfaan (talk) 09:05, 31 May 2021 (UTC)

Support - Archaeology was blown open in the first day of release due to the cache spoilers, stuff like the Ancient Perks, etc. The Wiki should document everything that is found in the game on update.

Additionally, how do you define what is a spoiler? Is it a Jagex set guideline or is it Wiki driven? (I'd hope Wiki) Talk to me ShaunyMy contributions 23:56, 31 May 2021 (UTC)

2. Distinguishing spoilers[edit source]

The game update today has proved that we need some way of warning users that they're about to read something that is a future content spoiler. As a temporary solution, we created a simple banner to indicate this at {{Spoiler}}, which looks like this:

Stop hand nuvola red.svg Spoilers ahead! This section contains spoilers for upcoming content based on the game's cache files. Continue at your own risk.

However, I feel like this doesn't do as much as we'd like to help the reader. Even if we have this warning at the top of a section on a page, it's quite possible for the reader to have already read/seen the spoilery text/images underneath the banner. With this in mind, I'd like to offer a few solutions, which we can either adopt in part, in full, or not at all, to help keep this content hidden for those who don't want to see it but also allow the more inquisitive readers of the wiki to reveal it. These are not mutually exclusive suggestions:

  1. Add a big red banner before future content spoilers. We're already doing this with {{Spoiler}} (above) as of today, but this could change subject to the outcome of this thread.
  2. Add a template which would allow sections of text to be blurred out until clicked.
    Demo: User:JaydenKieran/Sandbox
  3. Support adding a "spoiler" class to <gallery> tags which would blur out all of the images in the gallery until clicked.
    Demo: User:JaydenKieran/Sandbox (warning: the images on this page are actual future content spoilers - beware)
  4. Like #3, but with individual images embedded using [[File:Image.png]].
  5. Create a new wiki-wide feature which would detect files with filenames that contain "SPOILER" and blur them out across the wiki, wherever they're embedded (including special pages), until clicked.
  6. Add a styled version of {{Hidden}} to clearly indicate future content spoilers, which editors can put text/images/whatever they want in, and readers can click to expand.

Discussion[edit source]

Support 2, 3, 4 - I think these would handle all of the cases we could possibly have where we might want to hide a spoiler. jayden 20:49, 24 May 2021 (UTC)

Oppose, propose alternative - I think we should just make this simple and straightforward. We should have a separate page, similar to how we handle Upcoming content for all spoilable content that hasn't been announced or released like we're discussing here. This could be something like Unannounced content, Datamined content, or even RS:Spoilers. The naming of the exact page is not too important for me, but the usability is. If we keep this sort of information off the main page(s) that it relates to we're able to both save people from having something spoiled, and allow folks to go to one place for spoilers if they wish. Having it on the same page(s) gives too much opportunity for folks to have their content spoiled, either by editing or the accidental clicking of a template/function that is meant to hide the content. --Legaia2Pla · ʟ · 21:10, 24 May 2021 (UTC)

Oppose Legaia2Pla's alternative - I think that if the spoiler content is related to a certain page, it should be on the same page. Although it is unreleased in game, I'd argue it's official content that have been put into the cache by Jagex; said spoiler would be related to the page it belongs to. Nayfaan (talk) 09:26, 31 May 2021 (UTC)

Comment - Spoiler warnings are worthless because people just go and regurgitate them elsewhere elsewhere without them. Adventurer's log Wahisietel (Talk) Quest map icon.png 21:59, 24 May 2021 (UTC)

Comment - As long as they don't regurgitate them on the wiki, I don't think there's anything we can do about that, also I think that's why we are considering 5? Nayfaan (talk) 09:26, 31 May 2021 (UTC)

Support 2, 3 and 4 - I don't really care about spoilers myself, but despite the fact that people can just grab the images and post them elsewhere, I like to feel like "I did what I could" and having these instances marked as spoilers feels like as much as we can do to help the situation so I'm on board. Meeeeerds msg 23:14, 24 May 2021 (UTC)

Support 1, 2, 3, 4 - Theyre not the most ideal (if implemented perfectly I would like #5 but its probably too much of a hassle in practice) but tbh I don't have any better ideas Superiosity the WikianQuick chat button.png : Yo 23:25, 24 May 2021 (UTC)

Comment - Also, correct me if I'm wrong, but it seems none the proposed solutions work on mobile (or at least on my Android running Chrome). If the spoiler tags are implemented but dont work on mobile then this would be a problem for me and probably for other who care spoilers too. Superiosity the WikianQuick chat button.png : Yo 23:37, 24 May 2021 (UTC)
See my comment to coel about #5 below. Habblet (talk|c) 23:49, 24 May 2021 (UTC)
Fair enough, I'll throw in a soft support for 5 as well. Superiosity the WikianQuick chat button.png : Yo 01:10, 25 May 2021 (UTC)
FYI - none of the mockups I did are working on mobile because I didn't spend time to get them working on mobile, but it wouldn't be a difficult job and would work the same as desktop. :) jayden 00:03, 25 May 2021 (UTC)
Ah ok, that's all good then. I retain my support. Superiosity the WikianQuick chat button.png : Yo 01:08, 25 May 2021 (UTC)

Comment pending support - I'm currently looking very closely at #5 as a way to stop spoilers for stuff from the special pages such as NewFiles or NewPages as I image it is where a lot of people would go to see the newest changes in the game in a condensed form (or at least, I do, which is why I write this). To go to NewFiles and be swiftly, immediately spoiled on the morning (or let's be honest, afternoon, I get up late) on a content update based on story and lore is a bit of a kicker. It also working (hopefully) with RecentChanges and perhaps Watchlist as well would probably be a good addition, too. Are these possible first and foremost, and would it be for image and subsequent text or available to other things like article names or audio files as well? Achievements Coelacanth0794 Talk Contribs 23:42, 24 May 2021 (UTC)

5 is doable (I have copied the spoiler gallery css for the NewFiles page), we'd just need to set up a bot that removes SPOILER from the filename and fixes all links, which I think should be achievable as well, and it's something we wouldn't have to do often. Habblet (talk|c) 23:49, 24 May 2021 (UTC)
If that's the case and it's hopefully not too difficult to implement I'd Strongly Support 5 and Support 2, 3, and 4. Basically just covering all the places people who use the wiki in different ways would potentially spoil themselves. Achievements Coelacanth0794 Talk Contribs 00:02, 25 May 2021 (UTC)

Support 1-5, and Legaia's idea - If for some reason the current proposal doesn't pass as is, I'm also content with what Legaia is suggesting. Badassiel 02:36, 25 May 2021 (UTC)

Comment, somewhat related to Legaia's, Support on Coel's - Other than browsing through recent changes/new pages, which should be mitigated by Coel's comment, how would a user find these pages other than by specifically searching for them/having a portal like "Upcoming changes" that link to them? I imagine most of the stuff that is mined from the caches are more automated, and so should have very little human input on them correct? So regular pages should not have links to them anyway. I.e, cache shows models of A being dead. We should have the Dead_A_Model_image uploaded, but unless it was manually linked to by a human, it wouldn't appear on A 's page. So we can have the image available to be search by people who were spoiled by outside sources, but people just browsing the wiki normally would never see them anyway. Dragon longsword.png Cire04 TalkAttack.png 03:16, 25 May 2021 (UTC)

Support I want that we *do* upload these things but spoiler them - so that would be 2,3,4,5, whichever of them turn out to be feasible/"nice" to implement. Mejrs (talk) 10:34, 25 May 2021 (UTC)

propose alternative How about having a gadget that hides/shows tags such as Spoilers and Cache? Habibi (talk)

Support 5, propose alternative - Move explicit spoiler content out of the main page and include it in a subpage instead (such as "/Spoilers for future content"), and include a message bar such as:

Time.png
This article has a subpage with lore spoilers for future content, which can be found here.
Do not navigate to this subpage unless you intend to view the spoilers.

User talk:ThePsionic.png: RS3 Inventory image of User talk:ThePsionic ThePsionic Special:Contributions/ThePsionic.png: RS3 Inventory image of Special:Contributions/ThePsionic 11:42, 25 May 2021 (UTC)

Support 2-5 - I think the solution you've come up with in your sandbox is as close to perfect as I think we can get covering all bases for having content but also catering for the lorehounds. One thing to think about is even with the images being obscured, one can still use the arrow controlls to navigate between the images so it may be worth putting spoilered images into a seperate page to transclude so that they don't appear using that navigation. (I'm not sure if that actually works - I haven't tested it!) Lava hawk.png BlackHawk (Talk)    16:29, 28 May 2021 (UTC)

Support 1,6, change 5, oppose 2-3 (4?), comment 1-5 - for 1, I think we should make it that any page with a spoiler section on it would automatically apply a spoiler category to it, which would automatically add a spoiler warning on top of the page, although I'm not sure how this would work technically. For 2-3, I think covering it is a good idea, but from the demo I'm seeing, I propose that blurring is not enough, especially for the images. Although they are blurred, one can still somewhat guess what the image entails. If we decide on blurring the content, I would rather we black/white out (cover it with a white/black square and write "spoiler" on it) the spoiler content instead of blurring. For 4, I am not sure I understood the wording of the suggestion. If it meant that we will be putting the words "[[File:Image.png]]" without actually putting the image on the page, I would be against it (I think the image should actually be on the page). However, if we meant that the spoiler blur is to be applied to picture by picture rather than the entire gallery at once, I would be for it; it's actually better. For 5 & 6, I think making a box that actually hides the entire spoiler part is actually better than just blurring. I suggest that the code mentioned in 5 to not just blur the content wiki-wide, but enclose it in a spoiler box as suggested in 6. For 6, Legaia2Pla said it might be accidentally spoiled for someone if they misclicked, is it possible to add a confirmation dialog before showing the content? Although I don't think this is absolutely necessary. Nayfaan (talk) 09:19, 31 May 2021 (UTC)

Support 2 - 4, comment 5 - I think 2-4 are solid approaches to the solution, and to be honest, there's no need for much more hand holding than that. As for 5, does this take away from any other feature work? Talk to me ShaunyMy contributions 23:56, 31 May 2021 (UTC)

EDIT: Also... how do you define this process with A/B tests? Jagex will run stuff such as "these players will see a new tutorial login popup" and other players won't. This should be considered when it comes to spoilers Talk to me ShaunyMy contributions 23:58, 31 May 2021 (UTC)

Comment - After thinking about it for a while, for now I'm opposed to having unreleased story content* (in the same vein as BotM) on content namespace articles. Per Cqm, to avoid speculation on content that is subject to change, and also to prevent readers on mobile and editors (on source/visual mode) from being spoiled, which can still be the case today. It's also possible to receive a notification about an edit to the page, and possibly spoil yourself. I'm undecided about having a page dedicated to spoilers yet. I'm not sure about the degree of responsibility the wiki should have in preventing the spread of these spoilers. There seems to be a consensus in this thread to warn readers in some way. If we think readers should be warned, does the responsibility of not having these spoilers show up in search engine results fall on us? Should we consider ourselves responsible of others discussing spoilers that were encountered on the wiki, therefore avoiding having these spoilers on the wiki in the first place? Should we not discuss these spoilers on our Discord server, should we have a channel dedicated to them? I'm curious at what others think where the line should be drawn. I support removing or moving the current spoilers until this thread is resolved.
* For now I mean unreleased sprites, cutscene text, audio files and content related to existing NPCs/scenery that appear to be intended to be released in the near future and seem to be related to a storyline. Habblet (talk|c) 17:57, 6 June 2021 (UTC)

Alternative proposal[edit source]

I'd like to suggest that spoilers are not to be uploaded if they are clearly from a future piece of content until such a time that they are accessible in-game or are clearly scrapped (i.e. the miniquest has concluded but the assets in question were not shown). The spoiler policy that we have currently is fine for the majority of use cases, but I'm not a fan of slapping it on the wiki just because it's in the cache. This obviously does not include datamined items and NPCs, since we will have no actual way of knowing what their purposes are until they are actually released in game. It's fine to prepare the assets for uploading off-wiki if you don't mind about the lore too much, but keep it to yourself to make people enjoy the content as it releases. Per the quote from the RuneScape Discord moderators: "We want players to meet new characters and environments in the game, not in a file explorer." User talk:ThePsionic.png: RS3 Inventory image of User talk:ThePsionic ThePsionic Special:Contributions/ThePsionic.png: RS3 Inventory image of Special:Contributions/ThePsionic 06:34, 25 May 2021 (UTC)

Comment - What's the aim of doing this? Is it intended to help us get ready for future releases in the same way as collating information released through "official sources" (Category:Future content)? It seems in this case the data you're talking about for the event can be identified as being related to the event (has anything been added to the wiki yet for us to see as an example of what information can be gained from doing this?) but my understanding is that this isn't always the case: that it's usually a matter of interpreting what cache stuff relates to, and that cache content is more subject to change or never being added to the game? If that's the case then I think Cqm's point about RS:NOT#CRYSTAL and speculating on the potential use for cache content bares more consideration. If the intention is to prepare for future updates can we implement a blanket policy on using cache information when its reliability is subject to us correctly guessing what its use is? Do we need some guidelines on what is an acceptable level of certainty to link cache information to other existing/upcoming content? Or do we try harder to avoid speculation - stick to descriptions such as "this is a thing we found in the cache, it appears to relate to x"?

Another consideration, if we are intending to link to the existing/upcoming content and there is consensus to do so, is where is the information going to be placed? Sticking to upcoming updates or dedicated future update pages would probably lower the chance of someone accidentally seeing spoilers if they didn't want to, but in this example the event is underway so that makes no logical sense and would probably be best placed on the event page, but that makes it much more likely someone will accidentally spoil themselves (even with spoiler tags). I think James' idea on having a central page for data mined information on future content (maybe as a subpage of upcoming updates) would be a simpler solution?

It might be that I'm actually reading this wrong and the intention is just to document the cache more fully? We do sort of (with Category:Pages using information from game APIs or cache) but it's not done particularly consistently. If this is the case how are we going to handle instances of information that seems to be about future content where no official information has yet been released? Is there a certain level of notability we should require for content to be added? In any case I believe that RuneScape:Future content does need updating to reflect that it has become accepted to form pages based on the cache contents. If I'm thinking correctly we also use the cache to gain information on upcoming Treasure Hunter promotions and make related pages in advance too which would be worth mentioning. Magic logs detail.pngIsobelJTalk page 10:13, 25 May 2021 (UTC)

Comment - Honestly I kind of agree that we don't need to put everything that we glean from the cache on the wiki right away if it's buried enough that the few other people who have cache tools won't find it. On the other hand as soon as it gets put out there we should add it, and in that case I'm fine with using any/all of the above methods to hide them. I'd also be fine with adding the "spoilers" to a sub page, as in Some page/future or something like that. Also not sure how to define the line on what we do or don't add right away. Seers headband 2 chathead.png Elessar2 (talk) 11:39, 25 May 2021 (UTC)

Partial support - I'd say this should more apply to the situation we had Monday with cutscene stills (which is a modern issue because Jagex didn't necessarily upload a lot of stuff that spoiled animated cutscenes) and perhaps new models for existing characters. We could also upload these to, say, meta or even off-site like a google doc if we wanted to keep them on hand for when the changes go live. Achievements Coelacanth0794 Talk Contribs 19:18, 26 May 2021 (UTC)

Oppose - see my comments in above discussions. I think cached data should also be documented on this wiki. Nayfaan (talk) 09:07, 31 May 2021 (UTC)

Comment - The cache will forever have spoilers in it each update, I don't think you can effectively moderate it either if someone wants to upload it. Everyone will always want to be "the one" to upload that spoiler and reap the spoils from it.

""We want players to meet new characters and environments in the game, not in a file explorer."

Quite frankly, while I get where they are getting at it with this, they should realise that the Wiki has done a much better job of introducing *all* of the new content better than Jagex.

Also there's some slight irony in that message when they do marketing on their updates which ironically will contain images/concept of characters/artwork in a file server.

Just my two cents. Talk to me ShaunyMy contributions 23:56, 31 May 2021 (UTC)