Hello everyone,
today, I show you new additions to the SkyBlock game for minecraft servers. This time, new functions were added, which allow new features to the game and also make it way more customizable for the users of the game. As always, the new additions are all licenced under the MIT license and can be used on other projects for free.
1. Repository
https://github.com/Abwasserrohr/SKYBLOCK.SK
2. Index
- Repository
- Index
- New Features
3.1. Custom heads
3.2. New "checkislandacces" function
3.3. Trust other players
3.4. Customizable flags
3.5. Multi-line lore support for gui.sk - Pull requests
- GitHub Account
- How to contribute
3. New Features
With the new features and functions being added to the game, I'm getting closer and closer to the first release of the actual game. There are new issues coming in which I'll been trying to fix directly either into the master or by squeezing them into pull requests. I know, that's not very nice but some changes are so small that I didn't feel to show them here.
Now, let's get started with the changes I want to tell you guys. =)
3.1. Custom heads
There are many ways how to get custom heads in Minecraft. But if you need a custom head directly in vanilla Skript, there are not that many ways how to accomplish this task. I used the plain vanilla Skript method without any plug-in, this allows others to implement custom heads into their scripts without having to install any other add-on. But it actually would need another tweak to allow the pure vanilla Skript function, since Skript can't generator a random UUID.
Since we're using skript-mirror, a powerful mirror tool which allows us to use Java, this is going to get a upgrade in the future. The vanilla Version will get a special place if someone needs this.
This function allows the Skript user (creator) to get a head with an custom skin on it as an item variable in Skript. Why do I need the custom skin as a item variable?
If I want to create some unique menus, like a special menu for languages, these heads can be quite useful and also give the user unlimited amounts of customization. I can simply add all language (country) flags i need, upload it to the Mojang skin database and use it.
This process is even more easy, since the server operator only have to place a file with the right format as an url on https://mineskin.org and then generate a base64 encoded texture url, which is also being used by the new custom heads function.
Now, how has this been made?
Now, since we're not doing the Java part, it's fairly simple.
First of all, I defined the Function. It needs three parameters and returns the item.
- name - This is the name of the head, it has to be unique for every skin
- base64 - This can be found on the internet and is the texture value, which can look like this:
eyJ0aW1lc3RhbXAiOjE1NDQ2MDI3MDY1NDcsInByb2ZpbGVJZCI6IjMzOGFlMTFhZDQ3ODQ3NjFhYzhhZGNlNmQ5OTg3OWVmIiwicHJvZmlsZU5hbWUiOiJJbW1hbnVlbDk0Iiwic2lnbmF0dXJlUmVxdWlyZWQiOnRydWUsInRleHR1cmVzIjp7IlNLSU4iOnsidXJsIjoiaHR0cDovL3RleHR1cmVzLm1pbmVjcmFmdC5uZXQvdGV4dHVyZS81NzllYmY3ODQyYzQ0MGVmODk5YjFiM2FmZjYwNDVkZWM1NjU4YTFiZjQ4Mjc0MzU0MzVmMWY3NWFlYzI0NzFkIn19fQ==
- player - Also a player is needed.
function getcustomhead(name:text,base64:text,p:player) :: item:
Now, we know the name of the head that we need. Maybe we already saved this head in a global variable:
if {SK::HEADS::%{_name}%} is not set:
If we don't have the head set as an variable yet, we now generate a new head and then save it as a variable, then it is faster the next time.
Every head needs a unique idea, here, we can create one. We also need to import java.util.UUID
to do this.
set {_ruuid} to UUID.randomUUID()
Now we create a backup of the item in player's hotbar slot 0.
set {_tool} to slot 0 of {_p}
Then, the item in player's hotbar slot 0 is being replaced by the head by a vanilla command, there is no other way in vanilla Skript yet to get it.
execute console command "/replaceitem entity %{_p}% hotbar.0 minecraft:player_head{display:{Name:""{\""text\"":\""%{_name}%\""}""},SkullOwner:{Id:""%{_ruuid}%"",Properties:{textures:[{Value:""%{_base64}%""}]}}}"
Then, we set the local variable {_head} to the player's hotbar slot 0, which is the new skin head.
set {_head} to slot 0 of {_p}
Since we now have the head in a variable, we can give the player his old items back.
set slot 0 of {_p} to {_tool}
To make this process faster the next time, the local variable is set into a global one. The process above is fast but a big inventory containing 57 custom heads might take more than 0.01 seconds. With variables, this is almost instantly.
set {SK::HEADS::%{_name}%} to {_head}
Now, it's time to return the new head, which can be used in Skript.
return {_head}
If we already had the head, we can simply return the already existing head, very fast.
else:
return {SK::HEADS::%{_name}%}
Now, as said, the process is not perfect. But it works even without any add-on (random uuids have to be predefined), which opens new doors for people who don't want to use any add-on. Many people might not have thought of doing it this way, but it actually works. =)
The custom heads are later used for the languages menu, in which the visualization is very nice and helps players to get the right language.
Pull request: https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/44
3.2. New "checkislandacces" function
The new "checkislandaccess" function is checking the access to the island using a new way.
Why do we need another (and new) way to check if the player has access to the island?
The old and first way I did it was to set the two border points of the island fixed on island creation. This is a very fast and easy way to get what was needed: A protection to know if the player is on his island or not.
It also worked fine and did its job. But there are some problems which made this not as usable as it is:
- Since we have fixed border variables for every player, any change on an island would have to be made on all players and members.
- Adding people to an island who already are on another island is not possible without adding new borders, which would need another update if something changes. This would get bigger and bigger and messy, which I want to avoid.
- Having flags for specific islands, which can be defined by the island owner is not possible, since we’re not knowing on which island the player stands. There is already a function which does this type of function, but it is slower than this new function and the new function also gives a boolean back if the user is allowed to change something at the location where he is or not.
There are more things which made this a necessary issue which had to be fixed. This makes SKYBLOCK.SK very customizable not only for the server operators, but also for the players on the server, which many other SkyBlock solutions are lacking of.
To make the whole Skript more organized, I decided to add new folders for new functions. This is similar to Java classes, which also can be separated to get a nice overview of everything and easy to read files without getting messy.
This is also what I wanted and a way to make this happen is by creating another folder in the "plugins/Skript/scripts/SkyBlock/SKYBLOCK.SK/Functions" folder, which contains new functions.
As example, if something doesn't work and somebody has to find the right function for the job, he can simply look into the "Functions" folder and search there for the right function and then look why it doesn't work.
This also is better for the open source community, since some functions might also be interesting for other people.
I don't want to get into how it works here, it isn't very long but I don't want to overfill the posts with code... =D
But here are the functions and i explain shortly what they're doing:
function checkislandaccess(p:player,l: location,t: integer=1) :: boolean:
This function checks, if the user is allowed to do something at the location, within the function, it calls the getcurrentbedrock function to get the current bedrock location, which is the middle of the island.function getcurrentbedrock(p:player, l:location) :: location:
This function gets the location of the current bedrock for the player. It uses the getcurrentbedrockmain function to get the actual bedrock and also uses caching to cache the last bedrock location and only calls the getcurrentbedrockmain function if it detects that the player changed the bedrock location.function getcurrentbedrockmain(l:location) :: location:
getcurrentbedrockmain searches the new bedrock within the player's location. It works quite fast (0.02 seconds), the result should be cached and only be called if a new bedrock is needed. Example: If the player changes the island, then the new bedrock is needed once the player does something to know if he is allowed to do so.
I linked the first commit and also the pull request, in which the function changed until it got merged.
Commit: https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/45/commits/c711b52330076c9951ff0a2015d5adb31fb9b098
Pull request: https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/45
3.3. Trust other players
Trusting other players on a island hasn't been possible until now, thanks to the new checkislandaccess function, we can add trusted players to the bedrock variables of the island and then check if the player is a trusted player.
Previous, only the leader of an island and the members were able to build and break blocks on the island. Now, everyone can be trusted and is then able to help the player out.
To not overfill the Comments.sk file with more code, i added another function which is called "trusthandler", it does exactly that for what it's name stands for, handling trusted players. Instead of directly handling the trust arguments by players within the Comments.sk file, "trusthandler" is called with the arguments.
There are the following options for players:
- /island trust list - Lists all trusted players
- /island trust add - Adds a player
- /island trust remove - Removes a player
- /island trust - Prints a help for the commands above
I linked the commit directly. It is within the same pull request as the new "checkislandaccess" function.
All trusted players are stored in global variables. These are the default way in Skript to store data.
The new variable for trusted players looks like this:
{SB::island::%{_x}%_%{_y}%_%{_z}%::trust::*}
The x, y and z local variables are the location of the bedrock of the island (center), the player gets added to. Then later, the "checkislandaccess" can check if the player is on this list. If he is, the access is granted, if not, the player can't do anything.
Commit: https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/45/commits/348be175252ec3f59701556cee90d9640bb22083
Pull request: https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/45
3.4. Customizable flags
Now this is something new I'm happy about it is working now. =) Customizable flags allow the leader of the island to change the flags. To define what flags are, these are settings for specific actions which should be allowed for outsiders, which are not members of the island.
I've added the following flags for the island leaders, which can be changed using a new menu very fast and easy.
- Explosions
- Allow animal damage by outsiders
- Allow monster damage by outsiders
- Allow usage of buttons and levers by outsiders
- Allow usage of doors by outsiders
- Allow placement and destroying of vehicles by outsiders
- Make the island public available for everyone
These can easily be changed by one click. The player only have to open the menu with /island flag or /island flags and then click on what the player wants to toggle. If the server operator has this flag enabled (default), the leader of the island can then change the flag like he want.
Why do island leaders need this? Players are connecting together, many build railroads from one to another island or other things, like big stores with doors or buttons to open a path. With the flags, the island leader can set this how he wants. This makes the life easier for the server operator, since he doesn't have to mind if a player wants his minecarts secure while others want to make a railroad network through the server.
I don't want to show much more code on how that works but rather explaining how this is done:
The server operator can change the default settings and flags in the config.sk. The server operator also can change the flags for the lobby island.
It can also be disabled to not let people change any flags, if this is wanted.
The flag variables look like this and are all Booleans (either true or false):
{SB::config::defaultisflag::explosion}
and the default flag for the lobby:
{SB::config::defaultlobbyflag::explosion}
Once a explosion happens on the server, the location of the bedrock is being searched, if found, it is an island and {SB::config::defaultisflag::explosion}
is checked. If there is a player set flag set, which looks like this: {SB::island::%{_x}%_%{_y}%_%{_z}%::flag::explosion}
The x, y and z local variables are the locations of the bedrock of the island (center), which can be detected by the "checkislandaccess" function, which also checks for the flags directly and then returns either true (explosion is allowed) or false (explosion has to be cancelled).
The following features were added:
- Check flags on an event and allow the event if it is allowed by the server operator or the island leader
- Added default flags
- Added translations in German for all flags (English is coming in the future)
- Added a new menu which allows the player to change the flags by one click
- Added a new command argument for the new menu: /island flags
- Added the new flag command to the help command
There are many places which have been changed to make this possible. Most of the things that where needed for this to be possible happened in the pull request linked below:
Pull request: https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/45
3.5. Multi-line lore support for gui.sk
This is a small enhancement, which allows the lore (the text below an item name) to have multiple lines. All it does is splitting the "lore" parameter at every "\n" and then loop trough the new array and add it to the lore array using the already existing Java classes.Commit: https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/46/commits/871b698521e0e0b96b65191bd0b6a2b414e9895b
4. Pull requests
https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/44
https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/45
https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/46
5. GitHub Account
https://github.com/Abwasserrohr
6. How to contribute
If you're interested to contribute to SKYBLOCK.SK, feel free to ask Abwasserrohr on the Discord server linked below. It is also possible to create pull requests, if you know already what to do. =)
Also people new to coding are welcome. I'll already helping people getting into Skript and also into Java. If you need help, I'm going to try my best to help you. :3
Discord: https://discord.gg/FRuK5BC
Thanks for reading this contribution post. This time i didn't add all the code and explained everything, since there is too much to show and it would overload the whole entry. I also have to save some resources to create new steem accounts for fellow Minecraft players... =D
If you have feedback, i really appreciate any feedback, either negative or positive. I'm looking forward to make my posts better. =)
Keep on steeming and have a nice week,
/island flag
or/island flags
.Your contribution has been evaluated according to Utopian policies and guidelines, as well as a predefined set of questions pertaining to the category.
To view those questions and the relevant answers related to your post, click here.
Need help? Write a ticket on https://support.utopian.io/.
Chat with us on Discord.
[utopian-moderator]
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Thanks for reviewing my post. =)
Yeah, i should highlight the commands to make it easier to read. Thanks for your feedback. :)
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Thank you for your review, @helo! Keep up the good work!
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Nice to see what happend the last days.
It is such a good Gamemode you have coded for the server.
Its like Santa was here.
Many many thanks for that.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Thank you for the kind feedback. =D
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Hi @immanuel94!
Your post was upvoted by @steem-ua, new Steem dApp, using UserAuthority for algorithmic post curation!
Your post is eligible for our upvote, thanks to our collaboration with @utopian-io!
Feel free to join our @steem-ua Discord server
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Hey, @immanuel94!
Thanks for contributing on Utopian.
We’re already looking forward to your next contribution!
Get higher incentives and support Utopian.io!
Simply set @utopian.pay as a 5% (or higher) payout beneficiary on your contribution post (via SteemPlus or Steeditor).
Want to chat? Join us on Discord https://discord.gg/h52nFrV.
Vote for Utopian Witness!
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Coole Idee
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit