How about this, use nc.call to notify users when another user had entered/exited it's range and have the client register/deregister SOs. I'm not sure that will save much, setting up a SO might be an expensive call. Or perhaps the shared object for each user has a list of users in range that the server just updates.... or would that entire list be sent each time a single item in it is updated?
Naicu Octavian wrote: > >Suppose I only want to send position data to players that are within a > certain range. For example, anyone within 100 "meters". > > Your mileage will vary. If you have 1000 connected users and in each > 100m radius there are only 10 users then nc.call can be a good > decision! but in such a case you can also have a SO for each 100mx100m > sqare radius,etc... .Depends on what you are trying to do! > > On 28/08/07, * Mike* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Good point, Octavian. > Suppose I only want to send position data to players that are within a > certain range. > > For example, anyone within 100 "meters". > > SharedObjects don't really give me that luxury, do they? > I may be forced to use nc.call? > Or, is there another method? > > Is there a version of nc.call that does NOT require a return message? > > Naicu Octavian wrote: > > >I agree with everything said here, but i must add something to > defend > > poor nc.call's :) > > > > Another thing is that with nc.call calls for the server to the > clients > > you can target specific clients. A ns.send sends the info to all > > clients subscribed to that SO. This is a more general issue but > good > > to have in mind when one is developing a private messages > feature for > > example! :) > > > > -- > > Naicu Octavian, > > Project Manager for AVChat > > http://www.avchat.net <http://www.avchat.net> > > > > On 28/08/07, *Storm* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> > wrote: > > > > I agree with everything said here, but i must add something to > > defend poor nc.call's :) > > > > SOs may have a bad behaviour in some extreme cases such as > > updating right before disconnecting and such. I've had to > change > > some functionality from SOs to nc.calls due to this, those "few > > bytes" of the callbacks are pretty useful to ensure that the > > update has been really recieved. Therefor everything has its > > place, even in a one-to-all update scenario. > > > > Cheers > > > > > > On 8/28/07, *Joachim Bauch* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote: > > > > Dominick Accattato schrieb: > > [...] > > > Now, if you were talking about using the > SharedObject.send > > method, you > > > may not need to bubble up to your application code, > but your > > still being > > > sent to all the clients. That being said, you should just > > use the > > > sharedObjects sync functionality anyway. > > > > using so.send or SO syncs even saves you a few bytes > bandwidth > > as for > > nc.call, the client sends back the result of the method > call > > to the > > server (or the server back to the client) which isn't > done for > > SO events. > > Well, just a few bytes ;) but if you have lots of calls... > > > > Joachim > > > > > > _______________________________________________ > > Red5 mailing list > > [email protected] <mailto:[email protected]> <mailto: > [email protected] <mailto:[email protected]>> > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > -- > > > ------------------------------------------------------------------- > > If a man speaks in a forest and his wife is not there, is he > still > > wrong? > > > > _______________________________________________ > > Red5 mailing list > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Red5 mailing list > > [email protected] <mailto:[email protected]> > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > _______________________________________________ > Red5 mailing list > [email protected] <mailto:[email protected]> > http://osflash.org/mailman/listinfo/red5_osflash.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org > _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
