Feed The Beast Wiki

Follow the Feed The Beast Wiki on Discord or Mastodon!


Feed The Beast Wiki

Isometric renders for mobs[]

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
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)

Quest Book template[]

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)

Status Effects[]

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)

1.14 Vanilla renamed items[]

There are many items and blocks that were renamed in the 1.14 Village & Pillage update. We need to discuss how we should go about representing and displaying the differences between these renamed items on the wiki. Some things to consider are:

  1. How would the newer names affect the user experience on mods made for older versions? E.g. using JEI to search for a block
  2. What should we display to users on Vanilla pages for renamed items?
  3. Should we display the older item names on pages using a specific pre-1.14 Minecraft version?
  4. How should we handle renamed items for mods that span between pre-1.14 and 1.14?

Feel free to add to this list, or refer to a question by its number in the discussion below. All of this is up for debate. -- SizableShrimp🦐 (talk · contribs) 07:26, 1 September 2020 (UTC)

V template[]

I just used my bot account, ShrimpBot, to standardize Vanilla pages to all end in (Vanilla) for consistency and the fact that many articles link to disambiguation pages of Vanilla items that have alternate articles from mods that have the same name as the Vanilla item. This is obvious for me to see and catch since I have a user script that highlights any disambiguation pages in orange since the extension that does this, Extension:Disambiguator, is not currently approved on Gamepedia. Now that all Vanilla items are formatted the same, it makes sense to have a simple template, Template:V, that simply contains {{ML|{{{1}}}|V}}. It would make it easier to determine which pages reference Vanilla items and simplify the bloat of having to type {{ML and |V}} each time for referencing Vanilla items. This also seems cleaner than doing [[Dirt (Vanilla)|Dirt]] or {{L|Dirt (Vanilla)|Dirt}}, especially if we decide to change the naming convention for disambiguated mod pages. Not sure what the community thinks about "shortcut templates", which I believe this might fall under.

