Moderation repeat false-positives

The following assets are repeatedly being taken down for “misusing ROBLOX systems.” We’re not sure what systems these modules use that we would be misusing.

https://create.roblox.com/store/asset/138213123290899/Guardsman-Loader
https://create.roblox.com/store/asset/125399000917510/Guardsman-V2-Ingame-MainModule
https://create.roblox.com/store/asset/139418294903518/BACKUP-Guardsman-V2-Ingame-MainModule-BACKUP

4 Likes

You should’ve gotten a message in your inbox linking you to here: https://create.roblox.com/docs/en-us/production/creator-store#asset-moderation
but I know it can still be unclear what exactly is violating. In particular, we don’t allow importing remote assets through require, which seems to be done in all three (even if it is a fallback).

2 Likes

Heya! Thank you for the reply, it’s much appreciated. I’m looking over our codebase for the MainModules and I’m not seeing any remote requires in those. The loader is meant to fetch our most up-to-date module, which makes sense why that could get potentially hit.

Update: our MainModule has been taken down again and we’ve run out of appeals. I’m really not sure what to do at this point since we’re using require() but the MainModule has no external requires.


We reviewed the asset moderation rules and saw this clause was recently added. We have long files but none that cause rendering issues in the editor. Mostly just modules that have commands (~1.5k lines) and the client UI framework (~3.5k lines). Are we supposed to split our code into more modules? @riddlemasta

Roblox’s AI automatically does this.

As far as I’m aware like how it’s written in the documentation, and it will be automatically rejected.
Personal experience, I haven’t had this issue, although I would reccomend you try importing trough Microsoft Visual Studio “Rojo” (correct me if I am wrong) scripting third party module. Aswell more reccomended to save your files to your personal computer or cloud backup trough .lua format (if it’s just scripts).
Wishing you luck on getting around of this issue.

We do all of the updates to our MainModule through Git, no matter what we do even the backup module gets taken down even though it’s an extremely stripped down version with barely any functionality.

This is an extremely serious issue. Before I explain let me describe the structure of our system:

The “MainModule” simply requires MainModule.server
The server module requires many different modules from within itself that are part of the system. We slowly removed things from the system and tested to see if it would get taken down by the automod, and adding in this local require made the automod think of it as an external require. Any require from within this module, local or not, is causing our model to be taken down. (this is defined as script earlier in the code, for context.)

and I’m not seeing any remote requires in those

You have this, we don’t allow requires to other asset id’s:

	return require(
		if config.USE_LOCAL_MODULE
			then ServerStorage:WaitForChild("MainModule")
			else config.MAINMODULE_ID
	)
end)

And MAINMODULE_ID = 125399000917510, --// The ID of the MainModule.

Correct that’s within our loader, which we’re working on replacing since yes that would be in violation of the rules. I’m not understanding however why the two MainModules are being taken down alongside the loader.

Ah sorry, I didn’t read all your messages. Let me talk with the team

Apologies for being so persistent on this, one of my devs pinged me with “it’s over” and i started freaking out LOL

No worries, thanks for flagging. The issue should be fixed now. Sorry about all the stress this caused you

Thanks so much!! We appreciate it :slight_smile:

Np. Are these still needed in the backup mainmodule btw? Since external requires are not allowed:

	--// Guardsman - MainModule IDs
	MAINMODULE_ID = 125399000917510,
	BACKUP_MAINMODULE_ID = 139418294903518, 

So we keep a base settings module in the MainModule to make sure there’s no empty values when the system starts. They have no functionality in the system itself. We’ll likely end up removing them once the loader is fixed, since we need to find a better way to distribute it.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.