Some SurfaceAppearances seem to be displaying incorrectly. They appear as shiny black meshes. It’s a consistent & reproducible issue on one of our brand games - Raise a Rainbocorn - and is hurting the aesthetic of the experience. The bug doesn’t occur in studio.
Reproduction file: Reproduction.rbxl (66.5 KB)
Steps to reproduce:
Currently heavily affecting 20k concurrent players across our portfolio of games at novaly.net
Jailbreak is part of this too.
Thank you for the Repro file and steps. It helps a lot!
In the placefile you provided the Sphere’s SurfaceAppearance has a color property set to (0,0,0). Do you know why it had the black color? How did you create the placefile and the sphere? Did you copy it from somewhere?
On investigation, it looks like the issue is related to rojo. I checked the original asset files and Color is 1, 1, 1. It becomes 0, 0, 0 when the place is built.
For now I’ll create a script which finds every SurfaceAppearance and sets Color to 1, 1, 1 when the game starts.
We’re reverting the change that caused the issue. Shortly it should not be a problem.
Could you clarify what you mean by built? Do you mean when it’s published?
It’s an issue when the place is built into a single place file with rojo (external tooling), which I assume asimo is also using. Might not be necessary to revert. We can create scripts which manually set all the SurfaceAppearance colors for now.
I see. Thanks for clarifying!
We would need to think how to mitigate it. I am not very familiar with what rojo is doing.
We have reverted the change that was causing this issue.
Howdy. I’m one of Rojo’s maintainers. There’s a bit of context I need to set up to answer what caused this issue and how we need to fix it on our end. Hopefully it’ll help with your end and we can come up with a solution together.
To start, you should know that Roblox’s file format (rbxm/rbxl) is set up so that if one Instance of a class sets a property, all Instances of that class must set it. This means that in our case, if one SurfaceAppearance sets Color, all of them have to set it when serializing. The immediate consequence of this is that Rojo has to choose a default value during serialization because otherwise it wouldn’t be able to serialize properties correctly.
How the default property is chosen is where this issue arose. Rojo keeps a database of property data that includes (among other things) the default value of a property. However, the current version of the database that’s live in Rojo is from release 612. This predates SurfaceAppearance.Color, so we don’t have a default for it set. When this happens, Rojo still needs a default value for properties, otherwise we break entirely. So, we just assign a ‘real’ default value for each datatype. In Color3’s case, it’s 0, 0, 0.
In essence what happened here was that at some point, SurfaceAppearance.Color began serializing and it made it so that all other SurfaceAppearances from before the property needed to have it set. Since Rojo doesn’t know about SurfaceAppearance.Color, the default was set to 0, 0, 0 for them, which is the root of this problem.
Our solution is just to quickly finish up what work we need to and then make a new release with a more updated property database. I’m going to prioritize that and it’ll happen soon if I have my way.
Let me know if you have questions, and I’ll do my best to answer.
Thank you for the details! And thank you for a quick follow up!
Yes, setting the color default value to pure white (1,1,1) should resolve the issue.
We would like to release this feature as soon as possible and so far looks like this is the main outstanding issue the community identified. Do you have an ETA for the new release?
Do I understand correctly that the problem happens when there is a mix of old rbxm/rbxl assets where SurfaceAppearance doesn’t have a color property and new assets where it does?
Would “resaving”/“reserializing” all the assets solve the problem?
That should solve the problem, yes. If it doesn’t, there’s something going on that I’m not aware of and I’d like to know about it. This isn’t a new problem for us though, so it’s unlikely there’s other problems.
My ETA for a new release is “next few days/next week”. We’re a rather asynchronous team, so I have to wait on some people in different time zones to sort out what we need to do before making a new release. Knowing that this a blocker for people will make it a priority for us though, so I’m going to do everything I can to get it done next week at the latest. Sorry that I can’t make more of a guarantee, but I’m the only one that’s employed to work on Rojo and even then I have other responsibilities at my job.
No worries at all. I just wanted to know if we’re taking about days, weeks or months.
Howdy all.
I’ve made a release for Rojo that should fix this issue when Roblox re-enables the feature. You can download it here: Rojo 7.4.2.
You should be able to validate it fixing your problem by running a snippet like this over your place file:
for _, item in game:GetDescendants() do
if item:IsA("SurfaceAppearance") then
if item.Color == Color3.new(0, 0, 0) then
print(item:GetFullName(), "was not fixed! Ahh!")
end
end
end
If this prints anything, please report back. Unless it was deliberate, I suppose.