If an icon contains a tip and is tapped or longpressed on mobile, a tip will appear. Instead, tips should not appear at all on mobile.

Explained here: https://devforum.roblox.com/t/topbar-add-additional-functionality-and-themes-to-your-topbar/573313/149

To fix consider:

• Adding a Button1Down event to the DPad to drop-it-down when pressed

Requirements:

• Works with R6 and R15
• Works client sided and server sided
• Works on player characters and NPC characters
• Does not kill the Humanoid and is reversible (i.e. the character/npc can get back up again)
• A method to activate the ragdoll, and one to deactivate
• The ragdoll methods should be intuitive and contained within a single shared module
• As long as you ensure it meets all those requirements, I can setup the networking myself (or help you with it)

Resources:

• Nevermore Ragdoll: https://github.com/Quenty/NevermoreEngine/tree/a98f213bb46a3c1dbe311b737689c5cc820a4901/Modules/Server/Ragdoll
• This thread: https://devforum.roblox.com/t/temporary-ragdoll/428487 (especially replies from dcampeon and Weldify)
• EchoRepears maybe? https://devforum.roblox.com/t/r15-rthro-ragdolls/338580
• This post maybe: https://devforum.roblox.com/t/r6-ragdoll-system/772660/13

Additional

• Twitter thread: https://mobile.twitter.com/sleitnick/status/1410680863629643776
• Roblox Core: https://github.com/CloneTrooper1019/Roblox-Client-Tracker/blob/roblox/scripts/CoreScripts/CoreScripts/PlayerRagdoll.lua
• This place: https://www.roblox.com/games/6916978337/New-system-euphoria-ragdoll-test
• This latest devforum resource: https://devforum.roblox.com/t/ragdoll-script-open-source-r15-pc-mobile-xbox/1446787

• Setup ragdoll service, controller and utility modules
• Have ragdoll and unragdoll command

I was playing a game that had HD Admin in it on an Xbox One console, when I noticed that ROBLOX's rounded UI icons on the new top-bar are not present, yet the HD Admin logo is. (Again, I'm not sure exactly how detecting a player's platform would be possible, as ROBLOX only provides input-type detection APIs.)

• Consider dependency management for modules such as 'State' and all Utility modules and projects such as 'DataStorePlus' and 'TopbarPlus'
• Convert SharedModules to Shared - > Modules
• Setup 'Packages' folder within Client, Shared and Server
• Instead of 'shared' on the client, simply have everything within shared clone into both server and client
• Add TopbarPlus Icon to Client Packages
  • update modules.Icon
• Add ZonePlus Zone to Shared Packages
  • update modules.Zone
• Add DatastorePlus to Server Packages
  • update modules.User
  • update modules.PlayerStore
  • update modules.SystemStore
  • update modules.State
  • update modules.Serializer
• Remove Utility and Projects entirely from Core
• Remove dependencies from DataStorePlus
  • Have Maid and Signal as modules within UserStore (make sure to use the modified one without Promises)
  • update UserStore
  • update User
  • update State
  • have all modules reference parents correctly now that UserStore is parent
• Ensure Directory.merge works correctly
  • module references must only be merged when they are required (easy loaded)
  • to do this, check for corresponding module with Loader -> Extensions -> Core
  • when merging models, what if two models have same name but completely different children which we dont want merging? maybe only merge folders and configuration instances
• Instead of cloning shared into server and client, setup an entirely new folder within ReplicatedStorage too called 'Shared'
• maybe consider a global main variable .shared in addition to .client and .server
• Completely test and fix every change to the framework
• client does not appear to be initating
• test new remote system completely
• there appears to be a problem with returning multiple values, possibly to do with Remote Object?
• look for all uses of invokeServer and invokeClient and ensure they work with promises (and potentially timeouts)
• consider changing modules.System/UserStore to modules.DataStores.System/UserStore

Remotes

• rename to ServerRemote and ClientRemote
• move to a shared package
• setup a server and client module called 'Remote' which requires and returns these
• merge RemoteController and RemoteService into their easy-loaded modules
• update all references of main.services.RemoteService:createRemote and main.services.RemoteController:getRemote to main.modules.Remote.new()
• make irrelevant methods _private
• for all asynchronous calls return a Promise
• for :invokeClient...
  • introduce a timeout parameter
  • if that player leaves the game, then cancel wait

test

When in portrait mode the HD Admin mode is way to large.
Maybe this can wait until V3, there isn’t really that many games that use portrait mode and it’s still useable. Just wanted to let you know so V3 works on all screens.

Zone+'s original intention is to gather a collection of players, on the server. To do this, it performs a Region3 check, to gather an array of players within a 'rough' location, then it performs a raycast check to determine precisely where this rough-group of players are. There is one use-case on the client where Zone+ can be used: when a local player wishes to gather information of a collection of people within a zone. Recently however, lots of developers have been using Zone+ on the client to detect if the single local player is within a zone. This is inefficient and incorrect, as the Region3 check does not have to be performed at all (a simple downward raycast from the local clients humanoidrootpart is all that is needed).

Solution, either:

1. Setup warnings to make it clear that Zone+ should not be used in this way
2. OR (preferable if possible), figure out a way to bypass this additional check on the client, whilst maintaining its original functionality

Examples:

-'Label Icons' (from :setLabel) have a squashed image and text

• Captions appear tiny below the icon (make sure to consider setCellSize when fixing this)

I have made an example of how I would want it to work here: https://www.roblox.com/games/5238935539/HD-Admin-Logger
Would be cool to see something similar make its way into V3!

Re-enable tips and captions for mobile and instead have them offset ~50 pixels below the normal position so they're viewable below the thumb/hovering-finger

