Local multiplayer game with two remotes?

If it's linked remotes (Bluetooth, WiFi) it can only link one (I believe). But even if you could link two, they would both control the same thing (like two IR remotes, or one person on phone App). If you are talking about a "multiplayer" game where you just take turns, then sure!

Now, there is an interesting option with Apps - RomansXIVIWXVHEC is working on a game using a custom phone app for multi-input that is quite promising! 😄

Exactly the information I was looking for, thank you!

"Komag" wrote:
If it's linked remotes (Bluetooth, WiFi) it can only link one (I believe). But even if you could link two, they would both control the same thing (like two IR remotes, or one person on phone App). If you are talking about a "multiplayer" game where you just take turns, then sure!

Not entirely true. In players that support radio-remotes, you can see Settings / Remote identifies the connected remote as "Remote 1". I just tried and paired another remote to a Roku3 and now have 2 listed: Remote1 = RC03 model (game remote) and Remote2 = RC12 (from HDMI stick). Both work at the same time, i even tried playing my recent creation that way - it made me feel like a Jar'Kai practitioner

Now, i don't know of a way to distinguish the signals between the two remotes. I imagine that's easily fixable if Roku implements for B/S additional method like say roUniversalControlEvent.getSource() as String. And if i was designing this, i'd make it in case of ECP to return the remote app IP (e.g. "remote1" or MAC address for radio remote; "192.168.0.42" when remote app and ummm, "" for IR?) - but in any event to be able to distinguish origins

Ah, didn't know you could pair more than one. But it still ends up like two IR remotes, they just both do the same thing. So in a game where you take turns, at least both players don't have to pass the remote back and forth, and comes with the bonus of being able to sabotage the other player! :twisted:

Roku* - 
can we get a roUniversalControlEvent.getSource() method implemented that allows to distinguish (if we so please) between which remote was used?

Here is what it may return for example:

"infrared"
"ecp/192.168.1.42"
"radio/RC03/cc:6d:f2:a0:00:47"
"radio/RC12/cc:d6:b0:a2:00:21"

Explanation as to "why" in the sample returns - the strings returned by different remotes should be distinct (as possible), so that e.g. a local-multiplayer game can recognize which one it's hearing from. That can't be done with IR remote - but with BT/WiFiD it can include e.g. the MAC address and for remote app it can include the mobile device IP. Bonus:

• In the case of ECP, the IP might be useful for the game to connect back to the remote app (e.g. say it implements touch-pad control and the Roku app wants to tell it something about range or sensitivity; this re channel can "hear" via ECP /input but cannot "speak" back)


• In the case of radio remotes, optionally including the model# in the source info will allow the channel to figure out what extra features the remote has (e.g. motion sensors? mic?). This info is readily available (for viewing, Settings > Remote section)

On possible objection "but there are no games that need that" - it's "the chicken or the egg" dilemma: there aren't multiplayer games to take advantage of this because there is no way to distinguish between remotes as of now. Build it (it's a simple fn) and they will come. On "who has more than 1 remote?" - most everyone has a smart phone or tablet and via Roku remote app you got outright a 2nd remote.

"EnTerr" wrote:
Roku* - 
can we get a roUniversalControlEvent.getSource() method implemented that allows to distinguish (if we so please) between which remote was used?

Feature request noted. 🙂

Woo-hoo!

Brightscript Debugger> ? msg.getremoteid()   ' WFD remote '
WD:0
Brightscript Debugger> msg = wait(0, port): ? msg.getremoteid()  ' 2nd WFD remote '
WD:1
Brightscript Debugger> msg = wait(0, port): ? msg.getremoteid() ' IR remote '
IR:0
Brightscript Debugger> msg = wait(0, port): ? msg.getremoteid() ' ECP remote 192.168.1.49 '
ECP:0
Brightscript Debugger> msg = wait(0, port): ? msg.getremoteid() ' 2nd ECP remote 192.168.1.41 '
ECP:0      ' WTF? '

Well... kinda.

There is no way to tell the IP of the ECP remote, so can't connect back for enhanced services. Moreover, there is no way to distinguish between 2 different ECP remotes, since they all return "ECP:0" (bug? cruel joke?). 

And there is no way for the channel to detect the WFD remote model (and thus it has has A/B buttons or not; does it support motion sensors or not; does it have "replay" or not)

What happened, did the "bonus" part above get "Lost in Translation"?

"EnTerr" wrote:
...
there is no way to distinguish between 2 different ECP remotes, since they all return "ECP:0" (bug? cruel joke?). 

Yes, that's a bug in 7.5.0 firmware.  It will be fixed in a future firmware version.

"RokuKC" wrote:

"EnTerr" wrote:
... there is no way to distinguish between 2 different ECP remotes, since they all return "ECP:0" (bug? cruel joke?). 

Yes, that's a bug in 7.5.0 firmware.  It will be fixed in a future firmware version.

How about giving us the ECP remote IP in the identifier, please?
I justified the usefulness of that above - and while one may "pause" for a moment to ponder about the security implications - on "resume"  :P, there are no security concerns.

Also, to include the radio remote model# in the ID? As pointed earlier - some remotes have "instant replay" and some do not (because of the mic button); some have A/B buttons and others (e.g. HDMI sticks) don't. Let us be able to adapt to that "on the cheap" - yes, an argument can be made perhaps there should be a separate API for that for purity's sake - but KISS - i don't think anyone at the Co needs to generate themselves more work for job security