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. Thoughts? -Xbony2 (talk) 00:15, 14 March 2016 (UTC) --  Satanic Santa 🎅F T B Wiki Admin 02:44, 14 March 2016 (UTC)
 * 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.
 * 1) 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.
 * 1) 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.
 * 1) 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.
 * 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.
 * k
 * 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
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. --  Satanic Santa 🎅F T B Wiki Admin 19:17, 3 November 2017 (UTC)
 * My first attempt is rough.
 * [[File: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
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. 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. --  Satanic Santa 🎅F T B Wiki Admin 02:40, 9 January 2018 (UTC)
 * --  Satanic Santa 🎅F T B Wiki Admin 02:40, 9 January 2018 (UTC)
 * --SirMoogle (talk) 04:11, 9 January 2018 (UTC)
 * 04:19, 9 January 2018 (UTC)
 * -- sokratis 12GR 🎅 Staff  09:30, 9 January 2018 (UTC)
 * . 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)
 * , it looks best IMHO. -- Hubry  (talk) 20:47, 10 January 2018 (UTC)
 * , Simple is best. Crazierinzane

Results
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. --  Satanic Santa 🎅F T B Wiki Admin 22:18, 27 March 2018 (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). 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". --  Satanic Santa 🎅F T B 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, 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)

"Minecraft versions" infobox mod parameter
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. --  Satanic Santa 🎅F T B Wiki Admin 21:30, 5 April 2018 (UTC)
 * We should do this. I am against the spoiler idea though.
 * 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
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. 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. --  Satanic Santa 🎅F T B 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
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. 23:20, 19 June 2018 (UTC)


 * I vote for . 23:20, 19 June 2018 (UTC)
 * I vote for
 * --  Satanic Santa 🎅F T B Wiki Admin 23:21, 19 June 2018 (UTC)
 * --  Satanic Santa 🎅F T B Wiki Admin 23:21, 19 June 2018 (UTC)


 * I vote for ¯\_(ツ)_/¯ -Xbony2 (talk) 23:34, 19 June 2018 (UTC)
 * First choice: ; Second choice:  - DSquirrelGM &#120035;&#120031;&#120018; &#128504; 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 . --SirMoogle (talk) 05:11, 20 June 2018 (UTC)
 * I vote for . Indestructible Pharaoh VII 11:06, 20 June 2018 (UTC)
 * I also vote for . -- Hubry  (talk) 11:07, 20 June 2018 (UTC)

Results
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 as the representative, so that will be forwarded on to Slowpoke.

Using the Pn template in guides
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. 15:50, 22 June 2018 (UTC)
 * Sí.--  Satanic Santa 🎅F T B Wiki Admin 21:31, 22 June 2018 (UTC)

Tick conversion template
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" --  Satanic Santa 🎅F T B 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) --  Satanic Santa 🎅F T B 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)