43
Seeking feedback on Data Pack main categories and filters
Nov 4th UPDATE: As of this morning, the new dedicated Minecraft Data Pack section is live!
We currently have Data Packs as a subcategory of Mods which is incorrect. It was a temporarily solution to gather them into one place and it served that purpose.
We're ready to create a dedicated section for Data Packs to help support the Data Pack developers and grow the community that loves them. In addition, it will allow us to host periodic competitions as proposed by AmericanBagel in this thread.
In order to create the Data Pack section, we need a proper and ideally comprehensive set of categories. AmericanBagel and I started brainstorming in previously mentioned thread and have come up with following tentative list:
OLD | Tentative Categories | LATEST | Tentative Categories |
Note: List outdated. For reference purposes only. Latest to right arrow_forward
|
|
In addition to the main category list, we can provide additional filters. Meaning, one could select "Aesthetic" category & then further filter that list down by changing additional filters from "Any" to a specific setting.
One required filter will be:
Filter: Oldest Compatible Game Version
- All Game Versions
- Minecraft 1.15 snapshot ( Upon full 1.X release, corresponding snapshot packs would be moved into it )
- Minecraft 1.14
- Minecraft 1.13
- Any
- Advancements
- Functions
- Loot tables
- Predicates (1.15)
- Structures
- Recipes
Filter: Special Requirements | pending idea for a filter that includes OR excludes special requirements. Not flushed out / finalized.
- Resource Pack
- Optifine
- Tick functions
- Extra setup
PRIMARY FOCUS: What does the Data Pack community think of the proposed main categories? Are we missing any? Is there a better term for any of the proposed? Are any of them too specific / should be merged? If they all look good, please comment and let us know that as well.
Secondary focus: Optional filters. Besides the game version, are their filters that apply to all / most Data Packs and would be useful for developers & the community?
Looking forward to nailing this down and launching the new section.
Note: All existing packs will be moved into the new section and a script will attempt to automatically place them into a matching main category based on their tags / title. Any that don't match will go into "Other". Of course, creators can change the category.
Create an account or sign in to comment.
143
3
The new dedicated Minecraft Data Pack section is now live!
Thanks to everyone for their valued feedback and patience during this process. There's always more to be done but I think the new section has covered much of what we discussed here and will ultimately help the data pack community continue to grow.
The move:
All existing packs were moved into the new section. In addition, a script attempted to automatically assign the most appropriate subcategory based on existing tags rather than just dump everything into "Other". I encourage all developers to review what category the script assigned your data packs and revise if necessary.
The process also scanned all Data packs that are hosted on our servers for the various modifiers and automatically checked them off.
At this time the Data Pack scanner gathers much more data than it actually uses including namespace, description, all files, all modifiers and can detect tick functions and more. It also can auto tag submissions. At the moment, I'm only testing that functionality on datapacks that are detected to be "BlingEdit" data packs.
Site Wide changes:
Since Data Packs are now an official section, they gain the many site wide benefits of being it's own subject. They're no longer referred to as mods anywhere on the site including notifications. They get their own pop reel. You can filter them on your profiles, in collections and in your account management. You'll notice, they have a custom submission form with an optional resource pack dependency, game version compatibility, categories and attributes.
What's next?
Before going any further, we're going to see how the new system applies to existing and yet to be released Data Packs. Please share your thoughts on the current implementation as well as what you'd like to see in the future. Developers, if anything is broken, let us know / open a ticket.
Thanks to everyone for their valued feedback and patience during this process. There's always more to be done but I think the new section has covered much of what we discussed here and will ultimately help the data pack community continue to grow.
The move:
All existing packs were moved into the new section. In addition, a script attempted to automatically assign the most appropriate subcategory based on existing tags rather than just dump everything into "Other". I encourage all developers to review what category the script assigned your data packs and revise if necessary.
The process also scanned all Data packs that are hosted on our servers for the various modifiers and automatically checked them off.
- Advancements
- Functions
- Loot tables
- Predicates (1.15)
- Structures
- Recipes
At this time the Data Pack scanner gathers much more data than it actually uses including namespace, description, all files, all modifiers and can detect tick functions and more. It also can auto tag submissions. At the moment, I'm only testing that functionality on datapacks that are detected to be "BlingEdit" data packs.
Site Wide changes:
Since Data Packs are now an official section, they gain the many site wide benefits of being it's own subject. They're no longer referred to as mods anywhere on the site including notifications. They get their own pop reel. You can filter them on your profiles, in collections and in your account management. You'll notice, they have a custom submission form with an optional resource pack dependency, game version compatibility, categories and attributes.
What's next?
Before going any further, we're going to see how the new system applies to existing and yet to be released Data Packs. Please share your thoughts on the current implementation as well as what you'd like to see in the future. Developers, if anything is broken, let us know / open a ticket.
2
I do miss a player mechanic category...
Thirst, skills, combat combo's, my zombification data pack, friends or "/party"-like systems are all focussed on changing the natural behaviour of the player. Without the category I would classify them all as game mechanic and idk if that would suffice.
Creating the new category will cause game mechanic to become really small. I have no clue what falls under that category which doesn't fit in the existing categories or the new proposed category.
Maybe gamerule, weather and time modifying datapacks that do not depend on user interaction but use their own mechanic
Thirst, skills, combat combo's, my zombification data pack, friends or "/party"-like systems are all focussed on changing the natural behaviour of the player. Without the category I would classify them all as game mechanic and idk if that would suffice.
Creating the new category will cause game mechanic to become really small. I have no clue what falls under that category which doesn't fit in the existing categories or the new proposed category.
Maybe gamerule, weather and time modifying datapacks that do not depend on user interaction but use their own mechanic
1
I do see what you're saying. It does feel like we're missing what "Player Mechanic" would categorize and I'd like you to feel like your data packs are properly categorized. Is that the best term though? Maybe "Gameplay"? Hmm.
2
Maybe separate between player mechanics and world mechanics. That makes the split more obvious than when the category "game mechanics" would still exist. I'd say that "gameplay" is too vague though.
1
There should be filters to sort by crafting and smelting, to minigames, to new functions, because when you have all the packs in one clump it is hard to find!
6
I've been browsing the datapacks section of PMC and let me just say..... It's filled with shitpost-like recipe packs like this one (nothing personal). Recipes should only be allowed in datapacks as long as they go along with functions to allow crafting of blocks/items with new behaviour. Datapacks solely consisting of recipes for already existing, non-modified items simply aren't datapacks. They require no effort and can easily be generated using some kind of online recipe generator.
1
[deleted]
1
This is a dead thread, but yeah of course they are technically data packs. But there are infinite possible combinations of items in recipes, most of them making sense from one view point or another. Because they are so easy to make, they flood out the hidden gems of high quality and effort.
Anyways, the initial wave of recipe packs is over, I enjoy seeing more and more data packs with actual command usage. =)
And if you want to make a recipe only pack, I'm not stopping you. That doesn't mean I can't vent about how I feel about recipe packs.
At the end, I'm not wanting to revive an old thread for the sake of argument, so let's just agree to disagree.
Anyways, the initial wave of recipe packs is over, I enjoy seeing more and more data packs with actual command usage. =)
And if you want to make a recipe only pack, I'm not stopping you. That doesn't mean I can't vent about how I feel about recipe packs.
At the end, I'm not wanting to revive an old thread for the sake of argument, so let's just agree to disagree.
1
[deleted]
1
I feel like there should be a single player/multiplayer/ Maybe realms check box that people can use which will then add that tag or category to the list because you can't really have a datapack that isn't single player or multiplayer
1
An Experimental and/or WIP section. Great for adding some features to a pack than getting feedback or for non-serious just funny packs that might break your world
2
What about some sort of measuring system for lag (or a stress test)?
3
What about advancement as a category since datapacks which add advancements are very common.
3
But advancement are not neseseraly always used to add achievements, sometimes they are used to just launch functions, as an alternative to scoreboard.
I think it would be a too wide category.
I think it would be a too wide category.
2
BlingEdit Plugin
1
I just read up on BlingEdit on the subreddit. SethBling is a legend. I think developers would tag their BlingEdit Data Packs but we could add a special checkbox to indicate that it's a BlingEdit Plugin to support the format & community around it.
In general, this makes me reconsider the term "World Generation". Maybe "Terrain Generation" would be better.
In general, this makes me reconsider the term "World Generation". Maybe "Terrain Generation" would be better.
2
If you really want to link dependencies (which requires persistant storage for all versions of datapacks which seems impossible to me), then it should just be a text field instead of a checkbox "This requires BlingEdit".
Maybe add a checkbox saying "Can be used by other datapacks" to distinguish between implementations of "an API" and people stealing a datapack that was intended for end-users and adding a little bit on top.
I don't think BlingEdit has anything to do with world/terrain generation. It's a tool of which usage is completely user triggered. I still think they are valid categories for people modifying terrain based on player position, advancement events with /fill or /clone commands or structure blocks.
Maybe add a checkbox saying "Can be used by other datapacks" to distinguish between implementations of "an API" and people stealing a datapack that was intended for end-users and adding a little bit on top.
I don't think BlingEdit has anything to do with world/terrain generation. It's a tool of which usage is completely user triggered. I still think they are valid categories for people modifying terrain based on player position, advancement events with /fill or /clone commands or structure blocks.
2
cool, but you might want to add structure generation as well because you might want to modify naturally generated structures
1
Or even add your own with structure blocks and the like. I'm sure it's possible, even if I haven't worked out the specifics myself.
1
I think these categories are great and I'd love to see the extensive one to be included, even though this section may contain not that many project because they need quite some time so do. This request may seem a little bit selfish because I'm working on such a pack myself, but I love those packs. They really show what's possible with the features provided by the vanilla game.
Cosmetic and Aesthetic as well as Structures and World Generation seem to me quite similar.
I'm not so sure what to imagine under the category Player Mechanic
Cosmetic and Aesthetic as well as Structures and World Generation seem to me quite similar.
I'm not so sure what to imagine under the category Player Mechanic
1
Oops. Think you were comparing old categories to new proposed one. Aesthetic was replaced with Cosmetic & Structures was dropped in favor of broader World generation & adding an optional Resource Pack upload.
I just removed "Player Mechanic".
I just removed "Player Mechanic".
1
I'm a little unsure about the "cosmetic" tab as I don't think many data packs aim to make the game look better... Where it should go is with the texture packs but maybe I'm wrong
2
I'm not sure either but I think we'll keep it and see if there are any over time.
2
Well yea... hopefully 1.16 allows for custom blocks via the custom_model_data
2
Oh goodness, I hope so
3
What about when you can set two Minecraft versions in your Game Version submission, because if Mojang adds new commands your datapack deosn't work in older version. People would then know in what versions this datapack would work. So my suggesting would be something like this: Minecraft 1.14 - Minecraft 1.15
Keep up the great work :D
Keep up the great work :D
2
Very good point! Glad you brought that up.
In addition, I don't think Mojang would release an update that breaks old Data packs, so the site should be able to safely assume a pack that was released for 1.14 has compatibility range of 1.14 - 1.XX? So, we could have one drop down for version but it needs to be clear that it's for Oldest compatibility by visually showing the range.
Version Compatibility: [ Select Oldest Version ] to Latest Minecraft Version
I'm thinking along these lines so that when a new version releases, it doesn't seem like the majority of the packs on PMC are incompatible simply because the developer hasn't returned to manually update the latest version dropdown.
In addition, I don't think Mojang would release an update that breaks old Data packs, so the site should be able to safely assume a pack that was released for 1.14 has compatibility range of 1.14 - 1.XX? So, we could have one drop down for version but it needs to be clear that it's for Oldest compatibility by visually showing the range.
Version Compatibility: [ Select Oldest Version ] to Latest Minecraft Version
I'm thinking along these lines so that when a new version releases, it doesn't seem like the majority of the packs on PMC are incompatible simply because the developer hasn't returned to manually update the latest version dropdown.
5
Datapacks were regularly broken by updates to the command line structure, item name changes, and updates to game mechanics. What may work now, won't be guaranteed to work in 1.15 or 1.XX.
1
Alright. That's disappointing.
1
My personal opinion on datapacks and versions is that I like it when creators keep the version updated to the most recent version that the pack works on. So if I build a pack for 1.14, when 1.15 comes out I'd check it for compatibility with 1.15. If it still works, I'd update the listing. If not, I'd leave it at 1.14 until/unless I update it properly. Perhaps also putting other versions it works for in the tags, but keeping the main one up to date.
2
Someone who has knowledge of commands could just read the changelog of the versions and see if there are any restructured commands. For 1.15 so far there's only been additions, so if that doesn't change, you can assume that all datapacks for 1.14 are also compatible with 1.15. You can also assume that any datapacks made for 1.x.y are compatible with any following 1.x updates. So if these versions would exist: 1.15.1, 1.15.2, 1.15.3, 1.15.4, then a datapack for 1.15.2 would also be compatible with 1.15.3 and 1.15.4.
I don't have any statistics, but I feel like the amount of datapacks that break between sub-subversions of the game is neglectible.
Maybe a version range should be added to resource packs and projects as well.
I don't have any statistics, but I feel like the amount of datapacks that break between sub-subversions of the game is neglectible.
Maybe a version range should be added to resource packs and projects as well.
2
One thing that was changed or "fixed" in 1.15 is that you can no longer edit item data in the player's inventory directly. So datapacks who used that will not work in 1.15 for example.
4
So far basically any update broke/changed at least one thing (be it item/block ids like "sign" to "oak_sign" etc. or command syntax/behavior changes)
There is a reason why people write "this map only works in version X"
One good example are maps that are in the Realms map library.
Update break them in one way or another, and since Realms are always on the latest (non-snapshot etc.) version they remove those maps from the list of available maps (until they get updated by the creator(s))
There is a reason why people write "this map only works in version X"
One good example are maps that are in the Realms map library.
Update break them in one way or another, and since Realms are always on the latest (non-snapshot etc.) version they remove those maps from the list of available maps (until they get updated by the creator(s))
5
I think the ongoing demand for datapacks like random loot tables, radnom recipes, random item givers, rising water and lava and water levels and such, I think there should also be a challenge section to accomodate the demand for these types of content.
Also, when the datapack section is finally added, can we please get an easy way to move categories? In the earlier days of datapacks, many people were confused and some of the oldest datapacks are locked in the projects category, making it impossible for people to find them using the datapack category within mods. A smooth and automatic transferring of these items would be very useful for both developers and users.
Also, when the datapack section is finally added, can we please get an easy way to move categories? In the earlier days of datapacks, many people were confused and some of the oldest datapacks are locked in the projects category, making it impossible for people to find them using the datapack category within mods. A smooth and automatic transferring of these items would be very useful for both developers and users.
2
Looks good to me :thumb_up:
4
When this section is created, it needs the "1.15 Snapshot" version like CurseForge (Since some datapacks are for the 1.15 snapshot), and when 1.15 is fully released it should be Minecraft 1.15, and when the next snapshot for 1.15 is released, don't just call it "1.15 Snapshot" basically make a subcategory of a subcategory, for all the 1.15 snapshots, it also should be like this for other Minecraft versions.
1
Upto PMC if they take your idea on but this has already been solved by the members, we place our Snapshot packs in to Minecraft 1.14, then tag the upload with 'Snapshot'. So all you have to do is search using the word Snapshot. When PMC add Minecraft 1.15 to the drop down menu we just edit the upload and change it. This is why it's highly unlikely your idea will happen anytime soon. Maybe you'd like to do a post on the Forum about the importance of search tags and a simple how to, though must seasons content creators already know, some new creators may not..
2
Maybe just a plain old 'Snapshot' in the version option dropdown menu, that way we can put them into the 'Snapshot' category until PMC added the next official version as Mojang officially release it.
Then It being down to the creator to advertise which version of Snapshot it is, which is what we do anyway.
Then It being down to the creator to advertise which version of Snapshot it is, which is what we do anyway.
3
I like this compromise in terms of clear distinction without potentially adding X snapshot versions before ultimately merging them into the release. I would still default the version selection to the last full release on the upload form.
1
Yes I think it's a fair compromise, placing your pack under 'Snapshot' and then clearly providing the version of Snapshot in the packs title and or description. Then when say 1.15 is officially released and PMC add it to the dropdown menu, we can just edit our upload to the official version.
2
Cool. Also, I'll simply have all 1.XX snapshot packs move into the full 1.XX release. Essentially, it's just a rename and developers won't need to update the version manually.
2
In the Dropdown Menu I think it should be categorised as
Datapacks
Texture Packs
Texture Datapacks
Mods
Modpacks
Also allow for pack upload owners to change the categories of an upload by editing it in a dropdown menu when updating/editing an upload. This way it isn't down to PMC to do all that work themselves. All PMC would have to do is advise members that they can now choose and change categories after posting mods, packs etc rather than only when uploading for the first time, if that is possible..
Datapacks
Texture Packs
Texture Datapacks
Mods
Modpacks
Also allow for pack upload owners to change the categories of an upload by editing it in a dropdown menu when updating/editing an upload. This way it isn't down to PMC to do all that work themselves. All PMC would have to do is advise members that they can now choose and change categories after posting mods, packs etc rather than only when uploading for the first time, if that is possible..
1
As I mentioned earlier, I support the idea of allowing a resource pack download on the datapack resource page, but let's not split "Mods" or "Datapacks" into separate menu entries. It would be way too confusing and cluttered. Otherwise people will start requesting separate menu items for Sound Packs, Language Packs, Font packs etc etc etc etc
1
Mod and Datapack categories are already split in the drop down menu? Mods are Mods and Datapacks are Datapacks. They're two completely different things.
A Datapack with Textures isn't just a Datapack, it's also a Texture pack so I do believe there needs to be a Category for Texture + Data packs. An example 'Texture Datapacks'
Splitting up a Texture Pack and a Datapack that need each other isn't the way to go, it clutters up the website and forces people to have to download multiple separate packs. While you may prefer to do this for reasons like splitting it so that you have more content uploaded or some other reason, I prefer to keep my packs together as 1 download. I understand that there's a maximum file size restriction but that can be worked around by using outside file hosting websites which PMC accommodate.
Having a Modpack Category does not split anything. As a Mod Pack is a colletcive pack of Mods, not a single Mod.
Resource packs are packs that have been completely changed so I think it needs to be.
Resource Packs
Texture Packs
Texture Datapacks
Datapacks
Mods
Modpacks
A Datapack with Textures isn't just a Datapack, it's also a Texture pack so I do believe there needs to be a Category for Texture + Data packs. An example 'Texture Datapacks'
Splitting up a Texture Pack and a Datapack that need each other isn't the way to go, it clutters up the website and forces people to have to download multiple separate packs. While you may prefer to do this for reasons like splitting it so that you have more content uploaded or some other reason, I prefer to keep my packs together as 1 download. I understand that there's a maximum file size restriction but that can be worked around by using outside file hosting websites which PMC accommodate.
Having a Modpack Category does not split anything. As a Mod Pack is a colletcive pack of Mods, not a single Mod.
Resource packs are packs that have been completely changed so I think it needs to be.
Resource Packs
Texture Packs
Texture Datapacks
Datapacks
Mods
Modpacks
1
People looking for datapacks may not know where to find what they want if there are two separate datapack menus ("Texture Datapacks" and "Datapacks". Splitting them into two different categories would be confusing. Also, where would datapacks with optional resource packs go?
Besides, is it not better to just say in the description of a datapack whether it requires a resource pack
Besides, is it not better to just say in the description of a datapack whether it requires a resource pack
1
No it's not better to just say in the description, a lot of people don't bother reading the description, they download, install and then come asking questions about how it's not working.
Now allowing us the Texture/Datapack category negates that issue. We put the packs together and include the instructions.
The only valid and justifiable reason for splitting two packs up that actually need each other to even work properly, would be if they would exceed PMC's maximum file size restriction but even then there's no excuse for splitting them as there are file sharing websites out there for free and PMC accommodate for that by allowing you to include outside web addresses when publishing on here.
Now allowing us the Texture/Datapack category negates that issue. We put the packs together and include the instructions.
The only valid and justifiable reason for splitting two packs up that actually need each other to even work properly, would be if they would exceed PMC's maximum file size restriction but even then there's no excuse for splitting them as there are file sharing websites out there for free and PMC accommodate for that by allowing you to include outside web addresses when publishing on here.
1
People never specifically go looking for Datapacks, people never go and just search using 'Datapack'. They specifically look for a certain pack by searching for say Weapons, Advancements, Textures, 3D, Mechanics, they use search words. It's just a simple task of searching through different categories which we all do already, example.
If I'm looking for a pack that's combat related then I'll use the search word Combat and look under all categories. The entire point of having categories is so people can find what they are looking for easier. So if I want a Datapack with just Recipes then I'll look under Datapacks for Recipes or, If I'm looking for a Datapack offering more Items with Textures then I'd like to not have to look through all the Recipe Datapacks to find what I seek.
Separating Datapacks with Textures from plain old simple Datapacks that only offer advancements and recipes which quite frankly there are far too many off, as they are repeatedly published by beginner coders, means that the more advanced packs that offer far more than just advancements and recipes don't get lost in amongst it all.
If I'm looking for a pack that's combat related then I'll use the search word Combat and look under all categories. The entire point of having categories is so people can find what they are looking for easier. So if I want a Datapack with just Recipes then I'll look under Datapacks for Recipes or, If I'm looking for a Datapack offering more Items with Textures then I'd like to not have to look through all the Recipe Datapacks to find what I seek.
Separating Datapacks with Textures from plain old simple Datapacks that only offer advancements and recipes which quite frankly there are far too many off, as they are repeatedly published by beginner coders, means that the more advanced packs that offer far more than just advancements and recipes don't get lost in amongst it all.
1
Maybe better to allow datapacks to link to related texture packs, so users understand/accept they are distinct.
The two install differently. When I bundle them together, users treat the whole zip as as datapack, so then none of it works and I have to explain for the millionth time to unzip it, and install each part as appropriate.
would be VERY useful for the datapack to have two side-by-side download buttons... one for datapack, one for resource pack.
The two install differently. When I bundle them together, users treat the whole zip as as datapack, so then none of it works and I have to explain for the millionth time to unzip it, and install each part as appropriate.
would be VERY useful for the datapack to have two side-by-side download buttons... one for datapack, one for resource pack.
1
Actually I state in the description that the packs are all in the Zip file and that they have to unzip the downloaded file and install the zip files inside.
The zip files are clearly labelled DATAPACK or RESOURCE/TEXTURE PACK so there's zero confusion.
I also provide clear and straight forward installation navigation in the downloaded Zip file, so when they as instructed unzip the file the instructions are right in front of them,.
They treat the whole thing because you obviously fail to provide the information in the description, and even then if they didnt read it before downloading and came back asking why it wouldn't work, you say did you read the description. simple.
No one for Resource Pack doesn't solve the issue, you've clearly not read my posts thoroughly enough, I stated that there are resource packs that require datapacks and that I don't believe should be split up and separated when PMC and File Sharing Websites that are free, provide for them to be easily uploaded as one pack.
The zip files are clearly labelled DATAPACK or RESOURCE/TEXTURE PACK so there's zero confusion.
I also provide clear and straight forward installation navigation in the downloaded Zip file, so when they as instructed unzip the file the instructions are right in front of them,.
They treat the whole thing because you obviously fail to provide the information in the description, and even then if they didnt read it before downloading and came back asking why it wouldn't work, you say did you read the description. simple.
No one for Resource Pack doesn't solve the issue, you've clearly not read my posts thoroughly enough, I stated that there are resource packs that require datapacks and that I don't believe should be split up and separated when PMC and File Sharing Websites that are free, provide for them to be easily uploaded as one pack.
1
“They treat the whole thing because you obviously fail to provide the information in the description,”
I do. People are just people.
I do. People are just people.
view more replies ( 1 )
view more replies ( 2 )
view more replies ( 1 )
view more replies ( 22 )