Sep 20, 2018

@dualspiral dualspiral released this Sep 17, 2018 · 5 commits to sponge-api/7 since this release

Assets 5

This is a major release for Nucleus for Sponge API version 7.1

This was built from Nucleus commit: 320a345

Release Notes

If you're having trouble, visit our Discord channel: https://discord.gg/A9QHG5H

Important Updates

Updated Requirement: SpongeAPI 7.1 & Implementation Changes

Now SpongeAPI 7.1 has been released, many compatibility hooks for API 7.0 have been removed. There is now no guarantee that Nucleus will run on an
API 7.0 server. If you find that Nucleus does not run on your server, please revert to 1.5.5.

Also, I have taken the time to refactor some service loading code. It is possible that I may have missed a service.

PLEASE READ: nucleus.<role> permissions

This is a pre-release to get testing on the permission updates. Please note that no permissions have been changed, only role permissions have been added.

When I first set out to create Nucleus, the design of the permission nodes was to group like commands together. So, nucleus.tppos, for example, related to the /tppos command. nucleus.home was the logical grouping of the /home commands, including /home other, /home list etc., due to Sponge's inheritance.

However, this way of doing it has caused problems:

  • Owners want vanish on login as a permission, like Essentials, but complain that * makes them vanish on login
  • There is an AFK exemption permission, nucleus.afk.exempt.toggle, activated by *
  • nucleus.connectionmessages.disable - give yourself * and you won't be broadcasted to the server

I maintain my opposition to the * permission. It is a bad idea and is far simpler and intuitive than what Bukkit did. In fact, Sponge's permission system was not even designed to support *, or any wildcard.

I also recognise how much of a pain the current setup is for some use cases. So, this commit introduces the following permissions that automatically grants defaults:

  • nucleus.user that acts as a "super permission" for any permission labelled as USER in the permission tables
  • nucleus.mod that acts as a "super permission" for any permission labelled as MOD in the permission tables
  • nucleus.admin that acts as a "super permission" for any permission labelled as ADMIN in the permission tables
  • nucleus.owner that acts as a "super permission" for any permission labelled as OWNER in the permission tables

This does not, and will never, override any explicit permission that has been set.

As an example, you give your moderators the nucleus.mod permission. This, for example, gives them permission to enter staff chat. However, maybe you don't want them to access this. If you set nucleus.staffchat.base as false, this will override nucleus.mod. The same can be said for parent permissions, if you set nucleus.staffchat to false, a check to nucleus.staffchat.base will return false, regardless of whether nucleus.mod is set.

While this is cleaner than using /nucleus setupperms, you must be aware of the following:

  • These "role" permissions will never be given by default by setupperms.
  • Any permissions added to Nucleus that fall into one of these roles WILL be granted by default if you have the role permission. It is the responsibility of the server owner to check for any new features that may be added to these roles.
  • /nucleus setupperms will continue to exist, and will not grant new permissions automatically if they are added in new releases (but will if
    you re-run the setupperms commands).

If you want to use our suggested template and do not mind following our recommendations, use the role permissions. If you want to use our suggested template but DO want full control over what permissions you have, remain with /nucleus setupperms.

If you do not want to use the role permissions, this can be turned off in the config by setting core.enable-parent-perms to false and reloading.

Bugfixes

  • Fixed incorrect text on /sellall (thanks NickImpact)

Known Issues

  • Sometimes, an incorrect custom prefix might be selected. Nucleus uses whatever the permission plugin hands back, check your inheritance with the permissions plugin.

@dualspiral dualspiral released this Sep 9, 2018 · 8 commits to sponge-api/7 since this release

Assets 3

This is a pre-release version of Nucleus for Sponge API version 7.0

THIS IS A PRE-RELEASE VERSION AND MAY NOT BE STABLE

This was built from Nucleus commit: 2fe35eb

Release Notes

If you're having trouble, visit our Discord channel: https://discord.gg/A9QHG5H

Important Updates

Updated Requirement: SpongeAPI 7.1 & Implementation Changes

Now SpongeAPI 7.1 has been released, many compatibility hooks for API 7.0 have been removed. There is now no guarantee that Nucleus will run on an
API 7.0 server.

