-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Guest doesn't seem to join #40
Comments
Thought I had this working at one point but I've been making lots of changes, must have broken it somehow, need to investigate.. |
Both client and server were instantiated for each window. With deathcap/voxel-fuel@11fea02, the server is only instantiated if window.location.hash is not set (i.e., entered the main page URL directly, instead copying & pasting the baseURL+#roomIDhash it changes to after the page loads), but the game does not fully initialize (even though the client is always instantiated). |
Ref GH-40 deathcap/voxel-engine@dca59e5 Revert remnants of reverted non-atlas texture changes, reduce upstream diff deathcap/voxel-engine@c081cdd Merge branch 'upstream' deathcap/voxel-fuel@11fea02 Don't run a server if location.hash set (client-only) deathcap/voxel-fuel@297df45 Reuse RTC peerID as client ID for voxel-server connectClient() deathcap/voxel-fuel@943bc4d Add needServer() deathcap/voxel-fuel@a4a8623 Change to create a new messenger per connection, createRtcMessenger() deathcap/voxel-fuel@b5ecc65 Test using rtc-signaller-sw for now (cross tab only) voxel/voxel-recipes@e730119 0.1.0 deathcap/voxel-texture-shader@59088f5 Remove obsolete findIndex = find compatibility Commit message generated by https://github.com/deathcap/lmno-cl
As of the above build, this works:
Able to move around and see the avatars updated in both tabs. But, this doesn't work:
The second tab gets stuck (hangs on solid gray) and does not load, unless the first tab's game is started first (but you can start 1st, then reload the 2nd page to join). |
…H-40 deathcap/voxel-fuel@c61a383 Remove client waiting UI when client-only instance connects to remote server, too deathcap/voxel-fuel@2ed7526 Remove button on click - starting a the server instance works deathcap/voxel-fuel@8977120 Fix missing selves deathcap/voxel-fuel@64d9c9f Remove ever dependency; use DOM events directly deathcap/voxel-fuel@418c63c Refactor; add 'host server' button in client-only mode deathcap/voxel-fuel@5bade0c Add ever dependency deathcap/voxel-fuel@5ae0714 setupClientWaitingUI <div> Commit message generated by https://github.com/deathcap/lmno-cl
After much more testing (while working on deathcap/voxel-fuel#11), I believe I've begun to see this problem. Sometimes the client doesn't fully load. Chalked it up to rtc.io/switchboard network problems in the past, but now it even sometimes occurs when using rtc-signaller-sw, a completely local messenger. The last message logged is:
Reloading the page often fixes it (maybe a race condition of some sort?) |
Client-only mode good: https://gist.github.com/deathcap/1c642c49b569682f5937 Interesting difference: after the first 'generators: generated connection constraints', both first report 'rtc-quickconnect: is master, creating data channels: '.. but after the second, the successful case shows: monitor: signaling state: stable, iceGatheringState: new, iceConnectionState: new bundle.js:110940 and the failure instead shows 'rtc-quickconnect: is master, creating data channels: ["test"] bundle.js:110940'. The third 'generators: generated connection constraints' also shows the failure case selecting itself as the master. rtc-quickconnect chooses the 'master' based on a numerically-lower randomly-selected UUID, which could very well explain this discrepancy. |
did you file an issue over on |
@DamonOehlman see above. @deathcap is diagnosing some issues with |
Well I'm not sure its a problem with rtc-quickconnect, more likely a bug in my code :). Will have to investigate further |
I'll definitely take a look and see if I can help with the diagnosis. Might be a couple of days before I get to it though - sorry... |
OK - I've taken a look and yeah I think you are right on the race condition. Rather than implementing your own custom signaller (as per I've created a simple in memory messenger that is used in tests, here: https://github.com/messengers/memory It does start to feel like too many layers of abstraction (you have to pass the messenger to the signaller, which in turn is passed to quickconnect) but it does allow you to switch out components. I'm going to have a play with the voxpopuli and |
Yeah rtc-signaller-sw is a custom messenger, using postMessage/onmessage. Spawns a SharedWorker so it can work across multiple browser tabs, while offline. But I also player have the client & server running in the same page (for the single player case), still communicating over WebRTC, looks like I could use the memory messenger there. (Considering moving towards a more server-centric model, though. Reminiscent of WebSockets, where all the clients talk through a central server – but I like the ability WebRTC gives you of hosting the 'server' in the browser, not to mention SCTP. Since the signaler is for peer discovery if I only have one peer (the server) I'm thinking I might be able to do away with the messenger.. I need to investigate more, but maybe something like https://github.com/cjb/serverless-webrtc) BTW, I have a live demo up at http://deathcap.github.io/voxpopuli , though I really ought to fix those npm install issues #43 eventually... |
deathcap/inventory-window@114ce81 0.2.4 deathcap/inventory-window@b91e092 Cache scaled images, fix lag clearing image deathcap/itempile@0e90820 0.2.2 deathcap/itempile@1b71f45 Fix splitPile(0) to always return false, not 0 or NaN-count piles deathcap/voxel-fuel@667c3ea Switch to in-memory RTC messenger for now. Ref GH-40 voxel/voxel-land@1997cdf Firefox doesn't support console in web workers Commit message generated by https://github.com/deathcap/lmno-cl
Closing for GH-26 |
If you start a game in one window, then open up a 2nd window with the url from the first window, the 2nd window doesn't start/render the game.
The text was updated successfully, but these errors were encountered: