Legacy GM[Solved] Game Maker physics seem pretty wonky. Any way to fix this?

XirmiX

Member
Have 2 rectangular/square objects, one which is your "playable character" and another which is a wall. Both have physics on. I've added the ability to move for the object you control (and made it Kinematic as well);

When you press up this is the code that get carried out:
if speed != 6
{
speed += 1;
}
else
{
speed=6;
}
When you press down this is the code that gets carried out:
if speed != -6
{
speed -= 1;
}
else
{
speed=-6;
}

Yes, when I finally hit the wall, I hit it but then my object jumps back a few steps (restitution for both objects is set to 0 btw) back and gets stuck for like 3 seconds or so before I can move it again. Is this physics taking their time to calculate what to do? If they're so wonky when it comes to controllable objects, then how can you even incorporate this into a decent game at all?

chance

predictably random
Forum Staff
Moderator
If you're seeing jerkiness and non-physical behavior, then you aren't using box2D correctly.

For example, when you abruptly change an object's speed (other than at creation time), you risk breaking the simulation. Instead, try applying forces and impulses, as you would in the real world. Let box2D control how objects move, in response to those external forces. The same problems can happen when you manually move kinematic objects, which then interact with non-kinematic objects.

Essentially, doing these things can causes discontinuities in the equations of motions that box2D maintains for physics objects.

XirmiX

Member
So from what I'm understanding, what's even the point of having it in Game Maker? I mean, in that case it doesn't work well for games, so why is IT there and not a better physics engine?

Or if I've done something wrong, how could I fix this exactly? The physics statistics of my objects are as follows:
For the controllable object:
Solid: True
Density: 10
Restitution: 0
Collision Group: 0
Linear Damping: 5
Angular Damping: 1
Friction: 5
Sensor: False
Start Awake: True
Kinematic: True

For the wall:
Solid: True
Density: 0
Restitution: 0
Collision Group: 0
Linear Damping: 0.1
Angular Damping: 0.1
Friction: 0.2
Sensor: False
Start Awake: True
Kinematic: False

Also I have little to no clue how much I should set things to work well and not being too bad to a point where collision becoming jerky as the information regarding each of these subjects about physics doesn't give any examples with specified numbers so I could get a better idea of how to balance my object (tank hull and an immovable/indestructible wall object).

Nocturne

Friendly Tyrant
Forum Staff
I suggest that you do the tutorial that is available from the GMS Tutorials startup tab, and also read through the tech blogs I wrote:

http://www.yoyogames.com/blog/69
http://www.yoyogames.com/blog/70
http://www.yoyogames.com/blog/71

Also note that you should NOT be using the "solid" flag on the objects (or ever, imho!), nor speed, nor direction, etc..., and that when you use physics you are switching to a different system of movement and control that requires thinking about things in a different way. The physics engine in GMS works VERY well indeed, but it does require a bit of a paradigm shift to use....

Last edited:

csanyk

Member
Have 2 rectangular/square objects, one which is your "playable character" and another which is a wall. Both have physics on. I've added the ability to move for the object you control (and made it Kinematic as well);

When you press up this is the code that get carried out:
if speed != 6
{
speed += 1;
}
else
{
speed=6;
}
When you press down this is the code that gets carried out:
if speed != -6
{
speed -= 1;
}
else
{
speed=-6;
}

Yes, when I finally hit the wall, I hit it but then my object jumps back a few steps (restitution for both objects is set to 0 btw) back and gets stuck for like 3 seconds or so before I can move it again. Is this physics taking their time to calculate what to do? If they're so wonky when it comes to controllable objects, then how can you even incorporate this into a decent game at all?
You should never mix the old GML variables for speed, etc, with the Box2D variables. Look up the docs articles on physics, and learn about using the phy_* variables.

chance

predictably random
Forum Staff
Moderator
So from what I'm understanding, what's even the point of having it in Game Maker?
That's your problem: you aren't understanding. The issues you're having aren't the fault of box2D, but rather how you're using it. I find box2D to be well-behaved and stable, when used correctly.

Read some tutorials, as Nocturne suggested. Start out with a few simple objects, and get some experience controlling them with applied forces. Don't use kinematic objects. This will build up your "tool box". Eventually, you'll feel comfortable using box2D, and you'll be happy with the results.

So don't give up.

FrostyCat

Member
The point of having it in GMS is to make it easier to make certain games involving realistic 2D physics. It is not in GMS so that you can have it on all the time for stuff that should have it disabled. It is not in GMS so that you get to skip your physics lessons.

