"Watch" API: Manage Events & Observe Tables

Help and Feedback Creations Feedback
, ,
#1

  • 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

  1. Watch(Noun):Fire(Verb, Args)
    • Fire - fires the event on both Client & Server
  2. 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
  3. Watch(Noun):FireOnce(Verb, Args)
    • FireOnce - fires the event to the same side only
    • Client fires to Client OR Server fires to Server
  4. 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

 

 

No Copylock Example: Watch Module for Roblox Development - Roblox

3 Likes
#2

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.

4 Likes
#3

Actually it’s 10/10.

#4

is it me or is the syntax, especially the When part, actually more confusing than regular :Fire() stuff?

What’s the first parameter of Do for?

1 Like
#5

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.

1 Like
#6

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.

#7

People with bad connections would be affected by the increased networking.

#8

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.

#9

It all adds up in the end. Don’t forget that ROBLOX runs on mobile too which you pay for the data.

#10

I don’t know any sane people who use ROBLOX on GSM/LTE

#11

¯\(ツ)/¯

The data usage doesn’t matter too much, it’s just in this case it’s a public module which imo should be as optimised as it can be.

#12

Is that actually necessary?

#13

Ask StyLiS, lol

#14

Officially changed the version from Alpha to Beta today. Testers Welcome!

Original post has been updated and the sample place as well: Watch Module for Roblox Development - Roblox

#15

Sauce? This sounds very not true :stuck_out_tongue:

I can’t see a good reason to do this? It’s not like it’d stop wall-hackers, aim botters or people that teleport and kill you?

#16

No, obviously. It is to stop people spoofing events and making aimbots / other serious hacks.

#17

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.

1 Like
#18

Update: You can now use Watch to Observe properties of Tables.

local t = Watch('fooTable', {
    foo = 'bar'
})

t:On('foo'):Do(function (v, k, s, c) print(v, k, s, c) end)

t.foo = 'baz'

-- Prints 'baz', 'foo', 'Set', 'bar'
#19

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?

1 Like
#20

I have been back and forth on that idea myself. I’m about to eat supper, but I’ll make the change afterwards. Thanks for the feedback!

1 Like