Skip to content
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

[FEATURE] Support logic for ensuring only one tab executes code #3

Open
whitespine opened this issue Jun 6, 2021 · 3 comments
Open
Labels
enhancement New feature or request

Comments

@whitespine
Copy link

As it stands, if you executeAsUser/AsGM for a user with two tabs open, then both will execute. This is suboptimal if you truly only want one invocation of the helper!

I truly have no idea what the best way to implement this is. Some sort of handshake negotiaion between all foundry notifications? Keepalive notifications to track a "real" tab? Broadcast Channel api to negotiate between tabs on a client side basis]? All have some inherent problems. The first two are network traffic heavy/introduce latency, and the broadcast channel might not work on all browsers (probably doesnt work on electron, but that doesnt matter since you can't two tab electron).

I might be able to look into this myself at some point but atm am busy with lancer system. Would be nice though! We've got some logic that is fairly complex and would benefit greatly from this.

@manuelVo manuelVo added the enhancement New feature or request label Jun 6, 2021
@manuelVo
Copy link
Owner

manuelVo commented Jun 6, 2021

I agree that distinguishing different clients of the same player would be nice.

The Broadcast Channel sounds fun, however it doesn't help if the user logs in from different browsers/devices.

I've been thinking about different protocols to allow detection of connected clients. I've now arrived at one that comes with minimal network traffic overhead while also not introducing any extra lacency in most cases while still being able to detect clients timing out.

The thing that scares me the most about this is that I have no clue how to test such a protocol (especially the edge-cases of it)...

@dmrickey
Copy link

Is this still an issue? Whenever I go to log in to a world, any users currently logged in are grayed out and I can't pick that user. Does that not make this a non-issue?

@manuelVo
Copy link
Owner

manuelVo commented May 18, 2022

There are ways to hack yourself around that limitation and users that do so will experience the described behavior. Logging in as the same user multiple times isn't supported by foundry (hence the grayed-out name), but still mostly works if you actually do it. For that reason this enhancement is low priority, but if it can be implemented without hurting users that use foundry the intended way, it would still be nice to have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants