Difference between revisions of "Feed The Beast Wiki:Staff's Noticeboard"

From Feed The Beast Wiki
Jump to: navigation, search
(→‎Extension:SpriteSheet: my dumb suggestion)
Line 521: Line 521:
   
 
: Maybe I'm oversimplifying stuff but it might be possible to use some dumb template + css trick? make a template that loads a file as a background image with <nowiki>{{filepath:}}</nowiki> and use css to get the right sprite? might be worth a shot if we just need a simple solution. -- <div class="rainbow-ignore upside-down">'''[[User:Jinbobo|<span style="color:blue">Jin</span>]][[User talk:Jinbobo|<span style="color:green">bo</span>]][[Special:Contributions/Jinbobo|<span style="color:red">bo</span>]]'''</div> 06:22, 22 July 2016 (UTC)
 
: Maybe I'm oversimplifying stuff but it might be possible to use some dumb template + css trick? make a template that loads a file as a background image with <nowiki>{{filepath:}}</nowiki> and use css to get the right sprite? might be worth a shot if we just need a simple solution. -- <div class="rainbow-ignore upside-down">'''[[User:Jinbobo|<span style="color:blue">Jin</span>]][[User talk:Jinbobo|<span style="color:green">bo</span>]][[Special:Contributions/Jinbobo|<span style="color:red">bo</span>]]'''</div> 06:22, 22 July 2016 (UTC)
  +
  +
:: Scottkillen makes a good point there too. Very thoughtful, I like it. -- <div class="rainbow-ignore upside-down">'''[[User:Jinbobo|<span style="color:blue">Jin</span>]][[User talk:Jinbobo|<span style="color:green">bo</span>]][[Special:Contributions/Jinbobo|<span style="color:red">bo</span>]]'''</div> 06:33, 22 July 2016 (UTC)
   
 
<!-- Please do not edit below this line -->
 
<!-- Please do not edit below this line -->

Revision as of 06:33, 22 July 2016

Category overhaul

Everything related to categories is terrible. To start, we have changed the policy to allow for multiple categories per page. To make this more useful, we will be creating more descriptive categories. The following list of new categories will be updated as we add more:

We are also going to be renaming some categories and reevaluating their usefulness. The following categories need to be renamed and/or reevaluated:

  • Base
  • Resource Page
  • Transformation
  • Other
  • Converters
  • Portable
  • Sorting
  • Pipes
  • Tubes
  • Conduit
  • Modules
  • Attributes
  • Redpower
  • Miscellaneous Automation

The following categories have been replaced:

This project is more clearly documented on its project page.

Please discuss stuff. -- SatanicSantaFTB Wiki Admin 22:14, 8 February 2015 (UTC)

Okay so I have a few ideas with some of those; namely pipes, conduits and tubes etc..
My suggestion is to use categories that are bit more inclusive such as Fluid Transportation, Item Transportation, Energy Transportation which could each respectively classify things like BC pipes, IC2 Cable and Fluiducts. Another group of categories to assist this could be Item Storage, Fluid Storage, and Energy Storage which would classify items such as IC2 Batteries as well as BC Tanks
These could then also be supplemented (only for the energy ones) by the specifics such as RF Power or EU Power.
To recap how this would look
Wolfman_123_ · FTB Wiki Staff 04:37, 12 February 2015 (UTC)
Small continuation after looking through some more categories; I believe Modules is perfectly fine as it's simply just Steve's Carts modules which would be categorized as (Steve's Carts)-(Modules)
I also believe Attributes is fine however it may need a renaming to Genomes or something like that (I think this is the word Forestry uses to describe them, but please don't quote me on that)
Wolfman_123_ · FTB Wiki Staff 04:50, 12 February 2015 (UTC)
Last one I hope...
Can someone please explain what the hell Base is supposed to be as I don't really see much of a link between all of the content.
Wolfman_123_ · FTB Wiki Staff 04:52, 12 February 2015 (UTC)
I think Base is being used for machines that would be part of a large-scale industrial base? I'm not entirely sure though, there's one or two outliers in that.
Maybe it's for for pages that act as the base point for some form of industrialization, and are built on from there? Like 'components' but larger scale?
You're right though, there is not a lot of consistency across that category. PaladinAHOne Staff (talk) 07:01, 12 February 2015 (UTC)
Oh god then I realized that Forge and FML were in Base... What the hell was this category even?? PaladinAHOne Staff (talk) 19:44, 12 February 2015 (UTC)
Base is one of those categories that you just wonder what the hell went wrong. Really, it should either just have base mods like Forge and FML in, or they should go in Base Mod and I guess Base deleted. Chocohead NagEditsStaff 19:50, 12 February 2015 (UTC)
I'm not quite sure what to do about Forge and FML, but I have an idea for all the generators in that category sticking with the theme above.
* (IndustrialCraft 2)-(Energy Producer)-(EU Power)
* (Thermal Expansion)-(Energy Producer)-(RF Power)
Wolfman_123_ · FTB Wiki Staff 23:56, 12 February 2015 (UTC)
Base was for energy generators. The problem with Modules is it's too broad. It could mean SC modules, modules of mods, etc. Same goes for Attributes. I agree with your transportation stuff. -- SatanicSantaFTB Wiki Admin 02:51, 13 February 2015 (UTC)
Are you continuing on doing this? — NickTheRed37t · ru.MCW user
c · ru translator
13:18, 14 March 2015 (UTC)
I've been busy with other stuff, but it will be completed at some point. -- SatanicSantaFTB Wiki Admin 19:10, 14 March 2015 (UTC)
I may later think of an image of what I want to have as a category tree. — NickTheRed37t · ru.MCW user
c · ru translator
06:13, 30 March 2015 (UTC)
For those interested, I have been working on the categorization stuff. I moved Energy Transport -> Energy Transportation. -Xbony2 (talk) 14:48, 4 April 2015 (UTC)
So, uh, what is a consumer called? Like, Macerator (IndustrialCraft 2) or Induction Smelter. I'd propose something like:

-Xbony2 (talk) 15:11, 4 April 2015 (UTC)

Why did you put Miner in Cables? :P Chocohead NagEditsStaff 22:29, 4 April 2015 (UTC)
I didn't do it! :P I'm not even listed in the history of the page. -Xbony2 (talk) 22:46, 4 April 2015 (UTC)
So you just edited Cables... Alistaire14820 added Miner to it years ago. :| Our categories are so screwed up. Chocohead NagEditsStaff 23:22, 4 April 2015 (UTC)
btw, can you look over Energy Units? Thanks. -Xbony2 (talk) 23:31, 4 April 2015 (UTC)
since nobody loves me, I'm going ahead with my proposition :P -Xbony2 (talk) 13:33, 8 April 2015 (UTC)

I have created a utility that can help us along with phase 1 of the Category Overhaul greatly. It requires Ruby, and the mediawiki_api gem created by wikimedia (be sure to use 0.3.1 as the newer versions are broken). You can find it in the SatanicBot repo. You will need to create your own secure.txt file with the formatting "USERNAME \newline PASSWORD". Alternatively you can just edit your clone of generalutils to use your username and password. -- SatanicSantaFTB Wiki Admin 23:00, 19 August 2015 (UTC)

Templates that may want to be made

(Altars are popular these days) -Xbony2, Master of Feed The Beast Wiki (talk) 01:47, 2 November 2015 (UTC)

-Xbony2, Master of Feed The Beast Wiki (talk) 00:31, 3 November 2015 (UTC)

All from MineChem. -- SatanicSantaFTB Wiki Admin 20:51, 19 December 2015 (UTC)

I think over the free days I'll create the template for the Decomposer. --LuminousLizard de-native / "en-B2" (talk) 21:54, 22 December 2015 (UTC)

-Xbony2 (talk) 13:20, 30 December 2015 (UTC)

-Xbony2 (talk) 13:22, 30 December 2015 (UTC)

-- SatanicSantaFTB Wiki Admin 02:14, 29 February 2016 (UTC)

I will do that in the next days. Should I create a normal navbox or a module ? --LuminousLizard de-native / "en-2" (talk) 20:16, 3 April 2016 (UTC)
From quickly looking at the mod, it looks like it adds a lot of content, so I'd recommend a module if it doesn't make you uncomfortable. -Xbony2 (talk) 20:47, 3 April 2016 (UTC)
Done from my side ! Navbox created and tilesheets uploaded. Problem not solved .. should someone else make the rest => Section: Problem with SheetImporter -- Preceding unsigned comment was added by LuminousLizard (talkcontribs)

All of the GUIs can be found here. Thanks -Xbony2 (talk) 14:04, 30 March 2016 (UTC)

I'll make the last 3 in the list this weekend. Btw your link is broken ... but I can extract the GUIs out of the mod. --LuminousLizard (Wiki Staff and Editor) de-N / "en-2" (talk) 07:26, 16 April 2016 (UTC)
Yeah, Pam removed her machines in 1.8. Your link looks broken too :P In your preferences, you can set the "page type" to "Use a standard user wiki page" so User:LuminousLizard is your regular page, and UserProfile:LuminousLizard is the default global one. -Xbony2 (talk) 12:11, 16 April 2016 (UTC)
Done ! The link to my page is ok for me. One page is for a brief overview and the other for more, if interested.

The working stations from Tinkers' Construct. I will create the Stencil Table this weekend. --LuminousLizard (Wiki Staff and Editor) de-N / "en-2" (talk) 07:26, 16 April 2016 (UTC)

Why don't we have this... -Xbony2 (talk) 00:06, 25 May 2016 (UTC)

  • {{Cg/Drying Rack}} from TiCo, since it got a shit ton more recipes added to it in 1.9/1.10. -- SatanicSanta🎅FTB Wiki Admin 01:26, 11 July 2016 (UTC)

Mods that need devoted editors

Hey guys. What mods do you think need devoted editors? These would be kind of like mod-appointed developers, except that they would be recruited by higher-up FTB Staff Members. My current list goes something like:

  • All SlimeKnights mods (Tinkers' Construct, Tinkers' Mechworks, Tinkers' Steelworks, Natura)
  • Engineer's Toolbox
  • All CoFH mods (Thermal Expansion of all notable versions, Thermal Foundation, CoFH Core, etc)
  • Thaumcraft of all versions
  • Mekanism
  • Universal Electricity mods

Please provide your thoughts. -- SatanicSantaFTB Wiki Admin 21:28, 11 November 2015 (UTC)

Pictogram voting oppose.pngNo on Universal Electricity. That mod is dead. -Xbony2, Master of Feed The Beast Wiki (talk) 22:17, 11 November 2015 (UTC) oh and...

-Xbony2, Master of Feed The Beast Wiki (talk) 22:20, 11 November 2015 (UTC)

--LuminousLizard de-native / "en-B2" (talk) 09:50, 30 December 2015 (UTC)

I already mentioned that xd -Xbony2 (talk) 12:54, 30 December 2015 (UTC)
Sorry ... should only mean that I'm working something about it. --LuminousLizard de-native / "en-B2" (talk) 20:17, 1 January 2016 (UTC)

Final list for slow

Mods

I have been working on Tinkers' Construct a bit and Tinkers' Steelworks, and plan on being more active now to continue work. I'll gladly work on the other SlimeKnights mods once I finish the two Tinkers' –KnightMiner t/c 03:36, 20 February 2016 (UTC)
I'll start documenting Tinkers' Construct very soon, because I saw no progress made to it and TiC (Tinkers' Construct) in 1.9 have major changes that must be documented. --sokratis12GR Staff 05:17, 4 June 2016 (UTC)
I'll gladly deal with these, I'm already working on RoC, ReC is coming soon once I get home. (Need the tilesheet files, which are on my home pc). ChromatiCraft is the only mod I'm unfamiliar with, so someone else may have to do it or let it wait a bit until I become familiar with it. Up to you guys. Luke14199 (talk) 11:09, 10 January 2016 (UTC)

Getting Started Guide writer(s)

General Guide writers

I have a plan to write a ChromatiCraft guide in the near future. Luke14199 (talk) 10:19, 19 February 2016 (UTC)

Anything else you or the modpack team deem necessary. We also need translators of all languages, and general editors of all types.

-- SatanicSantaFTB Wiki Admin 22:16, 29 December 2015 (UTC)

More reliable communications with the rest of the organization. -PaladinAHOne Staff (talk) 20:50, 30 December 2015 (UTC)
meh -Xbony2 (talk) 21:50, 30 December 2015 (UTC)
I'd recommend using the teamspeak we have tbh, anyone working on the same project could communicate more efficiently. Admins could have their own channel, etc etc. Or if this is not an option, perhaps we could setup a forum or subforum somewhere? Just my 2 cents. Luke14199 (talk) 11:03, 10 January 2016 (UTC)
Teamspeak is kind of annoying because not everyone can use a microphone. We have Slack and IRC right now and it seems to be doing okay. We do have a subforum, along with the wiki staff's own barely-used hidden subforum. -- SatanicSantaFTB Wiki Admin 11:48, 10 January 2016 (UTC)
The wiki staff are super-crazy, I don't want to talk to them :P -Xbony2 (talk) 13:24, 10 January 2016 (UTC)
How much do you want ComputerCraft covered here? It does have an official wiki written by a large group of ComputerCraft fans (including myself), and I'd prefer not to have duplicate information between the two wikis. I would suggest having just a basic description of the features here, and leaving all content related to programming in ComputerCraft Lua to the official wiki. –KnightMiner t/c 03:36, 20 February 2016 (UTC)
This wiki is basically meant to include all information about all mods ever... which includes lua programming in ComputerCraft. It just wouldn't be complete without it. -Xbony2 (talk) 13:09, 20 February 2016 (UTC)
It may not be complete without it, but there still is the issue that covering ComputerCraft in its entirety would basically make this wiki be competing with with official wiki, and do we really want another case of multiple wikis competing to cover modded Minecraft?. Also, the majority of ComputerCraft fans seem to already contribute to the official wiki, so it would be a lot harder to get contributors here (on a personal case, I really could not write articles on the available APIs without copying from the official wiki, as nearly everything I know about programming in ComputerCraft comes directly from the official wiki).
Maybe we could include programming as it relates to other mods, such as a lot of the information on OpenPeripherals, and some tutorials might be relevant, but leave the specific functions and APIs to an interwiki link? –KnightMiner t/c 21:56, 20 February 2016 (UTC)
I agree with you that we should keep API docs to the CC wiki. However, that isn't to say we can't have very detailed articles about CC. -- SatanicSantaFTB Wiki Admin 22:16, 20 February 2016 (UTC)
This wiki is meant to be all-encompassing; linking to the CC wiki for the API docs and whatnot is fine, but that doesn't mean documenting those APIs here isn't something that can't be done and doesn't mean that that documenting the APIs here isn't something that isn't on the "ultimate TODO list" or "ultimate agenda" of the wiki. -Xbony2 (talk) 01:28, 21 February 2016 (UTC)

Blocking policy

Feed The Beast Wiki:Blocking policy should be a thing. And while this message sits in this noticeboard, someone at some point will do it. That someone is not me because I worded it badly when I tried and it looked stupid. -Xbony2 (talk) 23:25, 2 February 2016 (UTC)

I think the whole principle of a noticeboard is rather undermined if things are done after the requests are removed from it ;) Chocohead NagEditsStaff 23:31, 2 February 2016 (UTC)

Navbox Requests

Hey guys, I figured that since we don't really have a section for requests of people making navboxes, and I'm completely out of my depth in this regard, would someone mind helping me create the ChromatiCraft navbox? I can help with the categorisation and organisation of the pages, I just need someone to write the code. Cheers, Luke14199 (talk) 22:53, 19 February 2016 (UTC)

It's not really code; well, it is, but the formatting is constant and easy to copy. Just start with this:
--<languages />
--<pre>
local p = {}
p.navbox = function(navbox, highlightline, group, list, line, ni, l)

local cc = l{"ChromatiCraft", [=[ChromatiCraft]=]}

local blocks = [=[Blocks]=]
local generators = [=[Generators]=]
local consumers = [=[Consumers]=]

local items = [=[Items]=]
local tools = [=[Tools]=]
local components = [=[Components]=]

return navbox{title = cc, mod = "CRC",
	group{name = "blocks", title = blocks,
		list{title = generators,
			ni{"Generator", "Generator (ChromatiCraft)", "Generator"},
			ni{"Superduper Generator"}
		},
		list{title = consumers,
			ni{"Super Macerator"},
			ni{"Super Macerator"}
		}
	},
	group{name = "items", title = items,
		list{title = tools,
			ni{"Teleporty Thingy"},
			ni{"Drill of Doom"}
		},
		list{title = components,
			ni{"Drill Head of Doom"},
			ni{"Pizza"}
		}
	},
}

end
return p
--</pre>

extend it, and put it at Module:Navbox/ChromatiCraft. I'll add the translation tags. -Xbony2 (talk) 00:33, 20 February 2016 (UTC)

Just FYI, I have started scratching: User:3tusk/Sandbox/Navbox_ChromatiCraft. T3==ThaumicTechTinker, Urey.S.Knowledge Welcome back, commander 03:06, 18 June 2016 (UTC)

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

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

Vegan/Vegetarian Categories

So, the Vegan and Vegetarian Food categories are shit. Most of the things in them are not inherently vegan, but have the option to be made with vegan things (e.g., Apricot Glazed Pork can be made with Tofu since it is made with the listAllporkcooked oredict). We need some sort of change to the way these categories are set up. I don't know how though. -- SatanicSantaFTB Wiki Admin 00:11, 17 April 2016 (UTC)

How about having the sub-category substitute for them both, and things that can be cheated using Tofu can go in those. Chocohead NagEditsStaff 00:19, 17 April 2016 (UTC)
Proposing the categories of-

To replace the current categories. I don't think we need to have a category that includes cheaty substitutes, since most MC foods can use said cheaty substitutes. -Xbony2 (talk) 23:45, 19 April 2016 (UTC)

And a philosophical question- if I cheat in a Raw Chicken from NEI, does it count as vegan/vegetarian because no chickens were hurt in the process? -Xbony2 (talk) 23:47, 19 April 2016 (UTC)
I live with vegans and am friends with a lot of vegans, and I hear "non-vegan" quite a bit when referring to food made with animal. So I think that's a fine name for a category. Otherwise, there's also omni/carnivorous which get used a lot as well. -- SatanicSantaFTB Wiki Admin 00:03, 20 April 2016 (UTC)

New editor retention, an invitation

As former wiki lead, I invite everyone to participate in the discussion on the issue of editor retention: Admin's noticeboard -- Jin. (so xbony2 doesn't think i'm jc)

The Wiki's look via mobile

This is a question and suggestion about the mobile look. To start, via mobile you can't access Special pages like Recent Changes and such except if you search their full names. Other thing is tang you can't open stacked up changes for a page, I mean that the button doesn't work as intended, you have again manually to look for the change you want, or look it via viewing all the changes until you find the right one. Other thing is that you can't access page's talk or go to other.pages like, http://ftb.gamepedia.com/user:sokratis12GR and http://ftb.gamepedia.com/UserProfile:sokratis12GR you once again have to search this things. Other thing that's really bad is "sections", for achievements, sub headers and such. They are pretty bad , especially on user profiles and talk pages --(sokratis12GR, My Phone) --94.69.171.110 14:42, 5 July 2016 (UTC)

Yeah, the mobile situation is bad \o/ -Xbony2 (talk) 15:04, 5 July 2016 (UTC)
Not being access the special pages is annoying, but from an end user perspective, the issue is {{Gc}} doesn't show up, and navboxes don't either. It makes navigation even more clunky and frustrating, as well as defeating the point of most pages as the {{Gc}} that is in the infobox and crafting template(s) is normally the most useful part because people want to know what the item/block looks like and how it's made, which on mobile you just aren't shown. Chocohead NagEditsStaff 15:21, 5 July 2016 (UTC)
Another things that are really bad mostly for editing are that you can really easily by mistake click the back button while editing and you will lose your entire edit/page creations, because there is no warning to stop you, other shitty thing is that your text is overlayed with somewhat transparent black color, I can list a lot more things that needs to be fixed/changed, other thing also is that whenever you have added a page to your "Watch list" they aren't shown like they are watched. Well I think Cblair92 can help fix this issue --sokratis12GR Staff 18:19, 5 July 2016 (UTC)
Tis Cblair91. Well, Developaws, but it doesn't seem her account's name has fully migrated.
Editing pages doesn't really work on mobile in general. I don't think that's going to be improved much, but viewing pages certainly. -Xbony2 (talk) 00:33, 6 July 2016 (UTC)
About wiki's look via mobile. Because of CSS not working on mobile makes pages look ugly and don't have a structure, other thing is that templates & modules override their place and load exactly where they are added, like a Babel info if added in the middle of 2 Sections it will be written inside the one section and won't have lines or "ending points" which are would be better if they were there for the reader --sokratis12GR Staff 11:04, 6 July 2016 (UTC)
Also, I other thing I want to add is, take a look at https://minecraft.gamepedia.com/ It is more otginized for mobile and they also have a mobile app on Google play . Which is really well done for mobile (some things still arent). --sokratis12GR Staff 11:10, 6 July 2016 (UTC)

Necessity of the staff system

This wiki is known for the editorial staff system which is rarely met on other wikis. I don’t like inequalities that I sometimes see between the staff users and regular ones, but there comes a bigger question: is this staff system necessary at all? Minecraft Wiki doesn’t use it. Memory Alpha (the main Star Trek wiki) doesn’t use it. Wikipedia doesn’t use it. And they are all working well.

So I propose to avoid excess bureaucratization and break the current backbone of this wiki, so a more democratic system takes its place. As a compensation, if the staff system is going to be removed, I propose to do these things:

  • Grant full administrator (not bureaucrat) status to Xbony2, and possibly Chocohead.
  • Add reupload, editoredict, edittilesheets, translatetiles and all move* rights to autoconfirmed users. importoredict and importtilesheets should remain for administrators, number of whom will be already increased.

— NickTheRed37 (talk) 16:08, 14 July 2016 (UTC)

what inequalities exactly? -- SatanicSanta🎅FTB Wiki Admin 17:01, 14 July 2016 (UTC)
Inequalities such as votes where only staff members can participate in. Approval of a new staff member, for example, has to be discussed by everyone. — NickTheRed37 (talk) 17:05, 14 July 2016 (UTC)
do non staff even want to vote for staff members though? There aren't really votes that non staff members are excluded from that they'd even care to participate in. I can't remember if we still do this, but we used to encourage everyone to participate in staff votes-- turns out non staff members care more about content than user rights. I think at most we had 1 non staff member participate in a staff vote. -- SatanicSanta🎅FTB Wiki Admin 17:34, 14 July 2016 (UTC)
If we had non-staff that did vote, we'd honestly probably just let them vote. -Xbony2 (talk) 18:44, 14 July 2016 (UTC)
Anyway, I very strongly do not trust regular users with oredict/tilesheet rights. They are technical and easily abusable. And I do not want those rights to remain with three administrators, particularly when two of those administrators' activity happens to resemble the moon. This is one of the reasons we have staff, among a few others.
I've talked a good bit about merging administrator and bureaucrat. I just don't understand why you trust me with your personal JavaScript but don't trust me with access to assigning groups. That just seems silly to me. -Xbony2 (talk) 18:53, 14 July 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── You are being very inconsistent here xbony. You claim that we have staff because we don't trust regular users with the oredict/tilesheet extension (is this reason a priori? Staff came way before these extensions.) yet you claim that we should trust admins automatically with bureaucrat rights. I don't know you too well as I've only interacted with you a few days, but the impression I get from your response is that you're just salty that your aren't admin and bureaucrat.

The difference in responsibility between staff and editors is virtually nothing when compared to that between admin/bureaucrat. You have been against removing staff rank but you're for merging admin and bureaucrat together. Your argument is even more absurd when put into this perspective: "I don't understand why you trust me with your personal JavaScript but don't trust me with access to assigning group". I don't see any logical connection between trusting you with javascript and trusting you with groups. If I following along with your line of thought, I should be giving staff ranks to editors because "I trust them not to screw up". Personally, I find your position and motivation to be highly suspicious.

To sum up your argument in one sencence: The tilesheet/oredict extensions are more abusable than bureaucrat rights. Which is totally absurd.

This comment was reworded for clarity. --

04:04, 15 July 2016 (UTC)

uwot
Tilesheet/oredict stuff is not the only reason we have staff. It's just one of them. Patrolling, staff protection and banning are some of the other reasons- rights that certainly don't fit into my "editor" group (or autoconfirmed or whatever), and that shouldn't be restricted to the one and half admins. There's also other reasons we staff that aren't really related right-related; staff is partially more of a "title group" in that sense. Welcoming newcomers, making sure templates are made and applied right, making sure translations are done right, etc, stuff that non-staff don't do.
I am quite salty about that. I'm also quite salty that you're calling me an ignorant asshole. I'm also quite salty that I'm the only staff participating in these debates, that none of the staff have really stepped in to defend or rebuke me. But, it's more than that.
Anyway, JavaScript access, adminship in general, shows a very high level of trust. Admins can nuke user contributions. Admins can insert malware into the global JS. What greater level trust is there? Letting the admin raise your babies? :P (I'm not open for that by the way, in case you couldn't tell I was joking). I don't think assigning groups is a greater level of trust, but if it is, it is not by much at all.
Tilesheet and OreDict rights are abusable, but also technical. The trust is in both not abusing it, and not breaking it. If a user edits a hundred pages incorrectly, then we can nuke their contributions. If a user edits a hundred ore dictionary requests incorrectly, then we're shit screwed, and I have to spend an hour reverting their changes.
Btw, if it happens to interest you, my wiki survey shows that, so far, people who don't contribute very much don't contribute very much for a number of reasons. Lack of time is the leading reasons at the moment, with 19 votes, followed by lack of interest with 11 votes. Complex and unfair groups? Zero votes. You'd think it would get at least one vote, but I guess not. Users can select multiple reasons, btw, before someone accuses me of fucking that up. I'm not ready to release the full results yet, or call them full results (going to on August 1st), but this the group situation is one you (and me too, to be fair) have made a much greater fuss about than users really care about it. -Xbony2 (talk) 11:55, 15 July 2016 (UTC)
That’s why I suggest assigning a few new administrators, so their number increases to at least four (SatanicSanta, Retep998, you (Xbony2), Chocohead). Speaking of bureaucrats, if we want someone with rights assigned, and no bureaucrats are active, we can always talk to Curse.
Welcoming new users and checking what is done correctly can be done by anybody. I myself once welcomed a few users in Russian Minepedia, although I didn’t have any rank or title. Added in 14:06, 15 July 2016 (UTC)
I have an idea: create separate user groups for ones that are permitted to edit either tilesheets or OreDict database, if not more. That’s similar to Wikipedia: there are separate groups for users with auto-patrolled edits, patrollers, rollbackers, ones that can rename without making redirects, “template editors” (ones who can edit some protected templates) and (as I’ve seen in Russian Wikipedia) even ones that can upload files. We already have something like that, in the form of banhammer user group. Similar thing can be made here.
Tilesheet editors (tilesheeteditor, new usergroup)
  • Edit entries for the OreDict extension (editoredict)
  • Translate tile names and descriptions for the Tilesheets extension (translatetiles)
OreDict editors (oredicteditor, new usergroup)
  • Edit tile data for the Tilesheets extension (edittilesheets)
Administrators (sysop, additions to existing group)
  • Add groups: Tilesheet editors, OreDict editors
  • Remove groups: Tilesheet editors, OreDict editors
— NickTheRed37 (talk) 14:00, 15 July 2016 (UTC)
P. S. Special:Nuke is for deleting new pages, not reverting new edits. — NickTheRed37 (talk) 14:06, 15 July 2016 (UTC)
Yuck. I'd rather not have staff rights be cut up into pieces. Part of my group proposal seeks to eliminate that.
Also- there's something I disagree with you on, that I'd like to mention. Wikipedia and Wiktionary do have staff- it's just they're called administrators, bureaucrats and stewards there. The staff here are like the administrators there, but without access to JS and a few other tools. -Xbony2 (talk) 14:33, 15 July 2016 (UTC)
You’re lying. Majority of active editors on Wikipedia seem to be simple users. — NickTheRed37 (talk) 15:30, 15 July 2016 (UTC)
I didn't say otherwise. But the "staff" there are the same as the staff in the fact they administer the wiki. -Xbony2 (talk) 15:49, 15 July 2016 (UTC)
Then why we need a separate usergroup? I, once again, think that assigning new administrators, introducing the new microgroups that I proposed, and respreading the responsibilites will do the thing. — NickTheRed37 (talk) 16:26, 15 July 2016 (UTC)
But why have all the sloppy microgroups when you can roll it all in one group?
Also, random thing I noticed- technically, there's no written rule that states non-staff can't vote, at least any that I could find. It is a written rule of my group proposal, though, but I'll probably remove it; I personally don't see a problem with non-staff voting, even though they generally haven't expressed a desire to vote. -Xbony2 (talk) 16:50, 15 July 2016 (UTC)
Because the system will become more flexible when using them. Think yourself: why do we have the banhammer group if we could otherwise incorporate the only right it gives (the right to block users) into the staff usergroup? — NickTheRed37 (talk) 17:03, 15 July 2016 (UTC)
to whoever suggested having curse folks assign groups (I'm on mobile): that's a horrible idea. They have plenty of other shit to deal with, so it might take much longer than if me or Peter are to do it. I only really bother them when extensions get updates (mostly Tilesheets and OreDict-- HeaderCount rarely updates and they handle most other extensions globally). Also, editors get the translate tiles right, by the way. It's significantly less powerful than the other Tilesheets rights. -- SatanicSanta🎅FTB Wiki Admin 18:11, 15 July 2016 (UTC)
I do want to put the banhammer right into the staff group. That's part of my proposal.
I think Nick means Curse can assigns groups if we really need it, like if you and Retep get got or something. -Xbony2 (talk) 19:59, 15 July 2016 (UTC)

Cg and tile request

First person to do all the above gets cookies. Developaws (talk) 08:30, 20 July 2016 (UTC)

The tilesheet images you've provided are broken o-o black backgrounds, some tiles not being rendered at all. I'll see if I can re-dump them and get back to you. -Xbony2 (talk) 12:21, 20 July 2016 (UTC)
Can you provide the actual GUI images from the assets instead of in-game screenshots? -- SatanicSanta🎅FTB Wiki Admin 18:47, 20 July 2016 (UTC)
No from what I remember, since it's generated by a combination of components and stuff. -Xbony2 (talk) 01:22, 21 July 2016 (UTC)
Galacticraft done (abbreviated under GAL) -Xbony2 (talk) 01:50, 21 July 2016 (UTC)
Gah that's infuriating. Most GUIs are made from a combination of components, but at least they stay on the same damn image! -- SatanicSanta🎅FTB Wiki Admin 02:44, 21 July 2016 (UTC)
Mekanism tilesheet done ^_^ (abbreviated under MEK). I'm happy to do the templates, but Retep gets mad when I make Cg images so I'll leave that part to him. -Xbony2 (talk) 16:33, 21 July 2016 (UTC)

DAC appointment

I am officially appointing myself to document my mods. -- ScottKillen [] 19:39, 20 July 2016 (UTC)

  • Pictogram voting support.pngSupport. You seem to understand wikitext and have a passion for editing. 🐇Retep998🐇🐰Bunny Overlord🐰 21:57, 20 July 2016 (UTC)
  • Pictogram voting support.pngSupport: Nice to see some new enthusiasm helping documenting new mods Chocohead NagEditsStaff 22:29, 20 July 2016 (UTC)
  • Pictogram voting support.pngSupport. -Xbony2 (talk) 00:03, 21 July 2016 (UTC)
  • Pictogram voting support.pngSupport -- SatanicSanta🎅FTB Wiki Admin 00:44, 21 July 2016 (UTC)
  • Pictogram voting support.pngSupport Seems legit. -PaladinAHOne Staff (talk) 02:10, 21 July 2016 (UTC)
  • Pictogram voting support.pngSupport --sokratis12GR Staff 07:39, 21 July 2016 (UTC)
  • Pictogram voting support.pngSupport: I have seen that you love documenting mods and you are good at creating them. And as people say: "The more the merrier." IndestructiblePharaohVII 13:29, 21 July 2016 (UTC)

DAC appointment

I'm officially appointing ScottKillen to document my mods Advanced Generators and Pressure Pipes. -- Bdew (talk) 21:53, 20 July 2016 (UTC)

  • Pictogram voting support.pngSupport. ScottKillen seems to understand wikitext and has a passion for editing. 🐇Retep998🐇🐰Bunny Overlord🐰 21:58, 20 July 2016 (UTC)
  • Pictogram voting support.pngSupport: Nice to see some new enthusiasm helping documenting new mods Chocohead NagEditsStaff 22:29, 20 July 2016 (UTC)
  • Pictogram voting support.pngSupport. -Xbony2 (talk) 00:03, 21 July 2016 (UTC)
  • Pictogram voting support.pngSupport -- SatanicSanta🎅FTB Wiki Admin 00:45, 21 July 2016 (UTC)
  • Pictogram voting support.pngSupport Leems segit. -PaladinAHOne Staff (talk) 02:10, 21 July 2016 (UTC)
  • Pictogram voting support.pngSupport --sokratis12GR Staff 07:39, 21 July 2016 (UTC)

Extension:SpriteSheet

There are times when a tilesheet is not practical, but a small set of sprites on one sheet would help boost performance. Can we install this extension for that purpose? The extension was created by Curse specifically for gamepedia. -- ScottKillen [] 02:51, 22 July 2016 (UTC)

That is already what tilesheets are for. I can't think of any times where a tilesheet wouldn't be practical but a spritesheet would. They both do effectively the same thing in different ways. 🐇Retep998🐇🐰Bunny Overlord🐰 02:54, 22 July 2016 (UTC)
As you pointed out over at Feed The Beast Wiki:Tilesheet requests full tilesheets larger than 32x are not practical. Quality editing can include lots more than 32x graphics, but if spritesheets must always be tilesheets and tilesheets must always include almost all blocks and items from a mod, then surely there are many situations where giving an editor the ability to combine other images into an spritesheet that is smaller than a tilesheet would be desirable. If they don't use the tool then nothing changes, but a web savvy editor can increase page performance. What is the downside to that? Curse designed the extension for just this situation.
To give you an example, consider Turbine (Advanced Generators). A stylesheet that is not a full tilesheet would be ideal here. -- ScottKillen [] 03:22, 22 July 2016 (UTC)
If we did want to create a tilesheet with only a few items from a mod, we could do that. It would need a separate abbreviation, but definitely possible with the current system. I suppose if you dump the icons at 128x128 and then delete everything except the blocks you want, we could make a separate 64px tilesheet specifically for them. What do you think TheSatanicSanta? 🐇Retep998🐇🐰Bunny Overlord🐰 03:30, 22 July 2016 (UTC)
It seems a lot of work for someone to create a new tile sheet every time. Also, the tilesheet functionality is overkill here (we don't need name mapping or translation). Rhe wikitext determines the dimensions of the slice that is used, so unlike tilesheet, a spritesheet can contain mixed resolutions. Imagine if the example page I gave also included a GUI or two, which happened to be slices of the same spritesheet containing the block images. One spritesheet as opposed to 10 image loads and a large performance savings. -- ScottKillen [] 03:40, 22 July 2016 (UTC)
Wait. Why can't you make a 64 tilesheet out of 64x images? -- ScottKillen [] 04:17, 22 July 2016 (UTC)
Because I like to downscale the images so that they are anti aliased? That's why I ask for 64x64 images for the 32px and 16px tilesheets. 🐇Retep998🐇🐰Bunny Overlord🐰 04:20, 22 July 2016 (UTC)
Of course! The old anti alias ploy. Jolly Good. :) -- ScottKillen [] 04:22, 22 July 2016 (UTC)
Plus my program actually accounts for the non linear nature of sRGB so it actually resizes images correctly (unlike 99% of software out there). As of recently it also accounts for the fact that NEI renders translucent icons against a black background with the wrong blending mode, particularly noticeable for fluids (See User:Retep998/Translucent for an example). 🐇Retep998🐇🐰Bunny Overlord🐰 04:41, 22 July 2016 (UTC)
For this instance, a new sheet would work, but it's also a small enough mod that I don't think having a 64 sheet with all the icons would be problematic. I also don't really want to clutter the mod list with a bunch of ABBRV-BIG sheets (or whatever style we decide to do). I also don't see how creating a new sheet for big icons would solve the problem with other mods that are planned to use the large icons for their infoboxes. It may for GT since it adds so much meta shit that wouldn't show up in infoboxes, but for other big mods like Witchery and Immersive Engineering, it really wouldn't solve the problem. -- SatanicSanta🎅FTB Wiki Admin 04:27, 22 July 2016 (UTC)
If the mod is small enough then yes we could just add a third size to the existing tilesheet. It's the big mods that I am worried about. 🐇Retep998🐇🐰Bunny Overlord🐰 04:41, 22 July 2016 (UTC)
I agree, Retep998, so what is the downside of this extension? Also, as I mentioned, it seems a lot to go through when the name mapping features of a tilesheet are not required. In such a case, wouldn't the overhead of {{P}} and loading a full tilesheet counteract the performance savings of just having a spritesheet with 8 images? -- ScottKillen [] 04:50, 22 July 2016 (UTC)
If we want to have a 64px tilesheet with just those 8 icons, we already can do that. If we want to have a 64px tilesheet with all of ADVG on it, we can also do that. Really the only reason I see the spritesheet extension could be useful is for situations where you have a lot of mixed resolutions. Everything else we can just abuse tilesheets or plain images. 🐇Retep998🐇🐰Bunny Overlord🐰 04:56, 22 July 2016 (UTC)
I can't state the case any better that I have and it seems the answer here is always gonna be "Tilesheets can do it." and over on Tilesheet requests we will have to request and debate the necessity of every tilesheet (because even though they can do it there is obviously a huge cost involved)...when meanwhile all I really wanted to do with my time here is create stellar content. I don't need Spritesheets, but they are relatively common in modern web design and I thought I was helping solve a concern that TheSatanicSanta had about performance...but I can make great content and then let you guys worry about performance...so I'm going to drop this and get back to creating content. Thanks all of you for sticking with this up to this point. OK...back to wikitext. -- ScottKillen [] 05:26, 22 July 2016 (UTC)
I really don't want to discourage you. Both tilesheets and spritesheets involve having an image divided into multiple smaller images. It's just that we already have the tilesheet extension and it is already integrated into everything, and given two identical sheets the performance of using tilesheets is no worse than spritesheets. Really the big decision just comes down to whether we want a sheet with all of the mod at 64px, or just some specific stuff at 64px, or having them be individual images. Honestly, I doubt we'll come to any sort of standardized conclusion any time soon. Sorry for this mess. In the mean time just be bold. 🐇Retep998🐇🐰Bunny Overlord🐰 05:38, 22 July 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── <BOLD> You are right that both are essentially the same technique (the CSS parses the image on the browser side of things)...however, tilesheets have these limitations:

  • Must follow a strict cramped naming scheme.
  • Must be created by staff.
  • Images must be homogenous size.
  • Slices must be named.
  • Slice names must be translated.
  • Server must perform filename lookup and tile name lookup and translate to css for proper slicing.

Spritesheets have none of those limitations and the following advantages:

  • Server simply creates proper css.
  • Any image can be sliced.
  • No staff must be involved.

Now these three advantage give editors the power to do some pretty snazzy stuff quickly...and at the end of the day that is how we retain editors. Having to stop and request tilesheets and wait for them and maybe not get a response and maybe have to justify why you need someone to do all that work for you and maybe getting turned down...all of these things interrupt workflow, threaten creativity and make editors think that maybe all of that bureaucracy isn't worth it... I'm just sayin'...

Additionally, their is no risk from abuse. I am finding myself hard=pressed to imagine an abuse situation...and it can't easily replace {{P}}, so it can't even be abused in that way.

As far as tilesheets being integrated into everything...that is right and I am not proposing that this replace tilesheets...but I read the install instructions and this literally takes minutes to be fully installed and ready to use and available to those who can use it and out of their way if not.

As far as an identical tilesheet and spritesheet...client load time might be the same, but tilesheets with their name lookups and translations definitely incur a higher cost to serve the page. But the whole point really is that tilesheets and spritesheets won't be identical. Spritesheets are a delicate ballpeen and tilesheets are a fifty-pound sledge.</BOLD> OK...I've finally said my peace. I'll say no more and defer to the powers that be. -- ScottKillen [] 06:17, 22 July 2016 (UTC)


Maybe I'm oversimplifying stuff but it might be possible to use some dumb template + css trick? make a template that loads a file as a background image with {{filepath:}} and use css to get the right sprite? might be worth a shot if we just need a simple solution. -- 06:22, 22 July 2016 (UTC)
Scottkillen makes a good point there too. Very thoughtful, I like it. -- 06:33, 22 July 2016 (UTC)