If I have a server script, and it’s waiting for a remote event to be sent from a server, then why wouldn’t I fire it from the server into the client back into the server?
I thought it was bad practice, but now I’m in a situation where it would just make my life so much easier. Is it okay to do?
I’m basically just talking about reflecting an remote event off a localscript to just allow two servers to communicate together. As long as it doesn’t effect the player, it should be fine right?
In my game I have a lobby system allowing a host to send a remote event (from a localscript) to the server. I also am going to make it so if everyone other than the host clicks ready up, it would also start the server. The problem is I need to do calculations in a different server script to see if everyone has clicked ready up.
So I need two servers to communicate, I’d just use a bindable event. But I need two servers and one localscript to communicate on the same event.
You can use RemoteEvents whenever you like, they are there for a reason, and if it makes your life easier, feel free to use it. Don’t restrict yourself.
If you’re using multiple RemoteEvents for the same thing, or if your RemoteEvent is constantly being fired over and over again (For example, a RemoteEvent being fired every time an object loads), then that would be a bad practice when using RemoteEvents, especially if there is no form of waiting in your script (such as task.wait() for example).
I’d be running a remote event through two scripts just to get server-server communication. This really isn’t bad practice?
To my knowledge, it shouldn’t be. Your situation requires this, so it should be okay. As long as your events aren’t constantly being fired and creating some visible performance issues, you should be okay.
Multiple scripts one script, the backend doesn’t matter unless you’re organization heavy. You future self would enjoy some format, however.