Honestly I'm not a fan of "shortcut templates" like ML that save a few characters but give newer editors more confusion. More to keep track of, and if you know your tricks then it ends making less of a difference anyway (for example, you can just [[Dirt (Vanilla)|]] and it will just fill in the display). Or perhaps I'm just an old dog who doesn't like new tricks. -Xbony2 (talk) 04:46, 29 November 2020 (UTC)
I like "shortcut templates" in certain circumstances because it abstracts the process and allows the process to change. If we use the pipe trick or {{ML}} or something else and then wanted to change the format of Vanilla pages (see Retep's disambiguation proposal) to something more relevant, we would have to update any and all pages that use a hardcoded format. I agree that it can be harder to keep up with, but I think it might help in the long run, especially if this V template becomes used on a wide array of articles, allowing new and veteran editors to pick up on it. Also, the use of a dedicated Vanilla template makes it easy to identify when editing what items are vanilla items with either a page search or skimming an article. Along with the added benefit of being able to tell what pages transclude the V template and the ability to change how it functions at any given time, of course. These are my thoughts on the issue. -- SizableShrimp🦐 (talk · contribs) 05:00, 29 November 2020 (UTC)
I don't think there's a need to put '(Vanilla)' to all pages, most of the one that have the disambiguation page are blocks that can be chiseled, which I plan to remove the disambiguation and include all the chiseled blocks in the page when I have the time - AstroFlux (talk) (contributions) 08:39, 13 December 2020 (UTC)

Proposed MoS addition: ambox before hatnotes or visa versa[]

There's been a lot of discussion and debate about whether or not amboxes (like {{Stub}}) should be above or below hatnotes (mainly {{About}}). This has been discussed for a long time but it seems a consensus was never created. I'm impartial to either, although I will think more about it. I'm making this a vote but if there aren't strong feelings on it, it will be somewhat informal. The results will be appended to the MOS. -Xbony2 (talk) 07:10, 14 December 2020 (UTC)

  • Pictogram voting neutralNeutral. -Xbony2 (talk) 07:10, 14 December 2020 (UTC)
  • Hatnotes should have higher priority placements (above, on page) since presumably they're intended for long-term content placement of some importance. DSquirrelGM (talk) 07:28, 14 December 2020 (UTC)
  • I lean towards placing hatnotes after amboxes, because an ambox refers to the page (which is arguably more important), whereas a hatnote refers to the content. Though I might be biased because it’s the way this is done on the Russian Minecraft Wiki, meanwhile English MCW’s style guide has hatnotes above message boxes. — BabylonAS 08:06, 14 December 2020 (UTC)
  • I'm more biased towards amboxes before hatnotes, as amboxes are generally placed when a page requires some sort of maintenance, which should be fixed as soon as possible. Hatnotes are intended to be in the article, and sandwiching something that is undesired (amboxes) between hatboxes and the rest of the content looks strange. SirMoogle (talk) 17:28, 14 December 2020 (UTC)
  • Personally, I prefer the order to be ambox/amboxes first and then hatnotes. However, as I searched a bit, I was surprised that Wikipedia's MOS states the opposite. It is even made strictly clear in this page. But for me, amboxes first is my go-to way. — 🍕Yivan000 talkcontribs 🍕 07:14, 17 December 2020 (UTC)
  • I prefer having hatnotes before amboxes because it makes more sense to have content links at the top of the page for users to easily navigate to other, more applicable pages if they have traveled to the wrong one (e.g. an {{About}} hatnote). I also think having hatnotes before amboxes looks better graphically, since amboxes are indented further compared to hatnotes, which makes them look ugly and out of place when placed above hatnotes. This would also be in line with Wikipedia's MOS, which states, as I quote:
If a reader has reached the wrong page, they should find that out first.

-- SizableShrimp🦐 (talk · contribs) 06:13, 27 December 2020 (UTC)

How to fix an error in item list on uploaded tilesheet[]

  • Or how to fix blank item when available on the uploaded tile-sheet?

Hi! my name is Al_Cool I would like to update Misty World's wiki, but lack some knowledge. Today I've learned how to use template NI and the Tile-sheet system. When I try to preview a line in the Item viewer, the result is a pink square, like if there was a mistake. When I look at the uploaded tile-sheet and at the item's name, Mod name, x,y,z position are accurate. So when I ask to preview tile-list item 341130 named (View 341130 Glass Container MW 11 21 0 16px,32px.) When I search the item's icon on the tile-sheet*, it actually is at column 11 and row 21. So how to fix this? Alcool007 Contact Help us build a nice and friendly community on wikia :) 23:50, 18 May 2021 (UTC)

  • latest?cb=20200611045247

I think I got the start of a pierce through! By following and reading the source code of many template's link with or around the way tilesheet image are printed, I've ended up with two hypothesis.

  • A) Retry. Every template using the tile-sheet system link to the [[1]] rename template. If you read the warning on the document page, it say something about how this template should not be used when a languagefile.txt is left blank. [[2]] By default return a "empty" as a result witch is very similar to the pink square who replace missing tile image. So far I don't know how rename.txt work or if there is any way to edit it once the tile-sheet is uploaded. So something I would like to try is to Re-upload the Tile sheet while taking care about any warning message to make sure every steps is filled and not empty.
  • B) Delete. The only missing image in the template are from an advanced version of the game, like if the additional content was not correctly included. Most mods only list one tile-sheet. So I guess when updated or re-uploaded some user ratter like to delete the previous version. So its a long shot but, maybe deleting the previous tile-sheet file's version could solve the problem as only the newest content does not print.

So far since my 2 hypothesis require deleting a file or re uploading one by using a software that I'm not familiar with, I would ratter wait for someone more experienced that me to try to fix the problem. Alcool007 Contact Help us build a nice and friendly community on wikia :) 10:41, 19 May 2021 (UTC)

Alcool007: Sorry, which tiles are broken? I can switch some names around, or maybe just delete and remake the tilesheet (sometimes that's easier although Retep's software is better than it used to be). -Xbony2 (talk) 04:04, 19 June 2021 (UTC)

Merge proposal among Immersive Engineering's LV, MV, HV pages, and creating a new infobox template[]

Wire Coil

ModImmersive Engineering
RF traversing2048, 8192, 32768 RF/t

I propose the following sets of pages be merged:

This is on the basis that each set's items are functionally identical. The only thing different is their ratings (coil length, power capacity, etc.), which can be given in tables and/or the infobox. We can create an "Infobox Immersive Engineering" template so the pages' information can be tailored to Immersive Engineering's system.

