![[de]](/mwf/flags/de.png "Germany")
After digging through the movement code, I think that some of the "weirdness" in object movement (most of the times it behaves OK, but sometimes it is really strange) comes from the fact that objects move horizontally first. So, if an object has xdir 100 and ydir 100, it will try to move 10 pixels to the right first, stopping if there are any collisions, and only then it goes down. Looking at this I am surprised that diagonal movement (jumping, thrown objects) work well in our game :D, but of course the velocities from jumping and throwing are usually so low that the effect may not be as noticeable.
After the pull request I *might* want to try a branch that has a different motion strategy, with the following conditions:
* it is really just experimental, so I will not be surprised if we decide to not change that
* it may change the behavior of objects significantly, maybe breaking existing "veteran tricks" or even existing scenarios that rely on the current behavior
* it needs a good testing scenario that contains some typical movement patterns from the game, as well as the special cases here. This can and should be done before creating the branch, though :)
What are your opinions?
Edit: Moving horizontally first may have something to do with the gravity movement, just a note for myself.
After the pull request I *might* want to try a branch that has a different motion strategy, with the following conditions:
* it is really just experimental, so I will not be surprised if we decide to not change that
* it may change the behavior of objects significantly, maybe breaking existing "veteran tricks" or even existing scenarios that rely on the current behavior
* it needs a good testing scenario that contains some typical movement patterns from the game, as well as the special cases here. This can and should be done before creating the branch, though :)
What are your opinions?
Edit: Moving horizontally first may have something to do with the gravity movement, just a note for myself.
Yes, please! I definitely think it's a good idea to revisit the movement code.That's one of the main points that are basically always criticized in reviews (getting stuck on edges, awkward walking/scaling transitions, ...). So I definitely think it's worth a try :)
>it needs a good testing scenario
Another important factor here is the performance. Doing "better" movement probably means doing more work. Unfortunately, we currently don't have any benchmarks, so this is really just a potential issue to keep in mind. However, people are already complaining sometimes that the game is running too slow and then we have no idea why.
![[jp]](/mwf/flags/jp.png "Japan")
Wasn't the reason for that movement behaviour that sideways movement is directed upwards if it hits a wall, or so? It's been quite a while since I dug through that code, but I thought it somehow made sense…
Did a significant change, in the benchmarks the code runs at roughly the same FPS (+/- 1, which I think is just the average noise I assume). Differences:
- in Tests.ocf/Movement.ocs the motion with very high velocity ends up in the corner, as does the motion with low velocity. Downside: The Clonk starts tumbling, because it still hits the landscape (although realistically should not)
- in Tests.ocf/Movement.ocs the rock does not fly around as much
You can try it out yourself with the code here: https://github.com/gitMarky/openclonk/tree/movement
High velocities are handled poorly in the engine, though: When you move a Clonk with SetSpeed(1000, -1000) while flying, the ydir will decrease to 0 due to friction from hitting a ceiling very slowly, and the Clonk just sticks there for a few seconds. My expectation is that the Clonk would stop and fall down immediately, however I have no *good* solution for that. The only solution I have is set the velocity to 0, but that would stop things on every little contact with the landscape.
- in Tests.ocf/Movement.ocs the motion with very high velocity ends up in the corner, as does the motion with low velocity. Downside: The Clonk starts tumbling, because it still hits the landscape (although realistically should not)
- in Tests.ocf/Movement.ocs the rock does not fly around as much
You can try it out yourself with the code here: https://github.com/gitMarky/openclonk/tree/movement
High velocities are handled poorly in the engine, though: When you move a Clonk with SetSpeed(1000, -1000) while flying, the ydir will decrease to 0 due to friction from hitting a ceiling very slowly, and the Clonk just sticks there for a few seconds. My expectation is that the Clonk would stop and fall down immediately, however I have no *good* solution for that. The only solution I have is set the velocity to 0, but that would stop things on every little contact with the landscape.
>You can try it out yourself with the code here
You could also push the branch to the main repository, then we'd get snapshots for it!
![[gb]](/mwf/flags/gb.png "United Kingdom")
Did that, the branch
movement_changes is my latest version of the movement code. It makes some stuff more unified, but it is not optimal. Benchmarks run at about the same speed as before, there are no significant performance changes on my notebook. I'll be glad for a review and testing, of course.
So, did anyone test it? For me it looks okay, and I'd like to continue working on that one, but I do not want to base further work on it if it gets rejected. It is one of the bolder changes, but not really new.
I did some testing now, just playing around with regular objects in the game (catapult, cannon). Couldn't spot any wrong behaviour but was also unable to see any improvements. Are there specific things that work better after your changes?
There is a test in Tests.ocf\Movements.ocs: If you launch an object with say xdir = 1000, ydir = 1000 down a tunnel (that has the same angle) and the path is free, then the object will move down that tunnel. On the master branch the object will first try to move 100 pixels to the right, then hit a wall, and tumble right away. It is an edge case really, but it should make projectiles that rely on our ingame physics behave better. Collisions with the walls may behave differently, though, meaning: less sliding all over the place.
Yeah, I started the test, it did 3 out of 4 (and then failed) but there isn't much to see. We don't really encounter the situation you described but if it works better now then I don't see a problem with merging your changes.
>We don't really encounter the situation you described but if it works better now then I don't see a problem with merging your changes.
I encountered that every time I made fast moving proectiles in Clonk (first time for CR Caedes in 2005) - and I always just wrote my own physics by hand. Maybe it makes a change for musket shots (if they even use the normal movement logic)
Yeah, I'm sure some whacky 3rd party mods will benefit from the change.
Yes, if you compare the behaviour with the master branch, then you'll notice the difference: On master the high velocity launched clonk will tumble, but the rock will pass and jump over that wall and land on the other side. On the changed branch, the rock does not jump over that wall, therefore the test fails. Personally I do not mind that, but it could mean that some scenarios that rely on particularly this behaviour may break.
Okay, I do have one complaint. Duplicating objects in the editor crashes with your changes. :(
It's probably https://github.com/openclonk/openclonk/pull/102
Still trying out various things with the movement code - I'll sum up the insights here. Some of them are pretty obvious, but it may help understand things:
* The movement distinguishes between attached movement (walking, climbing) and free movement (anything else that just sits in the landscape (lorry, chopped tree, rocks).
* During free movement the velocity of the object is redirected between components, and the logic is as follows: Move horizontally first, if you get contact redirect the horizontal velocity upwards. Move vertically with the adjusted velocity. If you hit the landscape again redirect the velocity sideways, etc. This is important, so that objects can be pushed over small bumps in the landscape, but it also causes really strange things, such as fast rocks flying upwards, etc.
* The movement distinguishes between attached movement (walking, climbing) and free movement (anything else that just sits in the landscape (lorry, chopped tree, rocks).
* During free movement the velocity of the object is redirected between components, and the logic is as follows: Move horizontally first, if you get contact redirect the horizontal velocity upwards. Move vertically with the adjusted velocity. If you hit the landscape again redirect the velocity sideways, etc. This is important, so that objects can be pushed over small bumps in the landscape, but it also causes really strange things, such as fast rocks flying upwards, etc.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
