I've also had problems with code that uses low level protocol calls
getting data from a connection before the connection has been
completed. I haven't had a chance to investigate to be sure they were
problems with OpenPlay or with my code -- the game in question was
required to ship with a different network layer, so it this case
OpenPlay was only for testing while we waited to the Publisher to
deliver the required network layer to us.
WRT the issue with host ids, I suggest you go ahead and reject the
player, and have them automatically retry in 5 seconds or something.
Presumably that would give the host time to join. You might also look
into why the host is taking longer to join. Is it doing some
complicated game setup before joining that is making it more likely to
join slowly?
I'm not familiar enough with the inner workings of the Net Sprocket
layer to comment on whether it's possible to force the host to join
first within the Net Sprocket code. If you find a way to do it we'll be
happy to consider incorporating it into the main code base.
Hope this helps,
Ed
On Dec 31, 2005, at 3:29 PM,
zmorris@mac.... wrote:
> Hi, I am doing a lot of testing with launching multiple apps on my
> computer, and noticed that sometimes a player joins before the host.
> So the player gets id 1 and the host gets id 2. I am wondering if
> there is a way to make sure that the host always joins first, by
> basically stalling the join requests of the players. I don't want to
> reject the players, just only allow them to join once the host has set
> up the game.
> This really surprised me, because I designed the whole app with the
> idea that the host is always 1. So I am not sure if this is a bug,
> but I can't really go back and reprogram everything now. I am not
> programming for host changed events, and since they aren't implemented
> yet, I really think the host should always be 1. Is there any chance
> this could be fixed, and if so, when's the next release planned? And
> if that's out of the question, any suggestions on how I can go under
> the hood and make the changes :-P
>
> P.S. I have found several "bugs" related to join accepted and player
> joined messages. Sometimes they don't come at all, or they come out
> of order, so I get one of my game messages before I get join accepted.
> I have written a wrapper class around it that inserts player accepted
> and player joined messages so they always come, and then skips them
> when they come from netsprocket, which works ok for now, but I am
> worried about hard to find race conditions involving the player list
> being out of sync with the messages.
>
> Thanx,
>
> -----------------------------------------------------------------------
> -
> Zack Morris Z Sculpt Entertainment This
> Space
>
zmorris@zscu... http://www.zsculpt.com For
> Rent
> -----------------------------------------------------------------------
> -
> If the doors of perception were cleansed, everything would appear to
> man
> as it is, infinite. -William Blake, The Marriage of Heaven and Hell
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Openplay-dev mailing list (
Openplay-dev@list...)
> Help/Unsubscribe/Update your Subscription:
>
http://lists.apple.com/mailman/options/openplay-dev/ezavada%40io.com
>
> This email sent to
ezavada@io.c...
>
>
Ed Zavada
Pixel Dust Games
ed@pixe...
http://www.pixeldustgames.com/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Openplay-dev mailing list (
Openplay-dev@list...)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/openplay-dev/subscriber%40opensubscriber.com
This email sent to
subscriber@open...
opensubscriber is not affiliated with the authors of this message nor responsible for its content.