![](https://attach.openclonk.org/avatars/64-84632.png)
- Limit the maximum speed of Objects. If a Object is faster, it decelerates to it's maximum which is calculated via mass
- Set the maximum limit depending to background type, e.g. Objects in Water (Stone) don't fall done, they are way slower then in free fall
- OnHit: Objects maybe could shake free a bit of earth, if the have reached a certain speed?
![](https://attach.openclonk.org/avatars/126-5136.png)
>If a Object is faster, it decelerates to it's maximum which is calculated via mass
I think terminal velocity would be much better defined by some 'drag' variable. One of the first things you'll learn in physics it that mass is not related to gravitational acceleration (though I believe it does affect momentum).
>Objects in Water (Stone) don't fall done, they are way slower then in free fall
This could also be defined by a drag variable.
>OnHit
There is already the Hit() callback, but you'd have to write a script for displacing terrain.
I'd like to say these are some nice ideas which really could have a beneficial impact on the game. :)
![](https://attach.openclonk.org/avatars/185-9473.png)
P.S. The only thing that made me complain is that I could not explode the "firestone" lying on the ground with a shot from a musket
Which brings us to another thing I tought of once. To be specific - that each object would have a 2d collision 'mesh', that is calculated into terrain collision map for collision checks. On other hand it would require some algorythm to make objects not self-collide. But that could be usefull for defining hitboxes for many objects, eventually clonks as well. Maybe we could use these for marking entrances as well. This way we would have few areas, that can not only be rectangular/anchor based as they are now, but:
Hitboxes - for checking collisions, two types of these - projecticle-only hitboxes and "fully material" ones.
Entrances - two types as well - one for clonks/etc. and second for objects flying in(like lorry)
Other - that for example execute script when something is inside, etc. could save up much work sometimes.
Hitboxes - for checking collisions, two types of these - projecticle-only hitboxes and "fully material" ones.
Entrances - two types as well - one for clonks/etc. and second for objects flying in(like lorry)
Other - that for example execute script when something is inside, etc. could save up much work sometimes.
![](https://attach.openclonk.org/avatars/64-84632.png)
More or less the same applies to Objects - Hit() is already called b the engine, the same time when the engine decelerates the X/YDir - in this moment other actions can be possible.
That's just strange, you make it sound so easy... a balloon falling just as fast as a rock(@ maximum speed)? Or what do you even want to do in the engine?
![](https://attach.openclonk.org/avatars/185-9473.png)
> In an environment without air we would actually have a balloon falling as fast as a rock.
I am not stupid, you know? I am just saying that we either do it right, that means the whole concept: drag coefficients, object areas, which someone is going to solve for us in the 2D case (analytically prefered). Or we don't do it, cause this is not easy to implement.
![](https://attach.openclonk.org/avatars/185-9473.png)
> I am not stupid, you know?
Yes, I know. Sorry if my words looked like a doubt about your intelligence - I didn't mean it. Really.
> we either do it right ... Or we don't do it
My point is we should not. But if B_E thinks it is not that hard to implement we should consider his point as well.
![](https://attach.openclonk.org/avatars/185-9473.png)
![](https://attach.openclonk.org/avatars/64-84632.png)
![](https://attach.openclonk.org/avatars/185-9473.png)
1) gravitational force;
2) friction force (air/water resistance included);
3) support reation force if object is lying on the ground;
4) liquid ejection force if object is emerged in water/lava/acid;
5) elasticihty force if object is hanging on a rope;
6) impact force if object was thrown/kicked/shot;
7) rotational force if we put it THAT far...
And a whole bunch of other forces.
So if I was implementing ingame physics I would consider all these forces in resulting acceleration calculation (and yeah, it can not be done without vectors, because every force has a direction aside from value). So maybe it is good that I do not actually implement anything.
Do not get me wrong: I like the ideas you've posted at the beginning of the topic. But I do not think that their implementation worth the efforts I've stated above (in that question I totally agree with Maikel). If you want to impelement it simple way (like you already said), I am not going to stop or criticise you (not a chance). And I am definitely not the person who should share his thoughts concerning the ingame physics. (In fact I think that it was completely wrong for me to write anything in this thread in the first place). Sorry.
Let me just give an example, not a complete derivation.
Let's consider a lorry and a balloon, both of equal mass, 250 kg. You'd want the balloon to accelerate slower than the lorry, that is: you want more drag for the balloon, so you'd need more parameters than just a mass, at least something like an area. And that is just the simple case. If you want it somewhat realistic, you'd have to introduce at least 2 parameters per object, which describe the drag of the object in the x and the y direction. There are just so many objects with equal mass, but which should behave differently under air friction.
Let's consider a lorry and a balloon, both of equal mass, 250 kg. You'd want the balloon to accelerate slower than the lorry, that is: you want more drag for the balloon, so you'd need more parameters than just a mass, at least something like an area. And that is just the simple case. If you want it somewhat realistic, you'd have to introduce at least 2 parameters per object, which describe the drag of the object in the x and the y direction. There are just so many objects with equal mass, but which should behave differently under air friction.
![](https://attach.openclonk.org/avatars/64-84632.png)
![](https://attach.openclonk.org/avatars/1-0778.png)
To say it clearly: Mass doesn't play any role in how fast an object accelerates towards the earth.
![](https://attach.openclonk.org/avatars/64-84632.png)
![](https://attach.openclonk.org/avatars/126-5136.png)
![](https://attach.openclonk.org/avatars/64-84632.png)
Anyway, a maximum speed could depend on the material, rather than the object.
![](https://attach.openclonk.org/avatars/57-9339.png)
Dude, what happened to F = 1/2 *c * v^2 *a? a is a constant, v is a constant, the only think, you can change is c, which is the air resistance factor.
![](https://attach.openclonk.org/avatars/64-84632.png)
I personally am against concept of doing everything via scripts - sure. It's way more flexible, but in the end it just slows the whole thing down...
![](https://attach.openclonk.org/avatars/1-0778.png)
So, I'd say go for it.
![](https://attach.openclonk.org/avatars/29-2030.png)
On that note, we might actually give some materials like sand a non-infinite drag value. Objects that impact sand very fast could move into it a few pixels and cause a splash (just like water does now).
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill