What Problem Does This Solve?
LCK includes default UI (tablets) for user login and streaming setup, but you might want to build your own custom interface that matches your game’s style. You need a way to check if users are logged in, subscribed, and have configured streaming—without using the default tablet UI.ILckCore provides the core authentication and configuration APIs so you can build custom login flows and subscription gates.
When to Use This
UseILckCore when:
- Building a custom login UI instead of using LCK tablets
- Implementing subscription-gated features
- Checking if streaming is configured before showing recording options
- Creating a branded authentication experience
Quick Example
How It Works
Login Flow
- Start login → Get a short code (e.g., “ABC123”)
- Display code → User enters it on a website
- Poll for completion → Check if login succeeded
- Handle result → Proceed with authenticated features
Common Patterns
Complete custom login flow
Subscription gate for premium features
Check streaming configuration before enabling streaming
Conditional feature availability
Dependency Injection
ILckCore is injected using the [InjectLck] attribute:
API Reference
StartLoginAttemptAsync()
Initiates the login process and returns a short code for the user to enter on the login website.Result<string> containing the login code (e.g., “ABC123”)
Example:
CheckLoginCompletedAsync()
Checks whether the user has completed the login process on the website.Result<bool> — true if login completed, false if still pending
Example:
IsUserSubscribed()
Checks if the logged-in user has an active subscription.Result<bool> — true if user has active subscription
Example:
HasUserConfiguredStreaming()
Checks if the user has configured their streaming setup (platforms, keys, etc.).Result<bool> — true if streaming is configured
Example:
Login Flow Best Practices
Display code clearly — Use large, readable font for login code
Show instructions — Tell users where to enter the code (liv.tv/login)
Poll every 2 seconds — Balance responsiveness vs. server load
Set timeout — Don’t poll forever (60-120 seconds reasonable)
Handle errors — Network issues, expired codes, etc.
Good polling pattern
Error Handling
All methods returnResult<T> which can contain CoreError: