Custom Movement not working correctly

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.

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.

Is it THIS bug, perhaps?

Set Position to another object is acknowledged as a bug.

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...

Yeah, I can definitely say that, as of r58, the very first event of that capx still does not work, period.

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?

* 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.

Isn't 'decelerate' the same as using a negative value for 'accelerate'?

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?

sn't 'decelerate' the same as using a negative value for 'accelerate'?

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.

sn't 'decelerate' the same as using a negative value for 'accelerate'?

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.

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.

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.

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

commonace.js line 107

That's been fixed, was also reported in another thread.

. 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

Oops, missing 'var' keywords which strict mode doesn't like, fixed.

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

Good catch! Fixed for next build.

Well, it's nice to see my example has at least caught some bugs, but there's still the problem of the very first event not working at all. I've tested to make sure. Hell, I moved the text actions from event 3 as a debug measure. Definitely not working.

Well, it's nice to see my example has at least caught some bugs, but there's still the problem of the very first event not working at all. I've tested to make sure. Hell, I moved the text actions from event 3 as a debug measure. Definitely not working.

I think that's related to what I mentioned earlier: at first 'on ground' is false so it doesn't run, but when it lands on the ground it has 0 speed, and when it has 0 speed it never steps so the 'on step' event never runs. So it never sets 'on ground' to true. You probably want a detector or something there.

I'm aware of that, but even when it DOES move (when moving left and right in the full example), it doesn't work either.

Also, I'm pretty sure moving left with "accelerate at horizontal speed -400" and moving right with "accelerate at horizontal speed 400" is how it's SUPPOSED to work, because my attempts to accelerate via angle and decelerate using negative values work FAR WORSE than simply using negative and positive for left and right, respectively - anything else basically results in the PlayerSprite just moving to the left.

Edit: I can definitely say that the problem still isn't fixed in r59.

Disregard my last post. IT WORKS IN r59! Not amazingly, but what the hell, it's a start.