Shared Group Assets

Feature Requests Engine Features
#1

My current issue right now is that I have two groups: a “Testing” group and a “Production” group. The Testing one holds random stuff I make and modules I use, while the Production one holds the main games. It would be extremely helpful if my Production group had the permissions to insert models from the other group (InsertService:LoadAsset). It is currently a huge hassle for me to re-upload models from one group to the other whenever I make any changes.

Three possible solutions to this could be:

  • Manually choosing which groups to allow insertion from (upgrade the allies feature?)
  • Have all of the groups of players with edit access to group X be able to insert models from group X as long as a player with edit access to group X also has permission for edit access to games of group Y
  • Similar to the previous, but instead of extending privileges to all users with edit access, just have owners of groups be able to do this.

A counter-argument to this proposal could be that why not upload everything in one group. However, I would like to keep my production group as clean as possible (just to be tidy, especially since you cannot delete any assets that have been created). Having more assets in it would only make matters worse.

Also, there’s probably more use cases for this, and since it’s an optional feature for users, it can only lead to good things :smiley:
except for the time it takes to implement this but meh

3 Likes
#2

Why are you inserting assets? Couldn’t you just keep the assets in the place file?

1 Like
#3

Not if I want to reuse and make them extremely mobile

#4

That is what Models are for - you can just insert them across games.

#5

I would like to make changes to the models and not have to reinsert them in every single game where they are being used.

1 Like
#6

This seems like a really specific feature request. Why are you using two groups for testing/production to begin with? A more fitting solution would be to address the problem which is preventing you from combining them (e.g. ability to restrict a game’s access to certain ranks/people and have it not show on the group Games tab if you don’t have permission to join)

#7

Not really sure I understand what you’re saying there but for my scenario, only I (nobody else) have edit access permissions to either group. But in groups you anyways cannot give edit permissions for one place, you either have to give them for all group assets or not give them at all.

And yea it’s specific, but this could also allow a lot of future possibilities. For example: a user has animations uploaded to group X (where he/she makes the animations). Instead of having to re-upload every time for every group/project he/she works on, the user now only needs to take advantage of one of the three solutions posted above (minus the third if the user is not the owner of the group).

But I want to use separate groups because I just like how it feels for me (I realize this isn’t descriptive or anything, but its true - lol) and I don’t want to clog up my main group with random assets etc.

#8

So your problems are:

  • Can’t configure edit access place-by-place, asset-by-asset
  • Can’t share animations
  • Develop page/Inventory are a mess because there is no structure to them

Your use cases would all be resolved by shared group assets, but it’s the wrong tool for the job. Your suggestion identifies fundamental problems with these features, and if we don’t tackle the root problems in favor of one specific use case, other users still experience problems.

Access Privileges:

Scenario: We implement shared assets so developers can use multiple groups to control who gets edit access to which projects

Result: Developers are able to successfully control who gets edit access to which projects, but developers have to give up multiple group slots for a single development group. This does not properly restrict users either, as a clothing maker could change the prices of your gamepasses since they have asset edit permissions. There are also potential problems with removing membership/changing permission for a user in some groups, but forgetting to change them in all the subgroups.

True Solution: Proper access privilege permissions for groups. This addresses your use case of restricting access and the problems shared assets don’t solve. We might also look into a push/pull system where changes are manually approved by those with appropriate permissions to prevent users from nuking your game easily.

Sharing Animations:

Scenario: We implement shared assets so developers can share animations across multiple groups.

Result: Developers can successfully share animations between groups, but cannot for games uploaded to a user’s profile, and the owner of the animation can update it at any point to maliciously impact your game.

True Solutions: 1) Allow animations to be shared like other assets, 2) Allow groups to take assets, 3) Update inventory system so 3rd-party models have to be manually updated by group admin with appropriate permissions.

Develop Page Structure:

Scenario: We implement shared assets so developers can use multiple groups to organize their assets for projects.

Result: Developers are able to successfully organize their assets for projects, but either the test group ends up having assets for every game you make, defeating the purpose, or you create a new test group for every project and waste a tremendous amount of group space. This also does not alleviate the problem for single games with tremendous amounts of assets.

True Solution: A quality-of-life update for the Develop page, which may/may not be included when it’s overhauled. This includes: ability to archive assets so they don’t show up in Develop, ability to search through assets, and potentially the ability to tie assets to projects so it’s easy to find assets you’re looking for.


In conclusion, your use cases are certainly real and important, but we’d probably tackle them in a different way that addresses the root cause so that the benefits extend to more users and we don’t leave other problems lying around.

#9

The solutions you mention are clearly better but for me it’s also a matter of how long it will take to deploy this stuff. My second and third solutions require very minimal changes to the system, possibly taking ROBLOX 1 hour to implement?

What you’re saying, especially the “Develop Page Structure” - the thing I actually care about - require a lot more work. Not only would they have to make new structures to store this stuff, they would have to make designated UIs to display this.

So while what you say is definitely better, I don’t really want to wait 3 months for ROBLOX to implement this. I want it now XD

#10

Unfortunately, nothing in software development is this easy. Just allowing underscores in usernames took six months that we know of. It’s hard to grasp how slow a big company moves unless you’ve actually worked for one, but it’s entirely a matter of resources, prioritization, and stability. Yes, it sucks, but you’re never going to see a feature in a day or two – it’ll usually be months or even a year, regardless of project size.

Stability:

Yes, maybe ROBLOX could make this change in an hour, but would it be stable enough?

First, imagine what it would be like to go back and make a few changes to a game you hadn’t worked on in a year or two. That itself is already painful because the game wasn’t originally designed to support these changes. Now, imagine you continually adding thousands of these changes: your project would eventually turn into an uncontrollable mush. ROBLOX has to spend a lot of time making sure any changes they make don’t inhibit future development.

When the feature is finally implemented, they also have to do rigorous testing afterwards to account ensure millions of users can use the feature without issue. Maybe it wouldn’t be a problem to let this one feature be a little buggy, but if we have thousands of them the platform would be an unstable mess. Testing isn’t as simple as checking to make sure it works on the machine it was developed on. ROBLOX has to make sure a JavaScript feature they used on Chrome doesn’t break on Safari, that a layout which works on the test machine doesn’t scrunch up and become unusable on a smaller PC screen, etc. They have to factor in an insane amount of user variables, and this isn’t a quick process.

Resources & Priority

In any business, there is no free time. Employees are always assigned a project – usually multiple. Because of this, they would have to drop what they’re currently working on to implement another change. Maybe they could make a small change, but how do they determine which small change to make? There are countless smaller features they could work on.

To prevent themselves from constantly working on small changes, ROBLOX makes sure to design feature as best as possible the first time around. If we implement this, we’ll have 10 new feature requests for the remaining concerns that weren’t addressed. Yes, a more complete solution will take longer than any one of those features, but it will be quicker than constantly implementing smaller solutions that weren’t addressed and never being able to work on anything else.

Even once we design a complete solution, we still have other features that are more or equally important, and the feature we proposed has to wait on those.

2 Likes