It is possible to set the amount of resources to be extracted with an additional parameter in SetResource() now. The default amount to be extracted is 95 percent, which is the same behaviour as before the changes.
Deciphered what some of the functions are good for, since the original code is kind of cryptic. This should help again when expanding to diggable materials.
This messes up so many things as one could have expected. Instead we do the sensible thing and enable it only in the test scenario. For future reference all sequences involving an elevator and NPC clonks are broken with this feature.
The script now just sets visibility per player (VIS_Select) instead of creating one dummy object per player. It also uses the object directly instead of indirecting everything through an effect (the effect couldn't be used on other objects anyway).
..because the library wasn't actually USING the holding callback at all. And it had/has its own CON_Aim hackery anyway. No need for the control-library internal CON_Aim stuff then (I could imagine this might just lead to issues at some point).
Otherwise the situation could arise where you used a ControlUseStart object (the wallkit) but noholdingcallbacks was still set to true (because e.g. you used a hammer before). Then you would not be able to move the preview.
This is described in a comment to the referenced bug.
Which means that you can
1) Drag around the tree / nest in editor mode
2) Shoot zapnests that were put into a catapult by a scenario designer
3) Can RemoveObject a tree and the nest will fall down (instead of keep floating)
4) Can put zap nests in earth (just like in CR!)
Previously, it was checked incorrectly whether the action was "Dig". Then the check was thrown out completely in https://git.openclonk.org/openclonk.git/commit/39e86474fccbd54eb357175d2b8fbec5c60639ab - which did remove the warning but not solve the defect.
This should be a proper fix. The shovel only does stuff when the user is digging AND actually using this very shovel for it.
"menu" is an error prone name in one of the most frequently used/overloaded objects of the planet. Actually, there was a bug in some other thing which disappeared now. So I guess something, somewhere uses the name "menu", too.
Anyway, this is more consistent (because the other control stuff is in this.control, too) and less error prone. So it's a good change regardless of whether it actually fixes an existing bug.