I can carry out these changes. What say ye on this matter?

——JavaRogers (talk) 01:18, 18 June 2021 (UTC)

A special infobox for IE is a bit unorthodox and seems unnecessary, but if you wanted to merge the pages that would be okay. Good work on updating/improving IE info btw, that's something I've neglected for years (among other things). -Xbony2 (talk) 03:53, 19 June 2021 (UTC)
Haha yeah. Hey I appreciate the validation! About the infobox idea, I'm just playing off the fact that we have special infoboxes for a number of other mods. In lieu of creating a new template, would it be better to add some IE fields directly to {{Infobox}} (lvtraversing, mvtraversing, hvtraversing, etc.), or just use formatting tricks to make it work? ——JavaRogers (talk) 22:43, 25 June 2021 (UTC)
The regular infobox has some magic that comes with it, like {{{1inputtitle}}}/{{{1usetitle}}}, so you can add some custom fields without changing it. I can add to {{Infobox}} later if needed. -Xbony2 (talk) 18:17, 27 June 2021 (UTC)

Linking to and from Wikidata[]

I believe we should develop a consensus around how we link _to_ and _from_ Wikidata, and, by extension, other Wikimedia projects. On some occasions, Wikidata items (database entries) have been made for Minecraft mods; notably, ComputerCraft and NEI. Should we consider creating a WikiProject for creating links from Wikidata items to FTB Wiki? And vice versa, how should we link to Wikidata from FTB Wiki pages? Should we put it in the infobox? Should we put it in its own template at the bottom of the page? Discuss! --Tomodachi94 (View·Talk|Editor) 23:28, 9 September 2022 (UTC)

To add on, should we add an interwiki prefix for Wikidata? --Tomodachi94 (View·Talk|Editor) 23:34, 9 September 2022 (UTC)

IP editing disabled?[]

Why and when was IP/anonymous editing disabled? I mean, yeah, they sometimes create nonsense pages or do some nonsense edits, but those are spotted and reverted quickly. Their edits can be also really helpful sometimes, actually. I generally hate it when websites require you to login/register for every action. Note that there are also pages like Feed The Beast Wiki:Frequently asked questions which say things like "You don't need to sign up anywhere to start editing." - this ain't true. Qwertxquartx (talk) 16:06, 31 January 2023 (UTC)

As far as I'm aware, Fandom disabled IP editing on 'wikis targeted to children' to comply with things like COPPA in the USA and the GDPR in the EU and UK (which has provisions specific to persons under the age of 16.) I personally disagree with turning off edits from IPs, but I don't think there's anything we can do about this while we're on Fandom. —Tomodachi94 (he/they • sysop • talk) 19:29, 5 September 2023 (UTC)


I have boldly created a draft paid editing disclosure policy for this wiki. I believe this policy is necessary to promote the openness and transparency that the modded Minecraft community is based around.

This policy creation was prompted by a discussion in the Discord server about rekindling the relationship between the FTB Team and this wiki and how that would relate to paid editing (among other things). I encourage you to voice your concerns about this policy; this is not an official policy until community consensus has been reached. Tomodachi94 (View·Talk|Editor) 05:25, 22 April 2023 (UTC)

I personally don't have an issue with editors getting paid so long as it's disclosed and it doesn't restrict what mods the wiki is allowed to host Moderngamer327 (talk) 19:47, 22 April 2023 (UTC)

OcelotProposal: Removing redundant categories[]

A long time ago, I wrote CatProposal, which was intended to standardize categories for the images, templates, and pages of mods. However, I have seen the error of my ways and decided to write a new proposal, OcelotProposal, because ocelots were present in Minecraft before cats.

I propose that images and templates concerning a mod be placed into the same categories as the pages concerning that mod.

Here's an example: We currently have a category called Botania, and a category called Botania images. If this proposal is enacted, the images in Botania images would be condensed into the Botania category.

The main issue with this is that files and templates are not displayed separately from pages; I'm not sure if this is a legitimate issue or not.

(I am willing to write a bot that seeks out and condenses these categories.) Tomodachi94 (View·Talk|Editor) 01:39, 23 July 2023 (UTC)

