8/22/17 - Edit: Objects return themselves for chaining and methods that don’t execute return partials for reuse.
8/26/17 - Edit: Since objects are tables, they are now callable, so if the developer want to disperse with the words, you can now do this (although the more verbose method is recommended)…
Watch('GameState')('Change')(function (state) print('State is '..state) end)
8/27/17 - Edit: Watch now supports a generic Object class in preparation for being able to watch properties of existing objects (non-function keys of a passed-in table).
8/27/17 (later that day…) - Edit: Watch can now be used to Observe property changes on Tables!
Four Ways to Fire Events
Watch(Noun):Fire(Verb, Args)
Fire - fires the event on both Client & Server
Watch(Noun):FireAcross(Verb, Args)
FireAcross - fires the event to the other side only
Client fires across to Server OR Server fires across to Client
Watch(Noun):FireOnce(Verb, Args)
FireOnce - fires the event to the same side only
Client fires to Client OR Server fires to Server
Watch(Noun, Table)
Returns a proxy table.
Changing the proxy updates the original table.
‘Get’ and ‘Set’ fire events for watched properties only.
local foo = table.prop fires a ‘Get’ event
table.prop = ‘foo’ fires a ‘Set’ event
Event handlers receive 3 arguments on ‘Get’, 4 on ‘Set’
Arguments, in order, are value, key, accessType, oldValue
value = the current value in the table
key = the property name of the table
accessType = the string ‘Get’ or ‘Set’
oldValue = passed on ‘Set’, the value before it was changed
From what I remember, 1 remote used for everything is actually worse, you’re passing the extra argument to identify what the call is for as well as the remote, which when using individual remotes is avoided because its identified by the remote which is already being networked. Not sure if that was a great explanation, sorry.
The original answer to your question was that it was a name for the handle used later to unsubscribe event handlers, but now it just generates a unique handle and returns it.
The API is more concise now, thanks for the feedback. The new syntax is:
Watch('Thing'):On('Event'):Do(callBack)
Watch('Thing'):FireOnce('Event', args) -- Fires only on the side that called it (i.e. Server > Server, Client > Client)
Watch('Thing'):FireAcross('Event', args) -- Fires only the other side (i.e. Server > Client, Client > Server)
Watch('Thing'):Fire('Event', args) -- Fires all (i.e. Same as calling both FireOnce and FireAcross in one call)
It also uses 2 Remote Events now, the Server and the Client each has their own RE to simply notify the other side to fire an Event name if it has one to fire (and passes any arguments). I am interested to see if this will break down easily under load. In single-player, it appears to bootstrap and run faster than the PubSub solution by a small margin.
There isn’t a significant speed defeat. Phantom Forces literally encrypts all data going back and forth with no noticeable speed issue, so I don’t think networking strain will be caused by this lol.
Only if an encryption is used that outputs more data than it gets inputted.
Having 30 characters, which would at most be 40 bytes when encoded or so, is peanuts compared to the replication of parts, physics, … so shouldn’t be a problem. If that extra string leads to trouble, your scripts probably already did something wrong network-wise anyway.
You can still spoof events because you can read read what the client sends anyways? Aim botting also has literally nothing to do with networking, and in terms of networking, aimbot shots are exactly the same as regular ppl shooting.
I love this! I have a problem preventing me from using it though.
Currently it seems there’s no way to know which client used FireAcross. It seems like it would conflict with the overall design pattern you’re going for, but would it be possible for the client that called FireAcross to be the first argument passed?
When dealing with RemoteEvents (particularly OnServerEvent), I’m used to the first parameter being the player that fired the event. This makes it easy since I can trust that this player is the correct one I need to be dealing with, and not a spoof. With Watch I would have to explicitly pass in a Player when using FireAcross, and then trust that the client is giving me the right player.
Is this something that could be implemented, or does it go against the module’s design?