3
bvuno
michaelo
should i do a plugin from it, or add more features?
Create an account or sign in to comment.
14
2
I think the main thing I can see is just optimising it a bit.
> The score checks in your hud function could definitely do with condesing down: rather than checking for each colour 5 times, just check once and then call another function with the rest of the commands in. This would reduce the number of commands running from 80 to 21.
> When you're storing the players coordinates, it should be faster to to copy the whole Pos array to storage, and then store the coords from there, instead of storing directly from the player every time. You would need to run that all in one function as @a tho for multiplayer compatibility :)
Also I saw someone else suggested showing the biome, which you can just do with execute if biome! Wiki says there are 64 biomes currently, so you should probably use a binary search tree to reduce the number of commands. You'll need to make a load of biome tags for this: split them into two groups of 32, then split those two groups both into two groups of 16, then two groups of 8, then two groups of 4. For example, if you assigned them all a number and you were in biome number 3, the commands would check if you were in 1 - 32 or 33 - 64, then 1 - 16 or 17 - 32, then 1 - 8 or 9 - 16, then 1 - 4 or 5 - 8, and finally finding you with the last 4 commands in the function for 1-4. You could do this with the score checks in your hud function as well but that might be a bit overkill.
Hope that all makes sense!
> The score checks in your hud function could definitely do with condesing down: rather than checking for each colour 5 times, just check once and then call another function with the rest of the commands in. This would reduce the number of commands running from 80 to 21.
> When you're storing the players coordinates, it should be faster to to copy the whole Pos array to storage, and then store the coords from there, instead of storing directly from the player every time. You would need to run that all in one function as @a tho for multiplayer compatibility :)
Also I saw someone else suggested showing the biome, which you can just do with execute if biome! Wiki says there are 64 biomes currently, so you should probably use a binary search tree to reduce the number of commands. You'll need to make a load of biome tags for this: split them into two groups of 32, then split those two groups both into two groups of 16, then two groups of 8, then two groups of 4. For example, if you assigned them all a number and you were in biome number 3, the commands would check if you were in 1 - 32 or 33 - 64, then 1 - 16 or 17 - 32, then 1 - 8 or 9 - 16, then 1 - 4 or 5 - 8, and finally finding you with the last 4 commands in the function for 1-4. You could do this with the score checks in your hud function as well but that might be a bit overkill.
Hope that all makes sense!
1
maan you are what i was looking about!
>about the splitting the commands in different functions is something that i already did just after writing this thread, but you got a really good eye!
>the second point is something totally new to me ahah. to not use the scoreboard i tried to call the coordinate just by the nbt tag but i think there is nothing to change the variable type, i will apply your advice ASAP!
(should i make a storage for every player or with names i can store all in one?)
>i understand what you saying with the binary search tree but that mean that with 64 option we have to check first 32, then 16, then 8, then 4., then 2 that takes us to 62 maximum tries. there is something that could join in my help that is generics method like #minecraft:is_taiga but that would be really a pain the same.
>about the splitting the commands in different functions is something that i already did just after writing this thread, but you got a really good eye!
>the second point is something totally new to me ahah. to not use the scoreboard i tried to call the coordinate just by the nbt tag but i think there is nothing to change the variable type, i will apply your advice ASAP!
(should i make a storage for every player or with names i can store all in one?)
>i understand what you saying with the binary search tree but that mean that with 64 option we have to check first 32, then 16, then 8, then 4., then 2 that takes us to 62 maximum tries. there is something that could join in my help that is generics method like #minecraft:is_taiga but that would be really a pain the same.
1
i think i can do nothing with storing all the array of the pos if i have to take another array with them as integer, i will remove the 3 scoreboard and that's cool but i ha ve the same to use 3 different commands
2
Yeah if you just do nbt directly in the title then you won't get a nice round integer, luckily scoreboards only do integers so they fix it for you! There is another way you can do that with execute store, eg: /execute store result storage test Pos int 1 run data get entity @s Pos[0], where you can set it to be an integer, but you would only be able to do one coordinate at a time so it's not really any different from what you were doing anyway.
You should only need one storage as long as you do all the commands as @s in one function that's run as @a, eg: execute as @a run function. The game will run the function for each player one after the other, so the next player will override whatever was already in storage from the last player. So I would just do something like: /data modify storage cool:pack Pos set from entity @s Pos, and then you can do the scoreboard stuff from there.
Ah no, the idea is you only have to check 2 things each time. The first time you would have two commands like this:
/execute if score <> <> matches 1..32 run function check_1_to_32
/execute if score <> <> matches 33..64 run function check_33_to_64
Then in the subsequent functions you do the same thing until that you are just checking 2 numbers on their own. Every time you're checking if it's between values, rather than checking it it equals each value individually. It's a bit tricky to explain in words, but does that make more sense? In this situation though you wouldn't be using numbers, it would be biomes, so you would need to make your own biome tags. I've done something similar before by doing it alphabetically, it might look something like this:
/execute if biome ~ ~ ~ #a_to_m run function check_a_to_m
/execute if biome ~ ~ ~ #n_to_z run function check_n_to_z
It's the same concept, but it's much easier to do with numbers lol. I do agree though, messing with tags is a pain and honestly this would be quite a lot of work for something that I don't think would be very helpful anyway haha. It's normally pretty obvious what biome you're in, and I don't really think you need it on your hud. Just wanted to show it was possible though!
Just one last thing I thought of as well, you could get away with only runnning your commands once every two ticks instead of every tick. Because you're only using round numbers you won't be able to tell the difference!
You should only need one storage as long as you do all the commands as @s in one function that's run as @a, eg: execute as @a run function. The game will run the function for each player one after the other, so the next player will override whatever was already in storage from the last player. So I would just do something like: /data modify storage cool:pack Pos set from entity @s Pos, and then you can do the scoreboard stuff from there.
Ah no, the idea is you only have to check 2 things each time. The first time you would have two commands like this:
/execute if score <> <> matches 1..32 run function check_1_to_32
/execute if score <> <> matches 33..64 run function check_33_to_64
Then in the subsequent functions you do the same thing until that you are just checking 2 numbers on their own. Every time you're checking if it's between values, rather than checking it it equals each value individually. It's a bit tricky to explain in words, but does that make more sense? In this situation though you wouldn't be using numbers, it would be biomes, so you would need to make your own biome tags. I've done something similar before by doing it alphabetically, it might look something like this:
/execute if biome ~ ~ ~ #a_to_m run function check_a_to_m
/execute if biome ~ ~ ~ #n_to_z run function check_n_to_z
It's the same concept, but it's much easier to do with numbers lol. I do agree though, messing with tags is a pain and honestly this would be quite a lot of work for something that I don't think would be very helpful anyway haha. It's normally pretty obvious what biome you're in, and I don't really think you need it on your hud. Just wanted to show it was possible though!
Just one last thing I thought of as well, you could get away with only runnning your commands once every two ticks instead of every tick. Because you're only using round numbers you won't be able to tell the difference!
2
with what i just learn thanks to you i can made the compass of my hud a variable so that i dont have to have 5 different commands for a single color! how cool!
im going to move do all with the storages !
about the biomes i just think it like you, it is something that If it wasn't so over the top to do i would make it but that's not the case.
im going to move do all with the storages !
about the biomes i just think it like you, it is something that If it wasn't so over the top to do i would make it but that's not the case.
2
awesome, glad I could help!
2
My thoughts: I really like this datapack it is much cleaner looking than the f3 menu. I usually spend a whole 10 seconds trying to find where the coordinates are at and even that its hard to read because its mashed together.
What you can add: I can't really think of anything you can add except maybe what biome your in but even I don't know how to implement that using datapacks. I would just think of some more helpful things people would want to display on their hud. Also being able to select which things you want to show if you add more than one thing.
What you can add: I can't really think of anything you can add except maybe what biome your in but even I don't know how to implement that using datapacks. I would just think of some more helpful things people would want to display on their hud. Also being able to select which things you want to show if you add more than one thing.
2
that's really a good idea! i really appreciate this.
there is no nbt data to get what biome the player is, tho and i can't find other byways to get the biome name using vanilla minecraft :c
the customizable hud option would also be a little problem for the game,
i will explain: there is no way to get variable color in tellraw messages, i simply made 4 tellraw command for every color in the game (4, one for every direction) and this mean there are 64 commands that the game already have to check to show the hud ( i will optimize this in the next update)
i will try my best but i think the max i can make deactivatable the compass.
there is no nbt data to get what biome the player is, tho and i can't find other byways to get the biome name using vanilla minecraft :c
the customizable hud option would also be a little problem for the game,
i will explain: there is no way to get variable color in tellraw messages, i simply made 4 tellraw command for every color in the game (4, one for every direction) and this mean there are 64 commands that the game already have to check to show the hud ( i will optimize this in the next update)
i will try my best but i think the max i can make deactivatable the compass.
3
it be cool as plugin on server so i can get easy hud yes can you make it pvp friendly and show my pvp stats that be cool thank you
1
i can make it and release it open-source!
1
that be cool thank you
2
What datapack first? Title and short describtion of the function
