Feed The Beast Wiki:Centralized discussion

From Feed The Beast Wiki
Jump to: navigation, search

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

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 neutral.pngNeutral. -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.
WP:HATNOTEPLACE

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

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

Wire Coil



ModImmersive Engineering
TypeCable
Energy
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)