This update mostly focuses on improving the syntaxes related to player skulls.

Before that there is one other bug fix to note: writing if <expr>: for some boolean expression will no longer result in an error when the expression is null and you don't have skQuery.

Now:

Skull from Skin
This expression has been fixed - previously, it would only return a skeleton skull. Additionally, you can now specify an owner for the skull - this only affects the name that is shown, not the actual skin (defaults to 'MundoSK-Name')
The new syntax is

code_language.skript:

skull from %skin% [with owner %-string%]

Skin of Player or Skull
Bugs with this expression have also been fixed, and it can also now be used with blocks representing placed skulls.

Owner of Skull

code_language.skript:

owner of skull %itemstack/block%
skull %itemstack/block%'s owner

This is a new expression for the owner of the skull, as described above. This can be set.

One last note, the documentation search feature using '/mundosk doc <elem name>' has been changed, so that now, you can type in prefixes of the words or the first few words in the name of a syntax element to get to it. For example, you can do '/mundosk doc d s o p', '/mundosk doc dis s o p', '/mundosk d s o', etc. for Displayed Skin of Player.

The main focus of this update is a major reorganization of the code involved with skin and nametag changing in order to make it more maintainable and stable, as well as to make it easier to implement changes and new features.

Before we get into that, there are two small changes I want to mention:
Chat Tab Complete
This is just the addition to the documentation of this event's player event-value, which was previously undocumented.

