Feed The Beast Wiki:Centralized discussion

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)

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)

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)

Here is an updated version of Block Renderer for 1.14 and beyond (Both Forge and Fabric), if some of you didn't find it by now: https://www.curseforge.com/minecraft/mc-mods/block-renderer --Underfell Flowey (talk) 09:13, 18 October 2020 (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)

Tag system

After Minecraft released a new tag system for 1.13, Forge also replaced its OreDictionary it. We need to create Tag templates similar to current OreDict templates (I can't, as I'm not staff and thus can't create Special Pages.). Though it isn't very important for now, as FTB only has 3 modpacks for 1.14+, 2 of which are Unstable. --Underfell Flowey (talk) 09:13, 18 October 2020 (UTC)

We can use the oreDict template for tags. - AstroFlux (talk) (contributions) 16:04, 18 October 2020 (UTC)

After we add tags to its database, that is. --Underfell Flowey (talk) 16:43, 18 October 2020 (UTC)

We already have an OreDict extension that is in use. I'm not sure what changed in the tag system in 1.13, but it is something I could research. I don't think much changed however, and the oredict entries can just be updated. Only editors can update oredict entries at this time, but they are located at Special:OreDictList and Special:OreDictEntryManager. -- SizableShrimp🦐 (talk · contribs) 00:19, 19 October 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)

Is this wiki cool with articles regarding add-ons and mods for Bedrock Edition?

I'm new to this wiki and I'm wondering if there's already a system in place for Bedrock mods and add-ons. I can contribute documenting those, I'm just making sure that this wiki is cool with that. Y'know, like support in infoboxes, specific categories, stuff like that. Yivan000 (talk) 08:20, 3 December 2020 (UTC)

As discussed in Discord, yes this wiki does support documenting Bedrock Edition mods, addons, etc. If you find a template that exists for Java Edition that you need modified or a different version for Bedrock, please let me know. Also, to help with separating content, please place {{Bedrock}} at the top of all content articles relating to Bedrock Edition, as you are already doing. I believe hatnotes go above amboxes (e.g. you place {{About}} above {{Bedrock}}), so if you get confused just go with that. Thanks! -- SizableShrimp🦐 (talk · contribs) 18:02, 3 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)

• Neutral. -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 ^talk_contribs 🍕 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.	„
	— WP:HATNOTEPLACE

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

Propose to add "fluid" to {{Infobox ore}}

Since the go-to infobox for articles of chemical elements is {{Infobox ore}}, there should be a way to add fluids to the existing infobox, like the fluid form of the ore/element (different from the "molten" parameter). However, there is no way to add them, except for the others parameter, but that shouldn't be the place for a common type like fluids. To stop causing confusion, I propose that there should be another field in {{Infobox ore}} specifically for fluids.— 🍕Yivan000 ^talk_contribs 🍕 16:21, 21 December 2020 (UTC)

• This isn't a very controversial change and doesn't take much effort so I will go ahead and add this field. -- SizableShrimp🦐 (talk · contribs) 06:18, 27 December 2020 (UTC)