Blocks for changing the physical properties of an actor in runtime

nev

  • *
  • Posts: 384
It would be nice to have blocks which allow to change in runtime all the actor properties found under the Physics tab (in bold the ones I would give more priority):

- Can move
(- Can rotate)   <- Already Present
(- Affected by gravity)   <- Already Present
- Mass
- Angular Mass
- Material
(- Friction)   <- Already Present
(- Bounciness)   <- Already Present
- Linear Damping
- Angular Damping
- Disable Physics
- Auto-Scale Collision Bounds
- Enable Continuous Collision
- Can Be Paused
- Can Be Touched

Nev

Jon

  • *
  • Posts: 17524
What would be the use case for disabling physics at runtime and re-enabling down the line?

unatron

  • Posts: 9
I'd like to second this request. I have an actor that gets heavier and lighter at certain points in the game, and I'd prefer to change the mass than kill the actor and create a new heavier or lighter one. Thanks!

Miasmos Games

  • Posts: 878

Cupcake Bounce

Epic428

  • Posts: 1118
I could see disabling physics work to make a custom pause option. Then you can kill everything at once (pending it retains the values) without interfering with animations, etc. But I can't think of anything else.
James Moore - Official Support & Documentation.
We cannot and will not respond to PM's asking questions. Please make a new thread in the forums if you have any questions, Thank you.
For better support and faster response times, please post your logs regarding any Stencyl related issues. Debug > Logs > Generate Logs

pieceoshu

  • Posts: 2
Sorry if I mention something already implemented but here are some reasons:

Disabling continous collision detection
Disabling always active
Enable/disable touch
Change weight/friction/etc without crazy/patchy workarounds

In particular i have lots of actors that i make two of, one wih actor group and one with tile group, with identical animations that double the amount of space on my atlases. I do this because there are many on the screen at once and i have the tile versions with almost all physics disabled and the actor versions use practically all the phisics properties. It would be nice to make one actor that has a boolean for dynamically turning on all the physics necessary instead of twice the amount of actors with identical behaviors and taking up twice the space on my atlases.

MyChairHasALooIn

  • Posts: 310
I could use this too, I have a visual inventory system in a new project, as stuff gets chucked in the loot bag it piles up in a visually interesting way, the game features no other collision detection, so as the bag fills it causes slowdown.

The player does not need to interact with the contents in any way, and they are tracked in a seperate list. So if I could set all the objects that have fallen in and settled to non-moving then switch off physics for those further down the pile, it would reduce cpu load alot.

A similiar use is one many of you will have seen in action, where bodies that have recently become corpses and settled in their physics induced positionjs of occasionally amusing agony, they are then removed from the physical objects in play and just become decoration.

In another project I used a blood effect that could stick to walls, they have no need to remain physical objects after this has happened.

Xietao

  • Posts: 725
I can think the disabling always active can be done done disabling the behavior that cause it. ???
Free Time:
Monday, Wednesday, Friday: 13h
Tuesday, Thursday, Saturday, Sunday: 7h
Loving Linux...

tabletop

  • Posts: 379
I think some of you are grasping for straws here. I think overall performance fixes would be a better thing to focus on than such specific things like this. Since lets be real, if killing and creating a new actor on the spot that is "lighter" or "heavier" didnt cause so much lag then nobody would even care about this idea.

Hopefully 3.0 preforms better, atleast in its standalone apps.

nev

  • *
  • Posts: 384
Increase in performance is always a good thing. :) But substituting actors is a workaround. Having a mass parameter would make things easier. Besides, a smooth change of the mass would be virtually impossible even with the workaround.