Tab Complete
This event now has a `sender` event-value to represent the thing that was trying to tab-complete something. Like in a command, you can use `player` assuming that the sender will be a player (if it isn't a player player will not be set, like in a command).

Now for the more important focus of this update. To start, as there has been a reorganization of code, it's expected that certain bugs will be fixed and more likely than not some new bugs have been introduced. A specific bug that has been fixed is one that was introduced in MundoSK 1.8.3, where changing a player's nametag would also change their tablist name if that hadn't previously been changed.

In terms of more concrete changes:

Displayed Skin of Player

code_language.skript:

[(default)] displayed skin of %player% [(for %-players%|excluding %-players%)]   
%player%'s [(default)] displayed skin [(for %-players%|excluding %-players%)]

There has been a slight syntax change to this expression, in the form of a new `default` syntax. This cannot be used simultaneously as specifying specific target players or excluded players. The point of this new syntax is for the whole syntax to better describe its functionality. Previously, simply doing

code_language.skript:

set displayed skin of player to alex

would only change the skin appearance for players who hadn't been specifically targeted in previous uses of the syntax. Now, this functionality has been moved to the syntax using `default`, and the simple syntax that doesn't use `default` will change the skin appearance for all players regardless of prior values. This may be a bit confusing, so I added some examples to the documentation describing what certain code would do.

Nametag of Player

code_language.skript:

[mundo[sk]] %player%'s [(default)] name[]tag [for %-players%]   
[mundo[sk]] [(default)] name[]tag of %player% [for %-players%]

This expression has received a larger addition: the ability to change the nametag of a player differently for different targets. This functionality is essentially the same as and mirrored from the similar functionality of Displayed Skin of Player, with the note that this syntax does not allow excluded players. Other than that, the working of `default` and specifying target players is the same as Displayed Skin of Player, and like that expression, this also now has examples to relieve confusion.

This is a small update for MundoSK, just a couple of changes regarding tablist syntaxes.

Display Name of Player Tab
Changing this expression now maintains any team prefixes/suffixes that are present.

code_language.skript:

%player%'s [mundo[sk]] tab[list] name
[mundo[sk]] tab[list] name of %player%

This syntax has now been removed, because as of MundoSK 1.8 you can use a list of players, such as all players, in the Display Name of Player Tab expression, negating the need for a specific expression for that, and the above change in this release means that this expression is now completely useless (before you needed to use it if you wanted to maintain team prefix/suffix for tablist name changes). If you attempt to use this syntax in a script, you will get an error repeating a brief explanation similar to this.

Latency of Player Tab

code_language.skript:

(latency|ping) of [player] tab of %player% for %players%
(latency|ping) of %player%'s [player] tab for %players%
tablist (latency|ping) of %player% for %players%
%player%'s tablist (latency|ping) for %players%

This is a new expression, with functionality similar to Latency of Array Tab and Latency of Simple Tab in that it allows you to change the amount of latency bars shown for the player in the tablist. Like with those two, the amount of latency bars is always between 0 and 5. An additional note here is that since players by default do have latencies, this expression can be not set, which is the state of showing the latency bars corresponding to the player's actual latency. You can reset this expression to return to this default state.

Another update, this time with a couple of fixes and a couple of features.

Fixes

Create Simple Tab
Latency of Array Tab
Latency of Simple Tab
Setting the latency of a tab using MundoSK's custom tablist features now works! Remember that this should be a value between 0 and 5.

JSON Field of Packet
You can now set this to a list of jsonobjects when using array pjson, as intended.

Features

Array Tablist is Enabled

code_language.skript:

[the] array tablist is (enabled|disabled) for %players%

A simple condition to check whether the specified player(s) have the array tablist enabled. This can't be set - you have to use the Enable of Disable Array Tablist effect for that.

Packet Info Alias

code_language.skript:

packet info aliases for %packettype%:
  <new syntax> = <old syntax>
  <new syntax> = <old syntax>
  etc.

The main new feature of this update, packet info aliases, is a way to make your packet code nicer and more understandable. Using packet info aliases, you can write aliases that allow you to express the fields of certain packets in syntax specific to the meaning of those fields. An example is below, and is also contained in the documentation for packet info aliases.

code_language.skript:

packet info aliases for play_server_world_border:
  border action of %packet% = "WorldBorderAction" penum 0 of %packet%
  border portal teleport boundary of %packet% = int pnum 0 of %packet%
  border center x[-coord] of %packet% = double pnum 0 of %packet%
  border center z[-coord] of %packet% = double pnum 1 of %packet%
  border old radius of %packet% = double pnum 2 of %packet%
  border radius of %packet% = double pnum 3 of %packet%
  border speed of %packet% = long pnum 0 of %packet%
  border warning time [span|length] of %packet% = int pnum 1 of %packet%
  border warning (distance|blocks) of %packet% = int pnum 2 of %packet%

on packet event play_server_world_border:
  broadcast "Border Action: %border action of event-packet%"

This is a small update, just a couple of additions:

Documentation

WebSocketState and PlayerLoginResult are now known as WebSocket State and Player Login Result respectively in the documentation.

Conditions

Many of MundoSK's conditions that did not already have this, now have syntax for negated versions. For some syntaxes, this is just having `isn't` in addition to `is`, while others have word additions, like `disabled` versus `enabled`. The conditions are listed below:

Chunk is Slimey
Chunk is Loaded
Last Called Custom Event was Cancelled

Living Entity is Collidable
This condition now also supports multiple living entities as input.

Scores are Enabled
Player Tab is Visible
Player Tabs are Visible
These syntaxes, in addition to having syntaxes for negation, have also had their behavior changed when multiple players are inputted. Previously, a list of booleans would be returned (one for each input player). Now, one boolean is returned as would be expected of a condition.

It's been a long time since the last official update, but MundoSK 1.8 is finally here. Before we start going into syntaxes, I want to explain some changes to some other aspects of MundoSK.

/mundosk Command:

There is now a /mundosk command which can be used to do a few things relating to MundoSK. You can do /mundosk or /mundosk help to view help for this command.

The permission for this command is `mundosk.command`.

Documentation:

In MundoSK 1.8, much of the documentation has been re-written, and several changes have been made. The documentation is now written and stored inside MundoSK’s code, and imported into online documentation sites. The revamped documentation should now cover all features that exist in MundoSK 1.8.

Versioning has been added for syntaxes, though there are a few caveats with this. Many syntaxes have been significantly changed with lots of new options added in MundoSK 1.8, so most of these are marked as since MundoSK 1.8 (a few are marked as since an older version with notes in the documentation for certain syntax options/features that were added in MundoSK 1.8). Packet, Tablist, and Skin syntaxes have all been marked as since MundoSK 1.8 due to the vast amount of changes and additions to them in MundoSK 1.8.

Through the `/mundosk doc` command, MundoSK’s documentation is now accessible from within your server. You can do `/mundosk doc` or `/mundosk doc help` to view help for this command.

MundoSK’s documentation is also now coming to Skript Hub. At the time of writing, Skript Hub should contain the documentation as of MundoSK 1.8, while the documentation will be imported into skUnity a little while after this is posted, due to the preexisting documentation for older MundoSK versions there.

Scopes are marked as such using MundoSK’s documentation command, but are categorized as effects in documentation online, along with a note explaining this.

Config:

The `/mundosk config` command allows you to view the config from inside your server. You can also do `/mundosk config reload` in order to reload the config while your server is running. This does not work for the `enable_custom_skin_and_tablist` config option below.

The old ‘debug_mode’ config option has been replaced with the ‘debug’ config option. What this allows is for users to write the names of categories of syntaxes that need to be debugged, so that not all of MundoSK’s debug information is printed.

In addition, four more config options have been introduced:

• `enable_custom_skin_and_tablist`: This is used to indicate whether MundoSK’s tablist and skin syntaxes should be enabled (default true). In the past, there have been bugs with these features that prevented Skripters not aiming to use them anyway from using MundoSK’s other features, so this config option is now here as an option if this occurs again in the future. This config option will not matter if ProtocolLib is not installed on your server. Changes to this config option while the server is running will not do anything until the server is restarted.
• `tablist_remove_tab_delay_spawn`: (In ticks) This is used when tabs of players are hidden in the tablist and those players need to be spawned for the user of the tablist, in order to allow a period of time in which the tab is visible so that the players’ skins render. If you are having a problem with skins not rendering due to using tablist features, try increasing this time, though it may be a good idea to first ask me to make sure you are in the proper situation (default 5).
• `tablist_remove_tab_delay_respawn`: (In ticks) The same as the above, but for when a player is hidden in their own tablist, to allow their own skin to render properly for themselves.
• `border_disable_size_syntax`: When true, this prevents instances of `size` from being parsed as the syntax for the diameter/side length of a border. See World Border below for more information. (default false).

As there are so many different syntaxes and stuff that got added for 1.8 and there’s already documentation for all of it anyway, I’m not going to be explaining everything that I added like I have previously, but instead include a link to the documentation. Some stuff, like major features, or things I want/need to explain because they build on/fix previous features, will be explained.

Syntaxes are listed by documentation command category. The names of the syntaxes are the ones used in the documentation.

Miscellaneous:

Wait While or Until
When Boolean is True
Async Set
All Types
For Elements
Elements that Are
IP of Server
Port of Server
Living Entity is Collidable
Tree at Location
Respawn Location
Destination
New Nether Portal

Async in Timespan
Sync in Timespan
This is a minor addition to the sync/async scopes introduced previously that allows you to add a wait. This allows you to specify code to run with a delay while still running other code immediately after that.

Additionally, both of these scopes can now be written as normal lines of code in order to make the following code sync/async instead of only a certain block of code.

Number as Java Type
This was mainly introduced to facilitate certain packet manipulations where the number type was ambiguous, meaning the number had to be specified as a certain type through Skript.

Tab Complete
This is an addition to the previous Chat Tab Complete feature. Recent Bukkit versions have a new Tab Complete event that also covers command completions, so MundoSK users with those Bukkit versions will now be able to use this event with the same event values and expressions provided in the Chat Tab Complete event.

Tree Loop
This isn’t a new feature, but rather a fix: previously, if you modified a list variable while looping its tree, there was a great possibility of having a ConcurrentModificationException be thrown. Now, the list variable is duplicated immediately, so changes to the list variable are ignored by the iteration. This is in line with Skript’s behavior for looping list variables normally.

Server List Ping
Shown Amount of Players
Shown MOTD
IP of Pinger
These are a set of syntaxes relating to when a Minecraft client pings your server.

Chunk:

Load Chunk
Coordinate of Chunk
World of Chunk
Chunk at Coordinates
Block in Chunk
Blocks in Chunk
Chunk is Slimey
Chunk is Loaded
This is a new small category of syntaxes dealing with chunks, in order to be able to more easily manipulate chunks.

World Border:

Moving Border Diameter
Border is Moving
These are a couple of new syntaxes in addition to the previously introduced ones dealing with a border that is changing size. Also, all of these syntaxes (new and old) now work when a border changes size for any reason, not just by using MundoSK syntaxes.

Property of Border
`diameter` and `side length` have been added as the way to refer to the side length of a border. This applies to other border syntaxes that previously used size to refer to the side length. It is discouraged to use `size` as this is extremely general and conflicts with Skript’s size expression. As of MundoSK 1.8, MundoSK provides a config option to disable the size syntax completely in order to prevent uses of Skript’s size expressions parsing as a border syntax. This option is disabled by default, but is recommended for you to enable in order to catch any uses of the `size` syntax for border length and change them. In the future, the `size` syntax will be removed completely from MundoSK.

Book:

New Book
Previously, this expression required an itemstack for input which it would duplicate and modify properties of in order to create a certain book. Now, this syntax has been simplified so you simply write `book` instead of inputting an itemstack (`written book` is allowed in order to maintain compatibility with the most common uses of the syntax previously).

Generator:

Custom Generator
Previously, you could write code right under the main scope that would be called when generator of a world was starting. This has now been moved to a sub-scope called `initiation` in order to provide better code structure and allow more flexibility for future additions.

World Creator:

Generally, world creators and their behavior have been slightly modified. The most important change is that world creators are now immutable, meaning that the properties of a world creator don’t change. Instead, when you do something like `set seed of {_creator} to “12345”`, the creator stored in the variable is duplicated with the changed property and put back into the variable. This means, among other things, that if you have a creator inside one variable, put it into another variable as well, and change a property of it in the first variable, the creator in the second variable doesn’t change, which is a useful property to have.

Another change in creators is that they no longer have to have a name or a seed. Not having a name means that you can create creators that are meant to be used to create multiple worlds without having to give it some throwaway name. See below in World Management the Create World using Creator effect for more info. Not having a seed means that the creator will generate a random seed every time it is used.

Dimension
This is just a name change from the type that was previously known as environment. This doesn’t change much, as the actual dimension values themselves still have the same names. This just helps avoid conflicts with other addons (or maybe forks of Skript in the future) that register an environment type, such as RandomSk (I’m not sure how many people are still using it, but now it’s not a problem).

World Management:

Create World using Creator
You now have the option of specifying a worldname, rather than just using the worldname of the creator. This is required when using a creator without a worldname, which is now possible (see above in World Creator).

All Current Worlds

Automatic Creator
All Automatic Creator
Load World Automatically

These are completely new syntaxes to replace the old syntaxes for automatic world loading.

Custom Event:

Call Custom Event
ID of Custom Event
First, custom events now have a feature to specify that they are being called async. This should be specified when your code is running in async in order to allow Bukkit to handle the events safely.

Second, custom events can now be called with multiple ids in order to allow Skripters using your custom events more flexibility in their syntax. The ID of Custom Event expression now allows either only getting the first id specified, or all of the ids specified for the custom event.

Last Called Custom Event was Cancelled
Custom events are also now cancellable, and this expression can be used in code calling a custom event to check this.

Skin:
Generally, a huge amount of bugs from MundoSK 1.7.4 have been fixed - skin and tablist syntaxes were the main source of bugs to be fixed during the beta versions.

Displayed Skin of Player
This now supports changing the skin of a player only for specific players. Additionally, the player whose skin is being changed can now themself see the change.

Skin of Player or Skull
As the name suggests, this expression now works also to get the skin of a skull item.

Skull from Skin

Retrieved Skin
This is a new expression making use of the MineSkin API, created and maintained by Inventivetalent, in order to retrieve skins based on certain data. Note that as this uses an online API, it must be run in async in order to not lag your server.

Packet:

New features here are mostly new `pinfo` and `pjson` options that have been added.

Field of Packet
You can now write the name of a particular pinfo that isn't a type directly instead of as a string (meaning you no longer need quotes - those that were types already didn't require quotes).

• `"item" pinfo %number% of %packet%`: An Item field of a packet, represented (of course) as an item. Quotes are still used here as `item` might be interpreted as a type otherwise.
  
• `blockdata pinfo %number% of %packet%`: A BlockData field of a packet, represented as an item.
• `bytebuffer array pinfo %number% of %packet%`: A ByteBuffer field of a packet, represented as a list of numbers (bytes).
• `collection array pinfo %number% of %packet%`: A Collection field of a packet, represented as a list of objects.

JSON Field of Packet
You can now write the name of the particular pjson directly instead of as a string (meaning you no longer need quotes).

• `datawatcher pjson %number% of %packet%` and `watchablecollection pjson %number% of %packet%`: Types of fields of packet frequently used in packets dealing with entity metadata. Both have a structure where the keys for all of the values are numbers in string form, but the numbers aren’t necessarily consecutive, for example you could have 1, 2, 6, and 13 as indexes. (Hence why this can’t be just in the form of a list). DataWatcher fields also contain an entity, which is stored in the json with the key `”entity”`.
• `nbt pjson %number% of %packet%: An NBT field of a packet. This is a bit complicated to explain the structure of, so I’m copy-pasting from a PM I had with a user who needed to use this: The JSON structure of the result is like this: the JSONObject that the syntax returns has three parts:

1. The name, with index/key "name", which is just the name (sometimes null)
2. The type, with index/key "type", which is the type of NBT, and can have the following values:
3. - "byte", "short", "int", "long", "float", "double", the basic number types
4. - "string", for strings
5. - "byte_array" and "int_array", for basic number array types
6. - "compound", for an NBT compound
7. - "list_something", such as "list_string" or "list_compound", for a list of some other type
8. The value, with index/key "value", which is the actual value,
9. - In the cases of the number types and string type this is just the number/string (when accessing using a list variable in Skript it's like {_nbt::value}
10. - In the case of the number array types and the list type this is an array of the objects (when accessing using a list variable in Skript it's like {_nbt::value::*}, ex. {_nbt::value::1} for the first element)
11. - In the case of the compound it's a JSONObject of the NBT values, each also having its own name, type and value (when accessing through a list variable in Skript it's: {_nbt::value::example_name::name} for the name (which is the same as the index, so it will be "example_name"), {_nbt::value::example_name::type} for the type, let's say "string", and {_nbt::value::example_name::value} for the actual value, let's say "pie")

• `gameprofile pjson %number% of %packet%`: A GameProfile field of a packet. The structure is as follows:

1. The “name” key is paired with the name of the profile
2. The “uuid” key is paired with the UUID of the profile in string form
3. The “skin” key is paired with a MundoSK skin object

• `playerinfodata pjson array %number% of %packet%`: A PlayerInfoData list field of a packet. Each individual PlayerInfoData has a structure represented in the json as follows:

1. The “displayname” key is paired with the display name in json string form

1. The “gamemode” key is paired with a gamemode
2. The “latency” key is paired with a number representing the latency
3. The “gameprofile” key is paired with a GameProfile in json form as described above

Enum Field of Packet
You can now write `arbitrary` instead of an enum name in order to access all of the enum fields of the packet. This is useful when accessing certain NMS enums that don’t have equivalents in the normal format in ProtocolLib.

Tablist:

Like for skin syntaxes, there were a lot of bugs to be fixed with tablist syntaxes. Most tablist syntaxes have been adapted in order to allow changing display name/icon/visibility/etc. of certain tabs for multiple or all players at once. All syntaxes also now have safeguards when players that are no longer online are inputted, in order to prevent errors. In addition, some syntaxes have had syntax options added in order to provide a variety of ways to write certain effects. I’m not going to list all tablist syntaxes though most of them have been changed in some way however.

Scores are Enabled
Score of Player Tab
Score of Simple Tab
Score of Array Tab
MundoSK’s tablist features now support showing a score on tabs. Scores must first be enabled for a certain player/certain players/all players using the Scores are Enabled condition/expression, as they are disabled by default in order to not conflict with other ways of manipulating scores (or if you just don’t want scores). Note that MundoSK’s tablist score syntaxes work using packets rather than Bukkit and therefore can’t be properly modified by using more general score syntaxes (this will cause problems when using these syntaxes for the tablist as well as MundoSK’s score syntaxes).

Tablist Header or Footer

WebSocket:

WebSockets are the main new feature of MundoSK 1.8, serving as a replacement for MundoSK’s old socket syntaxes (those are not being removed, but it is heavily recommended to use websockets instead).

The major difference between MundoSK’s websocket features and its features for old sockets is that rather than just sending a single message and then handling a reply, possibly repeatedly, there is a websocket type, for websocket objects, which represent one end of a connection between a client and a server. MundoSK’s old socket features internally created one socket for each message to be sent; with websockets, a websocket is maintained and used in Skript to send most likely a high quantity of messages over a long lifespan.

An extremely important point of MundoSK’s websocket features is the handling of events that occur with websockets. In MundoSK’s old sockets, this was done at a simplified level with functions written on the server side to handle incoming messages and possibly return a response, and optionally functions written on the client side to receive the server’s response. MundoSK websockets are manipulated in a similar way at the basic level, but vastly improved. You write websocket client and server templates that are similar in structure to how you would write custom generators using MundoSK, by writing `websocket client %string%` or `websocket server %string%` at the top, with the `%string%` being an identifier used when creating websockets or starting a websocket server, and then having a few sub-scopes for different events, like `on open`, `on message`, `on start`, etc.

As all of the syntaxes relating to websockets are new, I’m not going to list them, but instead you can look up ‘websocket’ in the documentation to see them and their specific explanations. For examples, I have written one websocket example based on the old Inter Server Chat example for old sockets. This example almost exactly duplicates the behavior of the old example, with the only major exception being that it doesn’t provide a password functionality (this is possible and fairly easy using MundoSK’s websocket features, though those syntaxes are not dedicated only for using passwords). The example should be located on the Overview section.

MundoSK’s websocket features internally use the Java-WebSocket implementation written by TooTallNate.

This is a big release, so of course there are going to be confusions about some of the additions, so just comment in the Discussion section about questions you have. And even though this version spent a year in beta, there are still bound to be some bugs, so if you find some report them here, in Discord, or best of all, in the GitHub issue tracker.

Happy One-Week-Late New Year!