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.
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.
- 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!
movement_changesis 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.
>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)
* 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