For images I would be fine with setting a threshold at which point we create a separate image subcat, and using the base cat until that point. For templates, I think they should be kept separate as these are content categories and templates are not content. -- SatanicSanta🎅FTB Wiki Admin 13:54, 18 February 2024 (UTC)

Forking from Fandom[]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The result of the discussion was fork. No consensus was established about accepting Feed The Beast's offer; a second attempt to establish consensus on a final destination will be made at a later date. —Tomodachi94 (he/they • sysop • talk) 03:33, 10 September 2023 (UTC)

It's that time.

For the past few months, there has been occasional discussion about forking from Fandom to some other platform. Some of the main concerns were excessive advertising and bloat (read: autoplaying videos on some pages), the recent move by Fandom to promote a McDonalds promotion on the McDonalds wiki without even leaving a notice for the community until after the fact, and general negative experiences with Fandom's UI, UX, and DevEx.

Feed The Beast has offered to host us on their servers:

From User:Retep998:

I have been informed by @Slowpoke that FTB is going to move forward with a self-hosted wiki. We have the choice of whether we want to migrate the FTB wiki to that self-hosted wiki. If we choose to follow through we would continue with the same organizational structure and all our content, just running under FTB instead of Fandom. There are many pros and cons to this move, and I believe this warrants the rare @Editor ping for the editors to decide how to proceed with this.

Ultimately, the decision rests with us, the editors of Feed The Beast Wiki.

Here are the vote options:

  • Pictogram voting neutralNeutral, I don't give a monkey's tail.
  • Pictogram voting opposeAgainst fork, remain on Fandom.
  • Pictogram voting supportSupport fork, Pictogram voting supportSupport FTB's offer.
  • Pictogram voting supportSupport fork, Pictogram voting neutralNeutral on FTB's offer.
  • Pictogram voting supportSupport fork, Pictogram voting opposeAgainst FTB's offer in favor of another option (please detail what you believe should happen instead.)

Important note: If you are a sysop and you Pictogram voting supportSupport the fork, this could trigger other consequences for your adminship/bureaucratship.

Thank you for your time. Tomodachi94 (View·Talk|Editor) 22:50, 7 August 2023 (UTC)

