Physics Suggestions

A few things that'd be nice for the Physics Movement:

Being able to position a physics object to a non-physics object.

So for example, positioning an object to the mouse coordinates, so you can make a brick follow the mouse, and move/slow down with the force of the mouse. So you could use the mouse to pick up an object and wack other objects with it.

I suppose you'd do it by checking where the mouse is, and where the object is, and working out how much force it would need to have moved to that position.

EDIT: Also, with hinges, there seems to be a problem with the Stiffness variable. It crashes if I try and edit a hing-to-object action, and the stiffness value always appears as 0 in the main event sheet editor.

I've fixed a bug editing movement actions for 0.85, so that crash you find should be gone next build (but double-check for me).

At the moment if you change the position of an object with the physics movement it effectively teleports it in the physics world. So continually updating its coordinates to (MouseX, MouseY) means it actually has no velocity, and will teleport inside other objects if you move the mouse over another physics object.

I'm not sure how well it'll work out calculating the forces necessary to accurately reproduce following some coordinates, but I'll give it a shot, it'd definitely be handy. It'd be great to have a platform movement who could go round shoving bricks and such.

So for example, positioning an object to the mouse coordinates, so you can make a brick follow the mouse, and move/slow down with the force of the mouse. So you could use the mouse to pick up an object and wack other objects with it.

I suppose you'd do it by checking where the mouse is, and where the object is, and working out how much force it would need to have moved to that position.

You could do it manually by setting up some "lastMouseX" and "lastMouseY" variables, then check them against the current mouseX and mouseY. You could calculate speed and direction that way, and translate it to the object you're dragging around. Even if you're "teleporting" it to the mouse coord every frame, if you're manually setting it's x and y velocities then other objects will still react to it in a proper way.

As a test, I created two objects and added physics movement to them. Then I made this event:

Always: 
[ul]
	[li]Sprite: Set velocity to (20,0)[/li]
	[li]Sprite: Set X to mouseX[/li]
	[li]Sprite: Set Y to mouseY[/li]
[/ul][/code:u3qrhsk8]

When I move the mouse around, the sprite sticking to it jitters, because it's trying to "escape," but I can drag it into the other sprites and they'll fly off toward the right as if they were hit naturally.  It even calculates the angles of impact correctly, so they're not just flying straight to the right, but angling up or down depending on where they made contact.

If you were fully calculating the speed and trajectory by doing something like comparing "lastMouseX" with "mouseX," you might be able to avoid the jitter that comes with manually updating the velocity of the object you're dragging.

Alternately, when you click to drag an object, you could make it invisible, then position a "dummy object" that matches it at the mouse's xy coord.  Since it's just a regular sprite with no physics, it wouldn't jitter.  Then when you release the object, discard the dummy and make your original object visible again.

With some clever collision routines you could even check to see if there's an object to impact with between lastMouseX and mouseX, and change the mouse position manually to compensate for it so that you're not intersecting things.  Hell, you might even be able to fake velocity, mass, etc. for the mouse itself by manually updating it's coordinates.  I'll have to play around with it some to see what I can come up with.

Awesome cap! I may suggest Scirra to make a default movement as "Physics Platform", that would simplify all that huge block of code.

AHH! Found bug! In the cap, double clicking the 10 event (set velocity) makes colour settings popup.

Also I think this is a bug : why there's a delay when the detector should be in the player position? I mean, jump, and the detector will work like an elastic.

That bug's fixed in 0.85. But that demo is excellent! I'll definitely have to see if I can do something with movements to do that for you! <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

AHH! Found bug! In the cap, double clicking the 10 event (set velocity) makes colour settings popup.

I know, I've been having a problem with that too, I just haven't gotten around to reporting it yet. I should be more on the ball <img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" />

Whenever that happens, I've been having to just delete the action and write it again from scratch. Alternately, you should be able to "soft click" the numbers themselves to change them right on the event line without having to open the edit action window.

Edit:

Doh! Beaten by Ashley.

Also I think this is a bug : why there's a delay when the detector should be in the player position? I mean, jump, and the detector will work like an elastic.

The delay is there because the physics engine is updating before running the events, so there's a bit of a lag. Since it's just detecting when you're on the ground, it shouldn't be too much of a problem. If you were using it to, say, detect if you're stomping on an enemy's head, there would definitely be a problem.

[quote:p9zravng]

Also I think this is a bug : why there's a delay when the detector should be in the player position? I mean, jump, and the detector will work like an elastic.

The delay is there because the physics engine is updating before running the events, so there's a bit of a lag. Since it's just detecting when you're on the ground, it shouldn't be too much of a problem. If you were using it to, say, detect if you're stomping on an enemy's head, there would definitely be a problem.

Well, it's still a bad thing. In MMF2, rearranging your events fixed this bug. Anything for rearranging update priority?

Well, it's still a bad thing. In MMF2, rearranging your events fixed this bug. Anything for rearranging update priority?

I don't think so, at lest not yet.

MMF2 still does the same thing if you use a movement plugin. When I use the Platform Movement Object and set my detectors to it, they lag behind as well, and no amount of rearranging the events fixes that.

You can work around it in MMF2 by setting a separate player sprite on top of your PMO sprite, and then aligning your detectors to the player sprite. The whole package lags behind the PMO, but at least the detectors are updated correctly in relation to the player sprite.

With the physics movement though, if you were to make the physics object invisible and set a player sprite on top of it, you'd get wonky looking collisions.

A physics platform would be great! Also, You could make better looking plattform movements with the physics if you stop the object from bouncing.

The update priority rearranging thing would be fantastic! That's one more thing that mmf didn't have but should have. It's hard to find good workarounds for problems related to that.

[quote:12pya3dv]You can work around it in MMF2 by setting a separate player sprite on top of your PMO sprite, and then aligning your detectors to the player sprite.

Never thought of that. When i wanted a good plattform movement i created a custom movement with fastloops, and moved the detectors on each loop.

I'm not sure how well it'll work out calculating the forces necessary to accurately reproduce following some coordinates, but I'll give it a shot, it'd definitely be handy. It'd be great to have a platform movement who could go round shoving bricks and such.

I don't know how much it would be doable, but more than a "physics platform movement" would be a very powerful feature to have the capability of having 2 movements on the same time, so that you could integrate physics to any movement.

For example, I remember our Magic Racer game.. the engine was enterely made in custom events, and I remember that the most difficult part was to manage the collisions between cars.

In my case, it would have been extremely comfy to be able to integrate to my custom racecar engine a "physics movement" just for this aspect.

In case of somebody using the "racecar movement" (the most of the people actually), it would be pretty easy to tho the same with the feature mentioned above:

• add racecar movement

• add physics movement

• then just play with settings and add custom events as you like

I just realized there should be a "None" option under the Collision Mask property for physics objects.

What would you use a physics object that doesnt collide with anything for? Wouldn't it just fall off the screen if it had gravity?

What would you use a physics object that doesnt collide with anything for? Wouldn't it just fall off the screen if it had gravity?

Forces and torques would still apply to that object... I guess there could be some use, although marginal. Like some decorative objects, like falling leaves in the background that don't interact with the main game. If there is some kind of wind in the game, it could apply the leaves.

What would you use a physics object that doesnt collide with anything for? Wouldn't it just fall off the screen if it had gravity?

Particle effects. That's the major use. And a lot of particle effects don't use gravity.

Also, if there were no physics collisions, you could then test for sprite collisions, which would give you the ability to create detectors for your physics objects, or code your own collision routines instead of using the default physics collisions (which aren't conditionable).

For instance: Make a solid ball that's 32x32, then overlay it with an unsolid ball that's 34x34, give them the same mass, feed them the same velocities, etc. and you have a detector that will follow your ball without lagging behind.