16
PMC Lucky Blocks | A data pack event for anyone and everyone!archive
Bertiecrafter
Planet Minecraft Lucky Blocks Data Pack Event
We're excited to introduce the first official data pack event on Planet Minecraft!
View the full event details page to read all about it and familiarize yourself with the rules.Introduction video to the framework
Note: The video is slightly outdated. You now get a skull item instead of egg and you craft it using a gold block instead of ingot.
After learning what the event is about follow the steps below:
Getting Setup : Framework Download and Setup
1) Download the .zip file containing the framework and unzip it to your datapacks folder. This folder is accessible by clicking Edit > Open World Folder while having a world selected in the single player menu. Your datapacks folder should now contain a "PMC Lucky Blocks" folder with a "data" folder inside. Run the /reload command and make sure you see a message in chat telling you that the datapack loaded.
2) Open up the data folder and rename the "steve" folder to something you own, like your Minecraft username. The name you used will be your "namespace".
3) Open the folder: bertiecrafter/tags/functions/pmclb and edit each file inside. Replace all occurrences of "steve" with the namespace you defined in step 2.
4) Open the <your namespace>/functions/pmclb and edit the load.mcfunction file. On the second line, write "say IT WORKS!", save and exit.
5) Assuming Minecraft is still running with the customized datapack world, type /reload in chat. If you see "IT WORKS!" appear in chat, you can remove the line we added in step 4 and continue.
Note that each tag file you just edited already has a function file linked. Use the tick, load, register_options and uninstall function files inside <your namespace>/functions/pmclb to run certain commands on tick (20 times a second), load (after /reload), registration or uninstall respectively. The registration function will contain the necessary commands to register your implementations for use by the framework. Creating a new option will be explained in "Custom Content" section below .
Before
data/
data/bertiecrafter/tags/functions/pmclb/load.json (do the same for other files in that folder)
data/bertiecrafter/tags/functions/pmclb/load.json (do the same for other files in that folder)
After
data/
data/bertiecrafter/tags/functions/pmclb/load.json (do the same for other files in that folder)
Custom Content: Use your imagination to make something happen!
When a lucky block gets activated, a random option from the list of registered options will be picked and executed. All you have to do is register the option and implement it. You can repeat this step for as many options as you want.
1) Start by going into <your namespace>/functions/pmclb and open up register_options.mcfunction. Copy the template command down and make sure to remove the hashtag in front of the copied line. Fill in the title of the option, your (user)name and the function command that serves as entry point. Keep in mind that the title and author name will be publicly visible.
2) Create the function file you indicated as entry point in the command above. Simply put "say Hello World!" into the file, run the /reload command and run "/function bertiecrafter:pmclb/break/activate". If you see "Hello World!" appear in chat after you broke one, you successfully added an option!
3) Now you just have to properly implement it. Note that you can always directly run the option by copying the /function command from the register_options.mcfunction into chat. Just make sure the options are still properly linked by testing the options through actual lucky blocks or the activate command before submitting.
4) Useful commands:
/function bertiecrafter:pmclb/give/lucky_block: Give the nearest player a lucky block.
/execute as <players> run function bertiecrafter:pmclb/give/lucky_block: Give all selected players a lucky block.
/function bertiecrafter:pmclb/spawn/setblock: Place a lucky block in the current location.
/execute positioned <coordinates> run function bertiecrafter:pmclb/spawn/setblock: Place a lucky block at specified position.
/execute at <players> run function bertiecrafter:pmclb/spawn/setblock: Place a lucky block at the feet of selected players.
/function bertiecrafter:pmclb/break/activate: Simulate a lucky block being broken at the current location.
/execute positioned ~ ~1 ~ run function bertiecrafter:pmclb/break/activate: Simulate a lucky block being broken 1 block above the current location. Can be placed in a command block for quick testing.
Note that you must run /reload after every datapack edit.
Before
data/your-username/functions/pmclb/register_options.mcfunction
data/your-username/functions/pmclb/
After
data/your-username/functions/pmclb/register_options.mcfunction
data/your-username/functions/pmclb/
data/your-username/functions/pmclb/my_epic_option.mcfunction
Submission
You can never test enough. Make sure that the option registration is set up right and that every option still works when integrated with the framework, since you might have been testing with directly running the function command. Read the rules again and when you're satisfied with your submission, upload it to Planet Minecraft. Regardless of whether or not you get to contribute, we hope you had a blast creating anything you could come up with and maybe you even learned something from this event.Need help?
If you need help the framework setup, feel free to ask questions below. If you need help implementing your custom idea into the block, we strongly encourage you to follow this Minecraft data pack tutorial series as well as view it's references. You can of course ask questions but many of them are already answered online with a little bit of research. Good luck and looking forward to seeing the event unfold!
Thank you for participating!
Create an account or sign in to comment.
77
1
2
The Lucky Block event finished! Read the follow-up post here.
1
Downloading the new framework 9 hours before the event ends, wish me luck! Hopefully nothing drastic changes, I'm assuming I can just copy over my function files (all 1.16 compatible) and change to this new command:
data modify storage bertiecrafter:pmclb options append value {title:"<title>",author:"<name>",function:"/function <namespace>:pmclb/<path-to-function>",info:"<Extra info or blank>"} 1
As long as your functions are 1.16 compatible, you should be good to go. Each framework update is backwards compatible. (E.g., if your option registration commands don't contain the info field, nothing will break)
3
Sadly I can't submit my submission for the event because I STUPIDLY DELETED ALL OF MY OPTIONS!
Sometimes I hate myself... This might be one of those times
:(
Sometimes I hate myself... This might be one of those times
:(
2
Can we have a moment of silence for this tragedy? XD
Can't you get them back from the recycle bin or something?
Can't you get them back from the recycle bin or something?
2
oh yeah :0
I just saw that I deleted everything and rage quit instead of checking the recycle bin :(
(Sometimes I wish I don't empty my recycle bin constantly to make up for the massive lack of space on my computer)
me sad now...
(My submission was going to be a bunch of silly options to counter all of the amazing ones that other people have made: eg. annoying random bats, bob the useless. It would have been amazing!).
I just saw that I deleted everything and rage quit instead of checking the recycle bin :(
(Sometimes I wish I don't empty my recycle bin constantly to make up for the massive lack of space on my computer)
me sad now...
(My submission was going to be a bunch of silly options to counter all of the amazing ones that other people have made: eg. annoying random bats, bob the useless. It would have been amazing!).
1
i don't know how to make a separate function file.
2
For windows:
Get a text editor, I guess simple Notepad (already installed on your pc) will do.
Then in the "Save As" dialog, make sure to select "All files" as file type beneath the place where you enter the file name. Then enter your function name with ".mcfunction" at the end.
Note that if you don't select the File type (and leave it at "Text files (.txt)" instead of "All files (*.*)"), it will save as "myfile.mcfunction.txt" and that wouldn't work.
Have a look at this tutorial for more information. The section about how to create the pack.mcmeta file can help you with creating .mcfunction files. Just expand one of the spoilers based on what operating system you have.
Get a text editor, I guess simple Notepad (already installed on your pc) will do.
Then in the "Save As" dialog, make sure to select "All files" as file type beneath the place where you enter the file name. Then enter your function name with ".mcfunction" at the end.
Note that if you don't select the File type (and leave it at "Text files (.txt)" instead of "All files (*.*)"), it will save as "myfile.mcfunction.txt" and that wouldn't work.
Have a look at this tutorial for more information. The section about how to create the pack.mcmeta file can help you with creating .mcfunction files. Just expand one of the spoilers based on what operating system you have.
2
oooohhhh. igot it now, thanks!
2
Finally an event about datapacks... Unfortunately, a framework is imposed!
It poses many problems in my opinion:
- We (datapack creators) don't all have the same way of coding and that can disturb more than one. I know that this is also done so that everyone can try to do something, however I don't find the way it was done intuitive.
- The imposed framework is globally badly coded. For having a look at the code there are unfortunately much better things to do, which is disturbing for an event! It would have been necessary to review some parts, especially in terms of optimization (even if I know that compatibility is not always easy to manage). Commenting on what has been done also seems very important to me in the context where some people will use it as a base.
- Modifying the framework for 1.16 is a very bad idea. I know that the event was launched in 1.15 and that 1.16 (which allows more things) is out. Unfortunately doing a datapack event on two versions can cause compatibility problems. Either people playing with it will have to change versions, or the creators will have to update them once their work is done for a version that is still unstable.
- The recurring presence (each time the datapack is loaded etc...) of the name of the host of the event is also disturbing. I know that this argument may seem silly but it offers a lot of visibility for something that is unfortunately not worth it.
Anyway, I'm not sending this comment to denigrate the work that has been done upstream, but to suggest to review in the future the points I criticized.I'm not completely opposed to the idea of imposing a framework, but it has to be clear to everyone and this is just my opinion.
Awhikax
It poses many problems in my opinion:
- We (datapack creators) don't all have the same way of coding and that can disturb more than one. I know that this is also done so that everyone can try to do something, however I don't find the way it was done intuitive.
- The imposed framework is globally badly coded. For having a look at the code there are unfortunately much better things to do, which is disturbing for an event! It would have been necessary to review some parts, especially in terms of optimization (even if I know that compatibility is not always easy to manage). Commenting on what has been done also seems very important to me in the context where some people will use it as a base.
- Modifying the framework for 1.16 is a very bad idea. I know that the event was launched in 1.15 and that 1.16 (which allows more things) is out. Unfortunately doing a datapack event on two versions can cause compatibility problems. Either people playing with it will have to change versions, or the creators will have to update them once their work is done for a version that is still unstable.
- The recurring presence (each time the datapack is loaded etc...) of the name of the host of the event is also disturbing. I know that this argument may seem silly but it offers a lot of visibility for something that is unfortunately not worth it.
Anyway, I'm not sending this comment to denigrate the work that has been done upstream, but to suggest to review in the future the points I criticized.I'm not completely opposed to the idea of imposing a framework, but it has to be clear to everyone and this is just my opinion.
Awhikax
1
Thank you for the well balanced review =)
A general note for all readers though, the event is not on two versions. We're aiming for 1.16 only, with 1.15 support not being a requirement.
A general note for all readers though, the event is not on two versions. We're aiming for 1.16 only, with 1.15 support not being a requirement.
My Response (In spoiler to keep thread clean)
- The framework is also to make merging of data packs easier, besides offering new data pack developers a steady base to start with. I do think this is necessary in order to make the datapacks remotely merge-able and to welcome new players to the community.
- Feel free to PM me your detailed feedback on optimizations!
- The decision to upgrade to 1.16 has been made, since the breaking changes are relatively small and easy to fix, even though I am aware this will take time. Most changes are NBT based and base command syntax has not been changed. Almost all submissions have been able to update. The author of the other submission has not asked any questions or indicated problems occurring during the process, it seems like he has just been inactive. Staying on 1.15 would be of no use, since the data pack would have been outdated as soon as it was released.
- Your last point is valid from the mindset you're coming from. But if you consider the framework to be of more value, you would see that the framework removes a lot of work that the participants would otherwise have to do themselves. And in my opinion, a mention on /reload and on the lucky block item does not give that much visibility compared to the mention in chat for the creators of the options every time a lucky block is broken. If someone were to make a YT video on it, my name would barely show, since the video most likely won't show the /reload output or the inventory as much as simply breaking a bunch of lucky blocks.
- Feel free to PM me your detailed feedback on optimizations!
- The decision to upgrade to 1.16 has been made, since the breaking changes are relatively small and easy to fix, even though I am aware this will take time. Most changes are NBT based and base command syntax has not been changed. Almost all submissions have been able to update. The author of the other submission has not asked any questions or indicated problems occurring during the process, it seems like he has just been inactive. Staying on 1.15 would be of no use, since the data pack would have been outdated as soon as it was released.
- Your last point is valid from the mindset you're coming from. But if you consider the framework to be of more value, you would see that the framework removes a lot of work that the participants would otherwise have to do themselves. And in my opinion, a mention on /reload and on the lucky block item does not give that much visibility compared to the mention in chat for the creators of the options every time a lucky block is broken. If someone were to make a YT video on it, my name would barely show, since the video most likely won't show the /reload output or the inventory as much as simply breaking a bunch of lucky blocks.
2
Indeed I misspoke about the versions, I'll detail a bit more my point of view below.
My Response (In Spoiler for the same reason as you)
- As far as merging the datapacks is concerned, I had seen it and thought it was a good idea. As I said it will indeed be easier to use for new datapack developers, but I still stand by my position about having pre-written code (in addition to not being commented on).
- As far as optimization is concerned I'll look at it in detail later, I'm very busy at the moment. I'll try to think about sending you a private message. ;-)
- What I was criticizing here was precisely the fact that the version was changed during the event, in case all participants couldn't update their datapack. If everyone could do it, great!
- Indeed I hadn't paid attention to the names of the participants. The fact of putting messages in the chat is then debatable. Some people like to have them, others hate them (because it can flood for example). I'm in the 2nd category, but it's a personal preference so I wouldn't criticize this choice.
- As far as optimization is concerned I'll look at it in detail later, I'm very busy at the moment. I'll try to think about sending you a private message. ;-)
- What I was criticizing here was precisely the fact that the version was changed during the event, in case all participants couldn't update their datapack. If everyone could do it, great!
- Indeed I hadn't paid attention to the names of the participants. The fact of putting messages in the chat is then debatable. Some people like to have them, others hate them (because it can flood for example). I'm in the 2nd category, but it's a personal preference so I wouldn't criticize this choice.
2
Is it possible; within contest rules or code, to drop a gravel castle on the player and call it “fallen kingdom”?
1
yes =)
1
Can I give the player a quest of half-minute and kill him when he fails or it prevents the player from being free?
1
Uhhhhh questions like these are hard to answer, because the main goal is the player having fun. Some players might enjoy the mini quest, while others don't.
The 30 seconds is a timeout, while the quest within has an average completion time that you didn't mention.
Try to think about the average length the quest will take, the probability of dying and if a completion reward would be worth the time and risk. Imagine playing with friends and try to make it cause excitement and the fun kind of stress, not annoyance.
I know that "fun" for you might not be fun for all other players, but nothing can be done about that. As long as you'd enjoy your creation in a lucky block map with friends, it's okay =)
The 30 seconds is a timeout, while the quest within has an average completion time that you didn't mention.
Try to think about the average length the quest will take, the probability of dying and if a completion reward would be worth the time and risk. Imagine playing with friends and try to make it cause excitement and the fun kind of stress, not annoyance.
I know that "fun" for you might not be fun for all other players, but nothing can be done about that. As long as you'd enjoy your creation in a lucky block map with friends, it's okay =)
2
With Minecraft 1.16 releasing soon ( June 23rd ), it would be nice if submissions are created for 1.16 as well. I know this is an inconvenience for all options that are already implemented, but by staying on 1.15, the final datapack would be outdated before even releasing. Besides the many new features 1.16 brings, here are the breaking changes that you'll have to check and possibly change in your submission (sorted by significance):
- Don't forget to change the version number from 1.15 to 1.16 on your submission
- Datapacks won't reload any changes if loading fails. Don't let it fool you.
- Attribute names have changed! Attributes give certain buffs to armor and tools (attack damage, armor points, extra health, extra speed, etc, etc). For the new list of attributes, see here.
- The player "Dimension" tag now uses a string type instead of a number.
- Raw JSON format (used in /tellraw, signs and books) now uses the "contents" key instead of "value" key inside "hoverEvent". The "value" key still works, but is deprecated.
- Any NBT UUIDs changed key name and format. Please refer to the NBT wiki pages (entities / players) for new names and the four integer format. UUIDs can be generated here and are used to refer to (for example) what player the neutral mobs are angry at, the owners of pets and what mobs are leashed together. An example of the new format:
{Owner:[I;-1512290654,1919697193,-1398146403,-926186596]} - Thrown potion entities now uses the key "Item" instead of "Potion" to register potion effects
- Custom Skull (player head) block NBT "Owner" key has changed to "SkullOwner". Although already mentioned, keep in mind that also the Id key now uses a four integer array UUID.
- The zombie pigman entity changed to a "zombified piglin", I'd expect the entity id to have changes as well, but I don't know for sure.
- Angry animals (Bees, zombified piglins, wolves, iron golems, piglins and endermen) now use different NBT tags for anger. For example, the zombified piglin now uses AngryAt instead of HurtBy. Besides that, the duration of anger is now indicated by "AngerTime" instead of "Anger" for zombified piglins.
- Advancement trigger "safely_harvest_honey" has been removed, since "item_used_on_block" already exists.
- Advancement triggers now support a "player" checks that use loot table conditions. This makes a lot of dedicated fields deprecated since those loot table conditions can check the same thing. Although still functional, dedicated fields that could be implemented using loot table conditions is not recommended for new code.
- The jigsaw block (from the structure block family) changed quite a bit. View the full changelog here.
- Redstone behaviour changed a lot. Unlikely to be used in datapacks though, but I'll mention it anyways just in case anyone wants to spawn structures with it. See the full changelog here.
- Walls (any kind) now have a blockstate for each of the directions, indicating whether the wall in that direction (within the same block) should not exist, be low or be tall.
- (Dragon) fireball and wither skull direction and life NBT tags have been removed
1
If anyone gets stuck upgrading, please ask =)
2
This looks like a lot of fun to try, though I'll admit I'd have trouble coming up with ideas!
1
Can it be made in Minecraft 1.14.06 or Pocket Edition?
1
It won't work on Pocket Edition / Bedrock Edition and <1.15 is not allowed in order to take part in the event. However, the framework might still work in lower versions, so if you want to use it in a datapack outside the event, go ahead :P
1
Hey so is the word "Murderous" allowed? If not, what alternatives do I have?
1
I can't tell you, but perhaps you could search for the word on PMC to see if others got away with it? If you can't find any submissions, maybe an admin or moderator should answer this.
1
Welp, I’ll stick with savage lol
1
Deadly, fatal, lethal
2
you can place the spawn eggs in spawners and you get free armor stands. lol
1
A fun little easter egg I suppose XD
Send me a video of your armor stand farm haha
Send me a video of your armor stand farm haha
1
It'll also prevent the bug where if you place it on a non-full block like a button, the block gets replaced
2
I mean if you want to leave it there, you can, but there's a more polished way to do this. You could give the player the exact same skull item, but with a special tag like "{luckyBlock:1}" and then only detects items that do NOT have that tag. That will fix the spawner bug but more importantly, give the player the actual skull, and it looks nicer than a zombie egg and gives the player a hint of what the lucky block looks like.
1
For a long time I deemed this impossible, because tags disappear when you place the block and I preferred spawn eggs over having to drop the item on the ground. Only recently I published an update where lucky blocks don't have armor stands sitting at the lucky block to track it being broken any more and I didn't realise that means skull items can be used directly.
Will fix soon =)
EDIT: Fixed
Will fix soon =)
EDIT: Fixed
2
Theoretically, if you were still using the armor stand method, you could use a fill command that fills a square around the player that replaces skulls with that specific skin with a command block. That looks not so nice though. Or you could’ve done a different method: detecting each individual skull block around the player and summon an invisible armor stand on those that doesn’t have it. But both of the methods require a little bit too much effort and aren’t worth it for a lucky block data pack. But thanks to the detection optimization, the placement method can also be optimized :)
3
Still think it's pretty cool that there's an official datapack thing (too bad my creative block will probably prevent me from even doing anything)
2
Lucky Block Framework Update
Apparently the submissions are a lot more sophisticated than I had expected, so the register_options template command now allows to specify more information that can be used to explain how structures work, give hints, explain what a player needs to do to solve a mystery, etc.
The new template command is:
Apparently the submissions are a lot more sophisticated than I had expected, so the register_options template command now allows to specify more information that can be used to explain how structures work, give hints, explain what a player needs to do to solve a mystery, etc.
The new template command is:
data modify storage bertiecrafter:pmclb options append value {title:"<title>",author:"<name>",function:"/function <namespace>:pmclb/<path-to-function>",info:"<Extra info or blank>"} Note that this new version is backwards compatible, so you do not need to add the "info" tag to already existing option registrations.2
Lucky Block Event Update
I just reviewed the first submissions and I came across something I didn't think of, but will be added to the rules soon:
warning You're only allowed to take visible actions in option implementations. This means that tick, load, uninstall and register_options functions should not output chat messages, sounds or anything of the kind.
Also a friendly reminder to really try and make all globaly unique items (scoreboard objectives, teams, bossbars, tags, etc) actually globally unique. This usually involves adding prefixes to those names based on your namespace.
I just reviewed the first submissions and I came across something I didn't think of, but will be added to the rules soon:
warning You're only allowed to take visible actions in option implementations. This means that tick, load, uninstall and register_options functions should not output chat messages, sounds or anything of the kind.
Also a friendly reminder to really try and make all globaly unique items (scoreboard objectives, teams, bossbars, tags, etc) actually globally unique. This usually involves adding prefixes to those names based on your namespace.
2
So if I have a custom item that does something having to do with sound/chat, and that something is executed through the tick function, that’s allowed right?
1
Yup, you got it!
1
Also, what does "anything of the kind" mean? Would particles fall under that too for example? And if so, what wouldn't fall under it, at that point?
1
Yes, particles too.
register_options must only be used to copy the template commands for new options.
tick should only be used to track spawned creations and modify them or nearby players based on certain conditions. If you want a created entity to show particles near a player, you can do that.
load/uninstall should only set up or remove scoreboard objectives, bossbars, teams, etc.
The rule is mainly in place to prevent visible output that is unrelated to a chosen option, like a message in chat after /reload.
register_options must only be used to copy the template commands for new options.
tick should only be used to track spawned creations and modify them or nearby players based on certain conditions. If you want a created entity to show particles near a player, you can do that.
load/uninstall should only set up or remove scoreboard objectives, bossbars, teams, etc.
The rule is mainly in place to prevent visible output that is unrelated to a chosen option, like a message in chat after /reload.
1
Why though? Chat messages, and more so sounds, can be rather useful :/
3
You can still use all of the listed elements in your own functions when a lucky block gets broken or to make spawned creations a little cooler with sounds and particles!
Just ensure you stay invisible until it's your time to shine =) So don't make anything visible happen in load, uninstall, tick and register_options functions.
Just ensure you stay invisible until it's your time to shine =) So don't make anything visible happen in load, uninstall, tick and register_options functions.
2
Aah, alright, seems I have simply misunderstood you, sorry for that.
2
It's fine to ask anyways. There might have been more people questioning the same thing.
2
I want to participate, do I need to use my username or can I use my capitals "sc", as that's what I usually use.
1
It's best to use your full username as namespace, but feel free to use the short version for prefixes on objectives, tags, teams, bossbars, etc.
3
Hi, I was just wondering how many options the lucky block needs? I've got about five or so, at the moment but I'm not sure how many more ideas I can come up with that are actually good.
Should I keep it 100% good additions, or should I add some filler and junk, like small rewards and random stuff that other people have probably already done?
Should I keep it 100% good additions, or should I add some filler and junk, like small rewards and random stuff that other people have probably already done?
2
As said in the rules:
Unfortunately I can't give you an optimal amount of options. It's best to keep them of high quality and submit less options if you can't come up with more :p
A submission can have multiple options (lucky block implementations), but keep in mind that it's all-or-nothing when it comes down to being accepted into the final data pack. We rather see fewer high-quality options than a ton of quick and dirty options.
Unfortunately I can't give you an optimal amount of options. It's best to keep them of high quality and submit less options if you can't come up with more :p
2
Thanks, I just wasn't sure if I needed to make a full pack of just the important parts, the post was a bit vague about that.
3
Can I add a boss fight to my pack? (Don’t worry, I’m using your framework)
2
This was already asked, just keep it fun and make sure players can move on to the next lucky block if they want to. Another user decided to spawn some kind of activation mechanism that gives players the choise of spawning it. This allows the amount of required interaction to stay low, while the actual boss can be in depth.
This is not required though, you can also just spawn the mob directly and allow players to run away :P
This is not required though, you can also just spawn the mob directly and allow players to run away :P
view more replies ( 1 )
view more replies ( 10 )
