The musket was not a very popular and useful weapon, being inferior to the bow. It now shoots 5 weaker bullets in one shot with less damage per bullet, this might require some further testing and fine-tuning. Also the weaker bullets mean that they can be used in a gatling-gun (WIP) and in the airplane as well.
The problem occurred as soon as the clonk's leg vertices passed the edge. It seems the engine does not really align the bottom vertex to the material. However, the bottom vertex does have CNAT_Bottom & _Left & _Right, in theory it should be properly attached. Maybe this is a little bit broken engine-wise or maybe assigning both left and right to a vertex isn't supported?
Because the lower vertex (foot vertex) isn't attached, the clonk falls down onto its leg vertex and gets stuck in an endless loop of Scale, Jump, Walk, Scale, ...
When pressing left/right, this is no problem as the clonk will be pushed towards the edge when walking and soon touch it with its foot vertex (I assume at this point regular engine behaviour kicks in).
I added a little helper in the scale effect that sets COMD_UpLeft / UpRight whenever this situation is detected and only Up is pressed. 2 frames (1 is not enough) after the effect ended, the ComDir will reset to COMD_Up. It is then possible to climb an edge and stand still on top of it.
Maybe not a perfect solution (a perfect solution would probably be to fix attachment in the engine but I couldn't pinpoint the exact problem) but it works for now.
I deserialised the skeleton file and removed some bone positions that I guess were wrongfully included because they concerned the left (non-carrying) arm. I think I didn't break anything but if so, this patch is to be reverted.
Conflicts will be merged in the next commit:
planet/Objects.ocd/Items.ocd/Tools.ocd/Pipe.ocd/PipeLine.ocd/Script.c
planet/Objects.ocd/Items.ocd/Tools.ocd/Pipe.ocd/Script.c
The previous name suggested that the object actually gets put into another object. In fact it merges the stack count with other stacks, and it does not only try to (and reverts the state if it fails), but it actually changes other objects even if the function returns false.
The interaction with IsContainer objects is still flawed in a way: when a lorry is inside a (IsContainer-)hut, you can take the lorry into your hands. Since we don't have that possibility in the normal game, I leave it unchanged for now.
However, it is now possible to add a Chest (or a cupboard!) into a WoodenCabin and then store stuff inside of it.
It's a bit quiet, but I guess that's not really a problem. It's also out of sync with the arm movement, but it's all I got (and it's so quiet you don't notice it anyway!).
The error rarely happened when the clonk was attached to a wall solely with its head vertex. CheckScaleTop (Animations.ocd/Script.c) only checked the shoulders and hip vertices.
I also made sure that this.dist (FxIntScaleTimer, line 616) cannot exceed the animation length of "ScaleTop" although that shouldn't have posed a problem.
This doesn't work for intros, though, because they use simple messages. We should unify the systems to only have one dialogue system that uses new-style-menus and implement required features in those menus..
Also move all object sounds to global Sound.ocg so they are still played.
This is to prevent naming collisions. All sounds are moved because otherwise all scripts would have to be adjusted. Also, the distinction between sounds in definitions and sounds in Sound.ocg was rather arbitrary.
It will also ensure most sounds are reloaded when sound is turned off temporarily, although that should better be fixed properly.
Objects that prevent interaction just in some situations (hostility, dead Clonks, ..) should always be shown in the interaction menu (because otherwise players might suspect bugs) and TELL the player WHY they want no interaction.
For that, they might need to specify own error messages.
Known issues:
* The "OnOpen" callback is done even if interaction is disallowed, however just simply removing the callback might not be sufficient, because we might get a callback disbalance if objects change their attitude while the menu is opened and the menu is closed again.
* Some objects (which should) do not include the Library_Ownable. However, we have no base melees atm and since this might introduce new errors, postpone it to 8.0.
Previously, you would roll on landing when you had a movement key pressed. However, you would roll into your current direction even if you had the opposite movement key held down. This was one of the remaining possibilities of rolling into the void and being frustrated afterwards because the controls sucked.
Sven Eberhardt