As others have already pointed out, the physics system is a continuously interpolated environment manipulated with impulses and forces. If you find yourself manually setting coordinates or velocities all the time in a particular object or throughout an entire project, that is your cue to not use the physics system. Sudden instantaneous changes like these are not physics-compliant behaviour, and the Manual has clear warnings on that.
The Manual introduction for the physics system said:
• Try not to move instances from one point of the room to another in any way other than using the physics functions (ie: do not set the x/y coordinates manual). Although this can be done and in some circumstances it may be necessary, this is generally to be avoided due to the unpredictable results that it may have on the physics engine, especially when trying to resolve collisions.
...
• To prevent instabilities in the physical simulation Box2D constrains to upper limits the amount a body may rotate and translate within a single update. The apparent limitations will vary according to the accuracy of the physical simulation in accordance with the number of updates and update speed of the physics world, and also in accordance with the physics world scaling. This means that (for example) if you have a world update speed of 60, the maximum movement speed would be 20.
Your complaint about the Manual not giving concrete numbers is just plain dumb. The exact visual outcome of a force or an impulse varies with a fixture's mass and centre of gravity, the pixel-to-metre ratio of the physics world, existing velocity and acceleration, and where it is applied. If you aren't willing to do your part and get a clue what J=mΔv or F=ma are, you have no business whining about the physics system not doing what you want.

XirmiX

Member
Okay, I learnt a little bit about physics and for the sake of getting what I want to do, I would need to attach a force to my object, which I then can control via something like the mouse (although my aim is using keys). But for the type of thing I want to do, there's no examples anywhere that I can find (it's also strange that nobody has really bothered to make the type of thing that I've been trying to make and there's no tutorials which demonstrate how to achieve such type of thing. It's mainly platformers or something that is sandbox related with shapes and what not). So, how can I even begin to understand this if there is nothing presented for me? I really don't know. I don't know where to start. The blogs Nocturne were somewhat helpful, although I've not made much progress as far as physics go.

I think I need to put some things clear here:
The reason I decided to add physics is because the collision would otherwise need to be hard-coded/spaghetti coded. And I tried that and it didn't work. The reason for this is because my controllable object can move forwards and backwards, but it can also turn and since its collision box is not a circle (and having it as a circle will not get what I want, so I can't do that) or anything like that but a rectangle... the collision breaks once you try to turn the controllable object towards the static wall object whilst they are colliding. And that is the biggest problem here and why I decided to turn on physics; because the collisions then are done by default and all I need to do is just tweak some parameters, as far as I know. Although with physics on, I have no idea in how to set my object in motion when pressing keys and... what will even happen when I turn the object and make it rotate whilst its colliding with a wall? Will it get stuck? Will it move itself away from it so that it can turn? Will its rotation be slowed down in any way? Or will it simply not be able to rotate in which case hitting a wall with an edge would be pretty much game over for you considering the type of game I want to make (a tank game). And no, it's not one of those tank games where you have a sprite for 4 directions, you move in those directions and just pew pew away; I'm aiming for one where you can turn both your hull and your turret, whilst you can also move your hull (hull having collision with walls and other hulls (other players' hulls) but not the turret).

chance

predictably random
Forum Staff
Moderator
Learning box2D is a lot easier if you're already an experienced programmer. But if your problem-solving skills are still limited, it might be better to postpone box2D until you're more comfortable with basic programming, and comfortable reading the manual about complex functions.

I'm not saying you're not capable of handling box2D. But it sounds like you might be new to GM. So maybe it's better to work out some basic stuff with regular GameMaker functions first.

From your description of the game, it might not need box2D at all.

-- Is it a top-down view, on a level field with obstacles to drive around? If so, you don't really need box2D. Handle the collisions with regular GM functions.
(OR)
-- Does the tank move left-right across irregular (mountainous) terrain, with gravity acting on it? If so, this is a good use for box2D.

MaGicBush

Member
Yea, I had this problem when I started using GMS yesterday. I have not done any sort of coding since I last used GM 6 or 7 I believe it was(around 8-10 years ago now i'd say), and never messed with physics only making basic games using speed, etc. It seems like GMS added some stuff we didn't have back then, or I just never learned it, but I followed through and made a few games after learning GML with a book I bought from the old owner by Mark Overmars or something another if I remember right. I need to brush up and almost start from scratch it seems like I don't remember much lol. At least I still remember the flow, and how variables, and the basics work.

Last edited:

jackhigh24

Member
hay magicbush that book might not help, a lot has changed now in gm studio, physics was not even in it back then, you had to make your own, but your understanding of flow vars and the basics will get you right back on track with a quick flick through the manual, gm studio is the bizz now well getting there anyway.

xirmix do all the little box2d physics demos and tutorials that come with game maker and in a week or 2 you will be looking at this thread and thinking shoot oh well i said that once, now i know

MaGicBush

Member
Yea I didn't think it was in back then, but I couldn't remember for sure. I will definately be starting with the manual and following up with some sources . I have a small head start anyways, and GMS looks pretty amazing with what you can do compared to back then so I am excited and glad I picked up the Pro version on Humble a while back.

Good luck OP! I know it can be daunting, but stick with it and you will learn.

XirmiX

Member
Learning box2D is a lot easier if you're already an experienced programmer. But if your problem-solving skills are still limited, it might be better to postpone box2D until you're more comfortable with basic programming, and comfortable reading the manual about complex functions.

I'm not saying you're not capable of handling box2D. But it sounds like you might be new to GM. So maybe it's better to work out some basic stuff with regular GameMaker functions first.

From your description of the game, it might not need box2D at all.

-- Is it a top-down view, on a level field with obstacles to drive around? If so, you don't really need box2D. Handle the collisions with regular GM functions.
(OR)
-- Does the tank move left-right across irregular (mountainous) terrain, with gravity acting on it? If so, this is a good use for box2D.
I've already explained this... is it that hard to understand?
Up and Down to move in the direction your Hull of the tank is facing or the opposite direction it is facing and Left and Right rotating your tank's Hull, so you could move forwards or backwards in a different direction. Think about how real tanks move irl, or how they move in games like World of Tanks or Tanki Online. Now imagine those games being 2d; they would be top-down, right? Now, the tanks wouldn't start going left or right when you press Left or Right key buttons, would they? No; they would start rotating so that you could go in the right or left direction when you press Up or Down.

And yes, I already explained that I tried to hard-code it with just code and not using physics, but it did not work. And Tanki Online and World of Tanks uses physics too... well duh, they're 3D games, but also because when in those games you collide with obstacles with your tank and try to rotate your tank, the games don't glitch out. Instead your tank eith moves, stays in place or does whatever, but all is based on the angle you hit a wall with and what the physics say about that. That is also why I chose to use physics. Now, do you know how to attach keyboard controlled forces to an object? And are there rotation-based forces or it's all just movement based?

FrostyCat

Member
I've already explained this... is it that hard to understand?
Up and Down to move in the direction your Hull of the tank is facing or the opposite direction it is facing and Left and Right rotating your tank's Hull, so you could move forwards or backwards in a different direction. Think about how real tanks move irl, or how they move in games like World of Tanks or Tanki Online. Now imagine those games being 2d; they would be top-down, right? Now, the tanks wouldn't start going left or right when you press Left or Right key buttons, would they? No; they would start rotating so that you could go in the right or left direction when you press Up or Down.

And yes, I already explained that I tried to hard-code it with just code and not using physics, but it did not work. And Tanki Online and World of Tanks uses physics too... well duh, they're 3D games, but also because when in those games you collide with obstacles with your tank and try to rotate your tank, the games don't glitch out. Instead your tank eith moves, stays in place or does whatever, but all is based on the angle you hit a wall with and what the physics say about that. That is also why I chose to use physics. Now, do you know how to attach keyboard controlled forces to an object? And are there rotation-based forces or it's all just movement based?
And that's what chance meant by you having limited problem-solving skills: Implementing this kind of movement doesn't involve the physics system.

Instead of changing hspeed and vspeed, you change direction, image_angle and speed. Instead of adding x and y offsets directly, you add lengthdir_x() and lengthdir_y() offsets. Instead of checking collisions with the original collision mask as-is and staying in-place, you change image_angle by the desired increment before checking and snap back if a collision occurs.

And what's the problem with hard-coding physics? By design, many games need to sacrifice certain laws of physics while keeping others intact --- common victims include mass and density, rotational dynamics and frame-to-frame continuity. This is why game programmers need to be gritty problem solvers, have strong mathematical and scientific backgrounds, and know how to implement physics themselves even when physics engines are available.

XirmiX

Member
And that's what chance meant by you having limited problem-solving skills: Implementing this kind of movement doesn't involve the physics system.

Instead of changing hspeed and vspeed, you change direction, image_angle and speed. Instead of adding x and y offsets directly, you add lengthdir_x() and lengthdir_y() offsets. Instead of checking collisions with the original collision mask as-is and staying in-place, you change image_angle by the desired increment before checking and snap back if a collision occurs.

And what's the problem with hard-coding physics? By design, many games need to sacrifice certain laws of physics while keeping others intact --- common victims include mass and density, rotational dynamics and frame-to-frame continuity. This is why game programmers need to be gritty problem solvers, have strong mathematical and scientific backgrounds, and know how to implement physics themselves even when physics engines are available.
lengthdir_x() and lengthdir_y? I didn't even know that existed. See; the biggest issue for me is finding the right thing I'm looking for. The manual for the engine is so large that to find what I'm looking for would take ages. Should I just take my time of the day, for like a week to look through each and every command and what it does or something?

As for direction and image angle, I already started using those before I started using physics. The collision, as I stated before is the problem here. "Instead of checking collisions with the original collision mask as-is and staying in-place, you changeimage_angle by the desired increment before checking and snap back if a collision occurs." <= not entirely sure what you mean by that. And I read about lengthdir_x on the manual and it did not make any sense to me whatsoever.

P.S. I also realize I've misunderstood what Hard-coded means >_>

Nocturne

Friendly Tyrant
Forum Staff
Can I just say, and please don't take offense, that your approach to the whole problem is wrong? What I mean is that by insisting on having a rotating collision mask, you are creating a whole bunch of issues that really don't have to be there. Just make the collision mask FIXED and rotate the SPRITE as it's drawn. Will that cause a certain amount of clipping in the game graphics? Yes. Will players care? No... In fact, players would EXPECT that since games have been getting built this way since the dawn of time...

It's really worthwhile reading this by Mike D. : http://www.yoyogames.com/blog/32

Note that he wrote the original GTA games, lemmings and a whole host of others, and if he says "Well, personally I've always either stuck with box or radial collisions.... <snip> ...if the gun goes into the background, it doesn't really matter.", then I'd listen.

XirmiX

Member
Can I just say, and please don't take offense, that your approach to the whole problem is wrong? What I mean is that by insisting on having a rotating collision mask, you are creating a whole bunch of issues that really don't have to be there. Just make the collision mask FIXED and rotate the SPRITE as it's drawn. Will that cause a certain amount of clipping in the game graphics? Yes. Will players care? No... In fact, players would EXPECT that since games have been getting built this way since the dawn of time...

It's really worthwhile reading this by Mike D. : http://www.yoyogames.com/blog/32

Note that he wrote the original GTA games, lemmings and a whole host of others, and if he says "Well, personally I've always either stuck with box or radial collisions.... <snip> ...if the gun goes into the background, it doesn't really matter.", then I'd listen.
The game that this is targetted is towards people who are currently playing Tanki Online but are getting fed up with it/have left Tanki Online because of a series of some seriously profit-greedy updates. And they will care about this. And so will I. It won't feel like the original game in its play. If it doesn't do that, then my whole project has no point.

FrostyCat

Member
lengthdir_x() and lengthdir_y? I didn't even know that existed. See; the biggest issue for me is finding the right thing I'm looking for. The manual for the engine is so large that to find what I'm looking for would take ages. Should I just take my time of the day, for like a week to look through each and every command and what it does or something?
You don't need the entire Manual's worth of functions to be an effective GMS user. Just the fundamental ones and the ones you will personally use most often are enough:
• All the control structures under GML Language Overview
• Variable scope
• Basic drawing functions
• Basic file handling
• Math and string functions
• Basic instance properties
• Mouse/keyboard functions
• Basic room and view handling
• Data structures
Add more only when need arises, otherwise you'd just waste time cramming them in and then forget them through disuse.

And like always, there are the Index and Search tabs for the small exceptions. You don't necessarily need to know everything, but you do need to have an inner compass for where things may be.

As for direction and image angle, I already started using those before I started using physics. The collision, as I stated before is the problem here. "Instead of checking collisions with the original collision mask as-is and staying in-place, you changeimage_angle by the desired increment before checking and snap back if a collision occurs." <= not entirely sure what you mean by that. And I read about lengthdir_x on the manual and it did not make any sense to me whatsoever.
I'll show you some code comparisons between 4-direction movement and speed-direction movement, then I want you to re-read my earlier statement and think about where it fits.

In standard 4-direction movement:
Code:
``````var spd = 4;
if (!place_meeting(x-spd, y, obj_wall)) {
x -= spd;
}``````
In speed-direction movement:
Code:
``````var rspd = 5;
image_angle += rspd;
if (place_meeting(x, y, obj_wall)) {
image_angle -= rspd;
} else {
direction = image_angle;
}``````
In standard 4-direction movement:
Code:
``````if (place_meeting(x+hspeed, y+vspeed, obj_wall)) {
//Upcoming coordinate has collision
}``````
In speed-direction movement:
Code:
``````if (place_meeting(x+lengthdir_x(speed, direction), y+lengthdir_y(speed, direction), obj_wall)) {
//Upcoming coordinate has collision
}``````
The parallels are rather easy to draw.

Last edited:

XirmiX

Member
You don't need the entire Manual's worth of functions to be an effective GMS user. Just the fundamental ones and the ones you will personally use most often are enough:
• All the control structures under GML Language Overview
• Variable scope
• Basic drawing functions
• Basic file handling
• Math and string functions
• Basic instance properties
• Mouse/keyboard functions
• Basic room and view handling
• Data structures
Add more only when need arises, otherwise you'd just waste time cramming them in and then forget them through disuse.

And like always, there are the Index and Search tabs for the small exceptions. You don't necessarily need to know everything, but you do need to have an inner compass for where things may be.

I'll show you some code comparisons between 4-direction movement and speed-direction movement, then I want you to re-read my earlier statement and think about where it fits.

In standard 4-direction movement:
Code:
``````var spd = 4;
if (!place_meeting(x-spd, y, obj_wall)) {
x -= spd;
}``````
In speed-direction movement:
Code:
``````var rspd = 5;
image_angle += rspd;
if (place_meeting(x, y, obj_wall)) {
image_angle -= rspd;
} else {
direction = image_angle;
}``````
In standard 4-direction movement:
Code:
``````if (place_meeting(x+hspeed, y+vspeed, obj_wall)) {
//Upcoming coordinate has collision
}``````
In speed-direction movement:
Code:
``````if (place_meeting(x+lengthdir_x(speed, direction), y+lengthdir_y(speed, direction), obj_wall)) {
//Upcoming coordinate has collision
}``````
The parallels are rather easy to draw.
Still does not make any sense to me. I tried what you're presented to me, but all it did is mess up everything; the turret isn't following the hull as it did before, the collisions are still wonky (like, instead of actually colliding, the hull turns to face a different way when colliding and that isn't what I need here). I've understood what the command does and applied it to the projectile, however it makes no sense to me when you try to apply it to collisions.

And the code will get way too jumbled up if I do this via just code and without physics, since there will also be collisions with other tanks and checking whether the opponent is trying to push you back too, rotate into you, shoot at you as well and all of that will just make everything break or too complicated to code. Rather to use physics. So, with that in mind, is there some way I can apply force that is controlled via keyboard keys to the hull? So rotation-based forces and movement based forces?

Edit: The code not working properly was my bad. Though, the collisions still do not work correctly. Like, I put direction = 0; as the action after the if statement. Regardless, I need to use physics.

Last edited:

XirmiX

Member
Okay, so I tried to apply physics and it seems my hull is moving, but... I've applied physics_apply_torque to when you press Left and Right keys and physics_apply_local_force for Up and Down keys, yet... the hull only rotates when I press Up or Down and doesn't move at all. So, the Left and Right keys do absolutely nothing.

FrostyCat

Member
Are you applying torque/force from the right position and direction, at sufficient amounts and for an adequate duration? If not, draw a diagram, figure out what you need and then change the code accordingly.

Are you sure you don't actually need angular/linear impulse instead of torque/force? If not, you need to review your needs.

Are you assigning your non-static fixtures a non-zero density? If not, it won't budge.

Are you disabling phy_fixed_rotation? If not, nothing will get it to spin other than setting phy_rotation explicitly.

Are you acquainted with the principles of classical mechanics, e.g. F=ma? If not, hit the books until you get it.

XirmiX

Member
Are you applying torque/force from the right position and direction, at sufficient amounts and for an adequate duration? If not, draw a diagram, figure out what you need and then change the code accordingly.

Are you sure you don't actually need angular/linear impulse instead of torque/force? If not, you need to review your needs.

Are you assigning your non-static fixtures a non-zero density? If not, it won't budge.

Are you disabling phy_fixed_rotation? If not, nothing will get it to spin other than setting phy_rotation explicitly.

Are you acquainted with the principles of classical mechanics, e.g. F=ma? If not, hit the books until you get it.
1) Yes, I am pretty sure
2) Yes, I am sure
3) I am not assigning anything but the wall a density of 0
4) What the hell is that? Perhaps that's the answer to my issues then, but I've no idea what that is and why it exists.
5) Force = Mass x Acceleration you mean? I'm pretty sure I do. I have also familiarized myself with the physics options, such as density, restitution, collision group, linear damping, angular damping and friction.

