@dualspiral dualspiral released this Dec 1, 2018 · 2 commits to sponge-api/7 since this release

Assets 3

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

This was built from Nucleus commit: 5937ad9

Release Notes

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

Important Updates

Removal of GeoIP

GeoIP has been removed from the core Nucleus package. For this functionality, download Nucleus Heisenberg instead.

New Features

Updated /seen command

I've now added per-item permissions for the /seen command - that is, you can now finely tune who sees whether an IP address or player UUID is shown, for example. They all start with nucleus.seen.extended, and will be listed on the permission reference page.

You can also click on the IP address to run /getfromip, if you so wish.

Added /extinguish

This allows for players who are on fire to not be on fire!

Bugfixes

  • Fix seen always showing a player is never AFK.
  • Fix RTP cooldown issues

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 Oct 21, 2018 · 95 commits to sponge-api/7 since this release

Assets 5

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

This was built from Nucleus commit: 85c5a1e

Release Notes

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

IMPORTANT: Deprecation of GeoIP module

GeoIP will be removed from Nucleus in 1.7. This is due to low usage and the fact it isn't really considered "essential". However, do not fret, as
Nucleus Heisenberg replaces the GeoIP module with equal functionality.

I am having difficulties with Ore at the moment and as such, Heisenberg has not been fully published on Ore. It will be resolved soon and available
on Ore ASAP.

Note that the Warning and Server Shop modules will be removed in due course when suitable replacements have been written or found.

New features

  • Prepare for ability to use community supplied translations using a web based translation service

Bug fixes

  • Fix /clearinventory causing a StackOverflow
  • Fix /seen causing error on players with temporary mutes

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 Oct 13, 2018 · 104 commits to sponge-api/7 since this release

Assets 5

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

This was built from Nucleus commit: 8c8c8fb

Release Notes

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

IMPORTANT: Deprecation of GeoIP module

GeoIP will be removed from Nucleus in 1.7. This is due to low usage and the fact it isn't really considered "essential". However, do not fret, as
Nucleus Heisenberg replaces the GeoIP module with equal functionality.

I am having difficulties with Ore at the moment and as such, Heisenberg has not been fully published on Ore. It will be resolved soon and available
on Ore ASAP.

Note that the Warning and Server Shop modules will be removed in due course when suitable replacements have been written or found.

New Features

  • Added -a command flag to /clearinventory to clear everything
  • Added NucleusClearInventoryEvents for other plugins to hook into.
  • Added ability to add co-ordinates to /blockinfo

Bug fixes

  • Changed behaviour when a first spawn point could not be used for new players, will now fall back to other spawn options rather than the
    default world spawn point.

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.
Sep 20, 2018

@dualspiral dualspiral released this Sep 17, 2018 · 119 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

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 · 122 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 · 137 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 · 134 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 · 137 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 · 138 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.