If you destroy a remoteevent after firing it before the event is called on the client the client fails to receive the event.
The expected behaviour would be the event is fired on the clients and then destroyed.
This only occurs in a server/start server.
Simple repro (11.1 KB)
Is it though? If it’s destroyed, I would expect it to stop any transmissions that are in the process. However, I can see how it would be useful for it to finish flushing out whatever queued event fires have been made.
Why are you destroying them after firing them? It sounds like your system may be designed incorrectly if this is a problem.
Likewise you can’t fire remoteevents that aren’t destroyed but don’t have parents. It’d be nice to be able to, could slightly thwart exploiters and snoopers.
Just a wild guess, but that would kind of indicate that properties (like Parent change, which Destroys does, I think) are handled first, then RemoteStuff, instead of in the order they got triggered. (or for some reason the RemoteStuff gets sent in a later packet?) (TMYK)
Yeah, that’s what i was thinking.
@woot3 The reason I’m destroying it straight after is it is called when i want to ‘destroy’ my admin so the remote event tells the client to cleanup all admin related items.
@Crazyman32 I would expect the actions to occur in the order they were written.
You could easily have a single remote event for all users and just have each client delete it once the event has been received.
Otherwise, you should send a response from the client saying the request was received and then have the server delete it.
Correct, but remote events are asynchronous, thus it can’t be expected that the recipients receive the event triggers right after you make the call. It doesn’t yield until the clients receive it.
The remote needs to be destroyed server-side too though, I could wait until all clients have received it however I feel this is a bug, hence the bug report.
@Crazyman32
That’s true but I still feel that if I call the event first the client should receive the event first. We can only wait and see what the admins say.
If you set a property to A, then B, then C, the replication of it will be in that order too. When you call a RemoteEvent/Function in that order, other peers will receive it in that order too. Seems a bit weird that order is pertained everywhere except invoking remotes VS property/destroy