Apologies if this is in the wrong section I’m not 100% sure what category this would fall into. Onto the bug:
On the Roblox application the DataModel (game)'s name is “Ugc” instead of “Game”. I’ve gotten a few of my friends to test it in their games and they got the same result.
Test game: game "Ugc" test - Roblox
Video:
Hi, have you tried publishing the game (updating it)?
I’m not sure what that would achieve seeing as it’s an issue with the roblox client
To clarify on the intended behaviour here; afaik the DataModel shouldn’t be named “Game” but rather the name of the place itself; for example, in this case it should be named “My Test”. It being named “Ugc” is still not the correct behaviour regardless though.
In studio yes but in game if I remember correctly it should just be Game unless overwritten in studio (I could be wrong about that last little bit).
The game.Name property isn’t replicated between the client and server; and the default-name for it is always “Game” on the server regardless of Studio / RCC state.
I remember using game.Name before to retrieve a place-name; however I was just in Studio so it could have just been Studio behaviour. Back in October, there was an update to the DataModel Community Wiki page to specify the current “Ugc” name behaviour; previously it just said “The instance is named after the place’s title.” which gives me more reason to believe it was the live client behaviour; again I could be wrong though so apologies if I am.
It is very odd (and undocumented) behaviour regardless though, so perhaps the behaviour should be revisited by the Roblox team to make it more consistent.
Thanks for the report! I filed a ticket in our internal database.
Not a bug, you cannot rely on the name of DataModel in the same way you cannot rely on the names of Service Instances and have to use GetService.
Is there a particular reason you cared about the name of the DataModel?
As of now I have no reason as I’ve completely rewritten the code to follow better coding practices but prior the reason was a couple of my legacy modules broke as it relied upon the DataModules name as a means to filter it out of a cache of Instances (couldn’t tell you why I did it that way).
Is there a reason why it was changed to ‘Ugc’? It seems quite odd to be that of all things given that it doesn’t even unify the server and client behaviour for the property. I’m assuming it refers to the fact that it is possibly a more sandboxed DataModel than some other one used elsewhere?
At least in my case, I have previously used game.Name to retreive the place-name; that was previously the behaviour on the client and I can only assume some of my older projects are now returning ‘Ugc’ for the place-name; albeit I don’t maintain those projects anymore so I don’t really have the bandwidth to go back and check/update them.
It’s been a while since I’ve taken a look at the behaviour of this, but given my previous wording in a reply, this also seems to create a difference between the Studio and the live client behaviour, which presumably now each have a different game.Name value, not ideal for debugging; especially given the fact that this seemingly isn’t documented.
I was always under the assumption that the main reason we do that is to ensure the service is actually created? Are service names actually considered not reliable and could change in the future, or is this moreso just a reminder that some service names don’t match their ClassName and/or may not be created?
For what reason though? To display it? To decide gameplay behavior based on it? Something else?
The old behavior was incidental and not even reliable depending on the situation.
It’s a little bit different than you might think.
Most of the services you typically want do exist at startup. The reason is rather forwards compatibility: They may not always exist at startup, and there might even be some weird behavior like different scripts getting different copies of the service at some point, who knows. A method being the point of access is a good safety valve because having to tack additional magic onto the highly trafficked and perf sensitive path of “.” access is undesirable.
On the other hand, if you’re writing a library / plugin there’s actually enough weirdly named services out there that you would definitely have issues even with the precreated services if you didn’t use GetService. I believe the main motivation is it being an anti-cheat mechanism.