I’m not sure how this got here or if it’s intentional but apparently AudioContent is a part of Sound class which was intended to be for AudioPlayer, i got 2 preview buttons and for this to be here, it makes absolutely 0 sense since they both function the same way except for different types of class
This is also the case for pretty much all other properties like Image/ImageContent, Texture/TextureContent, etc.
They will hide the non Content properties at some point
1 Like
Hey @pankii_kust, thanks for the report – we’re transitioning from ContentId properties to Content properties – but looks like there are some growing pains here.
We’ll hide the ContentId properties so that it doesn’t look cluttered in the properties widget
1 Like
To clarify, we will be hiding the non-Content properties after announcing that we will do so on the devforum. The reason we aren’t doing this property-by-property and instead all at once is because there are several other changes that will be impactful to people’s workflows, and we only want to be disruptive once instead of over and over again. In the mean time, under the hood these properties are the same and we automatically convert between Content and AssetId, so you can use either (though I personally would advocate to start using Content if you aren’t already!)
Will it look like this?
And instead of:
whateveryoursoundnamemaybe.SoundId = "17637432983"You’re advised to use:
whateveryoursoundnamemaybe.AudioContent = "17637432983" 
If so, will .SoundId in scripts still work?
Roblox in the past has had backwards compatibility for these kinds of things. The script instance uses Script.Enabled now but code with Script.Disabled will still work.
1 Like
That looks correct! You’ll have to do blah.AudioContent = Content.fromAssetId(17637432983) for now as well, but we’re interested in looking at whether only assigning the string is useful. SoundId will work in scripts, but it’ll become deprecated, which means it won’t be suggested by studio going forwards.
1 Like
Please don’t do this. Auto-coercion is such a pain to deal with and is the cause of so many subtle bugs. I’m actually annoyed with StyleRule:SetProperty now doing something similar. I’d much rather live with the verbosity than deal with “when you assign it a string it secretly constructs a Content”.
I’m also pretty sure this isn’t possible to type-check. The ‘read’ type of the property would be Content but the ‘write’ type would have to be Content | string to permit assigning it to a string, which isn’t possible without making the class type a union of two extern types.
1 Like