Kicking players with a loop in an actively circulating game like TMM = “0 out of 16” servers that stop event more players from joining TMM. It would be nice to have the ability to shut down the game completely upon severe damage caused by exploiters.
If there is a possibility of exploiters shutting down servers themselves, Roblox could provide security keys for games so we could only shutdown games after providing a hard-coded key, which is less likely to be extracted due to level restrictions.
Alternatively, you could use filtering, which handles all the non-character exploiting cases and doesn’t require adding yet another feature (not to mention that hardcoded keys to authenticate before using a method is really overengineering things).
Just out of curiosity: How much would you be willing pay me or some other trusted community member to convert TMM to work optimally under filtering? I’m sure that that if the price is high enough someone would be willing to do it for you.
[quote] But he’s right you know.
Mark is always right. [/quote]
Just like I told you that if you learned 100 languages, your life would be easier, and I would be right. Alternatively, Mark Otaris could be a real game developer and know that converting a game to Filtering Enabled is as well a task in the limits of our time and knowledge and that NOT ALL THE TIME it will be beneficial to do it.
Filtering enabled is not a mystery, we all know it. Filtering enabled is not magic either, it’s a very early installment of Roblox game security and is yet very poorly developed for convenient use in many places. I by no matter discourage using Filtering Enabled, but it’s not a “solution to problems” like many think. Some cases may adapt it with fairly little work, other times you’re better off putting your precious time to a better cause. Roblox still has to contribute a lot so we could get rid of exploiters.
If you do everything by yourself - you’re a worker. If you manage to hand out tasks - you’re a businessman.
Poorly developed? It’s everything it needs to be. It prevents client changes from replicating to the server. I’m used to it, so maybe I have the wrong idea here, so please, list things that could potentially make it better and easier for new developers to use.
I wouldn’t benefit much from TMM going Filtering Enabled because I know how to get around the exploiter attacks without it, so the price just couldn’t be high enough for anyone’s interest. Aaand there would be a TMM source leak, not very dangerous to me, but who knows what others could make against me.
Just to answer your question, I’d give it a 40,000 robux. Yeah.
TMM isn’t that complex of a game. I can see you being worried about a source leak of a really complex game, but TMM isn’t exactly difficult to make. Why are you worried about a source leak?
I’d prefer an instance-free way (no remote events / functions) of communicating with server / client.
TMM isn’t that complex of a game. I can see you being worried about a source leak of a really complex game, but TMM isn’t exactly difficult to make. Why are you worried about a source leak?[/quote]
TMM is not complex as a mechanics. On another hand, however, take into matter the marketing solutions put in and you’ve got something that was made from years of experience, lots of thinking.
Oh – that makes much more sense. It is a pain to have to create a remote event/function every time you need one, and I believe the staff are working on that. However, this is your time to shine. Make a feature request for this and contribute back to the community 
“I’d prefer an instance-free way (no remote events / functions) of communicating with server / client.”
I think that people saying this are just making up excuses and haven’t actually tried to do anything much with Remotes. Once you actually get to doing the coding, the fact that you have to make a few Remote objects is such a miniscule portion of the work involved that eliminating it would make little to no difference. The bottom line is that you’re going to have to write a communication protocol, and that’s going to take time no matter what the API for it is, and the Remotes API isn’t much different than any alternative API for it would be.
Age of Glory has ~50 Remote* objects… but it also has 60,000 lines of code. How exactly the communication protocol API is set up doesn’t really matter in the slightest, overall I would say that a mere 3,000 lines out of the 60,000 were devoted to communication handling that could possibly have been avoided with a less secure network model at the cost of lower security. That’s only 5% of the code, which really isn’t much.
[quote] “I’d prefer an instance-free way (no remote events / functions) of communicating with server / client.”
I think that people saying this are just making up excuses and haven’t actually tried to do anything much with Remotes. Once you actually get to doing the coding, the fact that you have to make a few Remote objects is such a miniscule portion of the work involved that eliminating it would make little to no difference. The bottom line is that you’re going to have to write a communication protocol, and that’s going to take time no matter what the API for it is, and the Remotes API isn’t much different than any alternative API for it would be.
Age of Glory has ~50 Remote* objects… but it also has 60,000 lines of code. How exactly the communication protocol API is set up doesn’t really matter in the slightest, overall I would say that a mere 3,000 lines out of the 60,000 were devoted to communication handling that could possibly have been avoided with a less secure network model at the cost of lower security. That’s only 5% of the code, which really isn’t much. [/quote]
The annoyance doesn’t come because it’s simple. The annoyance comes from:
"ugh, have to make another remoteevent. God damnit why can’t I just call eventName:FireServer() and it creates it for me? Having to go out of the script and create another remove event is just an unneeded pain – even the devs agree with that because I’ve seen talk about instanceless Remote* objects.
I just use the selection service and :Get()[1] method and instance a new remote event or function into my selection.
I’ll make it into a plugin later ^^
[quote] “I’d prefer an instance-free way (no remote events / functions) of communicating with server / client.”
I think that people saying this are just making up excuses and haven’t actually tried to do anything much with Remotes. Once you actually get to doing the coding, the fact that you have to make a few Remote objects is such a miniscule portion of the work involved that eliminating it would make little to no difference. The bottom line is that you’re going to have to write a communication protocol, and that’s going to take time no matter what the API for it is, and the Remotes API isn’t much different than any alternative API for it would be.
Age of Glory has ~50 Remote* objects… but it also has 60,000 lines of code. How exactly the communication protocol API is set up doesn’t really matter in the slightest, overall I would say that a mere 3,000 lines out of the 60,000 were devoted to communication handling that could possibly have been avoided with a less secure network model at the cost of lower security. That’s only 5% of the code, which really isn’t much. [/quote]
The main thing that’s stopping me from just taking FE is it’s hacky-ness. I have developed a very big disliking to things that could possibly break. I like my games run without any extra effort on the core systems. For example, creating clientside welds, then waiting for server-side welds and removing them - what are the odds of new welds breaking older welds? What happens when I quickly equip / unequip my weapon several times?
And again, this effort wouldn’t even benefit me or anyone else much due to many custom security systems running on TMM which were made before filtering to adapt to the dangerous exploited environment of Roblox. Maybe a 10%+ in DevEx would actually be worth it? Haha :DDD
o.o
:Get()[1]
what?
I would imagine reading through a script’s source, finding “eventName:FireServer()” and adding an event if it didn’t exist – don’t see where :Get()[1] comes into play.
“Maybe a 10%+ in DevEx would actually be worth it? Haha :DDD”
Yet another thing you could contribute! Please make a feature request thread about that, as I would love for my opinion of you to improve!
I’m a haxor with haxor methods, or else I’m stupid.
I will probably release it tomorrow anyway.
Just to answer your question, I’d give it a 40,000 robux. Yeah.[/quote]
Let me know if you want me to convert it for you. I have been working with FilteringEnabled a lot recently, and it is pretty easy.
“The amount of time needed to go into managing and matching logic/ timing between these scripts is absurd”
That’s not the fault of the Remote* objects though. No matter what the communication API is you’re going to have to put time into doing that. It’s not like there’s a magical API that will get around that while still being secure.
“to the point where it’s more efficient to place them in tools that are given to all players rather than have it be in ReplicatedStorage or whatever.”
What’s wrong with this? If the Remote is associated specifically with that tool, in the tool is the correct place to put that remote. That’s the whole reason that Remotes are objects like they are rather than being some special global Remote Procedure Call construct, it’s so that you can scope them under the instances that they are actually associated with.