![[de]](/mwf/flags/de.png "Germany")
Can someone give an overview of the changes that are caused by the merge of the controls branch? I have two projects that override the controls, and the merge has caused some errors.
For example, one project object graphics attached to the right hand bone of the Clonk. These are not rotated properly since I use the controls branch. Also, the right mouse button seems to work as a throw-button now. How can I (easily) restore the old functionality of alt-using the object? I want to.
For example, one project object graphics attached to the right hand bone of the Clonk. These are not rotated properly since I use the controls branch. Also, the right mouse button seems to work as a throw-button now. How can I (easily) restore the old functionality of alt-using the object? I want to.
![[us]](/mwf/flags/us.png "United States")
I have just implemented a callback ControlThrow that gets called before the clonk does any throw activities (even before checking RejectDeparture). The easiest solution would be to use that.However, if the player remaps his controls to have throw on another key (e.g. a keyboard key), ControlThrow will also be on that key. If you want to guarantee that your alternate action is on right-click, you should just define your own control, give it a higher priority than throw and use that for your custom object activation.
About the incorrect bone transformation I suggest you open a bug tracker entry. Transformation is sometimes wrong on the primary hand as well (e.g. try carrying a bucket).
Somehow overriding the existing priorities did not work. I copied PlayerControls.txt to my project specific System.ocg folder and deleted everything but the [ControlSets] definition and the assignments for Throw and UseAlt. Then I switched the priorities, but it did not work.
What worked though was overriding ObjectControl in the Clonk control library.
What worked though was overriding ObjectControl in the Clonk control library.
>These are not rotated properly since I use the controls branch
That was ck's doing, see here
>Also, the right mouse button seems to work as a throw-button now. How can I (easily) restore the old functionality of alt-using the object? I want to.
Mh, I guess I can re-implement that similar to how it was before. It seems to be a sensible feature request
>Mh, I guess I can re-implement that similar to how it was before. It seems to be a sensible feature request
Does it maybe make sense to write that into a separate library or as an appendto, I don't see a reason to clutter the main content with alternatives which are use outside the main content.
ask Sven what he thinks about libraries and overwriting callbacks and bad interfaces
Can we have his opinion somewhere in the wiki or in a sticky? I know that it was useful advice, but I forgot some of it :/ It was something along the lines that you would not notice that your override no longer is called if the library programmer changes the callback.
What I mean right now is something related to the controls libraries. All five control libraries (ClonkControl, ClonkGamepadControl, ClonkInventoryControl, CarryHeavyControl, [Inventory], [CarryHeavy], [Clonk], [Clonk_Animation]) are still quite intertwined, even though I already decoupled a lot and split them up (originally they were one library).It is entirely possible that you cannot use one without the other and that the order in which you include them matters. That is not especially clean library design - but they are also not really libraries. They are scripts, split up for better clarity (instead of having one 3000 lines file).
It's on my todo™ to improve that situation.
On a more serious note, adding that functionality to the "normal" Controls library would really just require a few additions in the right places (f.e. an if (ctrl == CON_Use) would become if (ctrl == CON_Use || ctrl == Con_UseAlt)).Adding that as an additional library would either require one more abstraction layer around the mouse control stuff (which would also clutter the normal library) oooor some really, really ugly hacks. I am not really in favour of either.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
