Feed The Beast Wiki:Centralized discussion

Modpacks reform

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)

Well, it currently seems like the way to do this is to use the Ruby script written by Xbony2. Any other ideas as to how to quickly grab the mods list? --SirMoogle (🐥 • 💬 • 🌟) 17:30, 24 June 2019 (UTC)

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.

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)

Registry and unloc names in infoboxes

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

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)

Interwiki mess

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)

PneumaticCraft and PneumaticCraft:Repressurized

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

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

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)

BlockRenderer

For all editors, I found a new BlockRender mod for 1.14: https://www.curseforge.com/minecraft/mc-mods/item-texture-exporter

Because BlockRenderer is currently only available until 1.12.2. I haven't tried the new mod yet. --LuminousLizard ^{FTB Wiki Staff} _{de-N / "en-2"} (talk) 15:26, 12 October 2019 (UTC)

Misleading Authorship

This WIKi needs a big disclaimer that the information herein is not official documentation by the mods' authors. I'm sick of people complaining to me about my mod being broken because some page here is outdated. HenryLoenwind (talk) 11:18, 28 November 2019 (UTC)

Sorry about that happening to you. Sometimes, it is official documentation though... so such a disclaimer would be inaccurate... it would also be distracting if it was made big enough to force users to see it. -Xbony2 (talk) 05:21, 1 December 2019 (UTC)