Bte, here's the Step event code for the hull as it currently stands:
image_angle = direction;
if keyboard_check(vk_left)
{
physics_apply_torque(-2000);
}
if keyboard_check(vk_right)
{
physics_apply_torque(2000);
}
if keyboard_check(vk_up)
{
physics_apply_local_force(x-64, y, 0, +2000);
}
if keyboard_check(vk_down)
{
physics_apply_local_force(x+64, y, 0, -2000);
}

And here's the statistics/physics statistics:
Visible: True
Solid: False
Persistent: False
Uses Physics: True

Density: 2000
Restitution: 0
Collision Group: 0
Linear Damping: 1000
Angular Damping: 1000
Friction: 500

Sensor: False
Start Awake: True
Kinematic: False

/\ With all of that, the hull isn't moving at all; it's completely static. Also, I couldn't find a way to make rotation instantly reach full speed/instantly stop when you let go of the Left/Right keys with physics enabled; it's either some acceleration/deceleration or it is completely static :/

Edit: The collision box/sprite of the tank's hull is 128 pixels in length (going by X-axis, facing to the right) and ~80 pixels in width (going by Y-axis)

Jezla

Member
What is your pixels/meter ratio? The physical properties seem way too high (density, etc). You're probably not applying enough torque to turn the fixture if it's that dense. If you want it to turn instantly, as a tank would when you're driving, use an angular impulse instead.

