1

Hi everyone,

I’ve developed a custom resource stopper that’s been tested (with Cheetos) and is working well. It operates by sending heartbeats through scripts, making resources unstoppable.

However, there’s one catch: you have to manually paste a script into each resource you want to protect.

Before officially releasing it, I wanted to get feedback from the community. Would you find this useful, or is the manual script insertion a dealbreaker?

Looking forward to hearing your thoughts!

  • Yes! For sure upload it!
  • No
0 voters
2

While seemingly a good idea at the start, I will say, there are use-cases where your resources for lack of a better word “Need-to-die” - And I’m not just talking about scripts that aren’t made to be permanent, but there are cases where scripts will die out because you just didn’t account for a particular usecase…

  • missing parameter?
  • Unexpected return value
  • extra entry in a table
  • etc

While I do love the idea of heartbeats and monitoring for your various scripts (that go beyond the server console interface), I want to make a point that the immediate answer to a script dying (either for errors or otherwise) should be to improve the core source-code first and foremost.

And there are plenty of built in mechanisms (although I wish discussed more here) such as promises, pcalls, safe table navigations, and other built in features (depending on your langauge) that can prevent a lot of these ‘script-stoppages’ if infact used correctly.

AND I WANT TO RE-ITERATE, I’m NOT SAYING THIS TO BE A HATER, I think this is a good idea, but just for anyone reading thinking this is the “quick solution” to a script that errors out: You may be inviting other issues into your code by not addressing the root of your problem!

Just my unsolicited, (“Nobody asked me”), twocents…

Edit: And Promises within the forums

3

If your sending events from client to server, what’s stopping a bad client from stopping a resource and keep sending fake heartbeat from his own injected code

4

Assuming this script you add to other resources run a loop in coroutine, even if the resource itself errors on some event or loop the heartbeat will still function

1 Like
5

Sending a fake heartbeat would be possible, but if you create a network of heartbeats, the chance of recovering the resource stopper would be about 1%

6

interesting concept i would like to see how you would execute this cause i have many ideas in mind of how you would :thinking:

7

Aside from the fact that if you send an event every X seconds in every script, you’ll totally screw up your network and probably your players will be kicked off the server for network overflow sooner or later, it’s a total non sense. I can see doing this with an important resource that protects some things on client (like AC resource) and client side controls, but putting it in everything is absolutely a bad use case.

The solution for your problem is to have those heartbeat files in one file, and then put the shared file in the manifest using ‘@script-name/pathtofile’ in each script. That’s better than copying same code across all resources. Another better solution is to check the number of resourcers on the server and client. But there you run into the problem that some resources are server_only and the client doesn’t know about them, so you would have to read the fxmanifests using GetResourceMetadata.

Anyway, when you have delayed events and an overloaded server because dozens of players are sending 200 events to your server every 10 seconds, don’t be surprised.

1 Like
8

Hey, I get where you’re coming from, and I appreciate the feedback! Just to clarify though, the networking part only triggers once when the script is stopped, so it’s client-to-server at that point. While that, everything runs client-side, so it’s not like it’s constantly hitting the server.

That said, I understand the concern about sending events frequently, especially across multiple scripts. My team and I have done some pretty heavy stress testing—spamming events and trying to overload things—and we haven’t hit any major issues with network overflow or players getting kicked off so far.

Still, I totally agree that firing off events every few seconds from all over the place could get messy, especially as things scale up. I’m already looking into centralizing some of these tasks to avoid unnecessary event calls, and using GetResourceMetadata to better manage resources is definitely something that is also a good way to handle it, BUT if you want the direct and fastest way to ban/kick cheaters thats the way of going.

2 Likes
9

https://blue-style-shop.tebex.io/package/6526427
there will come a free demo or something of it but this is the final version of it paid

10

Was this just a big marketing campaign?

Aww I feel duped…

11

yup i think it was, which sucks