A small comment on the massive changes 1.20.5 is bringing to the table and it's massive effects to datapacks and custom maps as a whole:
I think the hardest thing with making the ideas I wanted to make happen into a datapack is that a lot of the times it's really really hard to do so efficiently, and some other times, Mojang would step in and mess with your stuff, and without the reach needed to overrule the thing they've irreversibly changed, you kinda just have to live with the storm.
It's understandable if because of that or any other reason, creators would prefer mods over datapacks since they can do what they want on a version they choose to do it at (basically removing Mojang's effect on things, at least partially, if you've read some of my secret Patreon dev posts), and if they choose to do so, we should still support them for it, because at the end of all this, they've spent the hours that could've been spent in other ventures that'll most likely give them way more money, to make sure you get the best things possible, in the best way that they can. (Wait, I've been making datapacks for 5 years? Time flies, man.) As for me? I'll just live with the storm and do my best to make sure all my projects I've made in the 1.20x series get a proper update to 1.20.5. I personally find the storm to be a challenge, a problem that I'm slowly overcoming with Scripter - which, in a way, is like the hand-crafted ship I'd built to weather this storm. But also because I wanted to experience the latest stuff the game has to offer with the tweaks that I've personally made to enhance the game the way I find fun to play.
But anyways, enough of that, the updates are coming. I'll leave update details on Discord if you wanted to check those out.
You honestly thought I was also moving to mods, don't ya? Reply to this one if you think I was about to say something like that at any point in the post.
I know that technically a datapack can stay at a given release too, but unlike mods, datapacks are more reliant on the tools that Mojang provides in each new release. So something I wanted to make back in 1.13 for example, can't really be made efficiently until way later on. It's kinda why I have a long list of old ideas. I just kept them all, even when I know it's not doable, so when it is, I can start messing with it.
At some point I'll make it possible so everyone could quickly make packs with my custom datapack creator Scripter. I'm not confident with showing the tool as it is now, as it was only built to suit my weird style, so it likely won't help anyone as it is. But someday, when I have a lot more time to spend on datapack shenanigans, I'll work on a version that can be used by a more diverse set of people, and release it by then.
Anywho, 1.20.5 is coming. Working on upgrading all my projects, more news in the Discord Server. See you soon!
Gee, I wonder what's the average time on how long it would take for an Important bug to be fixed. I got this bug marked as Important in 1.20.4 when I realized that it broke a Villager Names feature in a way that can't really be worked around efficiently, even with the new stuff available in 1.20.5, and somehow it survived the full 1.20.5 snapshot cycle without even being noticed.
Anywho, if you're wondering why the workaround still exists in Villager Names 1.20.5, this is why. I'll leave a note in the pack's Update Log by then as well.
My guess would be several years… [that's using my definition of important bug which ignores all the "Misspelled name in credits" & "Fixed bad pixel in X model" padding…]
Time for a discussion: I think the Datapacks section in PlanetMinecraft field should be split into 2 categories: Datapacks and Modded Datapacks.
Modded Datapacks are datapacks designed to work for a particular mod or a modpack. (requires the mod/modpack's link in the download as well, kinda like required resource packs)
Datapacks are for packs designed for Vanilla Minecraft.
I think that when datapacks are mentioned people mostly mean vanilla datapacks anyway, so that's why I think the term "Datapacks" should be for packs designed in Vanilla. Anyways, let me know what you think!
I don't really think another category would do in this case.
Categories are often used to split up the different branches of the same big tree. But modded datapacks and vanilla datapacks are their own separate trees altogether - even though they are both trees (tree in this case being a datapack), they work on different environments which most of the time isn't compatible with eachother (a modded datapack might modify something vanilla itself doesn't have, for example), and hence can't be considered branches of the same tree.
From an user experience point of view: If you're someone who has no idea about the technical things that can be done by vanilla datapacks, you'd assume modded datapacks and vanilla datapacks as one and the same (since they're both categorized as "datapacks" at first based on the site's current design), only to then install a modded datapack in vanilla and be confused about why it doesn't work, or vice versa.
Splitting it into two categories would be a bit much, instead we could theoretically add a checkbox for something like “Requires a mod” and they could filter out those that do.
I'm none too clear on the lines between texture packs / data packs / resource packs / mods so some clarification wight be a good place to start…
Assuming I correctly understand what you mean, having at least a filter setting for those that require additional software (Optifine seems to be a commonly sited example) would make sense. Whether an entirely seperate subfora is needed is more debatable as there may be those who prefer having only one place through which to search. [Which again brings up the issue of overlap between various sorts of game modifying 'things'.]
Bye the bye, this probably shoud be filled as a suggestion ticket if you find any reasonable level of support…
I hate planned obsolescence. Why intentionally make your products bad after a few years of use? Sure, you'd get more trades doing that, and more trades means more money, but it comes at a cost of screwing everyone over.
PS: I said this because my new mouse broke after a year of use, and I had an older mouse that lasted for 5 years before this. I can see why some people would hoard old stuff in boxes and just use that - I mean I would if it means I don't have to waste valuable time in buying a new mouse every year.
Also: If you haven't joined TheDiamondDiscord yet, now's a pretty good time to, as the upcoming Prototype of Project 521 will only be available for those who're in my Discord Server. Also, if you're already in the Discord Server messing with the Prototype, feel free to drop me any suggestions you have about it there, and I'll consider them all in future updates!
Project 521 will still be available on PMC, but I'll only post it when all the features for it have properly been sorted out. Currently I'm still working on the thing - it's a pretty huge project despite its simple premise, and I can't wait to show you all here about it, but for the time being, all that chat's going in the Discord.
It's funny how 521's going to add a custom thing that requires crafting something not possible to do in the current recipes system - which resulted in me having to figure out how to design an efficient custom crafting system on top of making sure 521 still works well with it, then this week's snapshot came about. The new changes to the recipes system meant that I'd have to consider more possible options in how I'm upgrading Scripter to 1.20.5 as everything it has to offer is clearly not being shown to us yet, but I'm sure it'll be worth it for the long run. More news soon!
I might take this chance to tell you why I don't want to make a single version that supports a wide variety of releases like I did before: The game changed how updates work that made it impossible to pull off. Nowadays, every version has its own breaking change and in order to support that I'd have to add files specifically to counter that change when it happens, and for some cases it would easily double the filesize, making downloads effectively impossible. (It's also pretty inefficient as there would always be files in the system the game doesn't even use that just takes up space) Imagine if I'd made 1 version of Decapitation that supports the entire 1.20x branch. With 1.20.2 the filesize would've been doubled because of Skin Reporting changes breaking head formats entirely (hence there needs to be a new set of heads written in the new format), and now 1.20.5 would've tripled the original filesize because of the huge change I mentioned in the last post. And that's even before the upcoming Tropical Fish Heads update that aims to add 3072 Tropical Fish Head variants in the game! (Also: that's still in the works, I just had to do everything by myself since the original help call didn't really work how I thought it would.)
So instead I've decided to design my own version naming system, using the letter to indicate which Minecaft dot release the update is for, and put all older releases available for free on Patreon. It's a bit more complicated to understand at first, but I always respond to help threads if you need help, and more importantly that means you guys can still download my stuff without the filesizes going overboard.
PS: If you like what I've done and you want me to do more of this stuff, support me on Patreon for more! There are also some exclusive stuff there, too! I'm just one person doing all of this so don't expect much exclusive stuff, but I try my best!
Outlaw F
4/13/24 7:20
• posted 7/10/21 9:38
MC_SIlver
3/30/24 1:44
• posted 7/27/20 5:51
UltroGhast
•3/26/24 10:04
kohara_
3/20/24 6:16
• posted 12/26/21 3:33
Reply to this one if you think I was about to say something like that at any point in the post.