T

The Green Dev

Guest
I don't usually use gms' physics because I spend longer coding the game for it when I can code what I'm trying to do without gms' physics. I usually just cant find a use for gms' physics most of the time.

Jezla

Member
Okay, I did some tests based on the info you gave, and my earlier post is correct. With the density you have, assuming a standard 10 pixels/ 1 meter ratio, your tank has a mass of over 204,000! If I make it 18 px/m (thus making it fit the dimensions of an m1 abrams tank, which is about 7 meters long) the phy_mass is well over 600K. A Abrams tank has a mass of about 54,000 kg. Your other properties need to be similarly reduced.

Secondly, the friction of a fixture must be between 0 and 1.

If you're making a top-down tank fighting game, then the physics system will serve you very well, but you have to understand it. There's a learning curve to it, like all things, as I've discovered with my own project that uses physics. You have to learn to think in different terms than regular GM:S methods of manipulating objects and handling collisions. I think you would benefit from some serious time spent in the Physics section of the manual and doing the included physics tutorials.

FrostyCat

Member
Also, I couldn't find a way to make rotation instantly reach full speed/instantly stop when you let go of the Left/Right keys with physics enabled; it's either some acceleration/deceleration or it is completely static :/
Duh, that's exactly what torque does, gradual change when applied over time. If you want instantaneous change, that's angular impulse. Anyone with a real grasp of classical mechanics would know the difference, and you don't seem to be one of them.

XirmiX

Member
Okay, I did some tests based on the info you gave, and my earlier post is correct. With the density you have, assuming a standard 10 pixels/ 1 meter ratio, your tank has a mass of over 204,000! If I make it 18 px/m (thus making it fit the dimensions of an m1 abrams tank, which is about 7 meters long) the phy_mass is well over 600K. A Abrams tank has a mass of about 54,000 kg. Your other properties need to be similarly reduced.

Secondly, the friction of a fixture must be between 0 and 1.

If you're making a top-down tank fighting game, then the physics system will serve you very well, but you have to understand it. There's a learning curve to it, like all things, as I've discovered with my own project that uses physics. You have to learn to think in different terms than regular GM:S methods of manipulating objects and handling collisions. I think you would benefit from some serious time spent in the Physics section of the manual and doing the included physics tutorials.

Does the Pixels To Meters displays "pixels per meter"? I believe my tank is supposed to be have a "medium hull", both in speed, armour and size. The length I am not sure what to have to it exactly... In Tanki Online, it seems like the hull's length is ~5 meters, although Tanki Online 2.0 demo, shows that it's way longer; perhaps ~10 meters long? I'm comparing this with the side of the cars and doors seen in the game. So, I think I'll try to leave it to be 8 meters as 7.5 isn't something 128 pixels divides to. Meaning, in Pixels To Meters, it should be 16.0000, correct (remember that it's length is 128 pixels and width is 80 pixels and the hull by default in the sprite texture is facing to the right)?

Okay, now onto the actual mass of the hull as well as its angular and linear damping as well as friction and shenanigans like that... what do these units represent? Like, if I set Pixels To Meters in my room to 16, what kind of a mass should I have? Remember I want to aim for high numbers here because it's supposed to be heavy and being able to view statistics of the hulls and weapons in my game is also something I'll be looking to implement, so it's quite important.

@FrostyCat I'll look into angular impulse then, thanks for the information. And yes, I am quite new to this, don't judge me for it.

Edit, I changed the stats to be the following and it's STILL static!

///Physics related hull movement code
image_angle = direction;
if keyboard_check(vk_left)
{
physics_apply_angular_impulse(-200);
}
if keyboard_check(vk_right)
{
physics_apply_angular_impulse(200);
}
if keyboard_check(vk_up)
{
physics_apply_local_force(x-64, y, 0, +200);
}
if keyboard_check(vk_down)
{
physics_apply_local_force(x+64, y, 0, -200);
}

Visible: True
Solid: False
Persistent: False
Uses Physics: True

Density: 0.5
Restitution: 0
Collision Group: 0
Linear Damping: 0.5
Angular Damping: 0.5
Friction: 0.5

Sensor: False
Start Awake: True
Kinematic: False

Take in mind that Pixels To Meters is set to 16. So, what am I doing wrong this time?

Last edited:

FrostyCat

Member
Why should we not judge you when you keep begging to bailed out like this, and show no understanding of underlying theory or a willingness to learn it?

The unit used is in the so-called "pixels-to-metre" factor is metres per pixel, and that is clearly documented in the Manual. It's called pixels-to-metre because multiplying a figure in pixels with it gives a figure in metres. You had it backwards.