Also, I have taken the time to refactor some service loading code. Please test this, there may be a couple of services that have not registered
properly.

PLEASE READ: nucleus.<role> permissions

This is a pre-release to get testing on the permission updates. Please note that no permissions have been changed, only role permissions have been added.

When I first set out to create Nucleus, the design of the permission nodes was to group like commands together. So, nucleus.tppos, for example, related to the /tppos command. nucleus.home was the logical grouping of the /home commands, including /home other, /home list etc., due to Sponge's inheritance.

However, this way of doing it has caused problems:

  • Owners want vanish on login as a permission, like Essentials, but complain that * makes them vanish on login
  • There is an AFK exemption permission, nucleus.afk.exempt.toggle, activated by *
  • nucleus.connectionmessages.disable - give yourself * and you won't be broadcasted to the server

I maintain my opposition to the * permission. It is a bad idea and is far simpler and intuitive than what Bukkit did. In fact, Sponge's permission system was not even designed to support *, or any wildcard.

I also recognise how much of a pain the current setup is for some use cases. So, this commit introduces the following permissions that automatically grants defaults:

  • nucleus.user that acts as a "super permission" for any permission labelled as USER in the permission tables
  • nucleus.mod that acts as a "super permission" for any permission labelled as MOD in the permission tables
  • nucleus.admin that acts as a "super permission" for any permission labelled as ADMIN in the permission tables
  • nucleus.owner that acts as a "super permission" for any permission labelled as OWNER in the permission tables

This does not, and will never, override any explicit permission that has been set.

As an example, you give your moderators the nucleus.mod permission. This, for example, gives them permission to enter staff chat. However, maybe you don't want them to access this. If you set nucleus.staffchat.base as false, this will override nucleus.mod. The same can be said for parent permissions, if you set nucleus.staffchat to false, a check to nucleus.staffchat.base will return false, regardless of whether nucleus.mod is set.

While this is cleaner than using /nucleus setupperms, you must be aware of the following:

  • These "role" permissions will never be given by default by setupperms.
  • Any permissions added to Nucleus that fall into one of these roles WILL be granted by default if you have the role permission. It is the responsibility of the server owner to check for any new features that may be added to these roles.
  • /nucleus setupperms will continue to exist, and will not grant new permissions automatically if they are added in new releases (but will if
    you re-run the setupperms commands).

If you want to use our suggested template and do not mind following our recommendations, use the role permissions. If you want to use our suggested template but DO want full control over what permissions you have, remain with /nucleus setupperms.

If you do not want to use the role permissions, this can be turned off in the config by setting core.enable-parent-perms to false and reloading.

Bugfixes

  • Fixed incorrect text on /sellall (thanks NickImpact)

Known Issues

  • Sometimes, an incorrect custom prefix might be selected. Nucleus uses whatever the permission plugin hands back, check your inheritance with the permissions plugin.

@dualspiral dualspiral released this Sep 4, 2018 · 23 commits to sponge-api/7 since this release

Assets 3

This is a bug fix and minor feature release for Nucleus for Sponge API version 7.0

This was built from Nucleus commit: e728f23

Release Notes

If you're having trouble, visit our Discord channel: https://discord.gg/A9QHG5H

Bugfixes

  • Make sure we use item translations rather than the query operation (thanks to NickImpact)
  • Fix speed reset setting the wrong values.

Known Issues

  • Sometimes, an incorrect custom prefix might be selected. Nucleus uses whatever the permission plugin hands back, check your inheritance with the permissions plugin.

@dualspiral dualspiral released this Aug 21, 2018 · 20 commits to sponge-api/7 since this release

Assets 5

This is a pre-release version of Nucleus for Sponge API version 7.0

THIS IS A PRE-RELEASE VERSION AND MAY NOT BE STABLE

This was built from Nucleus commit: 4f8ddc7

Release Notes

If you're having trouble, visit our Discord channel: https://discord.gg/A9QHG5H

Important Updates

PLEASE READ: nucleus.<role> permissions

This is a pre-release to get testing on the permission updates. Please note that no permissions have been changed, only role permissions have been added.

