Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Finalise Users/Profiles, Globals and Central Server Overhaul #140

Open
15 of 24 tasks
1ForeverHD opened this issue Feb 9, 2022 · 0 comments
Open
15 of 24 tasks

Finalise Users/Profiles, Globals and Central Server Overhaul #140

1ForeverHD opened this issue Feb 9, 2022 · 0 comments

Comments

@1ForeverHD
Copy link
Member

1ForeverHD commented Feb 9, 2022

Globals

  • See test server and write up details

Central Server

  • See test server

System User

  • CRITICAL: Strongly reconsider how Studio -> Server and Server -> Studio functions, or at least consider a Studio-only Lock permission/configuration that prevents an object (such as a role, ban, etc) being configured in game
    • The best course of action may be to apply locks to the 'Owner' and 'Manager' roles
    • Prevent this lock property from being configured by datastores
    • Ensure that locked roles always have a greater priority than equivalents
    • ALSO IMPORTANT: Introduce a studio setting (not an in-game setting) which *can only be modified in studio) that restricts global communications (default to global communications enabled).
  • CONCEPTUALISE how a 'server user' with profilestore will work
    • Does the user conform to the central server with data being sent over the network to it, or is memory store utilised to just 'hand over' who is in control of this user?
    • Determine how global data can be read from non controlling servers if they can't directly access the profile
    • How periodically are changed checked for, and what happens if their are both changes in the current records and incoming profile? How can these changes be merged without re-triggering signals?
    • How is the server to host the session determined? Sorted maps (ascended by timestamps) or queues? Are all servers checking this queue, or just the central server which publishes its results via globals?
    • How does the session handover occur? Should the lead server remove its queue position as soon as its save is complete, then have the next server (if any), forcefully take over that session? It's important that these handovers are at least 6 seconds apart to prevent exceeding Set Cooldown Limits.
    • Write up these changes into environments
    • Organise Environments so that only relevant information remains
  • Important: What happens if a role (such as the default owner role) is created before all data from an environment has loaded? What to do with the .loaded method within services?

Users/Profile

  • User:view()
  • UserStore:viewUser(key, version)
  • UserStore:updateUser(key, stateChanges)
    • stateChanges will be a table containing sub table description the action change (e.g. {{"insert", "Characters.Specials", "Ben10"}, {"set", "Cash", 999}}
    • This will require first checking in the server, then if not successful invoking a global to check all other srevers, then finally loading the user manually.
    • Once a user has been identified/loaded, apply the stateChanges
    • If user was manually loaded, make sure to destroy it right-away after use
  • Update all user.perm and user.temp data to PascalCase
@1ForeverHD 1ForeverHD created this issue from a note in Nanoblox v1.0.0 (In-progress) Feb 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Nanoblox v1.0.0
  
In-progress
Development

No branches or pull requests

1 participant