Removing private modules “removes” IP security for private module creators,
Keeping them removes security for game devs who use them and can’t see the source code.
Incorrect. Unless you’re an actual developer, new or not, you should use common sense in which things you allow in your game. Private modules are no exception. Removing this feature destroys user’s rights to protect their intellectual property.
All my modules broke so I suppose this has finally been implemented.
2 Likes
A feature that allowed people to safely import their arenas into my game is now broken, so I’m assuming this update was pushed through?
It also doesn’t work if the module is public, and I don’t possess the module in my inventory.
The update was pushed through today.
4 Likes
Seems like that you cannot use modules that are uploaded inside group A (Modules Storaged + testing group) and require it in Group B (official group with the games). Both groups have the same owner.
How does it work now?
Module must be uploaded in both groups, what can cause confussing and is double upload work.
I would like to see if they add that all modules can be required by all groups owned by the same person/user.
But other than that it’s a good update.
1 Like
How come my game still works? It’s published to a group, but requiring my private modules.
Maybe it works from user to group because we had to take 3 of our games down that require from group to group.
Well now it seems like it’s stopping to work.
It seems like its pretty inconsistent. I don’t see an discernible pattern.
Yes, it does ensure safety, but still, big game devs and company devs do NOT want their code to be stolen. People will claim the code is theirs when really someone else made it. This creates an issue for devs because devs don’t want to release their code, but they don’t want it taken down with this update. I use admins, application centers, nojump scripts, and many more things which all run off private modules. My business will be screwed when this update happens as we use these kinds of things to our advantage to give people the best possible experience.
As a game platform generally targeted at a younger demographic, safety is everything to Roblox.
If this change prevents even one person from seeing something they shouldn’t, it’s a win. Safety will always be #1 for Roblox. Everything else is secondary.
4 Likes
Yes and I completely understand that and support it. There was a comment I made sometime ago about how Microsoft keeps developing microsoft defender. Defender keeps you safe while using microsoft products and safety is one of their number 1 priorities as well. But you know what microsoft gives us that ROBLOX won’t? Microsoft gives users the option to disable defender at their own risk. ROBLOX would NEVER give creators an option to disable this “firewall” and let us explore, browse, and use these module scripts at our own risk.
It’d be nice if groups could buy assets so that devs could buy the MainModule as the group and then being able to execute it without having to update/upload it to the group every single time.
2 Likes
Absolutely agree. I’m using said workarounds and it’s really not fun. I hope Roblox will soon look into providing a solution for this.
2 Likes
You are now comparing an established multi multi MULTI billion dollar corporation to an unintended bug.
I don’t see anything wrong with patching potentially harmful bugs.
This is not “patching a bug”, and I don’t believe its as simple as “patching a bug”. My point is, this is a system that many developers rely upon in the community for the safety and satisfaction of users/customers. Countless groups will be forced to close. Countless games ended. This is not a bug, and it should not be “patched” like you said. This is a system that was exploited by users attempting to do harm to other users. Plus, in your response, you didn’t even acknowledge the fact that ROBLOX isn’t going to provide a way to “disable the firewall” that they are creating. I understand this is in the interest of safety, I understand people exploited this private modules system, and I understand that ROBLOX could have been loosing out on profit because of it. But to disable the system means that a lot of hard work will go to waste unless these developers make their modules open source. Which then, they would loose credit for what they have created. So again, this is not a “bug”. This is a matter of protecting what developers have created while protecting players from potentially harmful scripts. ROBLOX needs to evaluate this issue carefully in order to provide the best possible outcome for all parties, or else this will end in more chaos. Which it already truly has turned into chaos.
It most certainly IS a bug as previously stated by Seranok.
This was never a ‘system’ intended for use the way it was. It was simply a bug with the implementation.
2 Likes
It was NEVER intended in the first place. That’s the definition of a bug. Why don’t you follow my quote link up and read some of his responses in the thread.
I urge you to stop referring to it as a ‘system…’ because it was not. It was a bug.
You can’t fault the company for patching a potentially malicious bug. It’s not their fault that some people found out how to exploit the bug for business opportunities. - like I said before, if this patch prevents even ONE person from seeing something they shouldn’t, it’s a win. Safety always has priority.
- there are also a few feature request threads in #platform-feedback for this that would be a great spot to put your suggestions
3 Likes
As much as it was a bug to begin with, it’s important to note that it became documented behavior. There was a page on the wiki that even helped guide you to making your private modules even more secure. So while it was a bug originally and I entirely agree that it should go, it’s not very fair to play it off like a simple unintended bug being patched.
3 Likes