When I first set out to create Nucleus, the design of the permission nodes was to group like commands together. So, nucleus.tppos, for example, related to the /tppos command. nucleus.home was the logical grouping of the /home commands, including /home other, /home list etc., due to Sponge's inheritance.

However, this way of doing it has caused problems:

  • Owners want vanish on login as a permission, like Essentials, but complain that * makes them vanish on login
  • There is an AFK exemption permission, nucleus.afk.exempt.toggle, activated by *
  • nucleus.connectionmessages.disable - give yourself * and you won't be broadcasted to the server

I maintain my opposition to the * permission. It is a bad idea and is far simpler and intuitive than what Bukkit did. In fact, Sponge's permission system was not even designed to support *, or any wildcard.

I also recognise how much of a pain the current setup is for some use cases. So, this commit introduces the following permissions that automatically grants defaults:

  • nucleus.user that acts as a "super permission" for any permission labelled as USER in the permission tables
  • nucleus.mod that acts as a "super permission" for any permission labelled as MOD in the permission tables
  • nucleus.admin that acts as a "super permission" for any permission labelled as ADMIN in the permission tables
  • nucleus.owner that acts as a "super permission" for any permission labelled as OWNER in the permission tables

This does not, and will never, override any explicit permission that has been set.

As an example, you give your moderators the nucleus.mod permission. This, for example, gives them permission to enter staff chat. However, maybe you don't want them to access this. If you set nucleus.staffchat.base as false, this will override nucleus.mod. The same can be said for parent permissions, if you set nucleus.staffchat to false, a check to nucleus.staffchat.base will return false, regardless of whether nucleus.mod is set.

While this is cleaner than using /nucleus setupperms, you must be aware of the following:

  • These "role" permissions will never be given by default by setupperms.
  • Any permissions added to Nucleus that fall into one of these roles WILL be granted by default if you have the role permission. It is the responsibility of the server owner to check for any new features that may be added to these roles.
  • /nucleus setupperms will continue to exist, and will not grant new permissions if they are added in new releases.

If you want to use our suggested template and do not mind following our recommendations, use the role permissions. If you want to use our suggested template but DO want full control over what permissions you have, remain with /nucleus setupperms.

If you do not want to use the role permissions, this can be turned off in the config by setting core.enable-parent-perms to false and reloading.

Known Issues

  • Sometimes, an incorrect custom prefix might be selected. Nucleus uses whatever the permission plugin hands back, check your inheritance with the permissions plugin.

@dualspiral dualspiral released this Aug 21, 2018 · 23 commits to sponge-api/7 since this release

Assets 3

This is a bug fix and minor feature release for Nucleus for Sponge API version 7.0

This was built from Nucleus commit: 16b5a81

Release Notes

If you're having trouble, visit our Discord channel: https://discord.gg/A9QHG5H

Changes

  • Updated translation for zh_CN thanks to Tollainmear

Known Issues

  • Sometimes, an incorrect custom prefix might be selected. Nucleus uses whatever the permission plugin hands back, check your inheritance with the permissions plugin.

@dualspiral dualspiral released this Aug 19, 2018 · 24 commits to sponge-api/7 since this release

Assets 3

This is a bug fix and minor feature release for Nucleus for Sponge API version 7.0

This was built from Nucleus commit: 78d6257

Release Notes

If you're having trouble, visit our Discord channel: https://discord.gg/A9QHG5H

New features

  • /seen updated to show more information for offline players, if available (dependent on Sponge).

Bugfixes

  • Fix /helpop sending messages to the wrong players
  • Fix some URLs in chat having issues with formatting
  • Fix nickname prefix not showing

Known Issues

  • Sometimes, an incorrect custom prefix might be selected. Nucleus uses whatever the permission plugin hands back, check your inheritance with the permissions plugin.

@dualspiral dualspiral released this Aug 6, 2018 · 33 commits to sponge-api/7 since this release

Assets 3

This is a bug fix and minor feature release for Nucleus for Sponge API version 7.0

This was built from Nucleus commit: 137cc55

Release Notes

If you're having trouble, visit our Discord channel: https://discord.gg/A9QHG5H

Bugfixes

  • Fix another missing message key in AFK module when running /seen.
  • Ensure that we respect the Sponge teleport helper config when using RTP

