I had some problems with the steering and put them over here to seperate it from the "variable jump height" topic.
These problems are:
-I recently played the game with two friends who haven't played it before. They meant it's quite fiddly sometimes to move the clonk throught the landscape. For example you get stuck on some small edges on the ground and you have to walk back and jump over it.
I made a video to show what I mean: https://youtu.be/EmlBRy89EYs
I guess the gap is too small for auto-scaling.
-Moving from left to right (and vice versa) feels sluggish. Yeah it makes sense but it doesn't feel that great to move the clonk.
-When I use the grappling hook and hang on a wall or ceiling and then fall off, the clonk doesn't grap the rope, unless you press up. That's annoying when you accidentally fall off. The clonk falls all the way down until the rope ends and you have to climb up again.
-While diving down, the vertices of the clonk are too high (or the graphic is too low ).
Sometimes it's hard to tell where you can dive.
>-I recently played the game with two friends who haven't played it before. They meant it's quite fiddly sometimes to move the clonk throught the landscape. For example you get stuck on some small edges on the ground and you have to walk back and jump over it.
>I made a video to show what I mean: https://youtu.be/EmlBRy89EYs
>I guess the gap is too small for auto-scaling.
This should be a bug report.
> -Moving from left to right (and vice versa) feels sluggish. Yeah it makes sense but it doesn't feel that great to move the clonk.
This is intended, we never tried to have a mario-like moving.
> -When I use the grappling hook and hang on a wall or ceiling and then fall off, the clonk doesn't grap the rope, unless you press up. That's annoying when you accidentally fall off. The clonk falls all the way down until the rope ends and you have to climb up again.
Also intended so that you can let go off walls and determine yourself when to catch the rope.
> -While diving down, the vertices of the clonk are too high (or the graphic is too low ).
>Sometimes it's hard to tell where you can dive.
Agreed, somehow not that easy to fix and quite a bit of fiddly work. I don't have the time or interest at moment to look at this another time.
>This is intended, we never tried to have a mario-like moving.
The controls feeling sluggish has been critizied quite often, though. So I don't think we should take that as a given if we had a 'better' alternative
> -While diving down, the vertices of the clonk are too high (or the graphic is too low ).
>Sometimes it's hard to tell where you can dive.
>Agreed, somehow not that easy to fix and quite a bit of fiddly work. I don't have the time or interest at moment to look at this another time.
While looking at the screenshot above, I just wondered why the vertices don't turn with the Clonk if he is swimming in another direction.
Is that because it comes from the animation and not from the object turning? If so, if the Clonk as an object would somewhat turn (like a lorry or tree) along with the animation, and the vertices would therefore move around, could that maybe fix those kind of stucks?
@the discussion: http://bugs.openclonk.org/view.php?id=1312
Trains in CP/CE/CR were good examples showing a lack of braking+acceleration effects since it was always so noticeable aprupt when the train started or stopped rolling. The braking effects from things that got fired away with a cannon or explosion are very cool, too. But the braking in all normal movements (speed<=20) of the controlled Clonk are forcing you to take less risks when moving though really hard landscapes you find e.g. in some heavily violated acid or Stimmelinsel scenarios. In OC, you will know that a point is easy to reach with a jump but you don't take the risk because you have to compensate the braking before landing after a jump. When landing on very tiny flying materials (2x2 pixels), it's best to have zero horizontal speed... And it is harder & more math to position an AI Clonk to a certain position, which means that the whole pathfinding is even less accurate.
>In OC, you will know that a point is easy to reach with a jump but you don't take the risk because you have to compensate the braking before landing after a jump
But that's a different thing. The acceleration is kept because you also might want to directly continue walking after a jump without stopping for a moment. That's also why instead of kneeling down and stopping (like in CR) you can hold the direction key and roll.
Hmm.. Are you sure that you continue moving even without the movement keys held down? If so, that might be pretty easy to change..
Edit:
It is easier to see when you set the Decel in the Clonk's ActMap to 4: Your Clonk will continue moving for several seconds after EVERY straight jump or full speed walk. The braking distance was only halfed from 8 to 4 back then. And the roll has no impact in this thing, but if you continue moving 4px after each roll as well btw.
But yeah, maybe we can really get a slight change of the movement controls for the next release to make it feel better (including the jump adjustments)
>But please never comment out code (in the main repository) to deactivate it. If you want to remove code and maybe later re-activate it, then that is what we have revision control for.
Yes, usually I am against deactivating code that way, because the usual situation is that you encounter a line in comments and you have no idea whether it is a temporary change that someone forgot activating again or what its purpose was.
In this case I thought that someone would unlikely look for a change in digging in the shovel, so I decided against simply replacing the code and instead added that comment and conditions when the change should be reverted.
Additionally, you have the confirmation (in the history) in the future if we decided keeping that change or not.p
With the same logic we could have kept ALL OTHER changes/removals as comments. Because we never know if the changes are good and if we need to revert things.
Because we sometimes need to track changes and sometimes need to revert trials, we are using a tool that allows us to do so: We can check for every line of code when and by whom it was changed the last time. And we can easily revert commits and keep the connection between the original commit and the reverting commit intact (because you can say X reverts commit Y).
So even if we decide to revert the changes, we would not go and remove the comment and create a new commit. We would just revert the old commit.
So it's not necessary for history and it doesn't help in reverting. It miiiight help people realize the change when they skim through the code. But even then: If you want to show that the digging speed was changed from cylclic to constant, then that would belong in a comment and not in code!
You could e.g. say "// The digging speed has been changed to constant after some discussion. Previously it was cylclic. Revert if necessary." above your line and have even MORE information with less clutter than when keeping the old code.
Additionally, commented-out code is not tested. It could be that someone changes e.g. a variable name that is used in the code and when you activate it again, it is broken.
So it doesn't help with clarity either.
>If you want to show that the digging speed was changed from cylclic to constant, then that would belong in a comment and not in code!
That is a better solution, yes.
>With the same logic we could have kept ALL OTHER changes/removals as comments.
>Would we do another change that solely removes the comment? When would we do that?
It seems you are exaggerating here. After all, I already agreed with you even in my first reply and declared it as an exception to what I normally do.
>Additionally, commented-out code is not tested. It could be that someone changes e.g. a variable name that is used in the code and when you activate it again, it is broken.
Indeed, and the same applies for code that is not even there, so after reverting changes you may have the same problem with your old code.
I just tried to explain the rationale behind using the VCS instead of commenting out the code.
Further reading, if interested:
https://blog.kentcdodds.com/please-don-t-commit-commented-out-code-53d0b5b26d5f
https://visualstudiomagazine.com/articles/2013/07/26/why-commenting-code-is-still-bad.aspx
https://softwareengineering.stackexchange.com/questions/45378/is-commented-out-code-really-always-bad
https://stackoverflow.com/questions/758279/checking-in-of-commented-out-code
Good example for when "temporary changes" stay in that state for seven years, because noone cares to remove such a commented-out code block
Also, I didn't know whether it was a temporary change (didn't want to comb through the history), so I left it alone.
A good place for examples for additional functionality would be a) the wiki b) the docs c) the forum d) an upload on the forum or even e) a github repos.
But I don't even know any more what the code was supposed to do
https://i.imgur.com/AXqoGDl.mp4
It just used to look very different and a little bit less like a bug. So it's just the visuals I am talking about.
Anyway, with either settings for speed I can create a situation where the clonk top vertex has contact with the landscape and the animations switch between "Dig" and "Jump". With any speed meaning: Before the first of my changes, and afterwards.
Regarding running and turning and the motion feeling sluggish, from the original complaint: I did not notice that, actually. Maybe I am too accustomed to the controls already?
>Regarding running and turning and the motion feeling sluggish, from the original complaint: I did not notice that, actually. Maybe I am too accustomed to the controls already?
I agree here and would think that the feel of the game would change a lot if we go mario-style. All the other movement changes are less influential on the game-feeling, but probably improve controls for most of us.
> I think in many occasions it is also good if you can't correct falling of a cliff any more, for example if you being chased by an enemy and you make a mistake because of the pressure. It is harder to evade attacks as well.
But if that really is so, that's a good example of something a player can easily get frustrated about. ("It would have been easy to jump-and-run up there, but the ยง&/(& controls are just so bad!")
>Regarding running and turning and the motion feeling sluggish, from the original complaint
I believe, when I noticed that, the game didn't run at full speed. It was a bit slower, so it felt sluggish. Kinda stupid, sorry. ^^'
Update: Done with this, too, but I kept it on my private branch for now because I am uncertain whether the implementation is good. https://github.com/gitMarky/openclonk/commit/930a3fe16b526639fabbf265a7cf5abd86f1e3a3
>When you enter the water while doing a head-first dive jump the clonk stops abruptly and turns upward. It would feel more naturally started from the diving animation instead.
I noticed that too and I agree.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill