Custom Movement not working correctly

Bugs will be moved here once resolved.

Post » Tue Sep 20, 2011 8:33 am

Since collision polygons are now ready, I immediately attempted to try and create a Sonic-style movement with them by replicating the method Davo showed me for Construct Classic, but I've hit some snags that shouldn't occur, according to the logic, which is, event for event, close as possible to the original (except for using a boolean variable, which doesn't make any difference anyway).

Classic Cap (that works)

C2 capx (that obviously doesn't work)

The main problem:

The rotation sensors don't work, obviously. They don't change position or angle despite the conditions being met. In short, the very first event does not work, period.



Minor problems:

* The 'OnGround' sensor pushes out a bit too much. It doesn't do this in the original cap.

The other problems should be self-evident.

Of course, there are a couple of other problems that aren't bugs and more 'missing features', but...

* There's no 'decelerate' action for the Custom Movement. Why there is none is beyond me, honestly, it's practically necessary for any movement that needs the object to slow down gradually rather than stop on a dime.
* I have to make separate events so the movement would push out of more than one object. Until families are done, a simple 'push out of solid' would suffice.Candescence2011-09-24 10:39:13
B
94
S
37
G
11
Posts: 404
Reputation: 11,275

Post » Sat Sep 24, 2011 10:38 am

Alright, I've updated the capx, and removed all unnecessary events. There are now only 7 events.

The main problem is in the very first event, mainly its actions not working at all, so it shouldn't be hard to figure out what the problem is in debugging.Candescence2011-09-24 10:41:34
B
94
S
37
G
11
Posts: 404
Reputation: 11,275

Post » Sat Sep 24, 2011 10:58 am

Is it THIS bug, perhaps?

Set Position to another object is acknowledged as a bug.zenox982011-09-24 11:03:28
If your vision so exceeds your ability, then look to something closer.
Moderator
B
120
S
28
G
68
Posts: 4,843
Reputation: 48,287

Post » Sat Sep 24, 2011 11:20 am

I just tried that work-around. Doesn't work either, I'm afraid. Long story short, the very first event is not firing, period, for absolutely no reason. And I know for certain that the conditions are working fine, too, but...Candescence2011-09-24 11:21:39
B
94
S
37
G
11
Posts: 404
Reputation: 11,275

Post » Sun Sep 25, 2011 9:04 am

Yeah, I can definitely say that, as of r58, the very first event of that capx still does not work, period.
B
94
S
37
G
11
Posts: 404
Reputation: 11,275

Post » Sun Sep 25, 2011 12:47 pm

I've taken a quick look at this. I can't see any problems. I see the ball drop to the ground and stop, that's all. What are you expecting to happen? I'm not Davo, and Davo wrote the Classic custom movement, so none of this is obvious to me I'm afraid, you're going to have to spell out what you're expecting to happen.

I see the ball drop and then onGround is true and the Custom Movement's dx and dy are both 0 (because it has stopped). I don't know what Davo did in Classic, but in the HTML5 custom movement, if dx and dy are both 0, it doesn't step, because there's nowhere to step to. So the first event will not be running (On CustomMovement Step). Perhaps the Classic custom movement still stepped there?

[QUOTE=Candescence]* There's no 'decelerate' action for the Custom Movement. Why there is none is beyond me, honestly, it's practically necessary for any movement that needs the object to slow down gradually rather than stop on a dime.[/QUOTE]
Isn't 'decelerate' the same as using a negative value for 'accelerate'?
Scirra Founder
B
359
S
214
G
72
Posts: 22,949
Reputation: 178,544

Post » Sun Sep 25, 2011 12:59 pm

Ah, apologies, I guess I should've explained. Here's what's supposed to happen:

1) The spherical sensors, RotSensor1 and RotSensor2, when "OnGround" is true, are supposed to go to the sides of PlayerSprite. This obviously does not happen in the capx.
2) The two sensors push out of solids.
3) RotSensor1 sets its angle towards RotSensor2, which allows PlayerSprite to determine its angle.
4) And from there, PlayerSprite is able to rotate automatically on slopes, Sonic-style.

Hell, I'll even throw in a full capx with all the original events (not stripped down) so you can get a better picture of what's supposed to happen.

In short: Neither of the two RotSensors move at all, therefore the PlayerSprite can't rotate. That's the main problem.

Does this clear things up?

[quote]Isn't 'decelerate' the same as using a negative value for 'accelerate'?[/quote]
Eh, I don't think so. Left is supposed to be the negative value for 'accelerate', while right is the positive, I'm pretty sure.Candescence2011-09-25 13:02:55
B
94
S
37
G
11
Posts: 404
Reputation: 11,275

Post » Sun Sep 25, 2011 2:55 pm

[QUOTE=Candescence]
[quote]Isn't 'decelerate' the same as using a negative value for 'accelerate'?[/quote]
Eh, I don't think so. Left is supposed to be the negative value for 'accelerate', while right is the positive, I'm pretty sure.[/QUOTE]

I can't really help much with the rest of your capx, which seems quite complicated to me right now, I'll maybe get back to it later and try to wrap my head around it, but I can't for now ^^

But on this issue about acceleration I'm pretty sure you're being mistaken.
The way it is coded, acceleration (a certain amount of pixel) is added to the object.

It's not a matter of right/left, but rather a matter of moving forward (positive value)/backward(negative value) (hence negative should decelerate).
The direction depends only on the angle the object is facing.

That's at least how the code of the behavior is supposed to behave from the looks of it.Kyatric2011-09-25 14:56:09
New to Construct ? Where to start

Image Image
Image Image

Please attach a capx to any help request or bug report !
Moderator
B
247
S
85
G
40
Posts: 6,999
Reputation: 57,793

Post » Mon Sep 26, 2011 4:51 am

@Ashley
There are two bugs this exposes:

1. The collision position is not updated when setting an object's position to another object's hotspot.
commonace.js line 107

2. If the "push out at angle" action is used I get a grey preview in firefox. The error console said ux and uy were not declared.   
behaviors\custom\runtime.js line 349

Edit:
Found another bug, the angle used with "push out at angle" needs to be converted to radians.


With those fixed, the example should work better.R0J0hound2011-09-26 05:11:32
B
79
S
24
G
54
Posts: 4,738
Reputation: 40,739

Post » Mon Sep 26, 2011 4:57 pm

[QUOTE=R0J0hound]1. The collision position is not updated when setting an object's position to another object's hotspot.
commonace.js line 107[/quote]
That's been fixed, was also reported in another thread.

[quote]2. If the "push out at angle" action is used I get a grey preview in firefox. The error console said ux and uy were not declared.   
behaviors\custom\runtime.js line 349[/quote]
Oops, missing 'var' keywords which strict mode doesn't like, fixed.

[quote]Found another bug, the angle used with "push out at angle" needs to be converted to radians.[/quote]
Good catch! Fixed for next build.
Scirra Founder
B
359
S
214
G
72
Posts: 22,949
Reputation: 178,544

Next

Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 2 guests