There is no way to reduce the speed of the cursor that I am aware of, but I think I know what you need to do.

Set the cursor to hidden, and create a helper sprite with pin behavior

On created, pin the helper sprite to the object sprite (Position only)

Tell the helper sprite set position (Mouse.X,Mouse.Y)

Then, tell the object sprite to move X pixels per second at angle (HelperSprite.Angle)

In this way, the object sprite will follow the hidden cursor at the desired speed.

If you only want to be able to "click" on things that the object sprite is overlapping, you can add that as a condition.

[System] On Start of Layout

[Mouse] Set cursor to None

[Mouse] Set cursor from Sprite

This will turn your cursor into the sprite, that way speed will never be an issue.

Other useful information...

The sprite can not have dimensions larger than 64*64 to be used as a cursor.

The sprite set to cursor will appear as it does in the image editor, not as it does in the layout. Therefore, it will not take scaling/rotating into account.

Also you may wish to include the action "[Sprite] Destroy" following "[Mouse] Set cursor from Sprite" as you will otherwise have a static cursor in your layout which would be an unnecessary object and look odd.

Updates (Things I've tried to solve/working around this issue.)

1. Are changes in the player's velocity not being communicated properly between the peer and host?

Tried enabling physics for the peer and setup transferable velocity x and y values but this did not change anything.

2. Is it related to physics?

Completely removed physics and replaced everything with a custom movement equivalent and got the same result.

3. Is it related to precision/interpolation of transferable values?

Tried maxing out precision and experimenting with interpolation, did not produce anything of value.

4. Did I set something up wrong?

I edited the "Multiplayer Game" example provided by Scirra so that holding "W" (input: 0,1) would cause the peer to accelerate toward their lookaty, lookatx coordinates. This resulted in the same choppy movement I have been experiencing.

5. Does the peer need physics/custom movement enabled?

I tried enabling physics/custom movement for the peer's character, and allowing them to move it alongside input prediction, but it did not change anything.

Does no one know why this is happening?

When connected as a Peer, you will notice that your movement becomes very jagged and jittery while accelerating. Movement will at times also be jagged/jittery while decelerating. I know that this issue is related to changes in the peer's velocity, but I have no idea as to what the actual issue is. I am hoping someone can help me figure out how to remedy this.

The Capx linked below demonstrates the issue.

When running the layout, press the “Join” button to join the game. Your ship will automatically rotate toward your cursor, and you can press “W” to accelerate. There is text at the top of the HUD to let you know whether you are the host or a peer.

https://drive.google.com/file/d/0B9tqOz ... sp=sharing

This is the most accurate version i can make with my simple talents.

https://www.dropbox.com/s/52ic3swmbkd27 ... .capx?dl=0

The angle is always calculated with the same, non outgrowing, distances.

When doing this on the parallaxing layer the little errors get bigger when it gets far away from the layout origin.

The centre of mass is not used. I just can not get it done when using the centre of mass.

The second to last one actually had the least drift, but I think we might be approaching this all wrong. Even if the drifting is caused by the two forces acting on two different points, this issue doesn't exist when using a bounding box or circle and for that reason I'm pretty sure its a bug.

So I filled out a bug report, and hopefully it can be fixed before I lose my mind trying to figure out how to get physics objects using collision polygons to move the way they're supposed.

Thanks again for all your help, I'm going to continue working on this until I find a work around or the bug gets fixed. I've learned some important things about layer coordinates and how the physics engine works through this!

Problem Description

When applying force to a physics object that also uses a collision polygon, the object will not move in the exact direction that it should. How noticeable this drifting effect is depends on the angle you are moving at.

This is not an issue if the object uses a bounding box or circle for collision detection.

Attach a Capx

https://drive.google.com/open?id=0B9tqO ... XBzbGRKOTA

Description of Capx

Puts you in control of a ship which will rotate toward the cursor. Hold "W" to apply force in the direction the ship is facing. There is a background grid which will allow you to easily recognize how the ship is moving in relation to its surroundings.

Steps to Reproduce Bug

• Step 1 Move in any direction. It is most noticeable when trying to follow a grid line up or down.

Observed Result

The ship drifts off course, or follows parallel to the course it should be taking.

Expected Result

The ship should move in a straight line toward the cursor, without drifting in either direction. To see how the ship should be moving, change the collision mask to circle or bounding box.

Affected Browsers

• Chrome: (YES)
• FireFox: (YES)
• Internet Explorer: (YES)

Operating System and Service Pack

Windows 8.1

Construct 2 Version ID

r245

(This has been an issue in previous versions as well.)

Now i understand the problem. I apologize for not getting it earlier.

The reason for this is that the force is pushes from the center of mass and the rotation takes the origin.

But lets first go the path that you started. starting from the collision polygon.

Lets explore the center of mass, see if it drifts.

https://www.dropbox.com/s/6s7ay6vwoxtqb ... .capx?dl=0

It does not. It is pretty stable. But it is a little of do inevitable floating point calculations.

Is that enough to cause a torque when applying a force ?

https://www.dropbox.com/s/s2kl9qpgilaoo ... .capx?dl=0

Darn it, yes it does. So in some way, your guts are right.

Same problem when we use an exact imagepoint ?

https://www.dropbox.com/s/92uz1kof9rsp7 ... .capx?dl=0

Nope, not at all. So it kinda a butterfly effect, a little mathematical error that cause big changes.

I have no idea if it possible to do this better. In real life it is not possible, just less noticeable do the proportions of mass, forces, gravity ..... and so on.

Question remains, is this the cause of the problem we face.

https://www.dropbox.com/s/tb85vpfaawclh ... .capx?dl=0

No, no, i still notice drifting. An that is because the rotation gripes on the origin and the force gripes on an imagepoint that is not the origin. Those forces do not balance out.

But, we can not rotate an object with the center of mass as origin. Well, in a way we can, just set a torque towards the mouse coordinates on that layer. But then i dont know how to avoid the wobbling, the torque will always overshoot a little.

So, we have no other chance (but i am not the smartest in here, maybe someone knows how to stop the wobble) then taking the two system apart. The 'system that rotates in tick steps' and the 'physics system'.

Here goes:

https://www.dropbox.com/s/8tmehuf4r61tc ... .capx?dl=0

Hope this explanation satisfies you.

No worries about the misunderstanding, I really appreciate the input!

There is still some drifting and wobbling, although certainly much less now.

Knowing that this issue is a result of the two forces being applied to two different points gives me something I can work with when it comes to problem solving. However I'm not sure why that is an issue when a collision polygon is being used but not an issue when a circle or bounding box is being used.

Either way I'll get back to you if I ever figure out how to solve this issue completely. Can't help but feel like there must be a simpler way to do this.

You've given me a lot of information to work with, thank you so much

I do not see a collisions setup in that capx. So i do not understand the initial question, still.

About this capx.

Besides a few weird things that you do, i see nothing wrong, or i miss something.

Weird things ? ....

1 In the physics world there is no such thing as an immediately movement, like you rotate that sprite. That will mess things up, got to do things smoothly. (with respect to time).

2 You compare to mouse coordinates that are not on the layer that you are moving, due the parallax. Run it in debug, en click 'mouse', watch the coordinates for the layers, you will understand.

So, if i do those things in a better way .....

https://www.dropbox.com/s/4sqbnd0bjioqe ... .capx?dl=0

..... Do we still have problems ? Do i miss something ?

There is no collision setup because I'm not having a collision issue. The issue is that whenever I use a Collision Polygon for a Physics object, that object will drift or move at a weird angle while moving.

It seems like the capx you provided with mouse coordinates relating to the layer the ship is on and replacing immediate turning with velocity based turning did smooth things out a bit, but the issue remains.

It is most noticeable when trying to follow a straight path while going up or down, the player object will drift along the side of the path you're trying to follow.

Well, strip it to the bare bones, and share the .capx.

https://drive.google.com/open?id=0B9tqO ... mVheVpWUDA

Wouldn't it be easier for you to provide your .capx so we can see exactly what problems you have and hopefully offer clearer assistance?

There's not much to provide, I have the problem even when I strip it down to the bare bones.

The player sprite has the physics behavior and uses the collision polygon. The player sprite rotates toward the position of the cursor, and force is applied to the player sprite in the direction it is facing when "W" is held. The result is that the player sprite will fly crooked/drift when facing in most direction unless I used the bounding box or circle.

I'm making a multiplayer game and am looking into renting a server to host the matches on. The only multiplayer I know how to setup is peer-to-peer, and I am wonder if I should be taking a different approach or if there is a way to make sure the dedicated server is always the host.

The 'faster than its supposed to' thing is because of the density - which is judged by the area of the collision polygon. By reducing the area of the polygon from the bounding box, you decrease the perceived 'mass' of the object.

Unfortunately, I can't explain why you're getting asymmetrical movement problems - it's not something I've come across myself

Good to know about mass calculations, I thought it was based on the size of the sprite. As far as movement is concerned, would you be able to upload an example of a controllable sprite that has both physics and is also using a collision polygon? Something as simple as a sprite that rotates toward the position of the mouse and accelerates while "W" is held would be a big help to me.

I've tried simplifying everything down to the bare bones to try to figure out where the asymmetrical movement is coming from, but I haven't found any leads.