:setTip() creates a tip for both PC and console, while this method :setControllerTip will override any other tips specifically for users with a controller plugged in (can dynamically include PCs when a controller is plugged in/out).

This will be useful in scenarios where you wish to have different instructions for PC and console, e.g:

PC:

Console:

Improvements

• move to new standalone repository with installer methods like topbar+ (plugin, rojo, etc)
• remove all require() dependencies
• consider removing additonalHeight param as this causes confusion
• replace irrelevant : within non object methods to .
• improve tutorials to make people aware of using Zone.new() (in addition to createZone)
• add Destroy upper case alias
• consider making work with non-players

Bugs

• have the raycast fire from the hrp centre (instead of feet) for improved accuracy on upwards slanting shapes dipping into the ground
  

• explore rotated wedge bug. this may be solved by the points above
  

• random generation appears to fail below other parts
  Repo file: https://devforum.roblox.com/uploads/short-url/pn1v2zXgk3e5QxwU62m2QjnocD4.rbxl
  

• cluster infinite recursion https://devforum.roblox.com/t/zone-errors/864654/5

Main

• have a Zone module then a ZoneController as a child
• for zone, support both players and parts
• have methods like :getPlayers, :getLocalPlayer, :getParts, :checkPlayerInZone, :checkLocalPlayerInZone, :checkPartInZone
• have events which automatically initiate a loop when connected to - .playerEntered, playerExited, partEntered, partExited, localPlayerEntered, localPlayerExited
• for players, dynamically change between region3 + raycasting and solely raycasting depending upon factors such as total volume across all zones, number of players in server, localPlayer loop, etc
• for parts, call region3 like normal then raycast, however if a part is anchored (or not) consider caching results based on enum.accuracy
• handle logic, decision making and even raycasting within the controller
• when raycasting, perform a centre check initially, then if this fails use angle math to get the face nearest to the closest zone centre, and perform an additional tiny raycast in that direction
• introduce enum.Accuracy with items such as 'Precise', 'High', 'Medium', 'Low' and a zone.accuracy property
• once again have :update and. updated for calculating the zones min and max bounds and region, but completely scrap the 'cluster system'
• introduce :getRandomPoint again but this time do purely a while loop with completely random casting
• for ZoneController, remove create/remove methods entirely and just have ZoneController.getZones()
• parent utility modules like Signal and Maid under the Zone module

It would be useful if there were the ability to add Icons on the right hand side of the Topbar (Next to the ... button)

I have sometimes made modules that I feel like for someone who doesn't know how to program it is maybe a little hard to insert it if you have to like insert the main module, edit the parser and then add the module under it. A way to just add it in a folder without having to insert the main module would be nice. For example just add a folder under custom features.

Then to add a module simply put it in there and the main module will require it.
Also if you need to change like some core parts of the system, allowing the user to override some modules like the parser would be awesome.
You could for example just add a string value or something in that custom module named like "Override" and then the value could be "Parser" the main module would then look in the custom modules folder before requireing the core parser.

This would make it really easy for users in all ages and skill levels to add some custom functionaliy.

Thanks, Lucke.

• Add CHANGELOG.md
• Automatically update to Core with relevant updates (i.e. features)

Implement features such as 'tags', 'types', etc , similar to evaera's Promise API (https://eryn.io/roblox-lua-promise/lib/) (https://raw.githubusercontent.com/evaera/roblox-lua-promise/061c3a8659d97360df0a001a7143506cf907e21d/lib/README.md), when writing documentation with mkdocs and material (https://squidfunk.github.io/mkdocs-material/),

This is a clever idea, credit to Outlaster by Peak Precison Studios:
https://www.roblox.com/games/5343994291/NEW-Outlaster

Captions, where a fixed block of dynamically sized text appears below the icon. This will function similar to :setTip().

How the theming is set needs to be considered in more detail. Possibly consider creating two new objects, caption and captionLabel, or maybe have it match the buttons BackgroundColor and labels TextColor. Also consider corners.

This would have to work on PC and Xbox, while being disabled on mobile

Also hide when selected (like tips)

A small issue, just change the font to Gotham Bold or some other Gotham font

Repo file: https://devforum.roblox.com/uploads/short-url/pn1v2zXgk3e5QxwU62m2QjnocD4.rbxl

Investigate and fix

Yooooooo @1ForeverHD

I am now looking and searching for a long Time for something so I want to do that if ur Admin you only can use commands at 1 Person, How can I do that? Where are the Settings that allows me to change that? So Admins only can use like Mods commands at only 1 Person (so they are not able to do ;(command) all anymore? Would be nice to know!

is this the new HD Admin?

A ‘press overlay’ for when icons are pressed/hovered to more accurately mimic topbar icons

• rename master branch to main
• i believe we use terms such as 'blacklist' and 'whitelist' within role and global settings. determine a new term for these (such as ignorelist, etc) and apply them

The chat icon created through :createFakeChat apparently disappears randomly (maybe 1/10 sessions) and for all games with HD Admin V2

Right click would be pretty good, like if you right clicked a button you could have options that do different stuff. Would be really useful!

(Topbar+)

Edit: PR: #21

On PC it doesn't capture focus, and on Console it doesnt drop down at all

For those who stumble across this card and are wondering what an 'Environment' is: imagine a game where players have their own personal section of land. Within this local area, they can configure their own admin roles, settings, bans, etc which saves. Everything which takes place within this area though remains within this area. An area can be anything from a plot of land in a server, to a private server. This in essence is an 'environment'. The goal with Nanoblox is to allow the easy creation of these environments, while ensuring restrictions are in place to prevent abuse. By default, there is the 'Game/Global' environment, where changes impact every server (i.e. the default behaviour you'd expect of admin commands).

Ben's latest thoughts and proposals:

1. APIs should be simplified

• For example, RoleService.createRole(isGlobal, properties) should just become RoleService.createRole(properties), where 'isGlobal' and 'environment' now become properties. Consider renaming 'isGlobal' to 'permanent'. These properties default to false and Game/Global.

2. Redesign how environments are defined

• Instead of enums, consider strings, e.g. "Game" instead of main.enum.environment.Game
• Considerations:
  • How and when are these environments created? For example, the Game is one entity, while a PrivateServer can have many different private server owners. Same for zone environments.
  • This should be responsible for creating the separate datastore entities too - every environment will own its own SystemStore key (instead of roles, bans, etc)
  • Also consider how a record may change datastore entities when its environment is changed - for this, remove the record then re-add it to the new environment
  • Restrict the changing of environments if it does not exist
  • An environment module with a function like .getEnvironment which returns a promise. If that environment has not been loaded before, then initiate it and continue afterwards.
  • Have a module where environments are created, then create the default environments:
    • Game
    • PrivateServer
    • ReservedServer - maybe combine this with reserved
  • Remove SettingService.createPrivateEnvironmentIfA

3. Every record needs to have a UID

• For example, instead of bans["82347291"] it would be bans["82347291-IF9jL5UoJZ"] with a record property 'userId' that points to that user
• This includes Settings, where instead of having settings["Player"] and settings["System"] it should be settings["Player-AbUkL5UoJZ"] with a record that contains the keys 'player' and 'system'

4. Every System Service needs to change

• Every SystemService should have an associated object. RoleService would have 'Role', BanService would have 'Ban', etc. These objects will then contain the default values (instead of .generateRecord), the key 'record' (a State table where all display level values are stored), a default method :update(), which is the equivalent of doing .record:set(), and a a signal changed which mirrors .record.changed
• When :destroy() is called on one of these objects, it truly erases the data
• RoleService.recordAdded:Connect(function(roleUID, record) should become RoleService.roleAdded:Connect(function(role) and the same for roleRemoved, while roleChanged should be completely eliminated as the role object itself now has its own signal. Repeat for all other services
• SystemService.getObject(UID) should always be the same, while services can have alternative getters such as RoleService.getRoleByName(name, environment), BanService.getBanByUserId(userId, environment), etc

5. Virtually everything should use 'pathways'

• As the title says
• Consider having 'changed' to achieve this (instead of descendantChangedSignal)

6. How system items are displayed

• Items (such as roles, bans, etc) should be organised into environments. If no environments are present, then simply dont display the environment title at all. Something relatively similar to HD Admin's servers category:
• https://user-images.githubusercontent.com/51117782/127743960-dfa4e426-7d62-4236-85e1-1f63e0af6951.png

7. Belonging to multiple environments

• Within Command verification, if a user performing an action where it's uncertain which environment to act upon (e.g. if a game owner goes into someone private server, and the private server owner gives them admin), a prompt should appear informing the user to select their preferred environment and then taking them to the Player Settings page to select this.
• More details below

8. Objects/services now have to consider environments

• Objects/services like bans will now have to account for environments when calling methods such as getHighestRole

9. Reconsider some of the challenges posed by the current System and ConfigService

• This includes:
  • The retrieval of new config information every 10 seconds
  • The removal of items (such as roles) in game originally created in studio
  • The global updating of these roles

10. GDPR Compliance

• When a user is wiped, make sure to wipe all their associated environments (reserved, private, etc) too

Currently Nanoblox has a 'global' environment where data can be saved (such as bans, roles, settings, etc).

Now consider how a similar environment can be setup for private servers and servers created through the SavePlaceAPI:
https://developer.roblox.com/en-us/api-reference/class/AssetService

Also consider how zone-based environments can be created. For example, a game where everyone has an assigned piece of land, and only admin commands can be used in that zone on players in that zone. The environment can be associated to a player, but can also persist after this player leaves.

This will enable private server owners for example to permanently ban people and create saveable roles within their own private place whilst no spilling out into the rest of the game universe.

Revamp System user.temp.descendantChanged

• What happens if someone is banned on both Private and Global within surface level??????????????????????
• Important Consider how getters will work? Do you have to specify the environment? If so, a lot of methods and places will have to be updated (e.g. Args getSystemSetting/getPlayerSetting). Also consider what happens to state tables like that from CommandService (e.g. 'lowerCaseNameAndAliasToCommandDictionary') and SettingService (e.g. 'lowerCaseColorNames')
• Strongly consider reorganising surface level data (i.e. records) and events so that they have to be updated/set via a 'settingPathway' (e.g. "RoleSJDSFKLSDF.limitModifiers.global"), and then call ServiceName.objectChanged with the pathwayTable instead of settingName. Utilise createDesendantChanged (maybe) for this.
  • Rename 'pathwaySetting' to 'pathwayString' and then also have 'pathwayTable'. Make sure to do the same for the RoleService methods (which call it 'pathwaySetting')
  • Update the following services.recordChanged and give their objects 'get' and 'getOrSetup' methods which are mimiced from State
    • TaskService
    • RoleService
• Where possible, try to merge TOP LAYER and OTHER LAYERS into one, neaten up
• Completely revamp 'expiryTime' so instead of working for just the top layer, it can work for any layer (i.e. instead of doing record[key] = nil, do record:set(nil)
• Finally finish off the color changer detector table within SettingService.loaded()

Other

• Play around and compare SavePlaceAPI with Reserved Servers
• Consider changing 'PrivateServer' Environment enum to just 'Private'
• Reserved and Private servers have a unique game.PrivateServerId value, while CreatePlaceAsync Servers have a unique game.PlaceId value. Consider a way then to initialise a 'private' environment with just a normal PlaceId.
• Consider an 'environment' enum for Roles. Items can include 'Global' and 'Private' (which includes Reserved Servers). This environment property then determines how all other actions behave too. For instance, if a player ('Private' environment as their dominant role) 'perm bans' someone, that person will only be banned from their private server, not the whole game (i.e. global).
• Reconfigure System:
  • Consider revamping system user data so that it contains bans, roles, etc within a single user, instead of spread out over many, then whenever a private server is created, create a new system user
  • Create a SystemService with single method .createEnvironment(key)
  • Create an Environment object which contains the data loading/saving code
  • Move most of system handler code to Environment, while only keeping the 'Display' data which fires the surface level events and contains the surface level API
  • on :start(), have SystemService automatically create a 'Global' environment
  • check SettingService.createPrivateEnvironmentIfA, then create an additional environment with the game.PrivateServerId if...
    • privateServer is true and game.PrivateServerId and game.PrivateServerOwnerId > 0
    • OR reservedServer is true and game.PrivateServerId and game.PrivateServerOwnerId == 0
    • OR normalServer is true and game.PrivateServerId == nil
  • ensure this new setup works correctly with ConfigService
  • have ConfigService.setupComplete fire and set when Global data is finished, but don't worry about any additional environments
  • this means if a non-global environment is called (e.g. :createRecord()), that will fist have to check the environment exists, then yield if not loaded. ensure all APIs handle promises.
• Introduce a third enum 'Multiple'. For all _isGlobal params within System objects (to be replaced with Environment), if 'Mulitple' is passed through, request the caller to specify. If caller player not present or no return within 10 seconds, default to 'PrivateServer'
• Introduce an environment enum arg/param for System (e.g. :createRecord, etc), replace _global with isPermanent, and then update to all system services
• Determine how roles can be hidden (for example, on a PrivateServer, you wont want to see Globals unless you're the game owner). Maybe split them into two categories for the UI (bans, roles, etc): 'Global' and 'Private Server'
• Ensure Global Receivers and Senders also account for environment (for example, even if Global, if Private environment, only send to servers with the matching id)

Would like this so it can just enable/disable ScreenGuis.
https://developer.roblox.com/en-us/api-reference/class/LayerCollector
https://developer.roblox.com/en-us/api-reference/class/ScreenGui

Hello! Is there any reason why the ;face command does not let you use roblox decals anymore? And if it does, it only seems to work for the owner of the game.

Goals

• An object to handle the execution of commands or the execution of subtasks (which then go onto execute commands)
• Can work on server and client
• Provides wrappers and utility, such as thread tracking, maids, agents, etc
• Combined with TaskService on the server manage most-to-all modifiers

Overview

Tasks can be split up into three core components

• task:begin() - this determines all modifiers, then runs them in order, call task:execute() for each operation. if no modifiers, simply call execute once. after running all modifiers, call task:end
• task:execute - decides what jobs to run based upon its given properties (such as invoking a command, splitting the task into subtasks). try and pretermine this, e.g. task.splitsIntoSubtasks = true, for these subtasks then have task.parentTask
• task:end - if any commands active commands calls revoke, if any active subtasks calls end, then cleansup everything via the maid

To-do

Initial upgrades

• Improve setting like task.command
• Setup task:track and make it work for tweens
• Do not update task (originally thisExecution) with command properties
• Ensure :invoke/revoke is called on commands instead of .invoke/revoke
• Introduce a task.splitIntoSubtasks bool property (based upon qualifiers, player, global, etc) that determines its job when executed

task:begin

• Ensure all action (non-pre-action) modifiers are ordered correctly
• Have given modifiers ordered
• complete spawn modifier and strongly consider having thread:disconnect() after the given function has executed (instead of before)
• also ensure the thread methods have to wait at least 1 heartbeat before finishing (although the initial function doesn't have to)
• complete string time https://devforum.roblox.com/t/zoneplus-v2-construct-dynamic-zones-and-effectively-determine-players-and-parts-within-their-boundaries/1017701/33
• Important: all modifiers atm act as standalone and don't consider each other. Ensure that modifiers work together when combined (e.g. delay and loop, epoch and delay, etc)
• Setup task:begin so it either executes through all present modifiers in order, or calls execute once if no modifiers present. If multiple executes, wait until the previous execute has ended (this is likely where promises come into play)
• It's important these utilise task:track and Thread so if the task is ended early then the modifiers also stop (OR DO THEY?! strongly think about not doing this or at least think about self.totalThreads)
• Complete all action modifiers
• Call task:end when finished
• Within task:end/destroy, if isa server task and not a perm task, then call taskservice.removetask
• Make sure to end all present threads

task:execute

• If splitIntoSubtasks == true then generate an array of players based upon the given qualifier(s), split into subtasks, set these subtasks taskParent to self, then call :begin() on them

task:end

• Provide alias .destroy and .Destroy
• should there be two separate maids, one for the task and one for executions?
• for commands like icefreeze, walkspeed, paint, neon, spin, title, clone etc, when should the task end, and how?? Maybe on death, maybe persist on respawn
• listen for player removing (if userid), and call task:kill if fired
• introduce a command.persistence enum
  • none
  • untilDeath - character.humanoid.died
  • untilRespawn - targetplayer.characteradded, but also consider how this impacts other things. for instance, maybe add a heartbeat wait to the spawn modifier
  • untilLeave - a task is automatically removed when a player leaves, so also ignore
  • untilRevoke - simply ignore the task:kill at the end of begin
  • what happens if command.persistence.untilDeath or untilRespawn and 'spawn' modifier applied?

task:filterTextArgs

• consider setting 'filterText' for args such as 'Text/String'
• within the task constructor, determine the original Arg module table from commandName, iterate over all args, then if argtable isa filter/text command, then filter the value on a player specific basis (maybe utilise thread/promise since it asynchronous)
• filter over all args and if needs filtering convert with the new ChatUtil methods
• once all items have been filtered set a property and call a signal
• within execute, if this property is false then wait for signal to fire before continuing
• with the things learned from chatutil, apply them to other promises such as that in banservice, timeservice (which should be converted to TimeUtil then tested)

Networking/ClientCommands

• task:invokeClient/nearbyClients/allClients - use the client commnd remote to achieve this, note down the sent clients, and (IF PERSISTENCE IS NONE, THEN 60 OTHERWISE 0), passing through the taskId and ...
• also consider passing through {details} instead of just taskid which contains 'killAfterExecition'
• When sending off to clients for clientcommand, invoke all clients and only end task when heard back from all, OR timeout exceeded, OR heard back from 90% or more and exceeded 3 seconds
• Consider tailoring the timeout variable for the average upper limits of responses for that patticular command (instead of 60)
• within task.kill make sure to cleanup the client (if client present and has not ended) on end
• -If not needed, remove main.services.CommandService.Client.new
• if task:pause/resume/kill called on server, also call if for all relavent clients
• now handle command invocation on the client (clientcontroller receiver, find client command, etc)
• now handle command revocations on the client (same as above, then kill corresponding task)
• now handle pause and resume on the client
• task:revokeClient/AllClients - revokes (i.e. ends and cleanups) all specified 'sent clients)
• if a client remote request is blocked (exceeded) then send a follow up warning to the client. do this for both invokeserver and fireserver (for invoke consider promises on the client) and setup a remote object on both client and server to send/receive these errors. then set a function from the modules.remote moduler
• introduce a param for serverremote 'datalimit' which blocks all requests past a certain size
• move remotes from CommandService to TaskService
• setup TargetPool enum
• for each enum item, have a function which returns the pool of players (have an option to pass through a list of narrowed players, which can be a dictionary or an array)
• complete each enum item
• for invokeNearbyClients replace with the nearby enum value
• task:replicateTo/ToNearby/ToAll/ToServer - set a limit of 12 requsts per second and 200 bytes, fire to server (which checks the client command has the .replicateEffect method and the player client matches the task.player, then records task.replicationsThisSecond) then fire to desired clients and call replicateEffect.
• Command.preReplication(task, ...) - if false returned then block - e.g. for lasereyes block more than 3 requests a second, if piano cap the max/min pitch and volume
• task.replicationsThisSecond, totalReplications
• for verify replications, if false is returned, send an error message to client with the second returned parameter

Other modules

• within commandservice.createtask and taskservice.taskadded call :begin on returned value
• for the methods below, try to dynamically store references of names and userids to tasks
• taskservice:getTasksWithCommandName(commandName)
• taskservice:getTasksWithUserId(userId)
• taskservice:getTasksWithCommandNameAndUserId(commandName, userId)
• taskService.removeTasksWithCommandName(commandName)
• taskService.removeTasksWithUserId(userId)
• Have a setting which prevents the same command name being used on the same user until the previous has expired (first check command tristatesetting, if default, use settingservice value
• if revokerepeat true, remove all tasks of same commandname prior to creating (ensure user specific if user present)
• Complete the pre-action modifiers within CommandService

Final components

• CHECKOUT AND FIX ENUM (also remove the tostring requirement so thingy can work maybe)
• Consider changing task.caller to task.callerUser and introducing task.callerUserId (or just outright remove task.caller)
• Improve PlayerUtil so functions like 'getHumanoid' also take a userid which checks for getPlayerByUserId
• Setup events/signals for command/task/role added/removed/changed
• Consider replacing MessageService methods 'like hint, message, etc' 'All' with the target enum thingy
• Consider renaming batch (like from executeBatch) to statement
• Finish CommandService invokeCommand and revoke
• Important: Improve State tables
  • Investigate State missing table bug mentioned by Raza (see pinned .txt in team discord)
  • Instead of checking for .new, have a param to inherit descendant tables and set to off by default
  • Update System handlers so they utilise this new param (they need it to be true, not nil)
• Complete Agent/Aurora/Buff
• Complete Clone

Test all of Task (including CommandService and TaskService)

• Test the initiation process of creating a task
• Buff values are not resetting correctly??
• Ensure tasks remain for their specified durations (thoroughly test Command.persistence)
• update new persistence enums and introduce new enum 'UntilCallerLeave'
• Test command.persistence for server commands
• Thoroughly test task behaviours (maid give for example)
• Test buffs on server
• Ensure client commands work at a basic level
• test leaving during a client command invoke
• Test client commands with different persistences
• Ensure the ... is passed correctly
• Consider introducing a task method along the lines of task:invokeFutureClients()
• ensure the preReplication method works correctly (and blocks accoridngly)
• a property or something to prevent clone standing on your head when it follows
• Test buffs on client (including the dynamic agents)
• a way to track objects given to the task then anchor/unanchor (if previously anchored) when the task is frozen/resumed
• introduce a task:tween method which abstracts task:give(TweenService:Create)
• Test pausing/resuming on server (this includes tweening, and a mix of player-specific and server commands)
• Test pausing/resuming on client
• Test pausing/resuming on client via server
• Create the following commands:
  • Before doing this determine two things
    • How to detect the player specified 'nil' for the playerArg - maybe a property within tasks?
    • Tasks must remember the the highest role of the player calling them. They can then only be paused/resumed/cleared by users of equal or higher roles. Consider a setting for this? (for juniors and equals)
    • Ensure sounds (aka music) are pausable and resumable (consider adding some methods to Sound object). Also ensure sounds gets tracked like instances when 'given' to maid
  • ;pause (playerArg) - ensure can only modify tasks of equal/lower role
  • ;resume (playerArg) - ensure can only modify tasks of equal/lower role
  • ;clear, refresh, re (playerArg) - ensure can only modify tasks of equal/lower role
  • ;clearServer, clearAll - ensure can only modify tasks of equal/lower role
• Test all server to client methods
• Test all replication methods
• ensure the invoke timeout works correctly
• ensure the replications work correctly
• Test ;global where the command args are both 'player' and 'players' (see line 300 task for testing)
• Test sub tasks
• ;kill (which does ;kill me)
• ensure qualifiers 'users' and args 'players' utilise the getPlayerFromString method and perform correctly (ensure user qualifiers checking for correct displayname/username)
• integrate and test razas parser
• complete args
• thoroughly test all args
• thoroughly test all modifiers and the splitting of users within commandservice
• test all qualifiers

Additional

• Consider how the following will integrate with the Parser and contact raza
  • Command.opposites
  • Command.prefixes
• Setup and test these
  • Command.opposites
  • Command.prefixes
• modify command.cooldown so it prevents the caller from executing that command again for another 120 seconds. the cooldown begins as soon as the task finishes executing (or maybe as soon as called)? make sure the cooldown saves in case player swaps servers. also consider introducing a role setting which bypasses command cooldown
• rename to callerCooldown
• introduce serverCooldown which prevents anyone from executing that command again until cooldown expired.

Additional Buffs/Agent

• Accessories?
• Face, shirts and pants, but they're libraryIds not catalogIds
• A 'BuffEffects' extensions folder

Additional Role Stuff

• setup a roleservice method RoleService.verifyCanUseModifiers(user, commandName, modifiersDict) for role setting roleModifiersToOnlyRoleCommands
  • this will likely involve verifySettings returning the role where the value is present, then if setting above is true, check against all returned roles and their commands, else if not some true, then just easy check.

I've been trying to get them to work and they just won't. They used to work but I believe some update broke them or something.

• Remove dropdown:setBehaviour() as its a redundant method
• Utilise Maid object for Dropdown
• Setup 'events' for when Notify is
• Fix other minor topbar+ issues
• Add :createDropdown(options) method to Icon docs
• Consider exploring a different gradient transition
• Fix shift + p bug
• reset 0.8 size (commands) for dropdown notifs
• if console mode not enabled, dont have B and V activate
• maybe make right-side consistent?
• flip CONTROLLER icon to right-side
• gradient incorrectly applies to fakeChat?
• make gradient darker
• Add :setMid() method to Icon docs
• Update :setRight() method icon docs
• Add :setCellSize() method to Icon docs
• Add :enableControllerMode(bool) method to IconController docs
• Setup docs for Dropdown module (i.e. fully review lucke's dropdown
• press overlay and hover function

Topbar: About section (docs) + playground + devforum

• Dropdown
• Tips
• Gradients
• also mention Console support
• and update one of the themes with my new blue theme (nicer one)

Zone: About section (docs) + playground + devforum

• setup music system example zone+
• Client support yay (zone:initClientLoop() instead of zone:initLoop())
• make sure to update docs and forum to change ':getPlayers' must be called frequently

GlobalService

• Strongly consider merging GlobalService into their easy loaded modules
• This will allow for the modules to be easy loaded which is important for other services/modules (such as commands) which wish to initialise right away

• rename Sender to GlobalSender and Receiver to GlobalReceiver or just one Global object with all methods/props
• merge
• strongly consider returning a Promise for all asynchronous calls
• update comment examples
• test thoroughly

DataStore service

• Consider stripping it completely and converting it into a wrapper for profileservice and utilise promises
• Support for server-wide data would have to be considered (maybe this is where the new cloud scripts come into play)

• IMPORTANT: Ensure Nanoblox works even when datastores fail

• have saveasync, loadasync, etc renamed to just save, load, etc and return promises with relevant error messages
• if datastoreapi access is restricted (https://i.imgur.com/CzXC572.png) then have a single warning in the console instead of multiple from different sources
• update internals such as :grabData to utilise promises and with with the new methods
• ensure nanoblox works smoothly even with api services disabled

System

With this System can maybe simplified a lot?

GDPR

• Ensure Private and Reserved Server environments utilise the new datastore-key-player association to be GDPR compliant
  • Have systems and users utilise new association
• When a user is wiped, make sure to wipe all their associated environments (reserved, private, etc) too

Having inbuilt support to create tool tips for Icons would be useful for new users looking at the icons who may not completely understand what they do.

These tooltips would support the theme implemented for that icon.

I am unsure if this is something the setHoverFunction is expected to cover, however this would make it easier to create tool tips, especially those which match the themes implemented

Make sure to also test the fakeChat icon created through createFakeChat

I would like to request the ability to disable the API in HD Admin. Having the API enabled could be potentially dangerous if an unauthorised person has access to the server-side through a backdoor or other methods and they can then rank themselves to admin without the creator's knowledge.

• Add CONTRIBUTING.md
• Include relevant details such as...
  • Code
  • Docs
  • Bug & Feature Requests
  • Other

• have extensions.commands Directory.move to realcore.server.commands
• then have all of extensions.core merge into the corresponding areas
• ensure command descendants also merge correctly, such as the 'Client' module, it's assets, the commands assets, etc
• when merging modules, consider converting the original into 'NanobloxToConvert' then putting the new one into the original spot - if doing this, methods from the original should only be merged if corresponding == nil)
• full test merging (core, commands, assets, folders, etc)
• setup the command core module initialiser
  • have any 'Client' modules renamed to their parents name and moved under 'ClientCommands' under shared
  • within the Command module on init, register all commands and tags
• setup client commands basic
• respond to #18 and mark as closed

Notes:

• Some sort of object associated to players, similarish to maids, which enables you to apply temp effects (such as speed, health, size, camera, body transparency, etc)
• An easy way to 'revert' to the original state, for everything and/or specific items
• Have server changes replicate to client one?
• Some predefined params (like health, speed, etc) and custom ones (like an apply and remove function)
• Consider up and down tendencies (for instance, one buff may want to increase speed by 10 (from 16 to 26) but only works after buffs with forced down speed of 0 have been removed)

To do:

• Setup a single Buff object module which tracks players internally
• Setup Agent
  • Within player service add .agent to User
  • Finish all agent methods and properties
• when to clear agent buffs?
  • when respawn property
• Consider the following buffs...
  • agent:buff("Health"):increment(50)
  • agent:buff("Health"):increment(15)
  • agent:buff("WalkSpeed", 5):set(0)
  • agent:buff("WalkSpeed", 1):set(40)
  • agent:buff("BodyTransparency"):set(1)
  • agent:buff("BodyGroupTransparency", "LeftArm"):set(0.5, TweenInfo.new())
  • agent:buff("BodyGroupTransparency", 5, "LeftArm"):increment(0.5, TweenInfo.new())
• actions - a function with which applies a value
  • increment
  • set
  • consider a custom fade function
  • custom function
• Consider and act more strongly about reset on spawn
  • if true, clearing the buffs should do nothing, else if false then the buffs surely need to be reapplied?
  • How does this tie-in with tasks which have different persistences (e.g. some while alive, some when respawn, some continue)
• How is the base value decided?
  • for instance, what to do in scenarious where the property values change outside of buff (such as for health regeneration)
  • maybe getpropertychangedsignal?
  • For numbers calculate the difference between the current value and buff value
  • For fixed values simply record the default value when the very first buff is applied. Once all buffs have been removed, 'forget' the default value.
• weight
  • if not specified defaults to 1
  • buffs of higher weights have higher priority
  • if buffs have same weight, buffs created more recently take higher priority
• Now setup the reduce and applier:
  • consider weights
  • consider default/difference values
  • if 'override' present in any buffs then only apply the buff with override and the highest weight (or clock value)
  • ensure increment only works for number values (do consider some may have tables such as BodyGroupTransparency)
  • when reduceAndUpdate is called, if a buff already has a 'difference' value, then deduct that from the finalValue
  • setup a maid (which is given to the main maid) for every reduceAndUpdate
  • setup tweens. give the new maid a 'cleanup function' that cancels and destroys these tweens, and also sets the propertys value and difference value to the end of tween value
  • make sure to update assassinate so it accounts for new difference/original/base values
  • apply default value for non-numerical items
  • apply default value for numerical items
• effects - a function which returns a property or a table of properties
  • health
  • speed
  • jump
  • transparency -- records each individual partTransparency
  • bodyGroupTransparency
  • classTransparency -- transparency of classes (e.g. accessories)
  • material -- this may require forcing parts on top, see hd admin, must work for glass, neon, etc
  • bodyGroupMaterial
  • reflectance
  • custom function
  • shirt
  • pants
  • appearance (humanoiddescription)
  • face
• value
  • can also be a table
  • consider how this works inline with effects and actions (e.g. bodyGroupTransparency)
• buff:destroy/Destroy()
• buffs should not just be 'applied' and 'removed', all their effects should be reduced in a central environment (i.e. when a buff new or destroyed), reset players effects and apply again in central environment
• increment must only be used on numbers
• fix logic:
  • 'instance name' should not be used as a key - instead create a table where the instance is used as the key
  • defaultGroup[additionalString] (i.e. non-numerical items) should also be recording the specific instance (otherwise how can individual colors, transparencies, etc be remembered when applying to a whole body then reverting)
  • when a player respawns, always assassinate all buffs, but if 'remain' is true, then create new buffs of the same values (this means instance keys remain up to date)
• ammend numerical calculations
  • instead of recording the 'difference', record 'appliedValue'
  • if appliedValue is nil, then increment property by value
  • if appliedValue is different to buff value, then increment the difference between that
  • else do nothing
  • consider what happens if changing between :set :increment etc
  • ok do this instead: record 'previousOverride' - if this is different (and not nil) and applied value and buff value are different two, then at the top, set previousOverride to nil and take away previousOverride from the finalValue
• add decrement and tweenDecrement
• have the agent automatically tracked and destroyed when player removing
• have destroyed reversion values reduced inside the main method
  • have a .destroyed property set to true when buff destroyed
  • nilling of buff should be handled in the reducer
  • if destroyed buff in reducer, should it be ignored from buffs array?
  • this should now enable the tween effect to appear
• test
  • test buff modifications after applied
  • applying multiple of the same buffs, then removing these
  • retest all the tests with the new destroy reductions in the main method
  • also ensure all buffs are destroyed correctly under different circumstances
  • setting colors does not appear to work?
  • resetting with a buffs
  • tweening while died/respawning?
  • introduce a canBeNegative bool for numerical effects which prevents/allows value differences calculating past -0
  • the current test setup does not apply values correctly after reset
  • if died while tweening buff and keep on respawn true then does not persist
  • all effects
    • setup cloneable parts for MATERIAL and COLOR
    • if the corresponding part changed (e.g. color, transparency, material, size, etc), do same for clone
    • have cloned parts removed when no longer needed
    • organise cloning of parts into a method in BodyUtil
    • face transparency
    • get head and face to work too
    • test for r15 and r6
    • consider how to combine transparency with material, reflectance, etc
  • all actions (such as tweens)
  • health regeneration
  • applying multiple effects at once
  • applying same effects but different additional
  • remove buffs incrementally
  • removing set buffs
  • lots of random combos
  • if player leaves game it errors (maybe silently kill buffs)
• convert to new head for Agent/Buff
• ensure all buffs are destroyed when task killed
• Have a task:buff(...) method which abstracts user agent and creates a buff based upon the task.callerUserId task:buff("Health"):set(50)
• also consider abstracting task.maid:give() to task:give()
• consider making into a package
• also consider updating the 'remotes' package so it has a more flexible or auto generated parent folder

Client stuff

• Some sort of way to dynamically create, get and remove agents?
• A clone system that reverts effects like transparencies etc which may be applied

I'm trying to use HD admin in a building game that involves saving creations. Essentially, I've created a place using Create Place API for people to build in, which is then saved using Save Place API. When the place is first created, the Admin functions as normal. However, when the place is saved, then re-entered, the script completely breaks, and everything I've tried to hotfix it has been to no avail.

I'm not entirely sure if this sort of application is anything HD Admin was built for, but I just ask that this be looked into, and have Created Places be supported officially.

moved to #71 to decide later when cloud scripts are released

Unless @ (or player identifier setting) is specified and check for their real name instead

Considerations

• Convert utility MainModules into submodules (https://git-scm.com/book/en/v2/Git-Tools-Submodules)
• Remove promise dependency within Maid
• Re-consider Maid :give (does it actually return promises correctly?)
• Consider parenting Project modules under a separate name or location, as the HDAdmin directory creates confusion with the HD Admin Core application

Module organisation and consistency

• Consider merging service and object modules into one (e.g. ZonePlus.getAllZones() and ZonePlus.new()
• Consider renaming objects and references to ObjectPlus instead of just Object (e.g. ZonePlus instead of Zone).
• Only keep :colonMethod() for objects where self needs to be injected. Replace everything else with .method()
• Convert method names :getAllRecords to :getRecords

Plugins (to replace MainModules)

• Create a plugin for every project to completely replace the MainModules
• For this, have an 'Insert' button, and when the project folder is found, replace with 'Remove'
• When the plugin initially loads, check for its folder, and update if any changes

• complete topbarplusv2 and move out of repo
• complete zoneplusv2 and move out of repo
• rename master branch to main
• replace core website with new design and files
• reorganise files to src -> Core + default.project.json -> Client/Shared/Server -> etc
• Setup ROBLOSECURITY and PublishAssets.yml
  • core 6335518457/Nanoblox-Core
  • plugin 6335537744/Nanoblox
  • loader 6335527900/Nanoblox-Loader
  • commands 6335531490/Nanoblox-Commands
  • topbarplus
  • zoneplus
• Setup automation
  • Setup nanoblox core mainmodule asset
  • src -> mainmodule
  • publish asset
  • module to docs
  • deploy docs
  • build release
• move datastoreplus out of repo
• ensure webhooks work for all new repos
• consider dependency management for modules such as 'State'
• transfer all utility modules directly into the core
• remove projects and utility from docs
• update PublishAssets.yml so only the core remains (and make sure to update its new reference)
• rename docs from HDAdmin to Nanoblox

organization

• strongly consider making nanoblox an organization and moving to that
• setup organisation and teams
• change repo name to nanoblox/core
• change license to mplv2 https://tldrlegal.com/license/mozilla-public-license-2.0-(mpl-2)
• check all devforum links now refer to 1ForeverHD/Nanoblox, 1ForeverHD/TopbarPlus or 1ForeverHD/ZonePlus
• invite members
• setup nanoblox/core
• setup nanoblox/plugin
• setup nanoblox/loader
  • contain a 'Commands' folder and a 'Core' folder
• setup nanoblox/commands
  • have client modules named 'Client' within the command, and have all repo files structured CommandName (folder) -> init.lua + (optionally) Client.lua

My issue is that when I call IconController:setTopbarEnabled(false), the topbar doesn't disappear.

Situation and the reason why

Topbar+ is in StarterGui, but while my game is loading, the character doesn't spawn, so to remedy this, I clone the Topbar+ GUI into PlayerGui, then I require the module, create my buttons and load everything else. When it finishes, I have my loading script invoke the server to spawn the character, however, when I call setTopbarEnabled, it doesn't work. The first thing I did is to check my script for any errors. Then your module's code, I found a WaitForChild call in the IconController module (function getTopbarPlusGui, so I jumped to the conclusion to check my PlayerGui and I found that the Topbar+ GUI was duplicated. [The icons were created in one GUI, but WaitForChild is returning the other one])

As an improvement and a fix for this issue is to have IconController grab the GUI from Icon instead of using a WaitForChild call,

TLDR / I don't understand: If the GUI is duplicated then there is a chance that PlayerGui:WaitForChild("Topbar+") doesn't return the correct one, making setTopbarEnabled disable the improper one.

• Tell me if I should make a pull request for this instead.
• Sorry for the ambiguity and/or bad explanation, English is not my first language.

We should be able to disable VIP commands, rather than setting every single VIP command to Mod+.

Requested by elliot https://devforum.roblox.com/t/topbar-add-additional-functionality-and-themes-to-your-topbar/573313/113