Known Issues

  • Sometimes, an incorrect custom prefix might be selected. Nucleus uses whatever the permission plugin hands back, check your inheritance with the permissions plugin.

@dualspiral dualspiral released this Aug 5, 2018 · 37 commits to sponge-api/7 since this release

Assets 3

This is a bug fix and minor feature release for Nucleus for Sponge API version 7.0 See https://github.com/NucleusPowered/Nucleus/releases/tag/1.5.0 for what is new in the 1.5.0 release.

This was built from Nucleus commit: a48759a

Release Notes

If you're having trouble, visit our Discord channel: https://discord.gg/A9QHG5H

Bugfixes

  • Fix missing message key in AFK module when running /seen.
  • Fix incorrect message key in jail module causing jail timers to not tick down.

Known Issues

  • Sometimes, an incorrect custom prefix might be selected. Nucleus uses whatever the permission plugin hands back, check your inheritance with the permissions plugin.

@dualspiral dualspiral released this Aug 5, 2018 · 41 commits to sponge-api/7 since this release

Assets 5

This is a major release for Nucleus for Sponge API version 7.0

This was built from Nucleus commit: a1c40d8

Release Notes

If you're having trouble, visit our Discord channel: https://discord.gg/A9QHG5H

New Features

Completely rewritten the Random Teleport system

RTP had loads of problems (the code was awful), so I have taken the time to rewrite it. It should be a lot faster now (I found surface teleports were rarely failing with the new system!), and is also a lot more extensible for developers who want to use Nucleus RTP with their own tweaks.

IMPORTANT NOTE ABOUT RTP CONFIGURATION

Please note that the config has changed a bit. Despite my best efforts, some configs may not migrate properly, particularly if you have surface only warps enabled.

"surface-only" and "center-on-player" options have been removed and replaced with "default-mode". These are (by default):

  • "nucleus:default" - the default RTP behaviour, which selects a point around the spawn location
  • "nucleus:surface_only" - which selects a point around the spawn location that is on the surface
  • "nucleus:around_player" - which selects a point around the player location
  • "nucleus:around_player_surface" - which selects a point around the player location that is on the surface

Please take a moment to check your settings to ensure you get what you want out of RTP when you upgrade.

Added /enderchest support for offline players

Now you can inspect enderchests of offline players, thanks to recent updates in Sponge. You must have the nucleus.enderchest.offline permission, and you must be using a recent version of Sponge. Nucleus will tell you if the version you are using is too old.

Updated /speed command

You may now reset a users' speed by using the "reset" string in place of a speed. The description for the command has also been updated.

Added ability to exempt some worlds from "spawn on login"

You can now mark worlds as exempt from the spawn on login action, that is, if a player logs into an exempt world, they will not be moved to the spawn point if the spawn on login feature is enabled.

Update AFK to allow hiding AFK messages from those in spectator mode

Some of you might use Spectator mode to vanish and spy on people, but then go AFK and ruin the illusion that you aren't there. Now, you can prevent these messages going to the player base by turning on a setting in the config.

Add AFK status to /seen

As title, you can see the last time someone was active in /seen.

API updates

Added NucleusRTPService

The NucleusRTPService allows developers to use the Nucleus RTP engine for their own random location needs! It also allows developers to create their own location finding routines for use with the Nucleus RTP command. Developers can create their own RTPKernel and register it using NucleusRTPService#registerKernel, and then have users add the ID as default-mode.

Added NucleusChangeNicknameEvent.Post

This occurs after a nickname change. It is a read only event.

Added NucleusChangeNicknameEvent.Pre, deprecated usage of base NucleusChangeNicknameEvent

Please use NucleusChangeNicknameEvent.Pre instead of NucleusChangeNicknameEvent in the future.
NucleusChangeNicknameEvent will become the base event for both Pre and Post in v2.0.

Bugfixes

  • Fix incorrect spawn login exemption permission in config comment
  • Fix global spawn settings taking players out of jails on login (players will now always be reset to the jail point on login)

Known Issues

  • Sometimes, an incorrect custom prefix might be selected. Nucleus uses whatever the permission plugin hands back, check your inheritance with the permissions plugin.