nanoblox / plugin Goto Github PK

Homepage

• A live count of total concurrent users across all of Nanoblox
• Potentially a live count of how much total revenue (do not associate this information to individual games) a game makes from Nanoblox (i.e. the sales of gamepasses linked to roles, although since this can only be read from within that studio, could potentially be faked)
• Learn more (links to devforum)
• Install (links to plugin)

Design 1 (quick mockup):

Design 2:

Discover

• A page which lists all games which use Nanoblox with over 100 concurrent users

How to achieve?

• When a game installs Nanoblox (or has one within their datamodel), inform nanoblox.com via httpservice via plugin, save this information to website backend
• When a game uninstalls Nanoblox (or is removed from datamodel) inform nanoblox.com
• Every time studio session loaded up, inform nanoblox
• If a game is not heard of within 4 weeks, remove from sort
• Also consider a manual way to remove/block games in case of abuse

Future considerations

• A place where users can login/signup to then execute commands remotely (do not worry about this for now, this is something for 2022+)

test 4

Should this be through packages? Or instead maybe just load the Core MainModule, retrieve the necessary modules, then destroy?

Determine how the code from systems (such as UI components, client and server control of UI and data, etc) will be shared between core and plugin, and setup any relevant repos

test plugin

test 2

Plugin

• Convert 'Commands' repo to 'Extensions'
  • Rename MainModule from Commands to Extensions
  • Setup sub folders
    • Commands - already setup
    • Morphs - move all morph descriptions under here
    • Tools
      • Add updated and modified f3x tool to here
    • Themes - this will be where Nanoblox themes are located
    • Core
      • Add StatHandler to Extensions/Core/Server/Modules/StatHandler
• Plugin Loader
  • Activate/Deactivate
    • When pressing nanoblox icon display whole menu like ckstudio+/rojo
    • If no 'Nanoblox' present in ServerScriptService display a single Activate button
    • When pressed, check ServreStorage for 'Nanoblox (deactivated)'
    • Have a deactivate button at the button of the page
    • Listen for these changes within ServerScriptService.ChildAdded and update display accordingly
  • When Nanoblox loaded for first time (i.e. no loader detected), auto setup every extension
  • When an extension is loaded into the loader, create an attribute under its container - this indicates it's already been loaded and prevents it being displayed again in the new menu
  • A super basic interface
    • Split Extensions into three columns:
      • New - can be approved or rejected
      • Approved - can be removed (i.e. rejected)
      • Rejected - can be re-inserted (i.e. approved)
    • Make sure to listen for Extensions/Commands ChildAdded (move item to approved if a valid extension item) and ChildRemoved (move item to rejected if a valid extension item)
    • Notification when new extensions > 0 which when clicked opens up extensions manage page
• Consider setting up a 'Studio' settings group
  • Consider renaming 'System' settings to something else (maybe Game or Server)
  • Settings such as:
    • Enable Sync
    • PlayerDataName
    • SystemDataName
    • DisableFunCommands
    • (consider moving some system settings here)

Core

• Setup an Extensions folder within Server
• Move the Commands module code to CommandService and move all internal commands to Server/Extensions/Commands
• Ensure AssetService accounts for this change (e.g. it originally cached assets under Server/Modules/Commands)
• How will extension items like 'Morphs' and 'Tools' be retrieved? Maybe consider creating specifically tailored methods within AssetService
• Transfer everything under Loader/Extensions into the core Extensions folder
  • Only move commands instead of merge (to prevent overwriting internal commands)
  • Transfer everything under Extensions/Core into the corresponding Core locations, although **if present, completely ignore Loader/Extensions/Core/Server/Extensions
• Test

Initial setup

• Check for Nanoblox within ServerScriptService (if descendant name is Nanoblox and is a folder and find Loader then advance)
• If not present, display 'Activate' button (similar to the CK Studio plugin)
• Check for descendant added within serverscriptservice, if is nanoblox then advance
• On activation click, advance
• On advance, display Nanoblox panel and ensure commands are up to date within the loader
• Check for descendant removed within serverscriptservice, if is nanoblox then retreat

Command sync-check

• Determine a way to distinguish between already loaded commands (for instance if a command has been removed, renamed, etc) and completely new commands. Data stores may have to be involved, or potentially writing and reading to/from Config
• Have a 'new commands' section where commands can be reviewed and added in or ignored. Also have the option to 'add all' and 'ignore all'
• If new command, print "Nanoblox new commands!" in console
• For rejected and already-loaded commands, have these under 'inactive/uninstalled commands'

Test plugin issue

This means items can be easily read, modified and written by the user, plugin and core.

To do:

• How will this work with array and dictionary values? Do attributes even support this? (check all properties for tables/dicts too)
• Rename Config to Configuration
• Change Extensions class from Configuration to Folder (Configuration will be reserved for items with attributes)
• Strongly consider removing Commands entirely from System and data saving
• Learn how attributes work
• Replace Configuration Module with a folder that contains folders such as 'Roles', 'Bans' and 'Settings'
• Setup an attribute template for all of these (these will be a Configuration instance) OR Consider how the plugin will load new attributes
  • Have the plugin contain its own internal 'Config'
  • This is then used to build the config folder and attributes within the loader
• Ensure the templates have an attribute called 'key' which points to the the original table key
• The names of these config items can be anything they like (non important, dont save)
• Have the Core Framework convert this data into the original module data on initialisation at runtime

test 3

Config

• PENDING_MIN_CCU = 50
• PENDING_MIN_VISITS = 10,000
• DISCOVER_MIN_CCU = 100
• DISCOVER_MIN_VISITS = 100,000

Game Categories:

1. Pending

• Games waiting to be approved
• A game can only become Pending if it meets the PENDING requirements, otherwise is automatically rejected
• Can VERIFY, REJECT and BLOCK
• If a game is REJECTED, then it cannot apply again for 24 hours

2. Verified

• Approved games which appear on the discover sort
• If the game falls below the DISCOVER requirements, it will still remain as 'verified' but not appear on the discover sort
• Can UNVERIFY

3. Blocked

• This game cannot apply at all
• Can UNBLOCK

Action Types:

• VERIFY - moves the game to Verified
• UNVERIFY - moves the game to Pending
• REJECT - removes the game from Pending
• BLOCK - moves the game to Blocked
• UNBLOCK - moves the game to Pending

hello test

test 5

Explore a workflow where:

1. The 'Core' is a Reusable Package
2. The plugin installs the Core and Extensions (like commands)
3. Have the plugin (if possible) manually change the Core's PackageLink AutoUpdate property to true
4. Remove the Commands/Extensions Plugin MainModule and instead prompt the user if a change in version to the plugin is detected

When creating a role, have the ability to select a 'pre prepared' template. These will provide a name and description overview of what that template does. Templates include:

• Owner
  • Has virtually every single power
• Developer
  • Can configure things like roles, settings, etc
• HeadAdmin
  • Can broadcast commands globally and use abusive commands
• Admin
  • Can use abusive commands
• Moderator
  • Can use many utility commands
• VIP
  • Can use some fun commands but only on theirself
• Player
  • Can't really do much except viewing some menus (such as ;cmds), viewing their ping, etc

To do:

• Create a 'RoleTemplates' module
• Have an initial dictionary for each template with keys such as 'name' and 'description', then a sub dictionary of all the role setting pre-sets