![[de]](/mwf/flags/de.png "Germany")
I plan to make the clonk more flexible, more J&R like: The clonk should accelerate slower (and stop a little slower), all with the adequate animations. I intend to edit the engine source at the WALK procedure for that. Can you tell me where it is?Jump will not be limited to a 45° jump but depends on the current speed - in full running speed, the jump will be more horizontal, while standing it will be vertical. It should be possible to control the movement during the jump a little (like Mario or any other J&R). How little (or much) is subject to testing. Again I intend to directly do that in the engine (FLIGHT procedure). Comments? The clonk will be able to throw in any direction (already implemented) and also while (riding,) jumping, perhaps while scaling and hangling too. This is not implemented yet - it's just one line but I'd like to have an animation for that.
Using will be possible in any direction and actually is already implemented too. It's just that there are no objects yet which use the use-functionality. Which brings me to the shovel - it is currently not working with pressing down the LMB and probably the next object that should be taken care of. Any takers?
Other less important improvemetns that I have in mind are mainly graphical and since Randrian didn't post the model yet, I'll write that later.
The inventory management of the clonk plus the inventory HUD is still incomplete. Clonkonaut told me, that he will not time for that anytime soon. Apart from the simple clickable display of the objects in inventory, the empty spaces in the clonks inventory (e.g. [Bow] [nothing] [Rock]) needs to be managed. One solution is to automatically create and delete placeholder inventory objects but the better solution would be probably just an array ([0] bow, [1] nil, [2] Rock). Again, any takers?
Modellers, animators: For the new controls, it'd be sweet to have a (updated) clonk model with various more animations. I'll list my wishlist
Sven:
Currently not working are pushenter.
Mouse1WheelUp/Down do not exist. How can I use the mouse wheel as buttons?
As soon as the basic controls work, I'd like to move on to Drag&Drop and gamepad control. Regarding gamepad control, I have an idea how I could implement this without any engine changes. The Drag&Drop we need to think about - I imagine that C4D_HUD (or C4D_Gui) gets the D&D callbacks as well as (somehow) the contents-menu and script-menus (that were created by CreateMenu).
Other bugs:
The crew hud to the top should normally show the rank symbol but it doesn't. It seems SetGraphics is currently broken with the GFXOV_MODE_Action.
>For example animations for throwing while jumping, scaling, (hangling?) would be sweet.
that would scale the amount of work to O(2^N), I think you should use the mesh branch where you can have seperate models for each part of the body (trousers vs arms+body vs head - like we did in *** (sorry for using the bad word ;) ))
I had some problems when you talked about the acceleration. The first Versions of *** had such walk physics, but it was feeling like the Clonk was slicing over the ground - you had no complete control and the gameplay would slow down. I would prefer a "run"-Button and when you press the button on and on the Clonk can run faster but getting out of breath and is not able to throw etc.
>that would scale the amount of work to O(2^N), I think you should use the mesh branch where you can have seperate models for each part of the body (trousers vs arms+body vs head - like we did in *** (sorry for using the bad word ;) ))
It is planned that at least the upper and lower body are (at least in some animations) animated with different actions
I think after the plrctrl branch has been merged into default, work with more refined animations and actions can continue on the mesh branch(?) Otherwise, we need a intermediate solution (which should not be too much work - upper and lower body stuff would boil down to the usage of two layers, no?)
>upper and lower body stuff would boil down to the usage of two layers, no?)
Once we have a model for the Clonk everything will become easier. We could merge two animations (one for the upper- and one for the lower body) into one animation easily then (http://forum.openclonk.org/topic_show.pl?pid=3801#pid3801).
With the current system we would need one additional layer, though
>intermediate solution
!!!
Keep in mind that these "two merged animations" are not even implemented in the mesh branch.
>Keep in mind that these "two merged animations" are not even implemented in the mesh branch.
I am still hopeful :)
Solutions with additional layers always require some (quite some) extra work and maintenance. I think a better intermediate solution would be without another action at all (and keep hoping for ck to implement that action-merging-stuff :) )
>*** (sorry for using the bad word ;)
That I told you the other time that your references to gwX appeared a little arrogant has nothing to do with the name of the project. I didn't intend to keep you from talking about gwX or spelling out it's name in the future. My sole purpose was to give you feedback how you appeared (to me) in that discussion because you might not have noticed it.
>that would scale the amount of work to O(2^N)
What do you mean?
It means that with every new pose you want to combine with the old poses, you have the double ammount of clonks to draw and the double ammount of definitions in the ActMap (i know it has a new name...)
2^N is not exactly the factor because you need no animation with shooting while swimming or climbing while tumbling (but it would nice to have)
I would prefer a ragdoll physics like soldat has.
the only thing you have to implement are joints, that means that you can attach two objects at a shared position and the objects can rotate against each other.
So you can move the arm separately from the foot and tumbling and falling down would be ultra-realistic.
I hereby license the following file(s) under the CC-by license
2^N is not exactly the factor because you need no animation with shooting while swimming or climbing while tumbling (but it would nice to have)
I would prefer a ragdoll physics like soldat has.
the only thing you have to implement are joints, that means that you can attach two objects at a shared position and the objects can rotate against each other.
So you can move the arm separately from the foot and tumbling and falling down would be ultra-realistic.
I hereby license the following file(s) under the CC-by license
> I intend to edit the engine source at the WALK procedure for that. Can you tell me where it is?
C4Object::ExecAction.
> It seems SetGraphics is currently broken with the GFXOV_MODE_Action.
You're using PlrCtrl, I guess? Merge default, we've had a fix there for two weeks. (Edit: You know it was you who filed that bug report, right?)
> It should be possible to control the movement during the jump a little (like Mario or any other J&R).
Uuah. I know, gameplay > physics. But I dunno why, I always disliked that. On one hand side, Hazard agility is an enrichment in gameplay. On the other hand side, it is hard to hit someone with arrows over distance or thrown objects already.
>I intend to edit the engine source at the WALK procedure for that.
And SCALE and HANGLE? Will they have the same behavior?
>in full running speed, the jump will be more horizontal,
Care: A 45° jump goes furthest. It would be annoying to have to stop some pixels before a cliff to do the best jump. (Okay, this is actually what you do in real life, the last step before the jump is shorter, but again ggp.)
![[ca]](/mwf/flags/ca.png "Canada")
Well, since bows will be aimed with a cursor it's well likely to be a lot easier to shoot objects farther away.Also, if someone is sprinting they'll have more power when they jump. So even though the angle of the jump is more acute, it will go farther than a weaker powered 45 degree jump. Possibly the longer you hold down jump, the more power you will have; if you are running you could get more power than possible when still.
I mainly posted this to win over some interested an able people to help me do this. The control of the clonk and how it "feels" is an important part of the gameplay and involves a lot of testing (out new control possibilities) and adjusting. Apart from modellers/animators, I need at least one guy who would like to work with me on that (on the c4script side) - and has some own motivation and ideas how the clonk control could be made more fun. And with someone, I mean at least Zapper! How about you, would you like to work with me on the redesign of the clonk control? :P
I am currently completing the (basic) HUD, new controls and next going to rework the digging with the shovel plus a test object for using (possibly some kind of early version of the bow).To disable the previous hud, I just commented out the call to the function that draws the cursor info. Question: Should the portraits, the ranks and the inventory-drawing completely be removed?
I plan to completely remove the inventory-drawing - perhaps some additional (SetGraphics-)functionality is needed to still be able to show the possibly color modulated and graphics modulated (SetGraphics) picture of the object via script(?). Additionally, at the moment it is not possible to get the rank names of the clonk. If the name should be shown in the new HUD, there needs to be a function for that (with the remark that stupid use of the function would cause desync - but this already applies for GetName).
I do not plan to use Portraits at all in the new HUD and there is no other place they are used in the game. So to remove the portrait system completely seems in order. However it is such a big thing that I do not want to do it without feedback.
You can show a color modulated version of the picture using SetGraphics (picture overlay mode). Graphics modulation - i.e. masking - is not possible yet, but it would be a very useful engine feature.
>Currently not working are enter/exit and jump. I didn't test grab/push/enter.
Too bad.
Another thing that is not working how it should yet:The controls for the keys that are hold down are executed in another function (Execute) than other controls (that are executed from DoMouseInput). I don't want to make any changes there because I don't feel proficient with the controls and network syncing code. Anyway, the extradata of a repeated (hold) key does not change, meaning that the mouse position of a hold down mouse button remains the same as the one when the button was pressed. This is not desirable. However, I read a comment from Sven2 that indicated that the whole extradata-thing is a little of a hack anyway and he wants to rework that part anyway. Still, I want to mention this bug (or missing feature) here. Plus, I don't know when Sven2 has a workin computer for Clonk + time again.
So if another one feels able to fix that, would be great.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