Update: This (initial) vote will close 23:59, 9 September 2023 (UTC). A new vote will be promptly opened to decide on a more specific course of action; currently, the general consensus seems to be that Fandom sucks and that the community wants to move somewhere else. However, there is no consensus of where we should go. Thanks everyone for participating.Tomodachi94 (he/they • sysop • talk) 00:43, 4 September 2023 (UTC)


  • Pictogram voting supportSupport fork, Pictogram voting supportSupport Pictogram voting neutralNeutral FTB's offer as nom. Tomodachi94 (View·Talk|Editor) 22:50, 7 August 2023 (UTC)
    • I have changed my vote after reading further commentary about FTB's offer. Tomodachi94 (View·Talk|Editor) 00:43, 9 August 2023 (UTC)
  • Pictogram voting neutralNeutral, not because I don't care though. Will add my comments to the other section so this doesn't get too cluttered. -Xbony2 (talk) 23:02, 7 August 2023 (UTC)
  • Pictogram voting supportSupport fork, Pictogram voting neutralNeutral. I fully support leaving Fandom, the only real downside(beside the work) is Fighting fandom's absurd SEO. I'm Neutral on going with FTB because i feel like it does kind of suck going from one owner to another instead of being independent. I do think though FTB would be better than Fandom and would allow access to resources being independent would not Moderngamer327 (talk) 23:22, 7 August 2023 (UTC)
  • Pictogram voting opposeAgainst fork - instead go for rebranding for independent operation (with the ftb subdomain being redirected to whatever the new one ends up being, preferably). This option has been considered for a long time as well, and the impacts for existing users / editors would be minimal. DSquirrelGM (talk) 01:31, 8 August 2023 (UTC)
  • Pictogram voting supportSupport fork, Pictogram voting supportSupport FTB. My dissatisfaction with Fandom far outweighs my concerns about FTB. – Astralfields (talk) 13:28, 8 August 2023 (UTC)
  • Pictogram voting supportSupport fork, Pictogram voting neutralNeutral. - AstroFlux (talk) (contribs) 00:17, 9 August 2023 (UTC)
  • Pictogram voting supportSupport fork, Pictogram voting opposeAgainst FTB's offer. - Migrate to wiki.gg or alternative. Any move away from Fandom is a win. To me, this wiki has always been a modded Minecraft wiki and nothing FTB. Why should it be anything else? Crazierinzane (talk) 01:34, 9 August 2023 (UTC)
  • Pictogram voting supportSupport fork, Pictogram voting neutralNeutral on FTB's offer. I hate Fandom and want to go somewhere else. 🐇Retep998🐇🐰Bunny Overlord🐰 01:57, 9 August 2023 (UTC)
  • Pictogram voting supportSupport forking, Pictogram voting neutralNeutral on being under FTB. I dislike Fandom due to the poor UX and frustrating UI. However I dislike the idea of being under FTB. FTB is a brand, and Slowpoke no doubt will want to promote the FTB App, FTB packs, mods in FTB packs. Which is absolutely fine, but I don't think this wiki should be the official FTB wiki. I think the best course of action is us [ftb.fandom.com] rebranding to "Modded Minecraft Wiki" on another host like wiki.gg, and FTB can perhaps also use the wiki dump to kickstart their own wiki under them? PlatinumElectron (talk) 10:17, 9 August 2023 (UTC)
  • Pictogram voting supportSupport fork, Pictogram voting neutralNeutral FTB. --Qunynawy (💭) 19:35, 13 August 2023 (UTC)
  • Pictogram voting supportSupport forking, Pictogram voting neutralNeutral on the FTB offer. I think we should also consider the other wiki host options laid out by the Minecraft Wiki editors, since they too desire to move away from Fandom. — 🍕Yivan000 talkcontribs 🍕 14:14, 15 August 2023 (UTC)
  • Pictogram voting supportSupport fork, Pictogram voting neutralNeutral on FTB's offer. As long as wherever we're planning on migrating to has the most recent version of Mediawiki, I'm fine with it. SirMoogle (talk) 03:29, 4 September 2023 (UTC)
  • Pictogram voting supportSupport fork, Pictogram voting neutralNeutral on FTB's offer. Hosting isn't free and the amount of ads on Fandom can be annoying. Slowpoke's idea of using profits to go back into the wiki such as compensating writers for FTB content sounds great to me. But this wiki isn't very FTB focused. Ultimately I find myself indecisive. Pneen (talk) 16:47, 5 September 2023 (UTC)

FANDOM's response[]

FANDOM representative: Please leave your official response below this message. Tomodachi94 (View·Talk|Editor) 22:50, 7 August 2023 (UTC)

Feed The Beast's response[]

Feed The Beast representative: Please leave your official response below this message, if you have one. Tomodachi94 (View·Talk|Editor) 22:50, 7 August 2023 (UTC)

Editor comments[]

FTB Wiki editors: Add your comments here. Please only add a comment if you have something substantial to say.

  • Okay so, the biggest issue for me is bandwidth. I don't have the personal bandwidth to help make this happen. I am a bit more convinced that Tomo does, though, so he and Retep would probably be leading the technical effort. I would like Tomodachi to be nominated as an admin if he wishes to make this happen though. If he's okay with it, I'll make the nomination soon.
    I am also concerned about the potential success of this. I think the modded world has suffered greatly because of the split between the unofficial wiki and the official wiki, and having three major mod wikis won't help. It's hard to beat Fandom on SEO, even if the community is on our side. I don't think the editors are split on this decision, but the corpse wiki could be an issue that attracts flies.
    Slow has mentioned "rebranding" the corpse wiki if we fork. While we should yank the assets that belong to FTB, I do not think we should help Fandom with this. If we can't throw it out, then let the corpse rot; don't make it a zombie. We can leave that decision to Fandom though, as long as we make it clear that they cannot use our assets or claim to be official.
    I am concerned about FTB's ability to host the wiki; they used to, before we migrated to Gamepedia, and they weren't especially good at it. I believe that they have more interest this time and will be less negligent, but it is a fact that no one working at FTB is an expert at hosting MediaWiki wikis. You can hate Fandom's policies (I do lol), but Fandom is an expert at hosting wikis. So other wiki hosting services might be worth looking at, though I would rather be independent. I am concerned that the wiki could shutter if FTB ends up shuttering, just like how say the Technic Wiki has, but I think if we're good at making backups then it'll be fine.
    Slow has some concerns about some specific non-FTB pages, but it is all rather hyperspecific. Non-FTB mod pages will not be mass deleted or something. I am not particularly concerned about this. We will remain officially focused on FTB as we always have been, but individual editors may have their own agendas.
    Once forked, I hope to retain my admin/bureaucrat role in my semi active state. I am not afraid of Fandom taking away my roles on this wiki, or even banning me. I will take the L. I will not be going out of my way to make either of those happen, though, and I hope to comply with Fandom policies generally.
    I have mixed feelings, but assuming it happens, I will be assisting this fork. Just at a pretty low capacity. All of my random software will have links updated to the new wiki and such. -Xbony2 (talk) 23:53, 7 August 2023 (UTC)
    • I would accept a adminship nom, though I wish it were under different circumstances. <3 Tomodachi94 (View·Talk|Editor) 00:01, 8 August 2023 (UTC)
    • Rebranding the old wiki to Minecraft Mods Wiki would be purely at your detriment, obviously a more general Minecraft Mods Wiki will attract more people than a wiki about some specific mod packs (I know you document more than just FTB, but to most, the name makes it seem otherwise). Declining FTB's offer seems like the obvious call to me, this is a pretty big wiki with very few editors, if you're going to move you need a safe and secure host (AKA people who know what they're doing and have experience hosting). Personally I'd recommend moving to wiki.gg and rebranding to Minecraft Mods Wiki. I have valiantly opposed the Minecraft Wiki moving to wiki.gg, but that's only because we have far better options than it. For most wikis, wiki.gg is the way to go. I speak only to give advice, since I am not an editor, and that is why I am not voting. Good luck with the fork. - {{SUBST:User:Harristic/Signature}} 17:36, 8 August 2023 (UTC)
  • Another comment: it seems like we have most of the technical stuff of forking figured out, but dealing with username/account reclamation may be rather difficult. This is something that will have to be resolved. -Xbony2 (talk) 00:35, 8 August 2023 (UTC)
    • Looks like another wiki in a similar situation made a MediaWiki extension that helps with that, aptly titled MigrateUserAccount. Tomodachi94 (View·Talk|Editor) 00:53, 8 August 2023 (UTC)
      • Looks alright. Would need further investigation, of course. -Xbony2 (talk) 01:07, 8 August 2023 (UTC)
  • Looks like the main Minecraft wiki has accepted a hosting offer from Weird Gloop, the company the hosts the RuneScape wikis. I'm not an active editor here so I'm not voting, but Fandom is awful and I would love to see this wiki go anywhere else. Hypermoron (talk) 20:11, 15 August 2023 (UTC)
  • For the benefit of everyone here throwing their opinions in, can someone summarise the consequences (both positive and negative) of what would happen if we were to take FTB's offer? I'm somewhat following along on the Discord server and seeing that documenting potentially touchy subjects is a point of contention right now. SirMoogle (talk) 22:23, 4 September 2023 (UTC)
    • Pros: (Almost) full technical control over wiki plugins, skins, and others.
Cons: Concerns have been raised about Feed The Beast's technical ability to manage a MediaWiki instance. Additionally, there are concerns about losing our editorial independence and becoming a marketing piece for FTB. Advertisements might be placed on the wiki, but they would not be as extreme as Fandom's. —Tomodachi94 (he/they • sysop • talk) 00:55, 5 September 2023 (UTC)

The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Converting Template:Vanilla to a hatnote?[]

Currently, {{Vanilla}} uses an {{Ambox}}. {{Vanilla}} redirects users to another page, which is inconsistent with other templates serving a similar purpose (like {{About}}), which are italic text. As a fix, I propose that {{Vanilla}} is changed to be text-only. Thoughts? —Tomodachi94 (talk) 22:26, 17 February 2024 (UTC)

I disagree because the vanilla ambox is used on pages with essentially no content -- at least, no text content. It would also be especially weird for disambiguated vanilla pages. SatanicSanta🎅FTB Wiki Admin 13:44, 18 February 2024 (UTC)