You said you understood classical mechanics, yet 2 posts later you said you don't understand what damping, friction, etc. do and what units they are in. What kind of understanding does that demonstrate? Grab a textbook, search on Wikipedia, look up notes for physics students --- any reference worth its weight will tell you what these concepts you called "shenanigans" do and what units they are in.

The exact mass is irrelevant as long as it is positive, and forces and impulses acting on it are proportionate. Why else do you think mass shows up in F=ma and J=mΔv? You figure out what change in acceleration or velocity you want, multiply that by the mass, done deal.

We can't bail you out forever. And given how I've asked you to learn classical mechanics before and you still wouldn't listen, I'm out of here. But I'll say it just one more time: You head out to the library, grab a physics textbook, do the exercises on classical mechanics and learn what all those terms mean.

It's sink or swim for you and only you now.

Jezla

Member
1. You don't need image_angle or direction for a physics object. Take it out.

2. You're applying the force incorrectly. Change the local argument to -64 in both places.

3. Don't worry about trying to match real world values. I only used those as an example to show how absurdly out of whack your settings were. What you want if for it to FEEL like a tank, not actually simulate a tank, which is something you can't do in 2D.

4. Don't use magic numbers in your functions. Calculate the impulse or force you need and assign it to a variable, that way if it doesn't "feel" right to you, you only need to make one change.

XirmiX

Member
Why should we not judge you when you keep begging to bailed out like this, and show no understanding of underlying theory or a willingness to learn it?

The unit used is in the so-called "pixels-to-metre" factor is metres per pixel, and that is clearly documented in the Manual. It's called pixels-to-metre because multiplying a figure in pixels with it gives a figure in metres. You had it backwards.

You said you understood classical mechanics, yet 2 posts later you said you don't understand what damping, friction, etc. do and what units they are in. What kind of understanding does that demonstrate? Grab a textbook, search on Wikipedia, look up notes for physics students --- any reference worth its weight will tell you what these concepts you called "shenanigans" do and what units they are in.

The exact mass is irrelevant as long as it is positive, and forces and impulses acting on it are proportionate. Why else do you think mass shows up in F=ma and J=mΔv? You figure out what change in acceleration or velocity you want, multiply that by the mass, done deal.

We can't bail you out forever. And given how I've asked you to learn classical mechanics before and you still wouldn't listen, I'm out of here. But I'll say it just one more time: You head out to the library, grab a physics textbook, do the exercises on classical mechanics and learn what all those terms mean.

