Feed The Beast Wiki:Centralized discussion

(jumpto) (jumptonavigation)(comma-separator) (jumptosearch)

Modpacks reform[(visualeditor-ca-editsource-section)]

I'm proposing a few ideas on how to reform the documentation of modpacks on the wiki.

  1. Removing "Mods Included" sections on modpack pages, and linking to its auto-generated list on CurseForge instead (ex). Virtually all mods in modern modpacks are hosted on CurseForge. There may be a case or two where this incorrect, but the stubborn ones that come to mind (IndustrialCraft 2, Twilight Forest, etc) are all up there. GregTech is the only "big" exception, but I wouldn't be surprised if it followed IC2 in the near future.
    The "Mods Included" section really serves little purpose; it's absolutely tedious to update and create (speaking from experience), thus they often aren't really updated. Lastly, they are pretty much unused- It's not 2014 anymore; if you want to know what mods a modpack includes, you go it's CurseForge page, or go the launcher; the wiki is not the first stop.
    There should be exceptions to this rule, of course. Historical modpacks not moved over, like the Ampz Modpack, should allow for a mod list. This rule is mainly meant for future modpacks and current ones, like Infinity 1.7.
  2. Changing {{Infobox mod}} to convert "Modpacks" to a normal argument, instead of a section, and making it link to its auto-generated list of CurseForge instead (ex). The Modpacks section in mods is also not really updated, or even that used.
    It's a good thing it isn't that updated, or pages like BuildCraft would go on forever with the list of every modpack it's been in. The only downfall to this is that it will be incorrect for historical packs.
  3. With the current (unwritten?) policies, "listed packs" are the only allowed modpacks. Technically, all CurseVoice packs are listed, meaning they can all be documented. I think this should be kept as it is.
    Policy-wise, modpacks should be treated like mods (Technically, modpacks are mods, just a mod with many components from many people.). All modpacks should be allowed to be documented here, just like all mods can be documented here. Of course, like mods, FTB Wiki Staff should focus on documenting FTB packs. But, who are we to point away other users' modpacks? That only pushes users to host their documentation elsewhere, on other wikis or their own wikis.
    One point that has been used to counter against letting other modpacks be documented here is that it would clutter {{Navbox Modpacks}}. My solution to this is pretty simple- just keep FTB-created packs on that navigation box. A proper list could created like our mods, but I think keeping {{Navbox Modpacks}} FTB-only would be a good thing.
  4. Anyway, the point of these changes is to allow modpack documenters to focus their time on useful things, like creating modpack guides and better descriptions. It's to allow information better hosted elsewhere to be better hosted elsewhere, and to bring our modpack documentation and policies from 2014 into 2016.

