What are its advantages?
To me it seems it only has disadvantages:
-Performance hit? (It cant be free to query for existing parts and figure out how much the new part must be moved)
-Setting the position is more intuitive for new scripters than CFrame. However, because it is not guaranteed to set the position due to the aformentioned behavior, they are forced to use CFrame or deal with the problems that follow.
-To me it seems like an unwanted side effect. You want the part to a precise location. The part doesnt end up in that location. This should be a separate method (:resolvePenetration()? Idk) instead,
-I think this was not restricted to position only but also affected the size property. Same arguments apply. I have trees in my game that grow (So I need to resize the parts), and it was difficult to make it work without the tree turning upside down or jumping by 5 studs…
Therefore I make the following proposal:
Position and Size properties should not have the side effect of resolving penetration with other baseparts by moving the part upwards
A separate method should be introduced to provide that behavior since it can be useful in some cases
*BasePart:resolvePenetration() --A better name would be nice
*BasePart:resolvePenetration(direction) --instead of moving the part up to resolve penetration, you could set the direction
This behavior has caused me (and I believe others too) nothing more than difficulties. The only instance where it has been useful was to use it to do a hacky query to see if a space is free by attempting to position a part there, but that can now usually be done using a region3 query, and it could be done using the :resolvePenetration method anyways if that is added.
It’s fine how it is, or so far as I see it. If someone want to move a part, so that it’s intersecting with other parts within the same space, then they can use CFrame to do so. This just seems like a useless update to me since it can already be accomplished with the current API.
As for your issue with trees, can you not simply resize it then CFrame it back into place?
[quote] It’s fine how it is, or so far as I see it. If someone want to move a part, so that it’s intersecting with other parts within the same space, then they can use CFrame to do so. This just seems like a useless update to me since it can already be accomplished with the current API.
As for your issue with trees, can you not simply resize it then CFrame it back into place? [/quote]
The issue with the trees was that they had multiple unanchored parts, welded together (manually created welds as well as :MakeJoints() welding), and I needed to resize and reposition and reweld all of them without something messing up. Parts randomly being reposioned by roblox when i resize or reposition them didnt help, although it could be avoided.
This isnt an update that would add something new or fix something that is broken, its an update that would make working with roblox a bit more intuitive, not be full of unexpected behavior and surprises and not force everyone to use ugly hacks whenever they want to interact with instances.
Whilst I’m going to sound callous here, I hardly see how it’s unexpected behaviour.
For example, If I were to reposition your physical body to the same position as another person’s body (as in, you walked to it), you would push the other person away or you would stop next to them. You wouldn’t walk through them, or inside of them. So I hardly see how having a part move on top of another, when within the same space as another, is unexpected to any degree.
[quote] Whilst I’m going to sound callous here, I hardly see how it’s unexpected behaviour.
For example, If I were to reposition your physical body to the same position as another person’s body (as in, you walked to it), you would push the other person away or you would stop next to them. You wouldn’t walk through them, or inside of them. So I hardly see how having a part move on top of another, when within the same space as another, is unexpected to any degree. [/quote]
Setting the position is not moving. The physics engine is for moving. If you manually set the position of a part you probably have a good reason to position it to that exact position and you probably dont want it to be moved by roblox to a different somewhat arbitrary position.
:MoveTo kind of makes sense to have that behavior because its used for things where the behavior is usually good (moving characters to spawns etc.)
If we had a :SetPosition for models, it shouldnt do that.
Simply put, its a side effect that is usually undesired, and as such it should be separated from Position and be a separate feature.
The humanoid object is a good example of what happens when you fail to separate these features properly and instead stuff everything together because it happens to be enough in some single use case.
[quote] For CFraming models without setting PrimaryPart:
function translateTo(Model, Position)
Model:TranslateBy(Position - Model:GetModelCFrame().p)
end
[/quote]
Are you implying I actually have a real problem I need to solve instead of just wanting to complain about a relatively insignificant minor aspect of the API that I deem not perfect because I am bored?
This being changed would break an awful lot of things. It would be much better to keep this feature as legacy support and make a method to do what you want.
[quote] For CFraming models without setting PrimaryPart:
function translateTo(Model, Position)
Model:TranslateBy(Position - Model:GetModelCFrame().p)
end
[/quote]
Are you implying I actually have a real problem I need to solve instead of just wanting to complain about a relatively insignificant minor aspect of the API that I deem not perfect because I am bored? [/quote]
yes
I actually like the behavior of changing .Position, because if it were removed the only other way of getting the place-bricks-on-top behavior would be to change the size and thats no bueno
I wanted a method which has this behavior and allows you to set the unit vector along which the part is displaced instead of always up (thought I doubt roblox would bother)
