Translation notice
This page was translated with machine translation and may contain inaccuracies. If you can help improve it, please open an issue or submit a pull request.
The “ultimate answer” to vanilla furniture? ——New generation furniture frame "Pine Cone"
As an architectural decoration player, if a furniture module is recommended to you, what would you consider? Focusing on the art style, model quality, and content quantity of this mod? Or are you worried about the applicable version, module compatibility, and ease of use of this module? If you were a modder, how would you choose between these directions?
In the past, I have provided many answers to the topic of "vanilla decoration modules"[1]. After a year of exploration, accumulation and precipitation, I compiled the "Pinecone Core" furniture framework.
The founding of "Meow Workshop" and its unique interpretation of furniture
When I first got involved in data pack development a year ago, I was producing content for the survival server. At that time, I had already come up with the idea of making furniture in the game. That time coincided with the Minecraft 1.20.6 update, and the birth of the item component provided numerous possibilities for customizing items in the game. So after a month or two of modeling and development, I co-created the first work - "Meow Workshop" with my friend who made the model. It completely explained our thinking about the "vanilla decoration module" at that time: designing the furniture as a special "block", occupying 1*1*1 independent space, and carefully handling the placement and space occupation relationship with the vanilla block, using the analogy of "block" to increase the player's intimacy with the furniture. The furniture also has rich interactive effects and can even be customized in the game, making it fully prepared for multiplayer and server applications. These ideas are actually very unique, and even a little "unsociable" compared with common furniture modules. It is even difficult for me to measure the response it brings in terms of good or bad.
But regardless of the response, the writing of "Miao Workshop" was undoubtedly advanced at the time. It used almost all the functions of the Java version since 1.19.4 - display entities and interactive entities, function macros, and item components. The addition of these functions has pushed the data pack to unprecedented heights, and also made "Miao Workshop" as easy to use as a MOD. But correspondingly, its minimum version is helplessly limited to 1.21. Since the release of "Miao Workshop", most of the messages I have received have asked about the possibility of low version adaptation. While feeling deeply helpless, I also lamented the complexity of the Minecraft ecosystem. It’s a pity that I don’t know how to write MODs, which is probably a small regret for “Mew Workshop” at the moment.
Thoughts on content promotion and the birth of "Pine Cone"
It was also since the release of "Miao Workshop" that I gradually noticed various problems left over from the beginning of its design. Version compatibility, content updates, resource compatibility... they all drive me to think repeatedly about the way out of the "vanilla decoration module". As a decorative module, many players will naturally "pay" for the models of "Miao Workshop". This is also an important fulcrum for us to continue to promote "Miao Workshop" in the future. We have added nearly a thousand models to the first version when it was released, and now the number of models has reached more than 2,000. Even so, it is still a challenge for us to ensure subsequent model updates. The barrier to entry for making Minecraft models is low, but excellent models still require a lot of effort. It is foreseeable that at some point in the future we will no longer be able to make new models. Although basic compatibility updates are not difficult, "Miao Workshop" is a tepid decorative module. If it loses the fulcrum for the promotion of new content, it will probably mean the end of its life cycle.
So I also tentatively asked some model authors about their willingness to cooperate, and I came to the conclusion that most authors pay more attention to the independence of their works and hope to publish their works themselves. I once proposed an idea: to enable "Miao Workshop" to support model expansion packs. In this way, model authors can publish expansion packs by themselves, and players only need to install the main body of "Miao Workshop" and expansion packs from other authors to play. Unfortunately, the slightly weak infrastructure of "Miao Workshop" negates this possibility, and other authors are probably unwilling to let their models be used as "accessories" of others.
The future of "Miao Workshop" still needs to be explored, but in communicating with other authors, I noticed some new opportunities. Many authors can actually make very good models, but because they lack the corresponding technology, they have no chance to have their models represented in the game. What if I could release a new tool that is convenient enough so that model authors can convert the models into data packs and resource packs by themselves, and hand them over to the players as if they were independently released? This sounds like a very meaningful thing, and it will have a positive impact on authors, players, and even the entire gaming community. At this point, our answer seems to be ready. But this is not the case, a huge dark cloud is still hovering over the vanilla decorative module - the conflict of resource packs.
For a long time, resource packs have relied on custom model numbers specified by Minecraft. By defining a mapping table between numbers and models, the same vanilla item can be displayed differently in the game. Most decoration resource packs will use this mapping table to add custom models to items such as leather horse armor and firework stars that have little effect in vanilla but can support dyeing. And it is this mapping table that plays a key role that actually conflicts in different resource packs. For a specific vanilla item, even if there are no conflicts in the mapping tables, Minecraft will only read the mapping table with the highest priority. This means that if we install two furniture resource packs, both of which use the firework star as a vanilla item to define the model number, only one furniture pack will be displayed normally. Such a "feature" brought fatal compatibility issues to the resource pack, and also greatly limited the possibility of vanilla decoration modules - until the resource pack update brought by 1.21.4.
"Any item can call any model" is just the tip of the resource pack update iceberg, but it becomes the last piece of the puzzle to realize the "ideal" mentioned above. Now, we can create a very simple and easy-to-use generation tool. Its purpose is to help model authors who have no data pack foundation at all to create a simple and reliable data pack furniture module. The author only needs to export the model and textures, fill in some simple furniture configurations according to actual needs, and then run a script program to appreciate the wonderful process of converting his model into a data pack and resource pack. Import it into the game and you can synthesize, place and dye furniture directly in the game. Not only that, all furniture packages created using this tool can be used at the same time without conflict, which means that different authors can publish their works with confidence, and players can also add these furniture packages like matching modules.
This is the "Pinecone Core" I wrote.
data pack or MOD?
Regarding "Pinecone" developed based on data pack, it is actually difficult for me to have a glimpse of its prospects. I hope more players can experience content developed based on data pack, because they are developed faster and can keep up with the version. When you want to try making it yourself, the threshold for data pack is relatively low. But for now, most players may still prefer the traditional MOD form. After all, there is richer content there, and the backward version is not a problem. I believe that as readers of this magazine, everyone has experienced countless such discussions and even arguments. I once told myself that no matter the player or the author, everyone just chooses their own preference, and I can stick to the idea of developing my own data pack. I want to believe that data pack still has broad prospects, but every time I read bilibili's comments, I still can't help but wonder: Should I make them into MODs?
Maybe let’s look forward to what surprises or scares the next Java snapshot can bring.
Vanilla decoration module is an expansion pack that uses data pack and resource pack and does not rely on MODs or plug-ins. It can add decorative content to the game under vanilla games. Although from a technical point of view, it is more accurate to call it a data pack or a resource pack, in order to sound friendly, we still call it a "module" and add the word "vanilla" to distinguish it from non-vanilla MODs. ↩︎