It's sink or swim for you and only you now.
Wow, emm... I will say I am not 100% with these physics. That does not mean I don't have the right idea of what acceleration/deceleration, speed, velocity, force, mass etc. are or mean. A lot of it I learnt about in school and can recall. And thank you for clarifying that it's the other way round with pixels and meters (for some reason the phrase "meters per pixel" didn't budge my brain in understanding). I didn't really know much about J=mΔv (no idea why there's a triangle there), so I'll look it up.

I am willing to learn. If I didn't, I would simply forget my whole project completely, which I have not done. I have and will look at tutorials, manual etc. although before I looked at some of them and in my case, they didn't explain much, which is why I asked for information here.

Edit: Looked up "J=mΔv" and I got it. It's something I was quite aware of already tbh.

XirmiX

Member
1. You don't need image_angle or direction for a physics object. Take it out.

2. You're applying the force incorrectly. Change the local argument to -64 in both places.

3. Don't worry about trying to match real world values. I only used those as an example to show how absurdly out of whack your settings were. What you want if for it to FEEL like a tank, not actually simulate a tank, which is something you can't do in 2D.

4. Don't use magic numbers in your functions. Calculate the impulse or force you need and assign it to a variable, that way if it doesn't "feel" right to you, you only need to make one change.
I have seriously no idea what is wrong with my object now. I couldn't find any information on how to properly regular density, friction, anguler/linear damping etc. (I know what they are, but in terms of units, I have no idea how much I need to put where because there is nothing like "pixels/meters per second" anywhere or anything like that). I did everything you said I should do; removed "image_angle = direction;" and changed the numbers to be less humongous as well as changed my Pixels Per Meter in the room to 0.06600. Here's the code and statistics as it stands:
///Physics related hull movement code
if keyboard_check(vk_left)
{
physics_apply_angular_impulse(-5);
}
if keyboard_check(vk_right)
{
physics_apply_angular_impulse(5);
}
if keyboard_check(vk_up)
{
physics_apply_local_force(x-64, y, 0, +5);
}
if keyboard_check(vk_down)
{
physics_apply_local_force(x-64, y, 0, -5);
}

Visible: True
Solid: False
Persistent: False
Uses Physics: True

Density: 0.5
Restitution: 0
Collision Group: 0
Linear Damping: 0.5
Angular Damping: 5
Friction: 0.5

Sensor: False
Start Awake: True
Kinematic: False

For whatever reason, the hull is still rotating instead of moving forward/backward whenever I press Up or Down keys and whenever I rotate the hull, it doesn't start at full rotation speed and doesn't instantly stop when I let go of the keys! But I have gotten rid of the torque and applied angular impulse! WTF?! Other than that, I've gotten the hang of it in terms of numbers. Like, if Density is set to 0.5 (the mass), in the code "physics_apply_local_force" is set to 5 (the force) then the acceleration, based on F=ma would be 10. Quite small atm, but first I need to get the fact that local force acts and angular impulse both act like I've applied torque to them instead >_<

Edit: I tried to use some of the phy functions, but after inspecting the manual a bit more, this is used for instances/objects in physics based world that are either static or do not interact with other forces, which I cannot use for the tank itself because it's supposed to be a dynamic and "physics-reactive" object.

Last edited:

Jezla

Member
Maybe I wasn't clear enough about the local force. Leave out the reference to the x, y coordinates, as the xlocal, ylocal arguments of the function is relative to the x of the object. So:

var force = phy_mass * 5; //replace five with the acceleration you want in meters/second squared.
phy_apply_local_force(-64, 0, force, 0);

You will want to make force negative to go in the opposite direction.

Regarding the impulse, it's behaving as it should, and your confusion tells me that you really haven't put time into understanding how the physics properties affect the objects. Angular impulse just affects the rate of rotation, regardless of any forces currently acting on the object, so if you apply an impulse of 10, you are really setting the rate of rotation to 10. However, while impulse sets the object in motion, the damping is what will stop it. If you want your tank to stop turning when the key is released, increase the angular damping.

In addition, the density property does not indicate the mass of the object, but how dense it is, and is used by the simulation to calculate the phy_mass property. Density = Mass/Volume.

XirmiX

Member
Maybe I wasn't clear enough about the local force. Leave out the reference to the x, y coordinates, as the xlocal, ylocal arguments of the function is relative to the x of the object. So:

var force = phy_mass * 5; //replace five with the acceleration you want in meters/second squared.
phy_apply_local_force(-64, 0, force, 0);

You will want to make force negative to go in the opposite direction.

Regarding the impulse, it's behaving as it should, and your confusion tells me that you really haven't put time into understanding how the physics properties affect the objects. Angular impulse just affects the rate of rotation, regardless of any forces currently acting on the object, so if you apply an impulse of 10, you are really setting the rate of rotation to 10. However, while impulse sets the object in motion, the damping is what will stop it. If you want your tank to stop turning when the key is released, increase the angular damping.

In addition, the density property does not indicate the mass of the object, but how dense it is, and is used by the simulation to calculate the phy_mass property. Density = Mass/Volume.
I just read about phy_mass on the manual and it made no sense to me. Why is this needed here? Although it enabled forwards movement, so thanks for that, however when I set it for the Down arrow backwards (yes, as you said, I set it to be phy_apply_local_force(-64, 0, -force, 0); ) yet still it just rotates instead, strangely. And I thought I needed to set this at the create event, but apparently not (game crashed) so I placed all of this in the step event and it works fine.

Increasing angular damping will simply make the maximum rotation slower (and if it's the same number as the impulse, you will not be able to rotate it at all). Okay, let me demonstrate. Normally, this is what would happen in terms of rotation, right (in terms of, lets say degreese per second or something like that)
0, (rotation key pressed) 2, 4, 8, 16, 32, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, (rotation key released) 32, 16, 8, 4, 2, 0.

What I want happening (and I am pretty sure this is possible when it comes to physics as TO was able to achieve this as well) is:
0, (rotation key pressed) 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, (rotation key released) 0.

And I have not found any means to get this work right when physics are enabled.

Edit: Never mind the part about rotation. I fixed it by increasing damping AS WELL AS force/acceleration though the backwards movement is still a spastically rotational one

Another Edit: Apparently there was a glitch in the way the hull behaved (glitch in the engine I would guess). Everything was left the same and I double checked for that. After I deleted the Down arrow key's code and pasted the Up arrow key's code back in and set the force to -force, everything went as intended. Sincerely thank you, @Jezla . I'll get on with Turret movement now (I seem to have trouble syncing the rotation of both entities in such a way that when Left or Right key is pressed, both the hull and turret move in sync, however whenever Z or X is pressed the rotation is only applied to the turret). Also it seems like physics aren't really working as I wanted to whenever I am at about 45 degrees turned and hit a wall, press the forward backward button (depending on whether the back's or the front's corner has hit the wall) as well as a rotation button; it instead rotates the wrong way and then the whole thing flops with a full front/back edge facing the wall instead of it sliding off to the side. This might become major later on, although for now is fine and I'm not entirely sure if it's possible to change this, since it's physics that are determining this collision. Again, sincerely thank you for your help. And to anyone else who helped me get the movement and collision working almost as intended with physics

Last edited: