Physics Suggestions

New releases and general discussions.

Post » Sat Nov 17, 2007 12:58 pm

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.
B
4
S
1
G
5
Posts: 48
Reputation: 1,546

Post » Sat Nov 17, 2007 2:57 pm

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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,630

Post » Sat Nov 17, 2007 11:19 pm

[quote="Dines":u3qrhsk8]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.
[/quote:u3qrhsk8]

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:

[code:u3qrhsk8]
Always:
- Sprite: Set velocity to (20,0)
- Sprite: Set X to mouseX
- Sprite: Set Y to mouseY
[/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.

[quote="Ashley":u3qrhsk8]It'd be great to have a platform movement who could go round shoving bricks and such.[/quote:u3qrhsk8]

Well, you already can if you do it custom. I made a platform prototype where the player input changes the sprite's velocity and such. You can also "kick" objects around. It wasn't terribly difficult, really. It took longer to comment it than it did to make.

Here's a .cap:

[url:u3qrhsk8]http://projectbrimstone.googlepages.com/kickit.cap[/url:u3qrhsk8]

Just one small bug that I can't be bothered with figuring out right now, and that is sometimes the kick collision stops registering. I think it has to do with not defining specifically which object to kick, but I can't be arsed to fix it right now. Even so, it still works pretty well as a proof of concept.
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Sat Nov 17, 2007 11:24 pm

Awesome cap! I may suggest Scirra to make a default movement as "Physics Platform", that would simplify all that huge block of code.
B
2
S
2
G
5
Posts: 512
Reputation: 2,674

Post » Sat Nov 17, 2007 11:27 pm

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.
B
2
S
2
G
5
Posts: 512
Reputation: 2,674

Post » Sat Nov 17, 2007 11:30 pm

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! :)
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,630

Post » Sat Nov 17, 2007 11:31 pm

[quote="SuperV":2nubv4ns]AHH! Found bug! In the cap, double clicking the 10 event (set velocity) makes colour settings popup.[/quote:2nubv4ns]

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 :(

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.

[quote="SuperV":2nubv4ns]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.[/quote:2nubv4ns]

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.
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Sat Nov 17, 2007 11:39 pm

[quote:p9zravng]
[quote="SuperV":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.[/quote:p9zravng]

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]

Well, it's still a bad thing. In MMF2, rearranging your events fixed this bug. Anything for rearranging update priority?
B
2
S
2
G
5
Posts: 512
Reputation: 2,674

Post » Sat Nov 17, 2007 11:46 pm

[quote="SuperV":171kmyac]Well, it's still a bad thing. In MMF2, rearranging your events fixed this bug. Anything for rearranging update priority?[/quote:171kmyac]

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.
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Sun Nov 18, 2007 6:33 am

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.[/quote:12pya3dv]
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.
B
1
G
5
Posts: 20
Reputation: 1,265

Next

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 0 guests