Hello minecrafters and steemians,
today, i have again some new changes for the SKYBLOCK.SK Minecraft add-on I want to share with you guys. I'm testing the new game also on my own server and I wanted to give people a long time experience in playing SkyBlock. For this, I added the new island upgrades. I give a discount on the new upgrades if you're a alpha tester on my server. =)
The newly added island upgrades allow increasing the size of an island, hoppers and homes by a configurable amount trough an intuitive island upgrade menu.
1. Repository
https://github.com/Abwasserrohr/SKYBLOCK.SK
2. Index
- Repository
- Index
- New Features
3.1. Island upgrades
3.2. Hopper limitation
3.3. Set multiple homes - Pull requests
- GitHub Account
- How to contribute
3. New Features
I have one big change this time, which also includes two smaller new feature changes, which have been necessary for this to make sense.
Adding island upgrades by increasing the size of the island has been an issue for some days now and now I add it. This is not something players want, since they could have gotten the full size instantly. But these features are very good for server operators to limit the island sizes, hopper amounts and also homes of the players and let them pay in-game money to increase these limits. This makes the SkyBlock a long time experience, since the players have something to upgrade and have something to work for on their island.
3.1. Island upgrades
As said above, this is not appreciated by players who already play the game. This game has still no release but I'm going to wards the first release and this had to be included to not annoy players later on other servers. Since downgrading is not appreciated by players, this should be there at the beginning and not introduced later.
The island upgrades menu is a function, which is called trough the command /island upgrades and is displaying all available upgrades to the player, it shows already bought ones with green glass panes and the one, who aren't bought yet with red glass panes. This is easy to understand for players and is also a step further into more gamification of the game itself.
Since all the limits and the maximum upgrades are configured by the server operator, everything has to be calculated within the functions. This allows the server operator to change the settings later in the game, the already bought upgrades are changed automatically in the functions and there is no old data being left in any variable, which should prevent any further problems for the server operator.
I describe more about how this works at the hopper limitation, since it is used there.
Pull request: https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/50
3.2. Hopper limitation
Since hoppers can be very demanding, they should be limited. There are some players who create incredible big hopper storage systems containing thousands of hoppers, which is not good for the server performance. Server operators can set the limitation as high as they want and also allow players to upgrade the limitation over 5 levels to a custom price.
This gives the server operator a option to get some in-game money back from the player if they selling many things on admin shops to prevent too much inflation in the game.
Now I want to show how the hoppercheck function is working.
It gets called once somebody places or breaks a hopper and is allowed to do so, this is how it looks like:
function hoppercounter(p:player,action:text,amount:integer=1) :: boolean:
The function has three parameters and returns a boolean.
- (player) player
- (text) action ("place","break","update")
- (integer) amount (this is optional and needed if the action is "update")
if {_action} is "place":
set {_bedrock} to block at {SB::TEMPLOC::%{_p}%}
If the player placed a block, we get his last bedrock location (island middle), which gets updated by another function on every action if there is a change.
if {_bedrock} is a bedrock:
To make sure the location is correct, we only go forward if the block is actually bedrock.
set {_x} to x-coord of {_bedrock}
set {_y} to y-coord of {_bedrock}
set {_z} to z-coord of {_bedrock}
Since all the variables about the island are saved at a variable named after the bedrock coordinate (island middle), we need to get the coordinates out of the {_bedrock} variable, which is the bedrock (island middle).
set {_count} to {SB::island::%{_x}%_%{_y}%_%{_z}%::hoppercount}
This is the amount of hoppers, the island already has.
set {_defaulthopper} to {SB::config::starthopper}
set {_maxhopper} to {SB::config::maxhopper}
Then we get the configuration and set it into local variables to make it easier to read.
if {_maxhopper} is not {_defaulthopper}:
Maybe, the server operator has set the default hopper amount to the same as the maximum hoppers, in that case, we don't have any upgrades and simply check below if the maximum is reached.
set {_lvl} to {SB::island::%{_x}%_%{_y}%_%{_z}%::hopperupgrade}
set {_upgradeablehopper} to ({_maxhopper} - {_defaulthopper})
set {_hopperincreaseperlevel} to ({_upgradeablehopper} / 5)
set {_currenthopperbonus} to ({_lvl} * {_hopperincreaseperlevel})
set {_hopper} to ({_defaulthopper} + {_currenthopperbonus})
- Now, we get the hopper upgrade level of the island the player is building on, then it is calculated how many hoppers can be upgraded (at upgrade level 5) by subtract the default size amount of the maximum amount.
- Then, it is divided by 5, since we have a fixed amount of 5 upgrade steps to fit perfectly into the upgrade menu.
- Once we have the hopper increase per level, we can get the current hopper bonus by multiplying the current hopper upgrade with the hopper increase per level.
- The only step left is to add the new hopper upgrade amount we calculated to the default amount of hoppers the player is allowed to use.
- Now, we have an amount of hoppers the player is allowed to place.
else:
set {_hopper} to {_maxhopper}
If the maximum hopper amount is the same as the default amount, set {_hopper} to the maximum amount of hoppers.
#
# > Since it is bigger, print an error message and return false.
set {_uuid} to uuid of {_p}
set {_lang} to {SK::lang::%{_uuid}%}
set {_msg} to {SB::lang::bc::islandhopperlimitinfo::%{_lang}%}
replace all "" with "%{_hopper}%" in {_msg}
message "%{SB::lang::prefix::%{_lang}%}% %{_msg}%" to {_p}
return false
If there are more hoppers than allowed, return false and print an error message.
else:
add 1 to {SB::island::%{_x}%_%{_y}%_%{_z}%::hoppercount}
return true
If the limit is not reached, return true and also increase the “hoppercount” variable by one.
else:
return false
If the block above was not bedrock, return false. This should never happen, but for the case it happens, it is there. =)
Now, this is the part, which is there to prevent more hoppers being placed above the limit.
The part for breaking is not as hard as the place part:
else if {_action} is "break":
set {_bedrock} to block at {SB::TEMPLOC::%{_p}%}
if {_bedrock} is a bedrock:
set {_x} to x-coord of {_bedrock}
set {_y} to y-coord of {_bedrock}
set {_z} to z-coord of {_bedrock}
remove 1 from {SB::island::%{_x}%_%{_y}%_%{_z}%::hoppercount}
return true
else:
return false
It also checks if the bedrock is there and then removes one of the hopper count and returns true.
Commit: https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/50/commits/9b9ef2305d9ba025e34e7e0922c7e9614297a15c
Pull request: https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/50
3.3. Set multiple homes
On my test server, people were already asking for multiple homes quite often. I wanted to add them soon and also give something positive in this update for the users, since the other two features are not that nice for the users, this is a function they wanted.
Now, players can create multiple island homes using /island sethome [<name>] and then teleport to the home using /island home [<name>], if the player types a invalid home name, the player gets all home names as a list. Homes can also be deleted using /island delhome [<name>].
On big islands, this can be very useful and since this is also hooked into the island upgrade function, the player can upgrade the island to increase the home amount, if needed.
I also removed some code in the Commands.sk file and created a new "homehandler" function, which now is handling the homes, the Commands.sk only calls this function. This makes the code in Commands.sk easier to read and shorter.
Since "homehandler" is a global function, the server operator also can use this in custom scripts like below:
command /home [<text>]:
trigger:
homehandler(player,"home",arg-1)
This is very short and easy for server operators to include it into their own custom code. It is teleporting the player to the home with the name he set in the first argument of the command. The “homehandler” function gives feedback to the player like errors or listing all available homes.
Commit: https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/50/commits/72277ef01587799faf3602a62fe59d38eb76a80d
Pull request: https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/50
4. Pull requests
https://github.com/Abwasserrohr/SKYBLOCK.SK/pull/50
5. GitHub Account
https://github.com/Abwasserrohr
6. How to contribute
If you're interested in contributing to SKYBLOCK.SK, feel free to ask Abwasserrohr on the Discord server I linked below. If you already know how Skript works, you can create a pull request right away and improve SKYBLOCK.SK, I'm looking forward to see you there. =)
I also help new people who don't know how Skript works and also show the basics private in Discord, if you need any help, feel free do contact me.
Discord: https://discord.gg/FRuK5BC
Thank you for reading this contribution post. I wanted to make sure to use the pull requests more useful. Because of this I made all changes for the island upgrades within the one pull request. This makes it very easy to detect where changes happened and why without opening too many sites and looking around.
If you have feedback which you want to share with me, I'm glad for everything I can change or make better in the future. =)
Also ideas for SKYBLOCK.SK are highly appreciated.
Keep on steeming,
