LIVE - Upcoming Physical Properties and PartMaterial Changes

Separate feature request, but when this feature gets shipped, can we get density of hats to be set to 0.1 so that swimming in water isn’t negatively affected by having hats equipped? Right now you just sink unless you manually resize hats.

Unfortunately, a lot of games don’t do this.

2 Likes

It seems as if @EchoReaper has CanCollide true, while @Khanovich has it false.
On Khanovich’s gif you see that the part goes trough the baseplate a lot.
If CanCollide is true, wouldn’t that lead to some weird results, as the end of the long part hits the ground?

CanCollide was false on my parts as well.

Didn’t seem like it…

I attached two place files and source code – all of them set the parts to CanCollide=false

Your script increases the hierarchy being cloned 2x on every iteration of the loop - so for N iterations you spawn O(2^N) parts. We can’t handle 2^500 parts yet :frowning:

2 Likes

Oooohhhh – right. Oops. I’m also cloning all of the clones that have been parented to that part, so the total mass (with the density set to 0.1) is 819.2 which is around 146 4x1x2 parts of normal density. Didn’t see that. 146 parts moving the CoM of the character forward so much could certainly cause the character to fling.

Wouldn’t a part of the same mass on the back negate the effect?
The character would rotate less smoothly, but with the total added mass of 2.2 … not noticeable pretty sure.

The entire purpose of setting the density is to remove unwanted mass natively without resorting to hacks. No – adding a counterweight is not a solution. It’s a hacky, laborious fix that requires you to calculate the distance the counterweight should be from the character, add said counterweight to the raycast ignore list and mouse targetfilter, and recalculate the distance the counterweight should be from the character every time a different tool is equipped. Setting the density is a much better solution and it would defeat the purpose of this feature to resort to hacks to solve the problem.

I already proposed to allow us to set the mass to 0, but @Khanovich didn’t approve of it.
It would be nice if we could set it to 0, resulting in the following exceptional behavior:

  • The part has no mass, so it isn’t affected by gravity
  • It acts as if CanCollide is set to false, no matter the actual value
  • It still works with welds, basicly just being offset of Part0 and not influencing it in any way

I think in the term of physics, it basicly means it has none, except being positioned when welded.

He explained why density couldn’t be set to 0 already.

Because collisions would be impossible.
Hence the “act as if CanCollide is false, no matter what”

This is actually going to make a part of my game dealing with density and friction that I’ve been struggling to perfect easier. Awesome!

This was enabled last night but I’m observing before I make a bigger announcement on Monday.

Known Bugs:

  • You can set Custom Physical Properties Terrain for Humanoids only. (Should have no effect at all at the moment)
1 Like

Thought I’d post some notes on the API:

The property is BasePart.CustomPhysicalProperties. Its type is PhysicalProperties. PhysicalProperties has the following fields:

  • Density
  • Friction
  • Elasticity
  • FrictionWeight
  • ElasticityWeight

A new value of the type can be created with the global function PhysicalProperties.new. It can receive 3 or 5 arguments:

  • PhysicalProperties.new(density, friction, elasticity)
  • PhysicalProperties.new(density, friction, elasticity, frictionWeight, elasticityWeight)

CustomPhysicalProperties may also have a value of nil.

Some examples:

Part.CustomPhysicalProperties = PhysicalProperties.new(0.7, 0.3, 0.5)
Part.CustomPhysicalProperties = nil
Part.CustomPhysicalProperties = PhysicalProperties.new(0.7, 0.3, 0.5, 1, 1)
3 Likes

That’s approximately the number of atoms in the known universe squared.

I’m glad it’s still a “yet.”

2 Likes

If you’re going to fix it, at least make a way to disable the new terrain physics behaviour.

As amusing as this is, it’s not the sort of behaviour I want with terrain in my game.

10 Likes

:confused:

http://i.imgur.com/ewgPhZs.gif

My front-wheel drive, wheel friction 2 cars have terrible handling with this. Super drifty, unresponsive, and awful at hills. Definitely not a smooth default transition.

I’m still trying to figure it out. So far, messing with friction and elasticity on both the ground and the wheels hasn’t really helped much.

There’s this bouncing:


Which the car will do usually also start doing when just driving. I know it’s not an overconstraining issue because it still happens when I strip down the vehicle.

2 Likes

Yeah, I also had to spend quite a bit of time experimenting and re-configuring my game’s cars in order to make them work with these changes. Even then, I wasn’t able to get all the vehicles working as perfectly as they were before the new physical properties.
Try messing with the density on the wheels/other parts of the car as well.

Did you change the friction weight?