Feed The Beast Wiki:Centralized discussion

From Feed The Beast Wiki
Jump to: navigation, search

Modpacks reform[edit source]

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

-- SatanicSantaFTB 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[edit source]

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[edit source]

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

Results[edit source]

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[edit source]

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)

The FTB Wiki at Modoff[edit source]

FTB Wiki at Modoff 2 Reforged.png

Me, Hubry, and ImmortalPharaoh7 are representing the FTB Wiki at Modoff 2: Reforged! In case you don't know what it is, Modoff is a modding competition where participants are tasked to make a mod in a 9 day period (similar to ModJam). Me, Hubry, and Immortal, and any other interested editors, are sponsoring the event by documenting the top three mods from it (plus perhaps any mods we particularly like). The Modoff server is open right now for modders to display their creations and for viewers to vote on which one(s) they like the the most. We have our own plot as well, as you can see above, and I highly encourage you to visit it. A lot of the mods are real cool, and I spent a good bit of time working on our booth and it actually turned out pretty good so yeah. On February 18th, the results of the competition will be released, and me/Hubry/Immortal/any interested editors will start documenting the top three mods shortly after. Their website has issues so here is a link to a Reddit announcement with a bit more info. -Xbony2 (talk) 22:15, 8 February 2018 (UTC)

Modoff is over! The top three winners are Glacidus, Gaspunk and E-Vaporate. Me, Hubry, and ImmortalPharaoh7 intend to split them up somewhat (currently plan is Glacidus is jointly documented by me and Immortal, Gaspunk is documented by Hubry, and E-Vaporate is documented by me). If you are interested, and you might be, in documenting any mods from Modoff, I certainly encourage you to. Most of the mods made were pretty cool imo. Hubry said he's definitely going to document Dazzle, and I see myself documenting End: Reborn. Everything is up for grabs of course if you are interested; just go for it. -Xbony2 (talk) 15:23, 18 February 2018 (UTC)
Sorry Hubry I documented Dazzle -- SatanicSanta馃巺FTB Wiki Admin 23:52, 21 February 2018 (UTC)
Pressurized Defence is done -- SatanicSanta馃巺FTB Wiki Admin 19:56, 22 February 2018 (UTC)
End: Reborn is done -- SatanicSanta馃巺FTB Wiki Admin 22:31, 10 April 2018 (UTC)

Quest Book template[edit source]

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[edit source]

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. -- SatanicSantaFTB Wiki Admin 21:30, 5 April 2018 (UTC)

We should do this. I am against the spoiler idea though. 馃悋Retep998馃悋馃惏Bunny Overlord馃惏
What it鈥檚 released for doesn鈥檛 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[edit source]

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)

Promotional Content