Thoughts? -Xbony2 (talk) 00:15, 14 March 2016 (UTC)

  1. I think the main reason we still have Mods Included is because you can use that to navigate from modpacks -> mods. I know I personally use this all the time, even if it is absurdly outdated. I think some sort of automatic way to do it, or to get the modpack team to update it themselves would be good. I agree it needs to change.
  2. I have been thinking about this for a long time. Perhaps that is a good idea, though not all mods utilize that dependency feature (e.g., Flaxbeard's Steam Power).
  3. Agree. I think they could be listed as Unlisted Packs in the navbox.
  4. k

-- SatanicSantaπŸŽ…FTB Wiki Admin 02:44, 14 March 2016 (UTC)

Get the modpack team to update it. Ha. Automatically generating would make the most sense if we want to keep it. -Xbony2 (talk) 11:10, 14 March 2016 (UTC)

Isometric renders for mobs[(visualeditor-ca-editsource-section)]

Following the Minecraft Wiki's style guide for entity renders it could be possible to give all mobs a proper isometric render instead of just the Spawn Egg and some screenshots. Example with the Twilight Forest Ur-Ghast.

If you want to try it, install Mineshot (go Releases and pick the correct jar for your version), make a void superflat void (or with Barriers that's easier), spawn the mob with {NoAI:1}, press Numpad 5 to toggle the isometric camera (there are other controls shown in the github page) then take a screenshot, erase background and crop in some image editing software.

We'd probably need to agree on roughly what size to shoot for on the pictures (since monsters have different sizes can't really use the same zoom for everything), and also maybe get some big list of TODO articles if we do agree on doing that for all of the mob articles. Lykrast (talk) 22:42, 2 November 2017 (UTC)

I support this as long as the backgrounds are transparent. What if we had the renders for the infobox image (still having the spawn egg as the infobox imageicon) and then proper "natural habitat" images in the article body? That makes sense to me personally. -- SatanicSantaπŸŽ…FTB Wiki Admin 19:17, 3 November 2017 (UTC)
My first attempt is rough.
Buffalo experiment.png
I would like this however. I'd prefer if BlockRenderer added a mob dumping feature but I don't know how easy that would be. -Xbony2 (talk) 20:55, 3 November 2017 (UTC)
Worth mentioning that Better Questing can display a list of all registered entities along with a rotating 3 render in its quest making UI (maybe worth mentioning in that GitHub issue ?). Although until then we can still do it manually, would require a precise step by step tutorial for it though to be sure everything is in about the same style (void world (for uniform blue background) + {NoAI:1} + Mineshot's isometric camera + screenshot + delete background with magic wand or something seems like a real good start for it). Lykrast (talk) 21:04, 3 November 2017 (UTC)

Infobox list standards[(visualeditor-ca-editsource-section)]

We all know how much I love standards. So let's standardize lists in infoboxes. I have set up on a subpage of my userspace 5 potential standard formats for all lists in all infoboxes. All infobox lists will be standardized the same way, so the style used in {{Infobox mod}} will be the style used in {{Infobox material}}, etc. Vote for your preferred style and we'll narrow it down and pick a standard, and then we get to go around updating everything! Fun shit. Alright. Vote by using {{Support|The letter I have provided as the infobox name that corresponds to the style you'd like us to use}}. If you would prefer we discuss stuff I guess we can do that but I mean really this is pretty trivial so I don't really see the need in that. Let's have a standard by next Monday maybe. -- SatanicSantaπŸŽ…FTB Wiki Admin 02:40, 9 January 2018 (UTC)

  • Pictogram voting support.pngCE -- SatanicSantaπŸŽ…FTB Wiki Admin 02:40, 9 January 2018 (UTC)
  • Pictogram voting support.pngGimme the D --SirMoogle (talk) 04:11, 9 January 2018 (UTC)
  • Pictogram voting oppose.pngAB Pictogram voting support.pngCDE πŸ‡Retep998πŸ‡πŸ°Bunny Overlord🐰 04:19, 9 January 2018 (UTC)
  • Pictogram voting support.pngCDE --sokratis12GRπŸŽ… Staff 09:30, 9 January 2018 (UTC)
  • Pictogram voting support.pngD. I've been treating that as the unwritten standard for years now and changing everything else (which has been pretty much only A) into it. Really don't like A/B/C. -Xbony2 (talk) 12:28, 9 January 2018 (UTC)
  • Pictogram voting support.pngD, it looks best IMHO. --Hubry (talk) 20:47, 10 January 2018 (UTC)
  • Pictogram voting support.pngD, Simple is best. Crazierinzane


Wow I suck and did not follow up with this. D won by 3 votes and sokratis, who voted also for C and E, said he preferred D over the other two. I've added the standard to the Manual of Style. -- SatanicSantaπŸŽ…FTB Wiki Admin 22:18, 27 March 2018 (UTC)

Registry and unloc names in infoboxes[(visualeditor-ca-editsource-section)]

As seen on this page, including the entire registry name and unloc name makes infoboxes really wide and kinda ugly. I propose cutting the mod ID prefix from the registry name (it is implied that it is the mod ID) and removal of unlocalized names (since they are basically unusable by users, only by modders, translators and pack creators). --Hubry (talk) 04:37, 21 January 2018 (UTC)

I am in favor of trying this. -Xbony2 (talk) 16:28, 21 January 2018 (UTC)
The unlocalized name I don't care for. The registry name is useful to have and should be kept, but the modid part can be removed since the modid can be inferred from the mod the item is from (and should be documented in the infobox for the mod itself). πŸ‡Retep998πŸ‡πŸ°Bunny Overlord🐰 20:49, 21 January 2018 (UTC)
Not every mod correctly names their stuff, though. Twilight Forest, as I recall, does not include the mod ID in its unlocalized names and instead prefixes everything with "TF". -- SatanicSantaπŸŽ…FTB Wiki Admin 23:50, 21 January 2018 (UTC)
Hubry was a bit more specific on Discord and proposed the prefix be included if it was odd. -Xbony2 (talk) 00:08, 22 January 2018 (UTC)
I believe Santa is talking about unlocalized names, where there's basically no convention anyway. And unlike registry names, which are used by any command interacting with blocks/items and visible to the user through F3+H, the only time you ever see unloc is if you are digging in localization files and mod's source. They are ugly and useless here. --Hubry (talk) 00:14, 22 January 2018 (UTC)

Quest Book template[(visualeditor-ca-editsource-section)]

I was thinking having a template that shows a Better Questing page and quests would greatly help pages of quest based modpacks. Each quest on it would have coordinates on its placement and a hover tooltip to show its name, quest requirements and maybe some extra info. Pushing the idea further it could probably be possible to make a script to directly import Better Questing quests from a config (they have coordinates, requirements, name and all, the icons would probably be very problematic though). Lykrast (talk) 15:01, 24 March 2018 (UTC)

"Minecraft versions" infobox mod parameter[(visualeditor-ca-editsource-section)]

I would like to propose we add a new parameter to the mod infobox, "Minecraft versions" which would list every version it has been released for. This would also entail adding new categories automatically like "Mods released for Minecraft 1.7.10" etc. I have already implemented it at User:TheSatanicSanta/Sandbox/Version categories, just needs to be added to the infobox and moved to a proper template. I also would like to propose having a category on each mod page indicating the latest MC version (also automatic from the mcversion parameter), but nobody has responded to this idea really at all so I dunno. Please discuss this so we can come to a collective consensus. One improvement I could see would be wrapping it in a spoiler (maybe do it depending on how many are passed), but I'm not very attached to that. -- SatanicSantaπŸŽ…FTB Wiki Admin 21:30, 5 April 2018 (UTC)

We should do this. I am against the spoiler idea though. πŸ‡Retep998πŸ‡πŸ°Bunny Overlord🐰
What it’s released for doesn’t seem as useful as what it works with; people looking at a 1.7.10 category would be missing stuff that was released for 1.7.2 even though that would be perfectly valid/working in a 1.7.10 modpack or whatever. Also you need an example on overdrive, like BuildCraft. -Xbony2 (talk) 22:36, 5 April 2018 (UTC)
I guess we could do it in the lead section for each mod, saying which version it started off on. A lot of mod navboxes go with the most recent iteration anyway. --SirMoogle (talk) 03:39, 6 April 2018 (UTC)

Infobox tree[(visualeditor-ca-editsource-section)]

I worked on an infobox for trees idea, to concentrate tree related informations a bit like materials. I made the Menril tree from Integrated Dynamics and the Apple Oak from Forestry in my sandbox to test and show them. The idea behind it is that each tree (and it's "mundane" products like planks or logs that don't do anything special) would only have a single page for that, instead of the tree info being in the sapling page and having some blank log, leaves, planks pages. Some stuff like the fruits may still need their own pages I think.

What it gives :

  • Name, image (pretend the ones in the sandbox have actual images) and mod of the tree
  • Forestry genes (for Forestry trees)
  • Natural blocks that form the tree itself (log, leaves and sapling)
  • Drops that aren't natural blocks ("fruit", Forestry pollen and an Other Drops field)
  • Products from its wood (all vanilla ones (planks, slab, stairs, door, fence, fence gate and boat) as well as an Other Products field)

Want to know what the other thinks before rolling it out to actual pages. Lykrast (talk) 17:53, 25 April 2018 (UTC)

Sounds really cool. One suggestion I have is to include information on how wide the leaves grow so people can space their saplings apart appropriately. There might also be some other bits of information necessary for at least GT6 trees. I guess one of the first things we should try it on is the GT6 tree articles.πŸ‡Retep998πŸ‡πŸ°Bunny Overlord🐰 18:35, 25 April 2018 (UTC)
I've added trapdoor (Quark and 1.13 adds them), bookshelf (Quark and GT6), beam and panel (for GT6). Luckily GT6 doesn't seem to add much that cares about the tree type. For the demonstration, I've also added other stuff from Quark for the oak (like the bark and carved wood). Lykrast (talk) 19:33, 25 April 2018 (UTC)
I like it. I agree with Peter though that the size of the leaves would be useful. -- SatanicSantaπŸŽ…FTB Wiki Admin 21:05, 25 April 2018 (UTC)
I've added an "average width" and "average height" field filled with estimates. Most trees don't vary that much so this should be good enough for most of them. Lykrast (talk) 22:43, 25 April 2018 (UTC)

New FTB core team representative for the wiki[(visualeditor-ca-editsource-section)]

Slowpoke is unhappy with our current representative to the FTB core team due to a long breakdown in communication. As a result there is now the opportunity to elect a new representative. They would be responsible for communicating with the FTB core team on a regular basis to discuss any matters involving both the wiki and FTB, as well as having a say in decisions regarding the future of FTB. You may vote for more than one person in which case you must rank your votes in order of preference. You may also vote for the current representative if you think they are still the best option despite the breakdown in communication. Please make sure your choice is someone who will be proactive in reaching out to FTB and can communicate well. πŸ‡Retep998πŸ‡πŸ°Bunny Overlord🐰 23:20, 19 June 2018 (UTC)

  1. Xbony2
  2. TheSatanicSanta -- SatanicSantaπŸŽ…FTB Wiki Admin 23:21, 19 June 2018 (UTC)
  • I vote for TheSatanicSanta Β―\_(ツ)_/Β― -Xbony2 (talk) 23:34, 19 June 2018 (UTC)
  • First choice: TheSatanicSanta ; Second choice: Xbony2 - DSquirrelGM𝓣𝓟𝓒 🗸 01:37, 20 June 2018 (UTC)
    @everyone: I do not want and will not accept this position. Discussions with slowpoke have given me enough anxiety for me to literally shiver and for my lower jaw to tremble like it is below freezing. He has stated before that he does not trust me, which is fair, because I don't really have a high level of trust with the FTB Core Team either. I am sorry for my honesty. In addition, although I truly do wish the best to the FTB Team and their projects, I am mostly apathetic towards FTB, and like most of the editors, don't really play much FTB or care a lot how they conduct their business outside of the wiki. I do not want to fit my schedule around their meetings, of which I believe little will retain to me or the wiki at large. I am sorry if this position bother anyone, and I do not mean to offend anyone, but this is how I currently feel. -Xbony2 (talk) 01:47, 20 June 2018 (UTC)
  • I will have to say TheSatanicSanta. --SirMoogle (talk) 05:11, 20 June 2018 (UTC)
  • I vote for TheSatanicSanta. IndestructiblePharaohVII 11:06, 20 June 2018 (UTC)
  • I also vote for TheSatanicSanta. --Hubry (talk) 11:07, 20 June 2018 (UTC)


Since it's been long enough and there's been no recent activity on this vote, voting is now closed. You've voted to keep TheSatanicSanta as the representative, so that will be forwarded on to Slowpoke. -- The preceding unsigned comment was added by Retep998 (talk β€’ contribs)

Using the Pn template in guides[(visualeditor-ca-editsource-section)]

I came across this most recent guide and saw it used {{Pn}} throughout the body of the text. I personally found it aesthetically pleasing, but what does everyone else think? --SirMoogle (talk) 15:41, 22 June 2018 (UTC)

Yes.πŸ‡Retep998πŸ‡πŸ°Bunny Overlord🐰 15:50, 22 June 2018 (UTC)
SΓ­.-- SatanicSantaπŸŽ…FTB Wiki Admin 21:31, 22 June 2018 (UTC)

Tick conversion template[(visualeditor-ca-editsource-section)]

Had the idea to make a template to auto convert ticks to human readable durations on hover, as it will be useful on some parts of Prodigy Tech and could easily be used elsewhere. Currently got a little demo in my sandbox, and it goes up to (real life) days. Want to know what to change before putting it out there (and maybe find a name for it).

Somewhat related: another idea that'd use the hover text too would be one to compress big amounts of RF (or whatever) with SI prefixes (like 2.1 GRF instead of 2100000000 RF), and show exact amount on hover, mostly for DE. What you think of that? Lykrast (talk) 21:31, 7 July 2018 (UTC)

dunno about the energy thing, but I like the ticks. One small thing is that it should be singular only if it is 1 second; your current template lists "0.5 second" instead of "0.5 seconds" -- SatanicSantaπŸŽ…FTB Wiki Admin 00:23, 8 July 2018 (UTC)
Oh, actually, looking at the source, the style should be moved into a class and then probably given the same styles as the sic class (used in {{sic}}) -- SatanicSantaπŸŽ…FTB Wiki Admin 00:25, 8 July 2018 (UTC)
Would have said to maybe keep them distinct since they don't mean the same thing (sic vs hover text), but maybe most people won't notice. Lykrast (talk) 09:38, 8 July 2018 (UTC) NIR template (used on the IC2 navbox) uses it for its hover text so it'll need the class as well. Lykrast (talk) 14:28, 8 July 2018 (UTC)
I kind of feel like it should be the other way around; like 1 second. The RF thing seems weird but maybe interesting; how is it handled in-game? -Xbony2 (talk) 00:27, 8 July 2018 (UTC)
Most mods just display the complete number, but I know the Draconic Energy Core rounds displayed numbers with MRF/t, TRF and the like (like on that image I found). I would argue for the ticks in text, mostly for tables and such, maybe with an added parameter to decide. Lykrast (talk) 09:38, 8 July 2018 (UTC)

Separating Ender IO versions[(visualeditor-ca-editsource-section)]

Proposing that the current version of Ender IO documented should be moved to something like "Ender IO 3" or, "Ender IO (1.10.2)", and that we create a new mod page, navbox, etc. for Ender IO 5. Ender IO 5 recently came out in April, and the mod was basically overhauled. Keeping them together would require a large amount of maintenance work. Many items and blocks were removed, added, or had their textures changed, and lots of core mechanics from the mod were changed. Intipablo (talk) 14:03, 9 July 2018 (UTC)

There's some new blocks and items, but to be honest, I don't think anything needs to be separated. I can update the navbox and go through existing pages and update things. -Xbony2 (talk) 21:29, 9 July 2018 (UTC)

Interwiki mess[(visualeditor-ca-editsource-section)]

So, Pcj recently mass deleted likely-unused interwiki prefixes from all the wikis on Gamepedia. This has brought our interwiki stuff to my attention. There are a few issues:

  1. The "wikt" prefix was deleted. Bony thinks this prefix was used and I also think that, however if it was it was a duplicate because there is already a "wiktionary" prefix. We need to ensure only one is used, and decide on which one. I prefer "wikt" because it's shorter.
  2. There are two Wikipedia prefixes, "wp" and "wikipedia." Likewise we should pick one and correct everything on the wiki to only use this one. I personally like "wp," also because it's shorter.
  3. Likewise with "mw" and "mediawikiwiki"
  4. The "raw" prefix is incorrect. Is this actually used? Those URLs (hydra-media whatever) are no longer used. We need to check all of this thing's usages and hopefully delete it; I don't know why we would ever need this for an interwiki prefix.
  5. The following seem likely to be unused. We should assess these all:
    1. "commons"
    2. "ddgo"
    3. "google"
    4. "wikia"
    5. "wikimedia"
    6. "wow"
  6. Squirrel wants a CurseForge interwiki. Discuss that on the according discussion post.

Let us deliberate. -- SatanicSantaπŸŽ…FTB Wiki Admin 17:43, 26 July 2018 (UTC)

My opinions:
  • raw was added by Xbony for Augmented Interactions because he wanted to embed gifs - honestly these should be converted to videos and embedded in the gallery instead (see wp:WP:Extended image syntax#Video files).
  • Wow is used on Thundercaller. I think you added it just for that page :P - I didn't think it was necessary and I think it can be removed.
  • I dont think we have any use for Commons or Wikimedia, though Commons could potentially be useful at some point I guess?
  • google/ddgo - do we really need an interwiki for search queries?
  • IIRC the main Wikia site has interwikis for all the wikis, so that's basically one interwiki for everything there - though I think we just link to Wikia pages directly when we link there, so we could remove it.
I'm fine with cutting the six interwiki prefixes you mentioned. As for wp/wikipedia, wikt/wiktionary and mw/mediawikiwiki the shorter ones for sure. (mediawikiwiki sounds stupid, too.) --Hubry (talk) 19:09, 26 July 2018 (UTC)
wikt is used, particularly through {{Wikt}}. A few pages are broken now, but whateves >.> I prefer shorter prefixes, but also prefer them to be recognizable, so I am opposed to using "wp" which looks odd to me. -Xbony2 (talk) 01:18, 27 July 2018 (UTC)
In the meantime, I've adjusted the template to use the other prefix. DSquirrelGM𝓣𝓟𝓒 🗸 03:22, 27 July 2018 (UTC)



Representing the wiki, I, with help from Hubry, am at LimboCon with a booth (it's a bit bigger than the picture, there's an underground part). Come visit us, August 4th to 6th! The website is here. -Xbony2 (talk) 00:18, 4 August 2018 (UTC)

PneumaticCraft and PneumaticCraft:Repressurized[(visualeditor-ca-editsource-section)]

The current PNC pages are quite empty and outdated : since his port to 1.12 by desht and MineMaarten, Plants Seeds, associated Plastics and Electron Tubes were removed, for example. As there is almost no content for PNC, is it better to rename the PNC categorie to PNC:Re or make a brand new PNC:Re categorie? -Sewef13 14:11, 13 August 2018 (UTC)

If there's a title change from PneumaticCraft to PneumaticCraft: Repressurized, I'd create a new category. --SirMoogle (talk) 14:32, 13 August 2018 (UTC)

Status Effects[(visualeditor-ca-editsource-section)]

To make Status Effects page at least a little bit prettier, I suggest adding a type to the infobox to say "Status Effect" (instead of using "Mechanic"), having a separate category for things that apply Status Effects (just like we have Enchatments and Enchanting), and renaming the current status effect images to something a lil more structured like "Potion XXX", "Status XXX" or something similar. That last one may not be necessary if we find a way to get Status Effects tilesheets for mods (or anything similar that would make individual images for the pages not required). Lykrast (talk) 08:43, 15 August 2018 (UTC)

I'd personally be okay with simply adding status effects from all the mods to the EFFECT tilesheet. πŸ‡Retep998πŸ‡πŸ°Bunny Overlord🐰 08:47, 15 August 2018 (UTC)
There would be just the problem of disabigs, as for example both Astral Sorcery and Defiled Lands add a Bleeding effect. Lykrast (talk) 09:30, 15 August 2018 (UTC)
Because the status effect tiles are 36x36, we can't put them on the normal tilesheeets. Either they'd all go on the EFFECT tilesheet with a bit of manual disambig, or we'd have to have a whole set of new EFFECT abbreviations and tilesheets. πŸ‡Retep998πŸ‡πŸ°Bunny Overlord🐰 17:20, 15 August 2018 (UTC)
I support the infobox change. I also agree with Peter on the tilesheets. I'm not quite sure what you mean about the categories. -- SatanicSantaπŸŽ…FTB Wiki Admin 21:00, 17 August 2018 (UTC)
For enchantments we got Category:Enchantments for actual enchantments Category:Enchanting for stuff that apply them. For status effects we got Category:Status effects were we both have actual status effects and stuff that apply them (currently just the various Totem pages). So the idea was to also split that so they aren't mixed up in the same category. Lykrast (talk) 21:05, 17 August 2018 (UTC)

FTB One access for documenting modpacks[(visualeditor-ca-editsource-section)]

FTB is offering to give FTB One access to wiki editors who are willing to document modpacks. You would have early access to modpacks and the testing servers so that the documentation would be ready by the time the modpack is finally released. Please let me or TheSatanicSanta know and we will get you in touch with the appropriate people to grant you access. πŸ‡Retep998πŸ‡πŸ°Bunny Overlord🐰 23:23, 17 August 2018 (UTC)

Retep998, has this offer been rescinded yet? --SirMoogle (πŸ₯ β€’ πŸ’¬ β€’ 🌟) 22:54, 30 October 2018 (UTC)
Not that I am aware of. πŸ‡Retep998πŸ‡πŸ°Bunny Overlord🐰 15:47, 31 October 2018 (UTC)


I want to translate Feed The Beast Wiki:All templates to russian, but I have one little problem. Now, I'm on AFC templates section, I can't translate it, because I don't know what means AFC. Can somebody tell me please? --Qunynawy (talk) 11:31, 26 October 2018 (UTC)

{{AFC submission/created}} seems to have the full name (Articles for creation). Anyways, this seems to be a legacy section from the time when the wiki was FTB-hosted and I am not sure why these templates are still around and linked here. Don't worry about this section, I'd say. --Hubry (talk) 11:37, 26 October 2018 (UTC)