#the top is the account i just logged in
1 messages · Page 1 of 1 (latest)
using
public class UGSManager : MonoBehaviour
{
// Start is called before the first frame update
async void Awake()
{
var options = new InitializationOptions();
var profile = Random.Range(0, 10000000).ToString();
Debug.Log(profile);
options.SetProfile(profile);
await UnityServices.InitializeAsync(options);
gameObject.AddComponent<UGSAccountManager>();
gameObject.AddComponent<UGSLobbyManager>();
}
}
``` this my UGS starter, ran originally
{
var resp = new LoginAnonymousResponse();
try
{
await AuthenticationService.Instance.SignInAnonymouslyAsync();
AccountInfo account = new AccountInfo();
account.ID = AuthenticationService.Instance.PlayerId;
account.Token = AuthenticationService.Instance.AccessToken;
account.Username = AuthenticationService.Instance.PlayerName;
resp.accountInfo = account;
Debug.Log($"{account.ID}, {account.Username}");
return resp;
}
catch (Exception e)
{
throw new LoginAnonymousException($"Login anonymous failed, exception= {e.Message}");
}
}
this is account login code, called from another script (before lobby is created, but after UGS is inited)
public async Task<CreateLobbyResponse> CreateLobby()
{
try
{
var resp = new CreateLobbyResponse();
string lobbyName = "MyLobby";
int maxPlayers = 100;
var options = new CreateLobbyOptions();
joinedLobby = await LobbyService.Instance.CreateLobbyAsync(lobbyName, maxPlayers);
Debug.Log($"Created lobby with host id {joinedLobby.HostId}");
lobbyInfo = new LobbyInfo
{
lobbyID = joinedLobby.Id
};
resp.lobbyInfo = lobbyInfo;
return resp;
}
catch (Exception e)
{
throw new CreateLobbyException($"Failed to create lobby, exception={e.Message}");
}
}
finally this is my lobby code
this is basically it
@dim sand not sure if its acceptable to ping in these threads, but just incase you missed or need more info can let me know
That all looks fine to me from only looking at these, seems like your login log and the lobby Created lobby with host id should match
Did you change the format in the log in between? Your initial screenshot didn't show the same log and the screenshot showed a failure on the lobby creation call
How do you make sure the login is completed and successful before calling the CreateLobby?
heres a video to show better
and yeah i changed the logs to be more clear to the reader, here is the code that outputs the relevant pieces
public async Task<LoginAnonymousResponse> LoginAnonymous()
{
var resp = new LoginAnonymousResponse();
try
{
await AuthenticationService.Instance.SignInAnonymouslyAsync();
AccountInfo account = new AccountInfo();
account.ID = AuthenticationService.Instance.PlayerId;
account.Token = AuthenticationService.Instance.AccessToken;
account.Username = AuthenticationService.Instance.PlayerName;
resp.accountInfo = account;
Debug.Log($"SIGNED IN AS {account.ID}, {account.Username}");
return resp;
}
catch (Exception e)
{
throw new LoginAnonymousException($"Login anonymous failed, exception= {e.Message}");
}
}
public async Task<CreateLobbyResponse> CreateLobby()
{
try
{
var resp = new CreateLobbyResponse();
string lobbyName = "MyLobby";
int maxPlayers = 100;
var options = new CreateLobbyOptions();
joinedLobby = await LobbyService.Instance.CreateLobbyAsync(lobbyName, maxPlayers);
Debug.Log($"Created lobby with host id {joinedLobby.HostId}");
lobbyInfo = new LobbyInfo
{
lobbyID = joinedLobby.Id
};
resp.lobbyInfo = lobbyInfo;
return resp;
}
catch (Exception e)
{
throw new CreateLobbyException($"Failed to create lobby, exception={e.Message}");
}
}
this was disabled. reenabling it fixes the issue. but i think unity should have been handling this case regardless of this option.
because i know domain reloading is related to refreshing statics, but a brand new login should already be refreshing all the statics that are in the lobby singleton already... i feel this must be a unity bug
here is proof
@dim sand https://docs.unity3d.com/Manual/DomainReloading.html
i think unity just needs to do this here on statics and it should be ok?
i do start my UGS manager before my first scene loads, BUT that code is still ran after RuntimeInitializeLoadType.SubsystemRegistration. So that cannot be the issue
the setter is inaccessible so i cannot change it
I'll take a look today. I've tested these services with play mode reload options before and they should work correctly but maybe there's a bug
Can you also let me know the version of authentication & lobby you are using?
Okay i was able to reproduce, this is a bug on our side, I'll raise it to the team
Thank you! Is there a way i can track the fix ? This is my first time raising a bug for unity not sure how i can find out when its resolved
There's no public way to track this unfortunately
By the way, if you are using Unity 2022 or Unity 6, we have a prerelease of the multiplayer package available (com.unity.services.multiplayer) which consolidates lobby, relay, matchmaker and multiplay into a single package.
It offers improved workflows to easily find and connect with players and it does not have this bug as far as I can tell.
It is in prerelease so there may be some bugs.
Im on 2022, ill take a look at it, thanks. Im curious if theres any docs on it? Not sure how i missed it as i started integrating with ugs just last week.
And if i cannot track if this is released or not, would it mean only way for me is tracking releases and updating my package until i see that its fixed? Its fine but just checking if theres a better way at all.
Also, i had another ugs related question which i feared could be a pretty costly bug if it ever got to live systems, wondering if you could have any input on it.
I am testing my lobby system with 2 accounts and accidently was calling heartbeat in update function, which gave me rate limit errors, but also kept racking charges and queries to the service. I fixed this issue before it cost me any real money, but my question is that if i can accidentally do this, whats stopping a malivious user from doing this to me? I thought i shouldnt be charged for rate limited requests. Why am i racking qps/bandwith usage for rate limited requests? I asked this in unity forums/this channel and even sent a support ticket but i have t gotten a response so im quite confused. I would really appreciate if you could enlighten me on this
This cost me 3gb of data usage in 2 days from just 2 accounts, meaning in 48 hours these 2 accounts make 13 million requests, that sounds impossible if rate limit was working correctly, as heartbeat rate limit is quite high. So im not sure why rate limited requests are still charging me
My main question is that if im charged for rate limited requests, whats stopping from one bad actor making me spend insurmountable amount of money
Related to the multiplayer services sdk: https://docs.unity.com/ugs/en-us/manual/mps-sdk/manual/get-started
I'll forward your rate limit and cost question to someone more appropriate
Tracking package releases is your best bet for a fix for this issue
awesome. thanks for all the answers!
i also took a quick look at the mps, seems like a great tool that consolidates all the UGS microservices, ill have to explore it more
and thank you very much for forwarding the question also
Can you provide your support ticket # for the rate limiting issue?
#1910476 @dim sand should be this
Thanks
hey @dim sand i got a response from unity. It seems its a bug in the lobby metrics but not affecting costs.
Id like to thank you and Brandon for being so proactive on this issue!
Great to hear and to be able to help.
Let me know if you have feedback on the multiplayer services sdk, we are trying to make multiplayer development much easier and accessible. I hope it helps
ill try to give it a shot whenever I can. Though, one thing I can directly say is the forcing of singletons/statics in multiplayer game SDK's isnt always desirable as some people create their games in a way that they can simulate multiple game instances directly in 1 unity client, and these statics break those possibities right away.
I know theres unity MPPM and achieves most of this by itself, but is still limited to having only 1 hierarchy visible.
I am not actually using NGO for my networking (I am using netick) which enables this functionality with its sandboxes, and manages statics/singletons in its own special way. but these forced singletons from SDKs break that bound.
I also used Supabase before which had a non singleton SDK that was still quite easy to manage and use.
Other than that I am quite new to UGS, so ill have to explore it more and as I gather feedback ill try to highlight it in this discord server.
Finally, the reason it took me so long to try UGS compared to other services (I tried supabase/Steams lobby+relay, and my custom solutions for a bit) was that I was afraid of having no kill switch of any sorts in the sense that if UGS somehow ended up costing a lot for any reason, theres no automated way to shut it down, there are only email notifications I can set up. I already highlighted this to Unity in this discord server and some members(Iain Collins, Evil Otaku) were kind enough to ease my concerns and get me to give UGS a shot, but I think this fear is making many indie developers scared to develop with UGS. So more automated control over spending and cutoffs would go long way to build trust in the product.
That's already great feedback.
For the singleton point, we started adding support for non-static instances of our services for that specific reason
Not all services support it yet but the multiplayer one does.
Instead of using the singleton, you can create a set of services using UnityServices.CreateServices()
Example:
var player2 = UnityServices.CreateServices();
await Task.WhenAll(
player1.InitializeAsync(new InitializationOptions().SetProfile(nameof(player1))),
player2.InitializeAsync(new InitializationOptions().SetProfile(nameof(player2))));
var auth1 = player1.GetAuthenticationService();
var auth2 = player2.GetAuthenticationService();
await Task.WhenAll(
auth1.SignInAnonymouslyAsync(),
auth2.SignInAnonymouslyAsync());```
This will not work with the invidiual multiplayer packages though, only the new one
I hope we can do more controls over spending in the future. There are discussions around that