Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default project does not build/sync correctly #876

Open
nezuo opened this issue Feb 21, 2024 · 1 comment
Open

Default project does not build/sync correctly #876

nezuo opened this issue Feb 21, 2024 · 1 comment
Assignees
Labels
impact: medium Moderate issue for Rojo users or a large issue with a reasonable workaround. scope: cli Relevant to the Rojo CLI scope: plugin Relevant to the Roblox Studio plugin size: small status: external An external project is the cause of this

Comments

@nezuo
Copy link
Contributor

nezuo commented Feb 21, 2024

If you initialize a new rojo project, build and open it, and then sync it, the patch visualizer will show the following changes:

image

The Baseplate is in a completely different position. The color is also slightly different.

@kennethloeffler kennethloeffler added scope: cli Relevant to the Rojo CLI scope: plugin Relevant to the Roblox Studio plugin size: small impact: medium Moderate issue for Rojo users or a large issue with a reasonable workaround. status: external An external project is the cause of this labels Feb 21, 2024
@kennethloeffler
Copy link
Member

kennethloeffler commented Feb 21, 2024

So, this is a two-pronged issue:

  1. The difference in the baseplate position occurs because BasePart.Position does not serialize to file. The transform information is instead stored in BasePart.CFrame. If the default project specified BasePart.CFrame instead of BasePart.Position, then the serve and build results would match as expected.

    This can be solved by implementing "proxy properties" in rbx-dom: rbx_dom_weak should have a concept of "proxy properties" rbx-dom#277. This feature would reflect information between mutually dependent properties like BasePart.CFrame and BasePart.Position at the DOM layer.

  2. The color difference I still need to look into more... but I suspect it has something to do with BasePart.Color3uint8 (a compact representation for part colors that both Roblox and rbx-dom use and prefer). Setting a part's color to a Color3 will thus always round to the nearest Color3uint8. It may be solvable by implementing a custom setter for BasePart.Color. There might also be something wrong with rbx-dom's rounding implementation!

@kennethloeffler kennethloeffler self-assigned this Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
impact: medium Moderate issue for Rojo users or a large issue with a reasonable workaround. scope: cli Relevant to the Rojo CLI scope: plugin Relevant to the Roblox Studio plugin size: small status: external An external project is the cause of this
Projects
None yet
Development

No branches or pull requests

2 participants